In the previous post I mentioned that I joined QingCloud at the end of January 2021 as the operations manager for the KubeSphere open-source community. It has now been a year and a half.
Before this role, I knew little about open source. Fortunately, I already had more than four years of experience in technical communities, and there are similarities between the two, so I adapted quickly.
Of course, the twt community and the KubeSphere community are very different, so operations methods differ as well. In this post, I use the KubeSphere community to share what I have learned about open-source community operations and the surprises of this work.
Why I chose the KubeSphere community#
After leaving twt, I interviewed for multiple roles, including community operations at CSDN and OSChina.
I chose KubeSphere for a simple reason: CSDN and OSChina were more similar to twt, so I would mostly be transferring experience. KubeSphere promised more new learning (and it did).
After joining, I quickly integrated and took on content and event operations.
What is an open-source community#
To help you understand my work, let me define an open-source community.
An open-source community is a group of people with shared interests who publish source code under an open-source license and provide a space for learning and collaboration.
Take KubeSphere as an example:
KubeSphere is an open-source project initiated by QingCloud. Its source code is fully open and hosted on GitHub and Gitee (mainly GitHub). Anyone can view the code and submit Issues or PRs. In short, the KubeSphere community is formed by people who are interested in and contribute to KubeSphere.
Broadly, an open-source community consists of:
- the open-source project itself
- core maintainers
- contributors
- users
- project-related content
- the ecosystem around the project
These parts overlap.
So what makes open-source communities special?
In a word: openness and collaboration. People participate proactively to co-build the community. Whether it is product improvement, content production, or promotion, you will see voluntary participation without direct economic incentives.
The job of an open-source community operations manager#
The role is to grow the community and make it healthier and larger. Based on practice and learning, I divide the work into the following parts (some overlap with the previous post).
Product#
The product (the open-source project) is the foundation. Its quality and evolution determine community growth.
An operations manager has less product authority than product managers or engineers, but that does not mean no influence. Operators are closest to users, so they collect feedback and pass it to the team, influencing iteration.
Content#
Content is the foundation of technical communities, and the same is true for open-source communities.
The quantity and quality of content determine community growth. To get more people to download and use the project, promotion is necessary, and content is the main vehicle. Content also helps users understand and use the project.
Thus, content operations are critical. Technical articles and best-practice cases need to be continuously encouraged and produced.
Users#
Users are as important as content. Key metrics of an open-source community include downloads, GitHub stars, and contributor count. These all depend on users.
User operations require you to reach users, understand and meet their needs, listen to feedback, and empower them through content and events.
Events#
I emphasized the importance of events in the previous post. Open-source communities must organize events.
Events are not only technical evangelism and content output; they also help retain users.
Open-source collaboration ecosystem#
Open-source communities can cooperate with others as long as there is value, even if their projects compete. There is no absolute competition; cooperation is common.
Cooperation can include product integration, content collaboration, and co-hosting events.
Communities can also cooperate with universities and training institutions.
A stronger ecosystem makes the community stronger. Building that ecosystem is an important responsibility.
Surprises from operating an open-source community#
Open-source communities are open, and many people participate proactively. This has been one of the most surprising parts:
- Users often submit contributions on their own
- Content can be reviewed by users before publishing
- Events can recruit many volunteers
- A user committee makes more things possible
- Users answer each other’s questions
- …
In short, you see more proactive contributors who provide a lot of help that I had not experienced before.
Vision#
Community operations is a multidisciplinary role, so it is sometimes misunderstood as low-value “miscellaneous” work. That is not true. Not everyone is suited to it. I have worked in this role for six years and still do not claim to be an expert.
After entering open source, my mindset has become more open. I want to learn new skills and connect with more people, and I am more willing to share experience.
I hope that through collaboration, the KubeSphere community will become more open and collaborative, with more participants. Personally, I hope to learn more and produce more.
There is a comment system on this blog. You can log in with your GitHub account to leave a comment. I work in open-source community operations. I am far from an expert, but I would love to connect and discuss. My WeChat ID: zhaofawei26.