Chinese open-source communities have grown rapidly in the past few years, with more contributions to internationally influential projects. In 2021, all projects entering the ASF incubators were from China; as per the GitHub annual report last year, Chinese developers totaled 7.55 million, ranking second in the world.
Currently, large businesses are increasingly collaborating with each other to build open-source communities to form comprehensive ecosystems. With the rise of open source fever, related controversies have gradually gained public attention regarding open-source projects' motivation, compliance, and operations.
In this article, we invited Mr. Tan Zhongyi (Jerry Tan), Vice President of TOC of OpenAtom Foundation, to share his views regarding how to balance altruism with self-interest and avoid the trap of "KPI-first" when engaging in open-source projects.
Open source is not a utopia
Disagreements in perception often lead to controversy. Different interpretations of the original purpose of open source often influence people's judgments and attitudes towards open-source issues. Many individuals believe that open source is motivated by a utopian altruistic spirit, while others claim that antimonopoly concerns drive it. In Tan's opinion, both statements appear to be subject to limitations.
In the history of open source, Richard Stallman and Linus Torvalds must be credited as the "founding masters".
In the 1980s, Stallman observed that the printer drivers in the laboratory at MIT were not up to standard. He attempted to improve it, but the printer manufacturer refused to provide the source code. This is how a tiny spark ignited by this incident led Stallman to become the spiritual leader and initiator of the Free Software Movement.
As Tan mentioned, Stallman stressed that "free" in the movement refers to "freedom", not "free of charge". Free software should have "four essential freedoms", that is, you should be able to run, change, and redistribute the program(and any modified version) as you wish. In addition, Stallman was concerned with intellectual property and regulatory issues, as demonstrated by his GPL License design.
(Source: https://www.gnu.org/)
While it is likely that Linus, another pioneer, initially developed the Linux kernel for fun rather than as a serious endeavor. Having written a miniature version, he discovered that it worked well and then decided to publish the document in the hope that more people would provide feedback on his work.
In Tan's view, open source was not intended to prevent monopolies or promote utopian altruism initially, and its significance has been elevated over time. To Tan, open source is more akin to social collaboration than technology.
However, the multi-person collaboration model can only be successful under certain conditions. Open-source software can be modified or taken back, but modified content should be made publicly available for others to read. Otherwise, these modifications may violate the original intent of open-sourced software.
Tan believes that open source is founded on the principles of transparency, openness, and collaboration, with contracts such as open-source licenses providing a guarantee. The open-source partnership is now more widespread, not only among software companies, and it is affecting a wider audience.
The motivation behind open-source adoption in enterprises
Open-source development relies heavily on enterprise participation. Behemoths in China are willing to adopt a more open attitude and contribute their strengths regarding open-source compliance, selection, and collaboration to encourage the advancement of a comprehensive ecosystem.
Nonetheless, according to Tan, enterprises join open-source projects not to provide charity but to pursue their business interests.
As he said, an enterprise may participate in open source in three ways: by consuming, contributing, and participating independently.
The consumption of open-source software is one of the most direct ways to take part in open-source projects. It can reduce costs, and its effects are immediate. There could be a substantial cost difference between developing software from scratch and using mature software for secondary development. "The growth of Chinese IT companies would not be as rapid as it is today without the support of a wide range of low-cost open-source software." said Tan.
As for contributing to or creating their own open-source projects, the top reasons may be more diverse.
The first is the reduction of labor costs, as open-source software can be developed by anyone around the globe instead of depending on your company's developers solely;
Second, it can play a key role in building technical influence by working with the industry's leading companies;
Third, some business models are built on the back of open source, so a simple look at a company's revenue may not be adequate to determine its intention to participate in open-source projects, but rather by evaluating its products and ecosystem as a whole.
Tan discusses how business models influence motivations by describing top contributors to the Linux kernel, all of whom have quite different goals in participating in the open-source community.
Red Hat provides Linux distributions based on the Upstream First development model. It contributes to the Linux kernel to build and consolidate its technical reputation and convince users of its services;
Intel participates in open-source projects to support its hardware products;
Microsoft was once a significant contributor to the Linux kernel, focusing on virtual machine modules. Nearly half of Microsoft Azure's virtual machines run on Linux systems, and if it were unable to gain access to the upstream Linux community, any changes to its virtualization products would lead to increased costs. Therefore, supporting the Linux kernel will enhance Azure's virtual machine performance.
Just as Mr. Tan said, the benefits of contributing to the same open-source project may vary, which should be evaluated from multiple viewpoints, including its business model, target audience, and the market. Nevertheless, this also illustrates the advantages of the open-source model: a group of companies can work together in a common community despite their differing business objectives. With the public code and predefined open-source terms, the group can even achieve synergistic goals.
Beware of the "KPI-first" trap
Recent years have seen some firms place KPIs at the top of their priorities, resulting in flashy projects, a lack of realistic goals, or projects that do not meet their intended outcomes.
Enterprises need to take open-source seriously, and there must be a corresponding business purpose and strategy in place. When your focus is on technology branding, you must be careful and not ruin the brand once the project has been launched, since branding requires long-term and continuous effort.
Tan noted that there are not too few open-source projects but too many. Therefore, the manager responsible for coordinating open-source projects must carefully consider the purpose and measure the corresponding milestones and indicators to prevent short-sightedness and unreasonable expectations.
Meanwhile, open-source communities should establish a good audit and management mechanism. Presently, large domestic companies such as Baidu, Alibaba, and Tencent have their own audit procedures, indicating that enterprise open-source is gradually becoming standardized and systematic.
In the interview, Tan mentioned a system designed by him while serving at Baidu. "Every open-source project at Baidu needs an open reply from the department director, who needs to explain the reasons, benefits, and workforce involved in maintaining the project. If the ultimate purpose is clearly defined, the director must face the review committee, and no further progress is allowed unless they pass. "
In addition to the project crisis caused by the KPI-first strategy, some companies will later stop investing in open-source projects for business reasons. According to Tan, two factors need to be considered when making trade-offs in this situation.
The first question is whether the project can be considered valuable in the market. Only the project that is positioned in its place within the technology ecosystem can survive. Moreover, it is vital to determine whether the lead company is committed to sustaining the project over the long term and whether necessary decentralization is essential because it is inconceivable that contributors in the community will continue to maintain the project for nothing.
An excellent example of this is when Oracle acquired Sun, the creator of the Java programming language. Sun had an open-source project called Open Office, which was essentially a replacement for Microsoft Office. Oracle did not wish to maintain the project after the acquisition, but the Linux environment requires an Office-like editor, so the project must be preserved. Later, the project was donated to the Apache Software Foundation. I believe developers in the community would not have been willing to make regular contributions if Oracle had not donated it. However, if there are too many projects of this type on the market, even if foundations like Apache or Eclipse take the lead, the project may still slowly fade away, "said Tan.
Tan mentioned that not all open-source projects have to last a long time; we have to respect the natural development cycle. The project can be considered good if it can meet specific needs and be used by certain customers in this cycle.
A rational egoistic approach seems to be beneficial
The primary concern of any open-source project, whether it is initiated by an enterprise or by an individual, is how to survive. In this regard, Tan suggested that a rational and egoistic approach would be beneficial.
The logic of rational egoism is that if you can work in open-source projects for some time, the benefits should exceed your investment, thus having a positive return on investment. Tan elaborates, "Simply put, you have an open-source project with a positive ROI, and what you do is profitable for you and useful for others, referred to as rational egoism."
Several controversial cases of open-source authors deleting their files and disappearing forever may give us a different picture. This is partly because they did not receive sufficient payback from their contributions to compensate for their efforts. Developers may begin the participation by sharing their work with others to make improvements, but if the feedback and revenue do not support the contribution in the long term, meaning the input-output ratio is out of balance, then this model is not particularly healthy.
The same applies to enterprises. There is, however, a greater diversity of perspectives when it comes to measuring the benefits of open-source software. It depends on the purpose, from capturing opportunities to establishing standards, building a technology brand, and pursuing commercial interests. Since each of these purposes has specific resources and operating methods, the experience can't be applied universally.
With the growing number of open-source projects on GitHub and the rapid evolution of technologies, it is critical to have strong operational capabilities to succeed and survive. Moreover, open-source operations have different focuses according to their stage of development.
The first thing you should do after releasing an open-source project is to tell others about it. Following that, you need to let people use it and collect their feedback.
- Let others know of the project. Several indicators can be used to measure this awareness, including the star number on Github, Google Trends, Baidu index, WeChat index, etc.
- Allow people to use the project. A new or closed issue or PR number can be checked to see the feedback.
- Analyze the quantity and quality of applications in practical situations.
Quantifiable indicators to measure the effectiveness of operations vary for different stages. However, Tan warns, "Don't make these indicators into KPIs for operation teams, as all of these can be fabricated, with the exception of the practice cases. With a cheated prosperity, your project will fail like a blown away bubble. "
Q & A
Q: How powerful is the binding effect of open-source licenses? Does it have legal recognition and protection?
A: Open-source licenses are similar to intellectual property contracts, which are considered valid both domestically and internationally. This past year, we witnessed the first GPL violation case filed in China in which the plaintiff, Luo He Network Technology Co., Ltd., found three Internet companies had used their system code, which constituted an infringement. A case like this illustrates how Chinese regulations recognize the legal validity of open-source agreements.
Q: Do open-source projects led by enterprises necessarily have to contend with the issue of neutrality when they are mature enough?
A: Depending on the stakeholders' purposes and the leading parties' business ambitions, this model may not be appropriate for all of them. As an example, Android is no longer neutral today, but it is still thriving. Donating the project to a foundation entails losing 100% control, but the advantage is that open governance allows for more collaborators, so a company will likely consider becoming more involved in their open-source endeavors.
Q: Google appears to be a typical example of an open-source company achieving a "monopoly". Is this model likely to become a standard strategy in the future?
A: While many giants want to do this, it is not possible for everyone to do so. In the cases we have seen, Google has utilized Android to capture a large market share and then used GMS to charge for it. This business model is not the result of some pre-determined path but is the result of generational evolution. From a historical perspective, the search giant's success can be attributed to various factors.
The timing is ideal for Google because there is a need in the market, and technology has advanced to meet that need; Meanwhile, Google's primary competitors made some mistakes.
Based on Google's experience, you must consider how to link the technology and industry chains to form a common circle so that a win-win situation can revitalize and expand the ecosystem.
Q: There are some people who believe that open source is devouring the world. What are the prospects for open-source and closed-source software, and can they coexist?
A: The two do coexist. First of all, open-source licenses contain a disclaimer that the author is not liable for the results of the use of the software.
Commercial companies, however, require someone to assume responsibility for the operation. As long as companies utilize open-source software, they must be able to deal with the aftermath, either by themselves or by engaging a service provider.
Moreover, open-source software focuses on the infrastructure layer, while products and business models have their own business logic, which may favor private software. Therefore, open-source and commercial software must coexist for a long time, benefiting developers and end-users on different occasions. My opinion is that neither is better than the other, and I can hardly imagine a world in which only commercial software is available.
Conclusion
The technical value of open-source projects is determined by their ability to solve our problems. It is not necessary to look too deeply into the survival of open source, but how to keep it alive is the key.
In the open-source world, balancing altruism and self-interest is the first step to setting aside controversies and establishing an environment for collaborative coexistence. For an open-source project to survive, the leader must have clear objectives, prudent operations, and constant investment, whether a company or an individual. It is when there is a positive ROI that the project will gain momentum and get off to a good start.
Guest Introduction
Mr. Tan Zhongyi (Jerry Tan) is the Vice President of the OpenAtom Foundation and the founder of StarTogether, an open-source community for enterprise-level intelligent transformation. He has worked in open-source roles at Sun, Baidu, and Tencent over the past 20 years, accumulating a wealth of expertise in open-source strategy, compliance, and operations.
