This interview lineup
Guests: Chen Zili tison , author of The Book of Night Sky, Apache Member & Incubator Mentor, Apache Flink Committer.
Moderator: Zhuang Biaowei , director of Open Source Society, open source expert of Huawei Open Source Management Center. Participate in various community activities all year round, and be enthusiastic about research and sharing on open source governance, open source growth, and open source academics.
Q: We see a lot of developers of all kinds in the community, some are purely out of hobbies, some are students who want to learn and grow in the community, and some are sent to the community by enterprises with tasks. Please talk to tison, who are the more interesting developers you have met and how they behave?
tison: The environment of the students is relatively simple, maybe more pure. Their motivation is usually that they have learned a lot of knowledge in school, but it is difficult to get access to software that is relatively mature in the industry or can be used in a production environment. By participating in the open source community, the knowledge in the book and the software in reality are mutually verified. . Of course, there are also some that lay the foundation for future internships or jobs.
The open source community focuses on software value. When the community makes decisions, it considers the interests of the overall software users and the demands of core developers. There are generally three types of community members: one is the user, or End User; the other is the developer who wants to do ecological integration; the other is the kernel developer. If you participate in the open source community with the habit of enterprise development, you will soon find that the common control mode dominated by the approval process and the Deadline-driven working method of the enterprise will not work in the open source community. Open source collaboration emphasizes voluntary participation.
Q: We say that we should be neither humble nor overbearing in dealing with others. The examples you just gave are too "overbearing", but some people (more students) are always cautious in the community, and they are too humble. How to treat this situation?
tison: This kind of people often go beyond the scope of humility, but don't want to speak at all, or are too embarrassed to speak. They will be very careful to guess what you want to do, for example, after proposing a patch, they are stressed and worried about how others will react. If it's the aforementioned arrogant person, they'll take it for granted that maintainers merge their patches, no matter what it's written, and you better stop talking crap.
The problem of being too humble actually happens not only to the Contributor, but also to the Maintainer. Especially when the Maintainer pays too much attention to the churn rate, the number of Contributors and other indicators. This is also part of the Contributor's reliance on the Maintainer's arrogance.
For the newly joined Contributor, if the Maintainer thinks he needs help, he can guide them and tell them what to do when there is enough time, or tell him that it's okay when he notices that they are nervous. Not long ago, when I proposed a patch for a Gradle Plugin called spotless, there was a problem in the patch that was merged for the first time. Although I immediately proposed a fix, I was still quite embarrassed. At this time, the maintainer of spotless reassured me that everyone would make mistakes, and the work I did was a function that many users had been looking forward to for a year, and I was very proud of it. When I heard him say that, I was relieved. The Maintainer is not superior, and all members of the community are equal.
Q: How can I quickly adjust my status to a more suitable status in the community?
Tison: It is impossible to say that the open source community has a set of mechanisms to ensure that this problem can be solved, because treating people with respect is a matter of personal quality, and the only thorough solution is to read more books and learn more to solve the problem fundamentally.
If you encounter communication barriers in the process of participating in the community, you can observe how other members do it, especially how opinion leaders express themselves, which words they like to use to express a certain meaning, and so on. Different communities have different habits, the important thing is to fit the values of the community.
Q: I mentioned the various situations of individual participation in the community, but in fact there is a more important protagonist is the enterprise. Some companies just want to use open source things behind closed doors, preferably no one knows about them, but there are also some companies that will actively participate in the community. Do you have any interesting cases to share?
Tison: Enterprises use open source in roughly three ways. One is to use open source software, the other is to participate in upstream communities, and the other is to open source their own mature software and try to build an open source community.
It is common for domestic enterprises to use open source software unintentionally, and after discovering it, try to conduct supply chain analysis, security compliance audits, etc., all of which fall into the scope of use.
Some technology-driven companies, such as Ali and Bilibili, etc., their employees have the motivation and actions to participate in the open source community. The company level will also open source mature internal software to build influence, such as the RocketMQ project donated by Ali to the Apache Software Foundation, and the open source go-kratos project of Bilibili. On the other hand, more and more technology startups choose to use open source technology or open source their own core technology to win more attention and cooperation. For example, the distributed database TiDB developed by PingCAP is open source, and StreamNative started out as a distribution and subscription service for the open source software Apache Pulsar.
Domestic companies also often modify internal software based on open source projects, that is, secondary development. Being able to release a modified version, or contribute back upstream, is also some kind of participation. At least what should be done is that when promoting the magic modification software, the statement is based on an open source project magic modification. Most open source software licenses require the retention of author information. When an enterprise releases software to the outside world, it needs to clarify which open source software is used in the software.
A few months ago, Volcengine Inc. (Volcano Engine) made an observation project based on Apache SkyWalking, claiming to be self-developed, but it was later found to be similar to SkyWalking, but no statement about using SkyWalking could be found on the relevant website. Such a project is developed away from the upstream, and at the same time there is no open source spirit. It is no wonder that when I look at this project today, it is dying out as quickly as thousands of other internal enterprise projects.
Q: Will enterprises gradually improve due to the popularity of open source software? What is the root cause?
tison: I think the technological development of enterprises and the development of the open source movement can complement each other, and this process requires the efforts of us open source activists.
In the absence of the open source movement, business requirements for software can be met, such as recruiting employees to develop or purchasing proprietary software. So it's not that only open source software can solve business problems, it doesn't exist. The value of open source software is provided by the open source community that developed the software. Open source collaboration has a set of ownership mechanisms and reputation incentive mechanisms that have been tested for 20 to 30 years. Once enterprises realize that they can gain leverage from the development of open source software, and can bring value to themselves through the open source software that they are already using, I think enterprises can face up to the meaning of open source work and open source governance. This is a bit like the characteristics of the second quadrant in the value dimension. Users do not know what they need, but once provided, users will readily accept it.
In order to promote the development of the open source movement and the process of enterprises practicing open source, what we can do is to publicize how to correctly and efficiently cooperate with the existing huge open source community, help potential projects build open source communities, and point out which open source communities are useful. Vitality, which companies practice open source practices are good.
For example, we have to point out and criticize the illegal use of open source software mentioned above. Just because something is labeled as open source cannot be tolerated without a bottom line. For the cases that have been well done, I have also written many articles and introductions in the "Book of Yetian" official account.
Zhuang Biaowei: Newton said back then that I am so good because I stand on the shoulders of giants. This view of "making further contributions based on the contributions of others" is different from the domestic view. In China, the more you do not rely on external forces, the more honorable you are to do it from start to finish. Conversely, if you depend on others, it is not so honorable. But what I want to say is that there is no shame in making something better than him based on other people's good things. This chain of contempt needs to be broken.
Q: Have you seen any strange things when a company wants to run its own community?
tison: I recently communicated with friends and often quoted the golden rules of community mentioned in "People Powered", one of which is "community members work for the community, not for you".
What demands does a community member have? The ultimate goal of the open source community is to create good open source software and make it widely used. The ultimate goal of a good community member should be the same. In the process, he can exercise his skills, gain the reputation brought by peer evaluation, and find a job or create a career based on his knowledge of software and accumulated experience. .
I wrote an article called "Creating Value Together" , which mentioned that when doing community operations from the perspective of an enterprise, one of the basic points is to find the common ground of community value, participant value and company value, and use open source collaboration skills to play positive-sum games, while It is not a simple application of traditional enterprise management methods. Internal enterprise processes, such as audits, performance appraisals, etc., do not exist in the open source community.
What a community member wants to directly achieve is a personal goal, and his interests are related to software quality, personal development, and his right to speak in the community. On the other hand, the ultimate goal of a business is to make a profit. The common problem of open source communities initiated by enterprises is to copy the management model of enterprises, hoping to manage people and things in the open source community with the enterprise model, which leads to many problems in the management process.
Zhuang Biaowei: I would like to talk about the logic of the enterprise from the perspective of the enterprise. Enterprises must have their own costs, and if they pay costs, they will have benefits. For example, if I vote for 10 people in the community now, should I vote for 15 people next year, or only 5 people? If investing 5 people can attract 20 people, it means that 1 person can leverage 4 people in the community, and if 5 people can leverage 100 people, then the community's cost investment is cost-effective. Commercial companies are not doing charity. These are some things I want to say on behalf of enterprises. What does tison think of this mode of thinking?
tison: I think this point of view is correct, and enterprises should think like this. The challenge for enterprises is that they do not know how to measure the value of the open source community, because some values cannot be seen under the current evaluation system, which may make enterprises mistakenly believe that there is no value. Apache has a project maturity model, orbit.love also provides a series of means to measure community indicators, and ClickHouse has released its own query to measure community indicators. These are some cutting-edge explorations.
Another challenge facing enterprises is the unfamiliarity with the open source collaboration model. Leveraging the labor force is difficult, and requires considerable knowledge and hands-on efforts. It doesn't mean that I claim to have established an open source community today, and other people will line up to "contribute".
It is not difficult to achieve the target, but the difficulty lies in how the enterprise understands open source. After the enterprise establishes an open source office, how to understand the role of this department and how to measure its value from top to bottom and between departments.
Q: How do you view the issue that enterprises not only need to attract participants, leverage the labor force, but also need to be able to lead the technological development direction of the open source community?
tison: It can be done. The influence of enterprises in the open source community is divided into two types: hard influence and soft influence.
The so-called hard influence refers to Hashicorp to its project group, VMware to Spring core modules, or PingCAP to TiDB. Most or even all committers are company employees. In this case, how the software develops can naturally be controlled by the company.
But if a piece of software is adopted by more and more companies, it will always move towards a kind of republic system, and many companies have their own influence. At this time, if a company wants to guide the development direction of the community and software, it needs soft influence That is to point out the direction and the influence brought about by input and contribution.
What type of influence an enterprise needs and how much manpower and time should be invested in building this influence depends on the extent to which the survival and profitability of the enterprise are based on the dominance of the software. A typical multi-company project is Kubernetes. Both Red Hat and Ali are selling Kubernetes distributions, but their contribution to the upstream of Kubernetes can benefit every participant. They need this kind of influence, and they also need to make their solutions upstream standard solutions, rather than being subverted by other solutions. For Google, Kubernetes, instead of Mesos, has won the container war, has been able to protect its business from being disrupted by new technologies, and maintained Google's position as a technology leader in the industry, which has been a very fruitful result for the company.
From another perspective, dominance is not centralization. It's not that the presence of enterprises is everywhere, and everything has to be reviewed and approved. If this is done, the production efficiency of the project will be limited by the efficiency of the enterprise. Even if cosplay is open source, its actual efficiency is similar to that of the company's internal development software.
Zhuang Biaowei: There are a lot of decisions in the community, ranging from architecture-level decisions to PR integration. Important decisions may only account for 20% of the entire community, or even only 10% are critical decisions, and the remaining 80% are not that important. So we only need to guarantee the key figures behind the core features.
tison: In fact, in the open source community, directional decision-making is not the main content. We mention the concept of soft influence, and its establishment method is also that employees with an enterprise background develop valuable functions for this software. When we refer to the company's dominance over the company, or influence, or the right to speak, we must ask ourselves, what is the goal that the company wants to achieve?
In fact, there is only one goal that a company wants to achieve, that is, its own business will not be affected, and it can continue to make profits. The more it earns, the better. This is not something you can achieve by controlling an open source community.
If an enterprise wants to protect its own business, it is a very reliable way to participate in the upstream and feed back the experience accumulated in the enterprise's scenarios to the upstream, and add its own test suite to the upstream continuous integration pipeline. For example, after Alibaba selected Flink as its own flow computing engine, it has continuously invested a lot of manpower since 2015 to realize a large number of features including session window and incremental checkpoint, and in 2019 it acquired many Apache Committers. company. Xiaomi uses a large amount of HBase as a storage system within the company, fulfilling its own experience and needs upstream, and has also trained several Apache HBase Committers, which is a good practice. Even if it is not 100% "controlling" the community, it will not affect the pace of making money.
Of course, the open source community is not always cooperative, and there will indeed be problems that require different solutions from different members. At this time, it is necessary for enterprises to grasp the right to speak in decision-making through long-term operation to veto unreasonable solutions. Oracle's strong rejection of OSGi as the official solution for Java modularity in the JCP decision is a prime example. But such directional decisions are not the main axis of open source software development. Enterprises should maintain sensitivity to key decisions, but only by paying attention to daily development and operations can they gain enough soft influence. There are also many stories in the open source community about the final fork, which does not mean that the fork must be weak. It's a long story and I won't expand it here.