In Community We Trust

About the author: Huang Dongxu, co-founder and CTO of PingCAP

While drinking coffee with friends a few days ago, I happened to talk about the history of PingCAP and TiDB and the understanding of the core competitiveness of open source software companies. Looking back on the entrepreneurial career and the growth and growth of the TiDB community in the past few years, it is like A huge and ongoing sociological experiment, some of the originally scattered ideas gradually become clear as a main line, I want to write an article to summarize what the community means for open source software and open source companies.

Ubiquitous network effects

Two network effects

Many people have heard of network effects (Metcalfe effect: the value of the network is proportional to the square of the number of connected users), and many great products and companies have built a powerful moat through network effects. When it comes to network effects, the classic example is in the field of communications, such as mobile phones. Each additional user has greater value for all users. Although everyone does not intend to create value for others, once they start using it, this behavior will help the network create value. Many to C companies that we know well, especially social networks and IM (instant messaging software), have built extremely high barriers through this effect. NfX Venture described many kinds of network effects in detail in their blog ( https://www.nfx.com/post/network-effects-manual/ ). Before introducing the community, I want to focus on them. Two network effects related to open source software.

1. Network effects based on herd mentality

This type of network effect usually starts with some opinion leaders, who may be industry leaders, or social hipsters, and often appear when a new product is about to attack the market of an old product. Although this new product is not necessarily mature compared to market rulers, it usually brings some distinctive features or more cutting-edge ideas, attracting the support of opinion leaders who are dissatisfied with the "mainstream" or want to highlight their cutting-edge vision , Resulting in a that "16089868a0599a is used by cool people, if you don't need it, you will be eliminated ".

This feeling will form a network effect of herd mentality when new users join one after another, but the duration of network effects such as you can know: If the early opinion leaders only joined because they were “different”, then after the community becomes mainstream, these opinion leaders will have no reason to stay, and fans who follow these people may follow them. In addition, for this new product, the level of perfection is usually not as good as that of the old product, and the reputation and bad reviews will come at the same time in the early stage. At this time, if you do not quickly polish the product through the network effect and obtain a better iteration speed, then the network effect is not well-founded. is that the effect is more effective in the early stage.

Recalling the early community construction of TiDB, it was also because of the work of several founders in Codis, the reputation accumulated in the domestic basic software circle, and the support of some friends in the Internet technology circle, which formed the earliest endorsement.

1. Faith-based network effects

so-called "belief" is to join based on the recognition of an idea, thus forming a network effect. This is not uncommon in the software field. Both the free software movement and the open source movement are good examples. People, always have to believe in something. is extremely deep, and the tolerance for product defects is extremely high. Because belief is a long-term thought, for TiDB, this thought looks like: Believe that distributed is the future, and believe that business in the cloud era requires a database like TiDB. But this goal is challenging enough and worthy of long-term efforts.

The belief-based network effect may be similar to the herd mental network effect in the earliest stage. The key is whether the core community has a firm belief in the idea behind the product. Conversely, if you simply show your superiority, it will not last long. As your interest decays, the network effect will collapse.

network effects for basic software

For basic software, I have always insisted on two points of view:

• Basic software is "used", not "written".
• Iteration and evolution speed are the core competitiveness of this type of software.

These two points are precisely what the network effect can bring. Although the value chain is not as obvious as IM, the foundation of the network effect is the additional value that new users bring to old users. The value of basic software is reflected in the following points:

• Controllable risk (stability)
• More scene adaptability (discover new applicable scenes and continuously improve performance)
• Good ease of use

For risk control, the more people use it, the more the risk is shared equally by each person. One of the assumptions is: I am not special, and the problems I have encountered should have been encountered by others, and someone must be able to find and fix them earlier than me. it. This hypothesis is established in a mature and active basic software community, because the scene boundaries of the basic software are relatively clear, and the paths within the scope of application are roughly the same. The more the same path, the fewer pits. As long as one person steps on the pit and feeds it back to the community, no matter who fixes it in the end, this behavior is beneficial to other users.

The same logic holds true for scene adaptability. Individual cognition is always limited. Even the founding team of the project does not necessarily have a deep understanding of a specific application scenario. The creativity of community users is endless, and some use paths outside the design may be surprisingly easy to use, thereby developing new advantageous scenarios. Similarly, as long as there is a successful case, the value of the software will increase for other users with similar scenarios. The real-time HTAP data processing solution combined by TiDB and Flink is a good example.

The logic and stability of the usability improvement are similar, so I won't go into details. Using the flywheel effect brought by the network effect to improve the software, this idea I also mentioned in the article "The Cathedral will eventually fall, but the market will last forever".

The maturity curve and necessary stages of the

The birth of the community

Opening your source code on GitHub, or even using a public Git workflow, is not the moment the community was born. The real birth of a community is when a third party starts to intervene and connect outside of you and your code. It may be the first external PR or the first external issue. These are The beginning of the community. The community begins with connection, and it also accomplishes with connection. Open source is not the same as open source. Many teams and projects spend a lot of time on open source, but ignore the communityization of the code and the team behind it, which is a pity.

Death gap and slope of hope

As mentioned in the book "Crossing the Gap", open source software also has its own life cycle curve, which is closely related to the community.

The reason for the emergence of the image interruption layer is that the product maturity has not kept up. After users come over, they find that they are all pits. The various negative reviews that follow will make early supporters and founders tired and even lose interest.

For an open source software, the fault may be reflected in the early period of rapid growth, and then come to a quiet period of up to 1 to 2 years, and the growth has almost stagnated. For the community, almost all of its energy is used to fill in the holes for early users. During this period, users will grow naturally but the churn rate is also very high. This stage consumes a lot of resources, and the core contributors of the community will also be very tired. If they can't survive, they will die, so it is called a "death gap."

The good news is that the stage will eventually pass , bugs, if you change one, there will be one less. The product will gradually find its own positioning and best practices at this stage, and in the best practice path On the other hand, the product will become more stable and focused. If the positioning is just demanded by the market, will usher in a high-speed growth phase (mature period), and the community’s ecology will begin to accelerate with the popularization of products. This can be seen from the search index of Kubernetes and TiDB in the above figure to see a profile of this gap.

The end of the community

What will the end result of a good open source software community look like? For this problem, we actually have many examples that we can refer to, such as GNU Linux, Hadoop, Spark, MySQL, and so on. In my opinion, no matter whether an open source software and community is initiated by a commercial company or initiated and grown in other ways, in the end, a neutral organization independent of a certain company will surely take over the community. This is also the most natural and reasonable way.

Especially the company-led open source projects will face neutrality issues in the later stages. Because for a company, the most important thing is customer success, the demand for commercialization will definitely affect the function setting and development priority of open source software. And the priority is often changed (maybe more urgent and more specific), the change may conflict with the development rhythm of the community, but I don't think the contradiction between the two is irreconcilable, I will expand on it below.

mid-to-late open source software has supported the success and commercial interests of too many users. A neutral committee to balance the interests of all parties and supervise the responsibilities of all parties is a relatively successful practice at present. and beginning to have this The organization also shows from the side that this project is mature and has a good ecology. The open source software that has not yet reached this stage is mostly dominated by the company behind the project. In the mature stage of the project, the focus is to continuously optimize the success of customers and scenarios to make the entire flywheel spin. When there are more and more outside the dominant company The members are thinking and practicing the governance rule, which is a positive sign.

communities and commercialization coexist

and cooking & river and people on the shore

The previous article left a problem, which is the contradiction between open source and commercialization. No matter how I explain it, in essence, open source and traditional software sales models must be in conflict.

Let me give a better-understood example: If you compare open source to growing vegetables, the source code of open source software is equivalent to seeds, and business success is equivalent to growing vegetables. The traditional software business model is similar to selling seeds, but farming and fertilizing (hosting) ) Is the client’s own work. The seeds of open source software are free, the land belongs to the customer, and the person who planted the land is also the customer’s person, so open source vendors may only provide guidance services for planting, especially when some seeds are not very good for planting, guidance services are available. meaningful. But think about it carefully, as the seeds continue to improve (performance, stability, ease of use, etc.), they can blossom and bear fruit when they are scattered in the ground, so professional vegetable planting services are unnecessary. So manufacturers have to sell some additional value, such as insurance services. In case of extreme weather, at least a team of experts will help solve the problem. But this business model is still awkward, because most of the value chain is on the customer's side. Therefore, if a manufacturer only looks at the community from the perspective of potential customers, it is difficult to make a good product because there is no inherent motivation to continuously optimize the software.

A better perspective is to take a step back, and I will give another example that is well understood: treat the community as a river and belong to no one. We should keep the river clear and fluid together, and no one should overfish, different organizations. Both individuals and individuals can build their own ecology around the river. As for what the people on the shore rely on to make money, that is another question, which will be discussed later.

Customer Success and User Experience: Inherent Consistency

Although the first goal of open source software commercial companies is customer success, this is not inconsistent with being a good community. A common misunderstanding is that within open source software companies, the two teams form an opposing relationship. business team believes that the community is for commercial fish farming. When it is fattened, it must be harvested. At extreme points, it must be closed. The community team believes that commercialization will slow down the speed of ecological transmission and increase the threshold for use. Extreme practices are counterproductive. The tendency to commercialize. If you only think about the problem in your own place, of course both sides are right, then where is the problem?

The problem lies in the "stage" and "customer selection". The life cycle of open source software used by community users and business users may be completely different. Generally, open source software companies have two funnels, which I call the community funnel and the business funnel. Some people think that the community funnel is the upper layer of the business funnel, which I deeply believed in before, but after several years of practice, I gradually discovered that it is not the case. The two are independent. If they are simply used as a funnel, then there will be many problems, such as the classic question: what is the value of community users who will not flow into the business funnel? Therefore, it is definitely not a funnel, but a deep internal connection.

What connection? To make it easier to understand, let’s use growing vegetables as an example. The things incubated by the open source community, such as user success stories, community contributions to product polishing, and application scenarios explored, are just like raw vegetables and ingredients, and customers want a plate of fish-flavored shredded pork and don’t care. How did the meat and vegetables on the plate come from, so do you see the key points? The role of the commercialization team is like a chef, and the community operation team is like a farmer. The focus of the two is different. The focus of the chef is how to prepare the dishes, and the focus of the farmer is how to plant good ground and produce better ingredients. . It takes a long time to go from ingredients to a dish, but without good ingredients, no matter how capable chefs are, it is difficult to make a good dish.

For open source software companies, the internal consistency of the two teams of community and business is: good products and winning scenarios. According to our practical experience, it is better to focus on two key points in the community team:

• Community users' polishing of the product (in the winning scenario);
• Discover more winning scenarios.

These two key points will form a closed loop. The community team will continue to produce ingredients (winning scenarios and continuously evolving products), and the business team will focus on the further processing of the winning scenarios and the optimization of the customer journey. The two teams cooperate with each other to drive the development of the entire company and project. cycle. For example, the scenarios and solutions for TiDB commercial users are mostly born and polished from community users. Although the two user groups may be completely different, a big ecosystem-a commercial cycle is formed through TiDB, and PingCAP is The bridge in the middle. In addition, the community and the commercialization team will have a common North Star indicator: user experience.

The only way to realize large-scale realization: Cloud

A good business should be scalable. The business model of traditional open source software companies has the problem of human intervention, sales/pre-sales/post-sales delivery, etc., while the business model based on people cannot be scaled. . This problem was unsolvable before the birth of the cloud, so open source software companies needed to find a software business model that has nothing to do with open source (sounds a bit awkward, but it is true when you think about it), and the cloud is essentially a resource leasing business.

Let’s take the example of growing vegetables. In the traditional business model of the past, the position of the open source software company was awkward because the land and the vegetable growers belonged to the customer. However, on the cloud, the basic software business model is essentially A hosting service puts the "land" (hosting resources and infrastructure), the most important part of the original value chain, in the hands of the manufacturer, which is also good for users. After all, managing "land" is also a laborious effort. Thing, and it’s difficult to buy on demand. The problem is that what users want is just a good dish. Note that this has nothing to do with open source (growing vegetables), because regardless of whether open source is open or not, users pay management and rental fees, which is equivalent to that even if the seeds and ingredients are free, customers When you go to a restaurant to eat, you also need to pay for the dishes, because customers are buying good dishes and service experience.

In addition, many people think that the open source community is a barrier to competition, but it is not. The real barrier is ecology, and the open source community is an efficient way to build an ecosystem. If a product does not use open source to build an ecosystem, the effect is the same. . A good example is Snowflake. Although Snowflake is not open source, at the beginning of its birth in 2012, it has almost no competitors in the cloud data warehouse market, leaving Snowflake enough time to pass differentiated positioning and excellent user experience Building its own ecology, relying on the rise of the cloud and the scale effect has achieved great success.

How to be a good community

The above metaphysically discussed a lot of content about philosophy, and then let's talk about the actual practice. To be a good open source community is actually methodological, but the premise is to have the right way of thinking and angle of thinking, otherwise you will find countless things to do in practice, but you don’t know which one or which is more important. , The more uncomfortable is that you find that you can't measure right and wrong. The following are some of my thinking angles and key indicators considered when thinking, which can be used as a reference for community operators.

Who are you? What problem did you solve? why are you?

The foundation of a good community must be a good product. To answer the question "Who are you", it must be obtained by answering "What problem did you solve?" This is very different from the operation of to C products. Some community operators will turn their attention to various activities or publicity to pull new, and at the same time exaggerate the product capabilities, resulting in inconsistent with reality, this is the most common misunderstanding.

Many friends who do community operations often come to me: I have done a lot of activities and wrote a lot of articles, why does it seem to be ineffective? Usually at this time I will ask him: Can you explain what your product does in one sentence? What problem did it solve? Is this problem a common problem? Is this product necessary for you? At this time, he understood: perfect products do not exist, and good products must follow its advantages. For example, Redis obviously cannot be used for core financial transaction scenarios, but no one will deny that Redis is in the caching scenario. It is a well-deserved de facto standard. There are many similar examples, such as Spark, ClickHouse, and so on. So for the operation team, before doing any action, think about the above four questions.

easy to use determines the conversion rate of the funnel

Is it enough to find the winning scene? Of course not. If you treat the entire user journey as a funnel, finding the winning scene is at best finding the right entry. After entering the funnel, the important thing is to increase the conversion rate at each stage. is a key indicator that determines the conversion rate. The ease of use of the product, , is very similar to doing to C products. Many to B teams will subconsciously ignore this point, usually for two reasons:

• The community user Self-service is not paid much attention to, and the project officials even encourage users to contact the official team, because it is important to know that someone is using this information early, and the basic services and support of commercial customers are official, and the customers are not insensitive to the company. There is no motivation to optimize.
• Many products are life-saving products at the beginning of their birth, and users have no other choice. For example, in the early TiDB, when the MySQL expansion demand is imminent, users are more concerned about how to solve the problem immediately, the kernel capability is more important, and other things can be slowed down first and just endure.

The result of these two reasons is that there is insufficient attention to ease of use and user experience. This error is very hidden in the early stage of market competition. On the one hand, because the number of leads flowing into the funnel is not large enough, human support is acceptable, and the market competition is not fierce, users have no other choice. Imagine that when this market becomes mature one day and a large number of customers flow into the funnel after being fully educated, the support bandwidth of the team will definitely be insufficient; on the other hand, because the market has been educated and matured, there must be competitors who can do similar things. At this time, when you are not the only life-saving option in the market, users will definitely choose the one that is easy and worry-free, which is not difficult to understand. This is why in the middle and late stages of open source software competition, ease of use and user experience should be placed in the highest position. Regarding the “use of peace of mind”, the assumption has been resolved through mature ecology and case endorsements. On the point of “use of ease”, the open source software team born in China is far behind the world’s advanced level. After all, The overseas open source software competition is more fierce than domestic, because the foreign open source market has been born for a long time, and the demand for basic software in business scenarios is not domestic extreme. Usually several products can handle the same scenario, then of course it is easier to compete at this time. Usability (save worry) and ecology (rest assured).

There are a few questions. As the product leader of an open source project, you can ask yourself, how do you define a useful product in your product field? What are the best practices? What is the best similar level in the world? I believe that thinking about these issues will help product development. A good perspective to reflect ease of use is: the degree to which users can Self-servicing, and its index system is more : For example, the proportion of the entire product life cycle of self-service on the cloud, without asking questions from exposure to use in the open source community The number of active contributors to the open source community, etc.

Secondary propagation is the key to achieving network effects

As mentioned above, the premise of the network effect is that the use of any new user is a valuable addition to the old user, so imagine: If a community user silently uses the software, silently read the documentation and the best Practice the article, even if there is a bug, you can fix it silently (without contributing back). Is this valuable to the community and product?

I think it is not.

Although I know there must be such users, just like the silent majority. For community operators, the is not to let silent people use it more or more deeply, but to allow them to establish more connections with other users on the network. share experiences (writing case articles), Cultivate contributors, actively feedback the problems in use to the community, etc., and must pass these content to other nodes on the network to ensure that value is generated. For example: a user's usage scenario helped another user to choose a model, and a user's feedback helped the product find a bug and fix it. These are all examples of value generation. Don't let users become islands. If community operators can't see this key point clearly, they may fall into the situation of pursuing numbers for the sake of numbers (usage) and have done a lot of work, but they can't see progress from the overall situation.

network effects

The highest level of community operation is to transfer network effects from users' network effects to belief-based network effects, and to transfer the community center from the inside of the open source company to the outside to gain greater potential. Both of these are not easy. For the former, it may be more about abstracting, summarizing and refining concepts and maintaining long-term and correct insights. In addition, it is not easy to find a suitable group of evangelists. For the latter, as long as you accumulate enough successful cases and advantageous scenarios in the company-centric stage, and invest resources in the education market, the rest will be handed over to time. At this stage, the indicator of concern is brand power. Open source software community operation is an exponential curve game, and it must be cultivated with a long-term mentality.

Finally, as a conclusion, I want to talk about what a great open source basic software product should look like?

my eyes, a great basic software product is not only to solve the specific problems at the moment, but to open up a new world, a new perspective, and create new possibilities. Just like the invention of the smart phone, it used as a platform to give birth to great applications like WeChat, opening up a whole new world. like the invention of cloud, S3, and EBS, providing developers with new design methods, spawning new species such as Snowflake, and completely changing the way people use analytical data. The open source community is the most suitable soil for the birth of such great basic software, just like fish and water.

I don't know what the community will bring, and I don't dare to overestimate my abilities. After all, in the face of group wisdom, personal power is always small.