开源朋友圈 | 周鹏飞：如何从零开始做好开源项目的技术传播？

周鹏飞，CNCF Ambassador，KubeSphere SIG-Advocacy Lead。
周鹏飞作为一个开源相关从业者，认为开源其实是一把双刃剑，开源并非只有大家上述看到的益处。开源还有很多“阴暗面”和让人劝退的地方，特别是在国内开源商业化环境不佳，比如开源用户的付费意识和对开源的理解认知有限的情况下，要做好一个开源项目和开源社区，最终实现开源商业化的正向增长，这绝非易事。
在项目早期，开源项目在全球的推广与技术传播对很多开源项目的创始团队和维护者而言，其实也非常有挑战。周鹏飞在之前四年作为早期团队成员深入参与过 KubeSphere 开源项目、社区与生态从零到一的建设。因此，此次分享更多地以 KubeSphere 社区为例介绍他们的经验。
最近两年，开源作为一种新的开放协作模式，在国内快速被越来越多的大厂和创业公司接受和推崇。我们看到各个大厂先后成立的开源办公室，以及 VC 们对各家开源商业化初创企业的持续投入，让“开源”这个关键词备受关注。
事实上，开源这个事情也是千人千面。在企业看来，开源可以通过跨组织开放协作的方式帮助项目获得更多的贡献，建立生态；在开发者看来，参与或发起开源项目能给自己带来好的技术口碑和职业发展的竞争力；而在部分 VC 看来，借助开源社区能够快速迭代产品和推广，形成一种新的获客增长和商业模式。
KubeSphere是基于Kubernetes的一个发行版，愿景是打造一个云原生分布式操作系统，帮助用户更方便地安装、使用和运维Kubernetes，并在Kubernetes之上完成应用的部署、分发和生命周期管理。最近这两年，KubeSphere开源项目和社区的发展都非常快速，至今已有近百万下载量，总的贡献者人数约 300 人，社区有三个子项目 OpenFunction、 OpenELB、 Fluent Operator都进入了CNCF 孵化。开源是一场无限的游戏，我们才刚刚开始，接下来我们来聊聊如何从零做好开源项目的技术传播。

从写好README开始

对于开源项目来说，README是开发者的第一印象。为什么要强调开源项目 README 的重要性呢？因为很多开发者，其实对文档类的东西是不太重视。但是，我们最起码要确保README的内容质量，因为它是一个开源项目的第一张名片。特别是在项目前期没有专门的人去做项目的布道和推广的时候，一定要把 README 文档写得足够清晰简洁，文档里 Demo和Quick Start 一定要非常简单易用。从项目官网的第三方流量长期观察来看，来自 GitHub的用户关注度是最高的。
Kelsey Hightower之前说过一句话：Documentation is a feature。对开发者来说，文档也是最实用的 marketing 材料。根据CNCF调研，当开发者去学习一项新的技术或开源项目，文档是排名第一位的。
一个简洁易读的 README 是什么样的标准？比如在10分钟内能不能让一个新的用户快速了解你的项目，一刻钟内能不能把这个项目部署起来。其实在README里面可以嵌入很多动态化的元素。比如Gif动图、表情符号、视频等。此外，还可以加入资源导航，将README做的和网站一样。需要特别注意一些不太合适的行为，比如在README里面放一些商业产品的宣传，或者是中文英文混用，内容过于简短或冗长，描述与定位不清晰等等。
对于如何写好最基础的开源项目文档，谭中意老师也发起和组织了几位有过专业技术文档写作的业内人士编写了一个中文版的《开源技术项目文档指南》（github.com/CommunityLe… 老师也有一篇文章《开源软件的技术写作》（www.tisonkun.org/2022/05/08/…

找到前1000个种子用户

HashiCorp 的联合创始人 Armon 说他能清楚地记得他们第一个产品的前一千名种子用户的名字。换句话说就是要跟早期的种子用户保持更紧密的更高效的沟通，了解用户真实的产品需求和痛点，与用户一起解决真实。
在开源项目冷启动的前期推广布道和技术传播主要分为四大部分：
第一点是关于线上线下的技术活动，参加一些项目相关领域的线下活动会更容易接触到这个领域的关注者，在线下进行交流和分享更容易与开发者建立信任。比如云原生领域的 KubeCon、ApacheCon Asia、Kubernetes Community Days、Open Source Summit 等都是非常知名的业内活动。
第二点就是要了解开发者所关注的平台，了解国内和海外哪些技术媒体和开发者社区是比较流行的。酒香也怕巷子深，输出了好的技术布道内容还需要找到更匹配的平台去发布和传播，才更容易获得新用户的关注度。我在这里总结了国内外几个比较活跃的适合做技术内容传播的开发者社区。

第三点是刚刚提到的要有专业的文档和教程，文档包括用户指南和贡献者指南。文档的内容形式也可以丰富多样，除了常规的图文以外，用“asciinema”录制命令行动画也很酷，可以把命令行动画嵌入到官网中。如果是带用户界面的开源项目，录制一些操作视频和中立的技术教程发布到YouTube 或者 B站上效果通常也不错。

最后一点是注重提升内容的 SEO和社交媒体运营，这一点可能偏 Marketing 的角度，但也确实是非常有必要去关注的。如何让开发者在搜索引擎通过高频的关键词就能在排名靠前的搜索结果中快速找到你的项目官网内容非常关键。Twitter 也是很多开源社区喜欢的社媒平台，我们也经常用 Twitter 跟社区的用户和合作伙伴进行公开的互动。

培养健康的开发者关系与生态

当社区有了开发者加入后，怎么把开发者留下来并深度参与社区？这可能是很多做开源社区的朋友非常关心的问题，健康的开发者关系和活跃的社区生态很关键。这里所谓开发者关系可以分类两类，分别是社区与开源用户和贡献者之间的开发者关系，这就非常依赖我们经常提到的开发者体验。对于一些资深用户而言，即使他们不会写代码，通常我们也可以鼓励用户参与非代码贡献，比如测试、文档、国际化、翻译、用户案例分享、线下演讲等等；而对于一些深度参与的代码贡献者，在 Apache 基金会和 CNCF 基金会都有类似的认可机制，比如邀请贡献者加入社区成为 Member、PMC、Maintainer，往往这样的社区 title 会让社区成员获得非常大的认可和信任感。
社区通常是一个大型而离散的虚拟组织，而通过组织一些小范围的线下或线上的兴趣讨论小组和 Meetup 也能够帮助志同道合的人群在一起协作，建立共识。比如KubeSphere社区平时会组织一些特别兴趣小组的SIG 讨论组和例会，并且日程在 KubeSphere 官网的日程表上也可以公开访问，中文例会的回放会上传到B站，这个也是学习K8s社区的玩法。
对于社区生态，我们非常关注我们的开源产品与上下游的主流开源项目的互相集成，以及跟云厂商的合作。当开源软件互相集成后，两个社区彼此都会很乐意去帮忙互相推广。此外，我们还发现海外的云厂商合作心态会更加开放，比如 KubeSphere 跟 AWS、Azure、DigitalOcean和 Civo Cloud 的应用商店都有上架，与其公有云上的托管 K8s 服务提供了集成方案，这也为 KubeSphere 在各大云上的快速部署带来便利，以及各个云上的用户。