1. Open Source Is Growing More and More Popular

The 2019 IDC North America Open Source Software Usage Survey showed that 71% of enterprises are using open source software, and 54% plan to expand their usage. The 2020 Red Hat Enterprise Open Source Survey showed that 95% of IT leaders consider enterprise open source critical to their enterprise infrastructure software strategy.

On one hand, enterprises are increasingly accepting open source software; on the other hand, enterprises are also beginning to participate in open source. The main question to think about now is no longer whether to use it, but how to use open source software well.

It is fair to say that open source has entered a great era, with a profound impact on collaboration models, R&D processes, product releases, and every other aspect.

2. At the Core of Open Source Is Managing and Operating a Community

Open source is not about publishing source code; it is about managing and operating a community.

Much of the discussion about open source emphasizes defensive strategies such as licenses, management risk, and security risk. For large enterprises these are unavoidable, but obtaining backing from the top brings an enormous burden to open source, and in the end there is no energy left to manage and operate the community.

The characteristic of a community is consensus and collaboration. An open source project is the consensus of the open source community, and it is also the object of open source collaboration. The higher the quality and the greater the number of community members, the better they can represent the state of the art in that field.

Over a limited group of people, an unlimited community can be built. But over an unlimited community, an individual can only invest limited energy and time. This is the focal point of the competition among open source projects.

More high-quality people, participating for a longer time, is the key to the success of an open source project.

3. Open Source and Business Do Not Conflict

As mentioned earlier, open source is mainly about managing and operating a community, and a community is spontaneous and open, providing many free services.

A former colleague of mine said that open source is just free-riding: you put up a framework, there is nothing in it, you write bugs, and you expect the community to clean up after you. He was thinking from the perspective of the community. A community resents being exploited and commercialized.

But look at Kubernetes, which Google open sourced: major vendors all have their own distributions and managed versions, the CKA/CKD certification exams are in full swing, and there is a commercial part too, yet none of this has caused resentment in the community. These vendors hold a seat on the Kubernetes TOC, have submitted many PRs, and have promoted the development of the open source project.

Users of an open source community also need commercial services. Within the software lifecycle, there is a great deal of dirty, tedious work that users do not want to take part in, and all of it can become an entry point for commercial services. Open source and business promote and fulfill each other.

4. Run an Open Source Project Like Running a Business

I would rather use running a business as an analogy for an open source project. An open source project is not a project, not a one-off. An open source project should, like a business, pursue perpetual operation.

The release of a piece of enterprise software is the result of a group of people working together. Delivering a reliable release requires the full cooperation of product managers, designers, developers, testers, documentation writers, marketing, operations staff, and more.

The whole of open source collaboration can be understood as a supply chain, requiring the community to divide the work and cooperate, for everyone to participate and everyone to contribute, and finally to complete the assembly and reach the goal. Managing an open source project is managing such a supply chain.

I recall a story: in a year of famine, everything edible had been eaten, and everyone gathered together preparing to migrate, but with empty stomachs they simply could not walk. Suddenly, one person brought out a piece of meat, intending to share it with everyone before they set off. Then someone found a pot, someone gathered firewood, someone prepared to fetch water, someone dug up wild vegetables, someone brought out hoarded flour… and just like that a big pot full of meat soup was cooked, and everyone ate their fill and set off together.

This is a free group, with people leaving at any moment and people joining as well. Community governance is a big topic, and a very old one: you can set up sub-departments within the community to divide the work and cooperate; you can establish a command center to avoid disagreement and move forward in unison. But whether the meal can be served on time, and whether there is meat each time, depends to a large extent on whether you can spark everyone’s enthusiasm to participate.

5. The Goal Is Contributors, Not Stars

Taking part in requirements feedback, testing, design, discussion, making suggestions, writing documentation, promotion, answering questions, and so on — all of this counts as contributing, and it is not limited to writing code.

A star is a very quantifiable metric, often used to measure how popular an open source project is. I think DAU/MAU applies to open source projects just as well.

What should be observed in an open source project is how many contributors there are, the quality of the contributors, how many PRs are merged every day, the merge cycle of a PR, how many issues are filed, and the waiting time for an issue to get a reply. A bad living project has more lasting vitality than a good dead one. As long as someone is participating and contributing in the community, wrong content will eventually be corrected.

Once the goal is clear, many decisions in the community become much simpler. If contributors matter most, then you will value the feedback of community users, take the questions users raise seriously, hold online meetings, make offline visits, have in-depth exchanges, and drop the things that have no effect.

Gathering enough opinion leaders and high-quality contributors is what matters.

6. Cloud Native May Be an Opportunity

I mentioned in an earlier document that now is the best era of cloud native.

The cloud native technology architecture has distributed characteristics, which is inherently conducive to open source collaboration. It also reflects that organizational architecture and software architecture are consistent.

Traditional software infrastructure based on a standalone Linux system is migrating toward software infrastructure based on the Kubernetes system. This involves every aspect of the entire software system, and every industry is striving to integrate into it.

This is an opportunity for cloud native, and even more an opportunity for the open source community.