周鹏飞：如何从零到一为开源项目构建开源社区 | DEV. Together 2021 中国开发者生态峰会

内容来源：2021 年 6 月 5 日，由 SegmentFault 思否主办的 2021 中国开发者生态峰会圆满落幕。会上，KubeSphere 开源社区经理、CNCF Ambassador 周鹏飞发表了主题为《如何从零到一为开源项目构建开源社区》的演讲，分享开源项目和社区在初步建立时需要重点关注的事项。同时，他以 KubeSphere 开源社区运营的发展历程为例，介绍在围绕初创开源项目建立社区时积累的经验、好的工具和避坑指南。

 

分享嘉宾：周鹏飞，KubeSphere 开源社区经理，CNCF Ambassador。

 

速记整理及发布：SegmentFault 思否编辑部

 

 

从零到一：Go Big or Go Home

在开源项目孵化初期，公司能给到的资源和人力支持通常是非常有限的。特别是在创业公司，项目早期阶段只有几个核心研发人员，在公司内部和外部能利用的资源都是捉襟见肘的。在初始阶段，公司可以考虑从最基本的事情做起，把社区和开发者最关注的核心内容做到最专业，然后逐步地借助社区带来的用户和贡献者资源将开源项目一起做大。

 

哪些基本的内容是社区和开发者最关注的核心内容？如何投入有限的资源为项目和社区的发展快速破冰？今天将从以下四个方面跟大家分享和探讨：

 

1. 从写好 README 开始
2. 找到前 1000 个种子用户，打造社区闭环
3. 竞争壁垒：社区与合作生态
4. 开源商业化的初探

 

从写好 README 开始

 

README，不仅仅是说明书，它还是开源项目的第一张名片。

 

很多企业给开源项目做推广时，花了很大的精力和预算做 PR 文章，但没有花更多时间打磨和完善 README。GitHub 自身就是一个很大的社区，有自己的搜索引擎。从我们的长期观测来看，我们开源项目的官网和 GitHub 仓库的外部流量来源占比最大的还是来自 github.com，这意味着有大量的开发者通过 GitHub 自身的搜索引擎找到你的项目，然后从 README 快速了解一个新的开源项目。

 

 

Tips for README

大家都知道，一份看起来专业、吸引力的 README 更容易让读者有兴趣下载安装和体验你的开源项目。所以 README 的关键不仅需要在 10 分钟内，让新手快速了解你的项目定位（即 What, Why, How），还可以在 README 中尽量体现社区的活跃度与多元性。我们可以在 README 中灵活地应用一些有趣和易理解的图、文、Gif 动画、视频和表情包，帮助项目新手快速了解项目的功能和应用场景。

 

但要注意的是，README 中不要带商业与市场推广的内容，这是社区开发者比较反感的。建议使用英文来书写 README，用言简意赅的技术语言风格，避免写得过于简短或过于冗长复杂。

 

README 最基本的内容结构

下图是 README 最基本的内容结构，我们可以在 README 顶部放一个常用资源的导航，比如官网、论坛、文档的入口，还可以用 asciinema 录制命令行动画，或放上几个关键的 UI 操作截图和交互的 Gif 动画。如果有必要还可以放一个跟同类型项目的对比，在 README 底部可以尝试用 all-contributors Bot 工具自动展示项目所有的贡献者，并放上跟贡献者文档、开发者指南相关的链接。关于写好 README 可以参考的内容，推荐大家去看一个优质资源列表 Awesome Readme。

列表地址：

https://github.com/matiassingers/awesome-readme

 

 

找到前 1000 个种子用户，打造社区闭环

世界级开源公司 HashiCorp 的创始人 Armon 说自己能记住自家开源产品前 1000 个用户的名字，另一个创始人 Mitchell 每年飞 35 万公里和各大公司的程序员见面，向他们介绍和布道自家工具。这充分说明，种子用户对于早期打磨开源产品的重要性。

 

 

项目冷启动的推广：靠技术活动破冰

项目刚开源不久，自然没几个人了解你的项目，前期想自己组织活动号召其他人来参与的难度肯定不小。我们项目在早期也尝试过花大力气来办线下产品发布会，找过各种渠道招募，但是效果并不佳。后来我们选择走出去，参加行业内和其他社区组织的顶级技术会议和活动，比如 KubeCon、DockOne 社区、Cloud Native Taiwan 的技术活动，出去分享我们项目的技术架构和实现，交流社区当下流行的技术，以 “码” 会友，而不是直接去介绍和推广产品，这样也就让很多极客和开源爱好者对我们的开源项目有了尝试的兴趣。

 

通过外部的技术活动收获了一些早期用户后，产品逐渐有了一些口碑和人脉的传播，于是我们也开始尝试自己组织 Meetup，在线下与这些种子用户和开发者面对面交流，同时也建立了社群保持持续沟通。社区的本质永远是人，维系好跟种子用户间的开发者关系，通过他们的反馈快速迭代几个版本，产品也将会逐步贴合更多主流用户的需求。

 

 

了解开发者关注的平台

找到开发者所关注的垂直内容平台是输出和发布技术内容的前提条件。开发者通常会关注自己感兴趣的几个垂直社区，在国内有 CSDN、SegmentFault、OSChina 这样的开发者内容社区；而在海外除了三大社交媒体，也有像 Reddit、DZone、InfoQ 这样的垂直技术论坛和技术媒体，我们可以借助一些工具（比如 OpenWrite）将优质的技术博客文章分发到这些平台，也可以找这些平台寻求技术内容层面的合作。

 

专业的文档与推广同等重要

从 CNCF 2020 年度用户调研报告的数据来看，大部分开发者学习一项新的技术都是通过 Documentation 来入门，这个比例将近 80 %。谷歌和 Kubernetes 首席技术布道师 Keisey Hightower 在前两个月也发表观点说“文档本身就是一项产品功能”，此前还有 Jeff Lawson 表示“文档就是面向开发者最直接的 Marketing 材料”。

 

 

这些信息都足以证明，开发者学习新技术最依赖的就是文档。提供易用和完善的用户与开发者文档，应该是每一个开源项目和社区在早期需要优先重点考虑的工作。文档最好英文优先或者支持中英文双语，很多开源项目的中文文档也有社区贡献者参与翻译和维护。通常情况下，一般人不会花时间阅读完所有的文档，所以给文档设计 10 个以上的手把手快速入门示例（Hands-on Labs）也是非常有必要的，这样小白用户也能快速上手新项目。

 

高质量的技术文档通常还可以作为社区用户对外技术传播的内容素材。比如很多优秀的程序员小哥哥们都有自己的公众号和个人博客，我经常看到他们的技术博客或经验分享中会参考和复用一些文档中的内容。

注重 SEO，让搜索引擎为你带货

SEO 其实是一个非常专业的领域，值得长期投入，但在前期至少需要有一些基本的 SEO 常识，比如知道自己的项目能跟哪些热度高的关键词有关联，了解新用户通过哪些关键词找到了你的项目官网上的哪些内容。我们可以用 SEMRUSH 和 Keywords.com 等工具去检测和官网相关度和搜索指数较高的关键词，然后有针对性地根据这些关键词来输出技术博客和文档。

 

在进行技术内容创作时，除了灵活应用关联度高的关键词，还有一个很重要的常识：文档与技术博客最好能更多地布道通用的技术，不局限在产品本身，过多的 Self-marketing 内容会适得其反。在输出了一些技术内容后，我们还需要关注 Google Search Console 的搜索结果，做好定期分析与复盘。

 

自动化工具：工欲善其事，必先利其器

当有一大批用户通过各种渠道了解到我们社区的开源项目并下载使用后，这时候我们需要密切关注种子用户的反馈，了解用户是在什么场景下如何使用我们的开源项目。

收集用户反馈，让数据会说话

我们始终相信好的产品是用出来的，有很多社区用户非常乐意帮助我们打磨产品，他们会提很多有意思的需求或反馈，有时候也会吐槽产品或文档的不足。

 

 

运营开源项目有一个问题是你很难知道哪些人下载使用了你的产品，如果想更加精准地定位社区用户的画像，并对需求反馈进行收集，Hotjar 是一个很合适的工具，它可以用来收集用户反馈与监测网站。我们在 KubeSphere 文档页面接入了 Horjar 调研问卷，三个月内就收集了数千份反馈数据，也从问卷的数据分析中了解到大部分用户真实的使用场景，比如在国内有将近一半的社区用户会选择在物理机环境离线部署集群，这个结果是我们未曾想到的。

 

除此之外，还可以使用 Google Analysis 进行网站访问数据的分析，以及使用 Kibana 进行下载数据报表的自动绘制。还有一些你可能会关注的数据，比如统计开源项目在 GitHub 上的各项指标在一段时间内的增长情况，你可以使用 Nebula Graph 社区开源的 GitHub Stats 工具 进行自动统计，它可以帮助你了解开源项目的实际活跃程度。

与用户保持互动，解决问题并反哺产品

有了一批用户安装和使用产品后，社区自然就会变得非常活跃，而在这个时期跟用户及时沟通交流并帮助他们解决落地生产环境时遇到的问题就变得非常关键。社区沟通交流的渠道其实不太好做限制，我们社区的做法是，当下流行什么工具，我们就用什么工具。比如国内我们用微信群和中文论坛，面向国际社区我们用 Slack 和 GitHub issue & Discussion。

 

对于搭建、运营和管理这些沟通平台，社区也有成熟的工具来实现。比如社区论坛可以用开源的 Flarum 或 Discourse 来部署，KubeSphere 中文论坛就是用 Flarum 来实现的。对于想自动化管理微信群和群好友，可以尝试开源的 Chatbot 工具 WeChaty 或句子互动，这些工具都可以帮助我们提升运营的效率。

网站建设与开源协作自动化

前面我们提到过专业官方文档在社区的重要性。而文档需要静态网站来承载，社区也已经有一些免费或开源的轮子可以让我们快速建站与运营。比如 KubeSphere 官网就用到了 Hugo 框架来搭建，使用 Netlify 提供 Pull Request 的内容修改预览。

 

这里我想给大家安利一下 Netlify，官方非常热心地为开源项目提供了免费的账号来支持开源，在 Netlify 官网即可申请。最后，还可以借助 Cloudflare 免费的全球 CDN 对网站进行加速，这样就可以确保静态内容网站能够基本正常运转。

 

开源协作肯定离不开在 GitHub PR 和 issue 里的各种沟通。为了提升在 GitHub 上协作的效率，Kubernetes 社区开源了一个 ChatOps 工具：Prow，帮助社区参与者自动化地管理社区的 PR 和 issue、自动执行 Job 等。我们在项目初始就把 Prow 用起来了，ks-ci-bot 活跃在 KubeSphere 社区所有的 PR 和 issue 下，帮助我们实现自动合并 PR、打标签等日常操作。关于 Prow 工具的详细介绍可以参考博客。

博客地址：

https://kubesphere.io/zh/blogs/prow/

社区核心：培养社区归属感

在互联网运营中有一个经常被提及的说法是“留存率”。社区如果要长期聚集人气也需要提升留存率，这体现在用户和贡献者在参与一个开源社区时，社区能否给他带来归属感。每一个社区都会有它的温度和属性，社区的建设者对待社区的态度和传播的价值起到了决定性的作用。

 

设置社区组织架构与荣誉机制

对于开发者群体而言，开源组织用官方公开的渠道认可开发者的贡献大多时候要比物质奖励更有效果。很多开源组织和社区会使用证书和纪念周边的形式给予贡献者奖励，用公开的社媒来表达对贡献者的认可。KubeSphere 社区也不例外，除了根据不同的贡献程度设立不同等级的贡献者 title，我们还会在用户数量靠前的几个城市设立用户委员会，帮助委员会在当地自行组织活动与交流。

鼓励非代码贡献

社区的发展意味着多元化和多样性，贡献的形式也不局限于代码。即使社区里有一些不会写代码的同学，我们也同样会鼓励他们来参与社区贡献，比如参与文档撰写、布道与推广、案例分享、技术博客、录制教程、活动支持、需求建议反馈、国际化与本地化、测试等工作，可能会有很多不同背景或角色的人有兴趣参与进来。社区建设者只需要不断地去播种，把这些贡献渠道设计好，帮助全球的社区关注者参与进来，并且持续地优化贡献者体验，最终一定会带来不一样的惊喜。

 

 

开放交流与社区例会

在社区里的交流方式如果只有文字会比较冷冰冰，定期举办社区 SIG 例会可以让开发者之间有更深度的技术交流，让社区成员了解项目当前的一些新的特性开发和规划等进展，也能提升社区的活跃度。

 

SIG（Special Interest Group）是 Kubernetes 社区首创的玩法，持续运作的 SIG 机制帮助 Kubernetes 社区变得高度自治。我们社区也在学习 Kubernetes 的 SIG 玩法，在社区定期举行各个 SIG 的双周例会，将所有 SIG 例会的会议信息日程公布在官网，并在会后将 SIG 例会的录屏上传到 B 站，方便社区开发者回顾。

竞争壁垒：社区合作与生态

一个开源项目发展得是否健康，除了功能本身的快速迭代以及社区用户和贡献者的多样性，社区的周边生态也很重要，这会帮助开源项目本身构建更高的竞争壁垒。比如有多少相关联的开源项目能够合作与互相集成，有哪些云厂商能够提供托管与支持，这些合作不仅可以帮助开源项目丰富社区的生态，还能够让不同合作渠道的用户了解到你的项目。

 

 

社区合作的思路很简单，哪里有这个垂直领域的开发者和用户，那就尝试去跟这个平台合作。举个例子，对于 KubeSphere 而言，各大公有云 Kubernetes 服务的用户极有可能会是 KubeSphere 的用户，所以 KubeSphere 跟全球的各大云厂商合作是很合理的，目前 KubeSphere 已经与 AWS、Azure、DigitalOcean 和 QingCloud 等平台的容器服务进行了深度集成。另外，我们还会看上游社区的哪些项目可以跟 KubeSphere 产生紧密的关联，比如 Istio 社区我们也有去参与合作，并作为其 Provider。

开源商业化的初探

我们做开源商业化的一个核心原则是不能伤害开源社区和突破开源用户的利益边界。因为当开源社区用户发现厂商想来割开源的韭菜，那他们可能放弃使用转而寻找新的替代方案。很多人都说海外的开源用户商业合作意愿更好，比国内用户更容易付费，这可能是部分开源商业化公司还没有真正了解国内开源用户的真实商业诉求。

 

 

开源商业化公司需要先了解开源用户真正的诉求和希望解决的核心问题，然后去解决他们的核心问题，提供他们想要的增值产品与服务，这样的商业化路径可能是水到渠成的。我们在社区曾经调研了一百多位用户，发现这其中不仅有 80% 以上的用户是有在公司内采购话语权的，并且大部分是中小型互联网行业的用户。

 

因此，在了解用户画像以后，我们正在探索一种更低成本、产品服务付费方式更灵活的线上商业模式，这是适合互联网公司的玩法；而对于传统行业与金融政企类客户，还是通过既有的线下商业模式去推进。

 

以上是我今天分享的内容，大家如果有任何问题，欢迎随时与我探讨和交流（微信：13006337550）。 

关注【开发者生态】公众号回复：zpf 下载演讲 PPT

点击【阅读原文】观看周鹏飞演讲视频，重温精彩时刻

关注公众号：拾黑（shiheibook）了解更多

赞助链接：

关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/