With the investment and attention in the past few years, domestic open source communities have sprung up like mushrooms after rain. Today, the new AI forces headed by GPT have taken over the baton of topicality. We can review the achievements of the domestic open source communities that have emerged in the past few years in the cooling cycle, and what common problems can be improved. .
The title of this article is that the operation of domestic open source communities always has a peculiar style of painting, which is also in line with the mainstream feelings of software developers who are the main participants in theoretical open source communities in recent years. From dazzling open source marketing, to alternative innovations of one-time open source and switchable open source, to the involution and fighting of homogeneous open source... All these are not only very different from the open source movement driven by the hacker spirit that developers are familiar with. It is difficult to say that the open source policy has achieved the goal of digital technology innovation.
Support the development of innovation consortia such as digital technology open source communities, improve open source intellectual property and legal systems, and encourage enterprises to open software source codes, hardware designs, and application services.
"The Fourteenth Five-Year Plan for National Economic and Social Development of the People's Republic of China and Outline of Long-term Goals for 2035"
From the perspective of the construction and operation of the open source community, I think the main reasons for this situation are divided into three aspects: the problem of operating personnel, the problem of core team developers, and the fundamental problem of software product strength.
The problems of the operators mainly come from the use of consumer-oriented (2C, to customer) novice marketing thinking to do developer-oriented (2D, to developer) open source community operations.
It should be said that the objects of operation from 2C to 2D are all for individuals, and can be considered as some form of user operation: consumers are users of platforms or end products, and open source developers are mainly users of open source software. In terms of high-level user operation strategies, both of them need to sort out portraits around user groups, understand needs, and use resources to give users timely feedback, so that users can spend more time in your community and create the value you expect.
However, the consumer products that drive 2C operations usually have a short sales cycle and low threshold, which leads to the optimal strategy for 2C operations is novice marketing, that is, treating users as novice, only in terms of region, age, Distinguish between attributes such as gender and occupation, use quick feedback activities to stimulate users' immediate desires, earn the traffic required by the platform or sell products, that is, impulsive consumption.
A typical example is local push marketing where small gifts are exchanged for attention on the street. For example, a new delivery supermarket was built in a residential area. By hiring a group of pushers without any background requirements, they can distribute leaflets in places with heavy traffic, follow the supermarket’s official account or download an app to receive a few yuan in vouchers or small shopping malls. Gift. Basically, there is no need to distinguish the target group. People who can walk on the street are potential users of the supermarket.
Is this style of painting a bit familiar?
When the concept of open source operation was hot, many companies recruited operators for their own open source communities to operate users in the same way.
OceanBase likes and gives gifts
TDengine's Pest Control Program
Both of these examples aroused strong dislike from developers.
How to evaluate Ali OceanBase GitHub like gift? [1]
Developer Experience Anti-Pattern: Market-led Operations [2]
Open source operations should be discussed regardless of track record [3]
Developers are not happy to see such activities, not because they cannot give small gifts, nor because of the "original sin" of operations, but because these activities that use corporate resources to grab the attention of developers violate the common sense of software development.
For the case of OceanBase "like" gifts, stars are used by some developers on the GitHub platform as an auxiliary indicator for selecting open source software libraries, because the natural growth of stars basically comes from users' active praise and secondary dissemination. Star is not a key indicator for developers to adopt a software. The software has been verified by themselves or others, and a reproducible usage plan is the decisive advantage. star means that users actively praise it, and it is a weakly relevant reference that the software has been verified. OceanBase's "Like" gift-giving activities will not have a large-scale impact, but it will only destroy the original value of its own star count.
As for interpreting any form of star growth as the growth of the community size, it is nonsense. The behavior behind star is just a simple click action without any threshold. A person who has received a supermarket flyer can become a supermarket consumer without any training. But a person who joins in the fun to "like" the code warehouse has no reason to further participate. In fact, due to well-known reasons and the inherent niche characteristics of software development, even if it depends on the goal of increasing stars, such promotional activities will not even bring more than 1k new stars to OceanBase. Moreover, with OceanBase's large factory background, technical strength and production practice, it is basically unnecessary and unlikely to achieve the goal of increasing awareness by deliberately increasing stars.
For TDengine's pest control plan, this issue is a little more subtle. Because it seems to be related to writing code, and it seems to have created value for the development of open source software. Isn't such an activity worth promoting? At that time, the operators of OceanBase felt that it could be promoted, and they also engaged in a wave of re-engraving:
Homogenous Activities of OceanBase
Regarding these activities, @Xuanwo's comments in "Open Source Operations Should Be Discussed Regardless of Mind" represent the main views of open source developers:
We need to look at the value created by the event, not the motivation of the event organizer.
Are pest control activities worthwhile? Yes, but only a little bit. Compared with the cost of maintainers spending time to find typo, the value of this activity may be negative.
The projects of GSoC and other activities are all actual needs, and the projects need to be equipped with a mentor, and contributors can get full guidance from the mentor. By participating in the GSoC project, open source projects can address some long-term needs, and contributors can gain insight into an open source community and make their own contributions.
When I participated in the TiDB community, I also initiated a similar low-threshold work Tracking issue for restructure tests[4] to migrate existing tests to an IDE integration-friendly framework. After I have completed some key tool functions and interface development, most of the work is relatively mechanical translation.
The difference between this issue and the above activities is that it comes from actual needs, and the development method conforms to the common sense of software engineering. When I first found out that it couldn't run on GoLand, I felt that the selection of test framework should be optimized. After @disksing successfully migrated PD's test framework from PingCAP fork's check to testify, and also in the TiDB community, I saw two or three newcomers who had the same idea expressed their opinions on the lack of IDE integration. I started to promote this work.
The experience of tracking multiple subtasks in this issue was later spread to many other projects, and also inspired other code contributions in the process of guiding participants to disenchant the TiDB code. However, since the development threshold of TiDB core code is still not low, in the end I remember an example of not becoming a TiDB core developer through this issue.
TiDB has also done linter-related work, but the method is to use automated tools to scan modules one by one, instead of manually seeing one and writing an issue like TDengine or OceanBase and waiting for "external" developers to fix it. Too efficient affects digital growth.
Make some linters really happy[5]
Make linter facter by enabling bazel nogo to implement fast incremental linter[6]
For typo issues, the Rust community has a typos [7] tool that automatically scans, reports, and fixes them. It has been heavily used in Databend's project group, and it can basically eradicate typo problems.
In addition, there is another difference between the tasks mentioned above and the negative examples listed above, that is, developers can recognize that these tasks are chores, that is, chores. In addition to the value of discussion on issue organization and tool framework selection and development, developers seldom market specific chores, and in negative examples, the object of marketing is the chores themselves. It's no wonder that developers are so unimpressed by such prioritization-inversion marketing.
Due to the limitations of the text, there are other existing problems and solutions to these problems. This article will not expand them, but here is a simple list.
For developer-oriented operations, overseas industry practices are relatively rich. They have created concepts and concepts such as Developer Relationship (DevRel), Developer Experience (DX) and Community Evangelist. Position.
Text and rich text materials worth referring to in this regard are:
"The Art of Community Operation" [8]
《People Powered》[9]
YouTube channel of Jono Bacon, author of the above two books [10]
"Developer Relations: Methods and Practices" [11]
Developer Experience at Vercel[12]
Among them, "Developer Relations" is the preferred reading material that is most in line with the background of operators. It will discuss the portraits, segments and journeys of developer user groups, as well as how to formulate and successfully implement developer relationship strategies in enterprises.
Different from the one-pot recruitment requirements of domestic open source operations, a well-divided open source community team is roughly composed of the following types of roles:
The manager of the community team formulates community strategies and growth goals.
Operations specialists plan and organize events or games and are responsible for venue and material coordination.
Content experts formulate content strategies and implement them on the basis of community strategies.
DevRel experts are responsible for technical presentations, record the evolution of participation and feedback, follow up with high-potential developers, and tap opinion leaders.
In addition, if you can still find the corresponding talents, you will consider doing course development and following up user scenarios to transform potential business opportunities.
It is worth mentioning that content experts formulate content strategies, and producing and disseminating specific technical content is a very challenging job. You can refer to the design and implementation of the website "Cultivation and Development of English Technical Documentation Engineers" by StreamNative Documentation Engineer Sherlock .
Finally, the experience of operating domestic open source communities has the following reference materials:
From technical director to open source community operation: What have I done in the past two years?
"From Three to Ten Thousand", the Way to Rapid Growth of 2B Users"
It is worth noting that practitioners who operate open source communities among companies that sell software products or provide technical services can easily blur the difference between 2B (to business) and 2D. These articles discuss how to deal with user developers and how to produce high-quality content are worth referring to. For the understanding of 2B and 2D, it is recommended to add Chapter 8 of "Developer Relations" for comparison and understanding.
The so-called open source community is a community formed around a specific open source software. Software is not static, but iterative in response to requirements. The members who lead and complete this iterative process are the developers. Therefore, developers are the main participants in the open source community and the core productivity.
The domestic open source communities initiated by enterprises and the problems of operational deformation caused by developers are almost all caused by the lack of an open source strategy and the stress response of being forced to open source suddenly under the guidance of the theory.
Many companies decide to open source a certain internal system, but in fact it is just a follow-up behavior, without an open source strategy or experience: open source code is an end in itself.
At this time, as a front-line R&D personnel or grassroots R&D supervisor working on this system, I was suddenly told that the code warehouse that I deal with every day and submit changes will be open source. The subconscious self-protection strategy is Open Source Code Only - open source code is Is the source code released publicly under an open source license? Hit Publish... well done! As for R&D plans and development processes, what does this have to do with open source? Didn't I already open source it? These can be done as usual.
Therefore, what the enterprise open source is a code warehouse image of the internal system. This is actually understandable. After all, as long as the source code is complete, opening it up for everyone to read is a social contribution. There is no saying that companies must fully disclose the process of software development and the content of design discussions.
However, the effect expected by enterprises and even decision-makers in their hearts is not simply open source code, what they want is "co-construction". Although I have already criticized the ambiguity and whimsicality of this statement in "The Myth of Co-construction", for the time being, let's take it literally and understand the requirements of realizing "co-construction" in a collaborative way common in open source communities .
Right off the bat, you'll see that shared workflows are a must. If there is no unified development process, at least the mainline process, then even senior developers will not be able to participate further without necessary information and sufficient discussions. I mentioned this point of view at the beginning of "How Enterprises Practice Open Source Collaboration" , and discussed in detail with the four projects OceanBase, Apache InLong, TiDB and Taichi as cases.
The biggest leverage that the open source community can bring to the enterprise comes from developers with certain development capabilities and experience. Based on the premise of accessing the source code, the unrealized requirements, compatibility issues, and ease of use encountered by the software in specific scenarios Do in-place customization for sexual issues, and then feed back these customizations to the upstream, so that you don't need to repeat secondary development when using the new version of the upstream software. If it is a problem that cannot be customized and solved on the spot, the developer can do some basic debugging and report a clearer problem because of the access to the source code. Based on the same source code and unified development workflow, developers from different organizations can communicate in the same context and jointly promote problem solving.
For an open source community initiated by an enterprise, the initial developers must be employees of the enterprise. If the employees of the enterprise fail to take the lead in implementing this open workflow approach, it is even less likely that developers outside the enterprise will push the community in this direction. In the end, the community is still a lifeless platform with only mirror codes, without any vitality.
One of the most basic indicators to measure whether the upstream of an open source community has an open workflow is to observe whether it has a good development environment configuration experience [13] . Because of all open source collaboration based on source code, at least developers must be able to build their own development environment, be able to run through basic use cases and run unit tests. Otherwise, any changes are text editing and debugging in the brain, which is not impossible, but the threshold is very high. And it is an unnecessary threshold. Even people with this ability can see that the workflow is unreasonable, and they are unwilling to waste this time doing unnecessary efforts.
Finally, let's dig deeper into why this developer's self-protection Open Source Code Only strategy rarely appears in the open source project community initiated by individuals.
The direct reason is that individual developers often do not have the motivation and energy to build another set of workflows. These projects are often built in the public space with a common tool chain from the beginning. There is no two sets of internal and external workflows, so it is naturally "open source throughout the process".
The deep-seated reason is to explore why individual developers are more likely to accept open source collaborative development methods. This is because project authors often attract participants by developing high-quality software and strong ownership. Project authors are usually grateful to developers who can help them. For the problems and patches submitted by other developers, since the core function design and implementation of the software are completed by themselves, usually the project author can make accurate judgments, and has enough credit to make decisions, so he will not feel constrained by others during the collaboration process .
In contrast, the situation of enterprise open source. The software that can be selected as open source by enterprises is somewhat powerful. Under the current R&D promotion system, the first authors of these softwares have basically been promoted, otherwise they would rely on this achievement to change jobs with high salaries: they would not participate in the software open source community. The employees who will actually be assigned to handle the work of the open source community often do not have enough credit to make decisions. At least when most R&D teams do not care about the open source community at all, it is difficult for them to explain why an open source collaboration requirement requires other "internal "Developers are also aware of and cooperating with changing ways of working.
Therefore, these assigned employees can only handle the simplest affairs in terms of motivation and power. This leads to high-level "external" participants experiencing an inefficient collaborative process, leaving basically unable to complete any work; while "internal" developers are not dispatched by the work order system for "external" requirements that arise from time to time It takes time to deal with the company's work, which is annoying.
If one day the company remembers the story of "co-construction" again, and starts to give the "open source team" the demand for increasing the number of the community, on the one hand, the low-threshold means in a short period of time is only the chores mentioned in the previous section; on the other hand, , Not only that, people in the "open source team" have to ask "external" developers to participate in order to achieve their own performance. This kind of situation that looks down on the content contributed by others and is forced to kneel and lick service, I discussed it in an early article "Two Hats of Developers" .
If the first author of an enterprise open source project is still in the community, then the chances of these problems appearing are as low as those of an open source project community initiated by an individual.
For example, the Apache InLong project mentioned above was donated by Tencent. Zhang Guocheng, one of the original authors, is still heavily involved in community development and direction planning. He hopes to bring the software he created to the production environment of more users through open source code and the influence of ASF. At the same time, he also needs to maintain InLong usage instances within Tencent. Based on this motivation, and because he is the original author of the software, he was able to unify the internal and external version release process. PMC Chair Charles, who also bet his career on the InLong project, is the director of Tencent's internal InLong project. Driven by a strong sense of responsibility, he can actively publicize InLong's design concepts and use cases, and actively develop the community of developers. According to my observation of the InLong project, basically every two or three months, several qualified developers are nominated for the Committer team.
For example, the OpenDAL project I recently brought to the ASF incubator was donated by DatafuseLabs. Of course, you can think that its source is similar to @Xuanwo's personal open source project, but it is indeed a project established by DatafuseLabs. @Xuanwo's main business also includes developing and maintaining the OpenDAL project. @Xuanwo introduced the past and present of OpenDAL in BeyondStorage: why we failed [14] . On his personal blog, there is also a series of OpenDAL technical introduction and operation sharing.
The key point here is that building an open source community is not just code development. Although good software is the core, if the community wants to build up and operate self-sufficiently, it almost needs the enthusiasm of entrepreneurship. For the first author, the software is his own work, and the success of the software can drive his own success. At the same time, he also obtained the authority to indicate the direction of software development from the process of original software development. Take off with the blessing. The rise of TiDB is obviously an example, and after the founder faded out of the core community and was replaced by a professional manager who had no relationship with the project as the technical director, the typical smell of open source from various large companies began to appear.
Of course, it does not mean that if you are not the original author, you can only wait passively, but it is more difficult for the successor to obtain a reputation similar to the original author through hard work, and the successor often has little motivation to do such a thing. I remember that there are quite successful cases in which this is done. It should be considered that the senior engineers of Alibaba Group participated in and gradually inherited the leadership of the Flink community.
Regarding how developers should participate in the open source community, how to organize and build related materials in the open source community, the most recommended is naturally "The Cathedral and the Bazaar" [15] . Among them, the second "Cathedral and Bazaar" and the third "Cultivating the Mental Layer" respectively discuss the ways and advantages of open source collaboration, as well as the ownership and reputation of open source software.
In addition, Making Open Source Software [16] is a valuable reference material, GitHub's Open Source Guide [17] is a couple of concise booklets on the subject, and Open Collaboration [18] is an interesting GitHub A comprehensive book on the open source community and its patterns on the platform.
It should be said that the implementation problems of operating personnel mainly come from the immaturity of the industry, and the experience is not widely known. With the exposure of many good cases and bad cases, I believe that operators can quickly find a new position and establish operational capabilities for developers. In fact, there are signs of this, and some pioneering talents have appeared.
Regarding the position and incentives of developers, once an enterprise realizes that the success of the open source community is basically internal entrepreneurship, then if it still decides to take the open source route, the relevant resources and talent allocation will no longer be missing. On the developer side, with the guidance and experience sharing of successful open source project communities, I believe that with the pragmatic spirit of developers, I can also understand the methodology needed to build an open source community. Of course, from knowledge to actual implementation, it seems that it is still a difficult hurdle to cross.
In addition, if the domestic open source community wants to develop and obtain a broad operating space, the most difficult problem in the end is how to improve the product power of open source software, or the quality of open source software.
Wu Sheng, the author of SkyWalking , mentioned in the interview "Open source has no black magic, the bubble will burst in two years" [19] :
The core of open source is to have product thinking. From a certain point of view, the community leader must be a very technical person. But from another perspective, it is more important for a community leader to regard an open source project as a product or a commodity that can be sold.
The biggest fear of open source is the competition for speed and performance. If you blindly pursue speed, the result is that after your function comes out, others can quickly catch up through some optimization, which will cause you to lose your living space. Only by continuing to innovate can we continue to go on. In this process, if we blindly rely on KPIs and data indicators brought by marketing to guide the development of open source projects instead of returning to the problems that open source projects need to solve, this will become a disaster for the development of open source projects.
Many extremely popular projects in history can't leave anything behind after the excitement. The core reason is that the software's product strength is not strong enough, that is, it can't solve practical problems, and even the problems it claims to solve do not exist.
The content involved in this discussion is too complicated, and I think throwing this question has achieved the purpose of this article. I gave some specific examples in the first section "Users Don't Buy It: How Do I Use It?" in "The Death of Dachang Open Source" , which can be used as a reference.
References
[1] How to evaluate Ali OceanBase GitHub likes and gifts? :
https://www.zhihu.com/question/494108102
[2] Developer experience anti-pattern: market-led operations:
https://dx.phodal.com/docs/anti-patterns/marketing-drive-developement.html
[3] Open source operations should be discussed regardless of track record:
https://xuanwo.io/reports/2022-13/
[4]Tracking issue for restructure tests:
https://github.com/pingcap/tidb/issues/26022
[5]Make some linters really happy:
https://github.com/pingcap/tidb/issues/22979
[6]Make linter facter by enabling bazel nogo to implement fast incremental linter:
https://github.com/pingcap/tidb/issues/35345
[7]typos: https://crates.io/crates/typos
[8] "The Art of Community Operation":
https://book.douban.com/subject/26976995/
[9]《People Powered》:
https://book.douban.com/subject/35531548/
[10]YouTube channel:
https://www.youtube.com/jonobacon
[11] "Developer Relations: Methods and Practices":
https://book.douban.com/subject/36337667/
[12]Developer Experience at Vercel:
https://leerob.io/blog/dx
[13] Development environment configuration experience:
https://t.zsxq.com/0e2fvSfXz
[14]BeyondStorage: why we failed:
https://xuanwo.io/2023/01-beyond-storage-why-we-failed/
[15] "The Cathedral and the Bazaar":
https://book.douban.com/subject/25881855/
[16] Making Open Source Software:
https://producingoss.com/
[17]Open Source Guides:
https://opensource.guide/
[18] "Open Collaboration":
https://book.douban.com/subject/36199828/
[19] "Open source has no black magic, the bubble will burst in two years":
https://www.infoq.cn/article/v0wqth2ubqwayxg08b7t
Swipe to view all references
Reprinted from丨tisonkun The Book of Night Sky
Editor丨Weng Peipei
Related Reading| Related Reading
How to join Kaiyuanshe?
2022 Kaiyuanshe Annual Report: Opening up a New World
Introduction to Kaiyuanshe
Founded in 2014, Kaiyuan Society is composed of individual members who voluntarily contribute to the cause of open source. It is formed according to the principle of "contribution, consensus, and co-governance". It has always maintained the characteristics of vendor neutrality, public welfare, and non-profit. International integration, community development, project incubation" is an open source community federation with the mission. Kaiyuanshe actively cooperates closely with communities, enterprises and government-related units that support open source. With the vision of "Based in China and Contributing to the World", it aims to create a healthy and sustainable open source ecosystem and promote China's open source community to become an active force in the global open source system. Participation and Contributors.
In 2017, Kaiyuanshe was transformed into an organization composed entirely of individual members, operating with reference to the governance model of top international open source foundations such as ASF. In the past nine years, it has connected tens of thousands of open source people, gathered thousands of community members and volunteers, hundreds of lecturers at home and abroad, and cooperated with hundreds of sponsors, media, and community partners.
