On June 5, 2021, the 2021 China Developer Ecosystem Summit hosted by SegmentFault came to a successful conclusion. At the event, CNCF Ambassador, Kubesphere Open Source Community Manager, Pengfei Zhou delivered a talk titled “How to Build Open Source Communities for Open Source Projects from Zero to One”, sharing the key issues open source projects and communities need to focus on when they are starting up. He also uses Kubesphere’s open source community as an example of how to build a community around an open source startup, as well as some good tools and guidelines for avoiding pitfalls.
Pengfei Zhou, Open Source Community Manager of Kubesphere, CNCF Ambassador
Sort and publish shorthand: SegmentFault Editorial Department
Zero to one: Go Big or Go Home
In the early stage of open source project incubation, the resources and human resources that companies can provide are usually very limited. Especially in startup companies, there are only a few core R&D people in the early stages of the project, and the resources available both internally and externally are limited. In the beginning, companies can consider starting with the basics, focusing on the core issues that the community and developers care about most professionally, and then gradually leveraging the resources of users and contributors that the community brings to make open source projects bigger and bigger.
What are the basic things that the community and developers are most focused on? How to invest limited resources to quickly break the ice for the development of the project and community? Today I will share and discuss with you from the following four aspects:
1. Start with Readme 2. Find the first 1000 seed users to create a community closed loop 3. Barriers to competition: community and cooperative ecology
Start by writing the README
The README, more than just a manual, is the first calling card for open source projects.
Many organizations that promote open source projects spend a lot of effort and budget on PR articles, but don’t spend much time polishing and refining READMEs. GitHub is a large community in its own right, with its own search engine. From our long-term observation, the largest percentage of external traffic to our open source website and GitHub repository still comes from github.com, which means that there are a lot of developers who find your project through GitHub’s own search engine, and then quickly learn about a new open source project from README.
Tips for README
As you all know, a README that looks professional and attractive is more likely to get readers interested in downloading, installing and experimenting with your open source projects. So the key to the Readme is not only to give novices a quick understanding of your project positioning (i.e., What, Why, How) in 10 minutes, but also to reflect as much community activity and diversity as possible. We can flexively use some interesting and easy to understand pictures, text, GIF animations, videos and emojis in the README, to help beginners to quickly understand the project’s functions and application scenarios.
Be careful, however, not to include business and marketing content in the README, which community developers tend to hate. It is recommended to write the README in English, in a concise technical language style, and to avoid being too short or verbose or complex.
The most basic content structure of the README
The following figure shows the basic content structure of the README. We can put a navigation of common resources on the top of the README, such as the entrance of official website, forum and document. We can also record command action pictures with ASCIINEMA, or put several key UI operation screenshots and interactive GIF animations. Also put a comparison with a similar project if you need to. At the bottom of the Readme, try using the all-or-bot tool to automatically show all of the project’s contributors and put links to the contributor documentation and developer’s guide. For more information on how to write a README, we recommend a great resource list, Awesome Readme.
Find the first 1000 torrent users and create a community loop
Armon, the founder of Hashicorp, a world-class open source company, says he can remember the names of the first 1,000 users of his open source product. Mitchell, another founder, flies 350,000 kilometers a year to meet with programmers from major companies to teach them about his tools. This illustrates the importance of seed users for early polishing of open source products.
Promotion of project cold start: breaking the ice by technical activities
The project has just been open source, so naturally few people know about your project. It must be quite difficult to organize your own activities and call on others to participate in the early stage. In the early stage of our project, we tried to make great efforts to hold offline product launch conference and tried various channels for recruitment, but the effect was not good. Later, we chose to go out and participate in top-level technical conferences and activities in the industry and other community organizations, such as Kubecon, Dockone community and Cloud Native Taiwan, so as to share the technical architecture and implementation of our project, exchange current popular technologies in the community, and meet friends by “code”. Instead of introducing and promoting the product directly, it got a lot of geeks and open source enthusiasts interested in trying out our open source project.
After we gained some early users through external technical activities, the product gradually gained some word of mouth and network spread, so we also tried to organize our own Meetup, to communicate with these seed users and developers face to face offline, and at the same time to establish a community to maintain continuous communication. The essence of the community is always people, maintain a good developer relationship with the seed users, through their feedback quickly iterate a few versions, the product will gradually fit more mainstream users needs.
Understand the platforms developers focus on
Finding a vertical content platform that developers are interested in is a prerequisite for exporting and publishing technical content. Developers usually pay attention to several vertical communities that they are interested in. In China, there are developer content communities such as CSDN, SegmentFault, and OsChina. In addition to the three major social media, there are also vertical technology forums and media like Reddit, DZone, InfoQ, etc. We can use some tools (such as OpenWrite) to distribute quality technology blog articles to these platforms, and we can also go to these platforms for cooperation on technical content.
Professional documentation is as important as promotion
According to the CNCF 2020 Annual User Survey, the majority of developers learn about a new technology through Documentation — nearly 80 percent. Keisey Hightower, chief technical evangelist at Google and Kubernetes, also commented two months ago that “documentation is a product feature in itself”, after Jeff Lawson said that “documentation is the most direct Marketing material for developers”.
This information is enough to prove that the most important thing developers rely on to learn a new technology is documentation. Providing easy-to-use and well-developed user and developer documentation should be an early priority for every open source project and community. Documentation in English is preferred or both Chinese and English are supported. Many open source projects have Chinese documentation translated and maintained by community contributors. Usually, people don’t take the time to read through all the documentation, so it’s important to design 10 or more hands-on Labs for your documentation so that young users can get started on new projects quickly.
High-quality technical documentation can also often serve as a source of content for community users to disseminate technology. For example, a lot of good programmers have their own public accounts and personal blogs. I often see their technical blogs or experience sharing that they will refer to and reuse some of the content in the documents.
Pay attention to SEO, let the search engine take goods for you
SEO is actually a very professional field, worth long-term investment, but in the early stage at least need to have some basic SEO common sense, such as knowing their own project can be associated with what hot keywords, to understand the new users through what keywords to find your project website what content. We can use tools like SemRush and Keywords.com to detect keywords that are highly relevant and searchable on the website, and then tailor these keywords to the output of technical blogs and documents.
In the creation of technical content, in addition to the flexible application of highly relevant keywords, there is also a very important common sense: it is better for documents and technical blogs to preach more general technology, not limited to the product itself. Excessive self-marketing content will be counterproductive. After exporting some technical content, we also need to pay attention to the Search results of the Google Search Console for regular analysis and review.
Automated Tools: To do a good job, one must first sharpen his tools
When a large number of users learn about our community’s open source projects through various channels and download and use them, we need to pay close attention to the feedback of seed users and understand how users use our open source projects in what scenarios.
Gather user feedback and make the data speak for itself
We always believe that good products are made for good use, and there are a lot of community users who are very willing to help us polish our products. They will give us a lot of interesting requests or feedback, and sometimes they will make fun of the deficiencies of the product or documentation.
One of the problems with running an open source project is that it can be difficult to know who is downloading your product. If you want to more accurately target the profile of your community and gather demand feedback, HotJar is a great tool for gathering user feedback and monitoring your site. We have connected Horjar survey questionnaire in Kubesphere document page, and collected thousands of feedback data within three months. We have also learned the real usage scenarios of most users from the data analysis of the questionnaire, for example, nearly half of the community users in China will choose to deploy the cluster offline in the physical machine environment. This result is beyond our expectation.
In addition, you can use Google Analysis for website visit data Analysis and Kibana for automatic drawing of download data reports. Some other data that you may want to look at, such as statistics on the growth of open source projects on GitHub over time, can be done automatically using the Nebula Graph community’s open source GitHub Stats tool, which will help you understand the actual activity of open source projects.
Interact with users, solve problems and feed back the product
Once you have a group of users installing and using the product, the community becomes very active, and it is critical to communicate with users and help them solve any problems they may encounter in the production environment. It’s not easy to limit the channels of communication in the community. The way our community works is to use whatever tools are popular. For example, we use WeChat group and Chinese forum in China, and we use Slack and GitHub Issue & Discussion for the international community.
The community also has sophisticated tools to build, operate, and manage these communication platforms. For example, community forums can be deployed with open source Flarum or Discourse. Kubesphere Chinese forum is implemented with Flarum. For those who want to automate the management of WeChat groups and groups of friends, try the open source Chatbot tool Wechaty or Sentence Interaction, both of which can help make our operations more efficient.
Website building and open source collaboration automation
Earlier we mentioned the importance of professional official documentation in the community. Documentation needs to be hosted on a static website, and the community already has some free or open source wheels that allow us to quickly build and operate a site. For example, Kubesphere’s official website uses the Hugo framework to build and uses Netlify to provide a preview of the content modification of the Pull Request.
I’d like to introduce you to Amway Netlify. The government is very enthusiastic about providing free accounts for open source projects to support open source. You can sign up on the Netlify website. Finally, you can use CloudFlare’s free global CDN to speed up your website, so you can make sure that your static content site is basically up and running.
Open source collaboration can’t be separated from the communication on GitHub PR and Issue. To improve the efficiency of collaboration on GitHub, the Kubernetes community has opened source a ChatOps tool, Prow, to help community participants automate community PR and issues, automate Job execution, and more. We used PROW at the beginning of the project, and KS-CI-bot was active in all of the PR and Issue of the Kubesphere community, helping us to automatically merge PR, tagging, and other daily operations. See this blog post for more details on the PROW tool.
Community core: foster a sense of community
One oft-cited term in Internet operations is “retention.” A community also needs to improve retention if it is to build long-term popularity, which is reflected in whether the community gives users and contributors a sense of belonging when they participate in an open source community. Every community will have its temperature and attributes, community builders attitude towards the community and the value of dissemination play a decisive role.
Set up community organization structure and honor mechanism
For the developer community, it is often more effective for open source organizations to recognize developers’ contributions through official, public channels than through financial incentives. Many open source organizations and communities reward contributors in the form of certificates and memorials, and use public social media to acknowledge contributors. Kubesphere is no exception. In addition to creating different levels of Contributor Title according to different levels of Contributor Title, we will also set up user committees in the top cities to help committees organize their own events and exchanges.
Encourage non-code contributions
Community development means diversity and diversity, and the forms of contributions are not limited to code. Even if there are some students can’t write code in the community, we will also encourage them to participate in community contribution, such as participating in the document writing, sermons and promotion, case sharing, tech blogs, tutorials, recorded activities support, need advice feedback, internationalization and localization, testing and other work, there may be a lot of people from different backgrounds or role are interested to participate. Community builders just need to keep planting seeds, design these contribution channels, help the global community of followers to participate, and continuously optimize the contributor experience, which will ultimately make a difference.
Open communication and community meetings
If only words are used in the communication in the community, it will be cold. Regularly holding community SIG meetings can enable developers to have deeper technical exchanges, let community members know the current development and planning progress of some new features of the project, and also enhance the activity of the community.
SIG (Special Interest Group) is the gameplay pioneered by Kubernetes community. The continuous operation of SIG mechanism helps Kubernetes community to become highly autonomous. Our community is also learning the SIG play of Kubernetes. Biweekly meetings of each SIG are held regularly in the community, and the meeting information schedule of all SIG meetings is published on the official website. After the meeting, the recording screen of the SIG meeting is uploaded to the B station for the convenience of community developers to review.
Barriers to competition: community cooperation and ecology
The healthy development of an open source project, in addition to the rapid iteration of the feature itself and the diversity of the community’s users and contributors, is also important for the surrounding ecology of the community, which will help the open source project itself to build higher barriers to competition. For example, how many related open source projects can cooperate and integrate with each other, and which cloud vendors can provide hosting and support, these collaborations can not only help open source projects enrich the ecosystem of the community, but also let users of different channels of cooperation know about your project.
The idea of community collaboration is simple. Where there are developers and users in this vertical, try to partner with this platform. For example, Kubesphere will probably be a Kubesphere user of the public cloud Kubernetes service, so it makes sense for Kubesphere to work with other cloud vendors around the world. Kubesphere has been deeply integrated with AWS, Azure, DigitalOcean and QingCloud container services. In addition, we will also look at upstream community projects that can be closely associated with Kubesphere, such as the Istio community, which we will partner with as a Provider.
On the commercialization of open source
One of our core principles in the commercialization of open source is not to harm the open source community or violate the benefit boundaries of open source users. Because when the open source community finds out that vendors want to cut open source, they may give up and look for new alternatives. Many people say that overseas open source users have better business cooperation intention and are easier to pay than domestic users. This may be because some open source commercial companies have not really understood the real business demands of domestic open source users.
Open source commercial companies should first understand the real demands of open source users and the core problems they want to solve, and then solve their core problems and provide value-added products and services they want. Such a commercialization path may be a natural one. We have surveyed more than one hundred users in the community, and found that more than 80% of them have the right to speak in the company’s purchase, and most of them are users in small and medium-sized Internet industries.
Therefore, after understanding the user portrait, we are exploring a lower cost, more flexible payment methods for products and services online business model, which is suitable for Internet companies play; For customers of traditional industries and financial government and enterprises, the existing offline business model should be adopted to promote the business.
The above is what I share today. If you have any questions, please feel free to discuss and communicate with me (WeChat:13006337550).