Skip to main content
  1. Blog/
  2. Community Ops/

Three Years of Open-Source Community Operations: What I Did

·1108 words·3 mins· 0
Fawei
Author
Fawei

More than three years ago, I joined the QingCloud KubeSphere team to do open-source community operations. Before that, my understanding of open source was shallow and I lacked experience. After three years, I cannot claim big achievements, but I have learned a lot. In this post I整理 and share those lessons.

Preface
#

I have written posts about community concepts and my operations experience. If you are interested, feel free to read them.

I usually write from three dimensions: content, events, and users, because they are the major parts of community operations (in my view). But operations includes more than these three, so I will try to be comprehensive.

Content operations
#

Content is critical to community growth. An open-source community usually includes:

  • product documentation (usually on the website)
  • technical sharing (articles/videos)
  • promotional content

This content is published on key channels: website, WeChat official account, GitHub, Bilibili (or video platforms), and high-traffic tech sites.

Based on this, content operations generally include:

  • improving documentation
  • maintaining a steady stream of articles to grow followers
  • producing videos through online live streams and offline events

Below are the focus areas from my work.

Technical articles
#

The KubeSphere WeChat account has grown steadily thanks to continuous technical content.

Technical articles include user cases (best practices), installation/deployment, and deep dives.

Documentation exists, but it is often not detailed enough. We can expand it into more detailed “doc-style” articles, especially installation guides.

Technical content comes mainly from two sources: engineers and community users.

To encourage output, we set incentives. For community users, we offer honors (contributor titles/certificates) and material rewards (fees or swag). For users who consistently contribute, we provide special rewards.

Still, the number of users who主动 submit is small, so we need multiple approaches:

  • open calls for submissions via WeChat and forums
  • proactive outreach to users
  • finding content in tech communities and requesting reprint permission

Open calls often have limited effect unless rewards are high. Outreach and content discovery are more effective but harder: how do you find users who can write well?

In KubeSphere, we look for users with real implementation experience and invite them to write best-practice articles. Some users are not confident writers, so we designed a template to lower the barrier. This greatly increased output.

Contributors then enter an author pool and, with ongoing communication and incentives, some continue to produce new articles.

Recurring columns
#

Besides technical articles, recurring columns are useful. For open-source communities, a weekly or biweekly newsletter is especially valuable. It can include project updates (new features/releases), event updates, and new contributor spotlights (with certificates).

The goal is to help users quickly understand community status and recognize new contributors. Users do not need to track GitHub changes themselves, which saves time.

KubeSphere also created a “Cloud Native Weekly” column. After several iterations, it focuses on open-source project recommendations, article recommendations, and cloud-native news. The main goal is to attract more followers to the WeChat account so more people learn about KubeSphere.

Technical sharing videos
#

These videos come from community events and recorded tutorials.

KubeSphere has organized and participated in many offline and online meetups and live streams. All recordings are uploaded to Bilibili and the website. Some are from larger conferences like KubeCon where engineers and users share.

We also worked with Shang Silicon Valley to launch a K8s + KubeSphere course, which remains popular. It helps beginners learn the basics and improves retention. Courses can be a good approach, but quality control is essential.

Event operations
#

Open-source communities can increase visibility through events, generate content, and improve participation. It is a win-win-win.

KubeSphere events fall into three types: offline meetups, online meetups, and live streams. Offline meetups have the best atmosphere but cost more.

To reduce cost and increase impact, most meetups are co-hosted with partners (usually other open-source communities). Collaboration beats solo efforts.

We also participate in external events, such as other community meetups and conferences. We submit talks to large conferences like KubeCon, and fortunately many are accepted.

KubeSphere has participated in Open Source Summer for several years, an open-source program for students launched by the Chinese Academy of Sciences. A similar program abroad is GSoC.

Offline events mainly impact onsite participants. To extend impact, we must archive and redistribute content. Whether or not the event is live-streamed, we should publish videos afterward (unless restricted). Within a week, we publish a recap with videos and slides/PDFs.

KubeSphere uploads each talk to Bilibili and updates the website. Users can review through both channels. After updating the site, I also send a recap email to registrants with links and slide access instructions (often guiding them to follow the WeChat account).

User operations
#

A key task is understanding user composition and segmentation. Different users require different approaches.

For open-source communities, users can be roughly categorized as: users, code contributors, and non-code contributors.

User operations can be summarized as acquisition, retention, activation, and conversion (sometimes excluding conversion). I will not expand each here; I may write a separate post later.

One operation I especially like is the user committee.

Three years ago, KubeSphere had a solid user base and some active users. Inspired by the “cloud-native community,” we created the KubeSphere user committee and city chapters. Today there are five chapters: Shanghai, Hangzhou, Chengdu, Guangzhou, and Shenzhen. Each chapter has a lead, co-lead, and members.

With the committee, we organized offline meetups, company visits, campus visits, and more. Members stay active in the community by speaking, writing, mentoring Open Source Summer projects, and recording podcast episodes.

The committee has become a backbone of community operations and growth.

Other work
#

Although content, events, and users are the major parts, community operations includes more: ambassador recruitment and maintenance, partner expansion, and case-user discovery and maintenance.

Operations is complex and interconnected. Each task is not independent; they must be combined. We also need the right mindset and a correct understanding of open-source communities.

A few “common sense” points
#

  1. Contributor churn is normal. Whether code or non-code contributors, many are active for a period and then fade. If you can re-activate them, great; if not, do not force it. Do focus on consistently active contributors and expand the contributor base.
  2. User churn is normal. Users may stop using the product for many reasons. We should maintain existing users and grow new ones, while learning why churn happens and improving weak points.
  3. You cannot do everything users ask for. We cannot satisfy all needs or solve all problems.

These are my personal lessons. The writing may be rushed and incomplete. I hope more people share experiences and exchange ideas.