我的书签
添加书签
移除书签第 5 小节：开源项目的维护和管理
如何推广开源项目
「酒香也怕巷子深」这句话在互联网时代特别适用。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在还记得一句话 「一个公司的核心竞争力，一是技术，二是营销」。对于一个开源项目，将代码放发布到代码托管平台仅仅是一个开始，真正重要的是社区运营工作。如何让更多的人能够快速了解你的项目而不是无人问津？如何让有兴趣的人更积极的参与项目而不是永远仅仅依靠一己之力不可持续？这些都是非常现实的挑战，也是一个开源项目能否健康发展的重要基础。 Apache 软件基金会（ASF）的 Apache Way 的核心理念就是 Community over Code （社区重于代码），也说明开源项目建立社区的重要性。
要做好一个开源项目的推广，项目内容中除了源代码之外，完备的文档体系对吸引大家关注以及参与都是非常有帮助的。总之，如果仅仅只有一堆源代码，会让很多人都望而却步，以下简单列举三个非常必要的文档和规则说明。
项目总览自述文件（README）
开源项目中的 README 文件是非常重要的，你可以在 README 里面系统介绍有关这个开源项目的重要内容，包括项目主要功能特性、架构原理、安装及部署说明、简要的使用说明、目录文件结构、常见问题说明、交流沟通方式等内容，以便关注者能快速地了解这个项目的基本情况和总体情况。在常见的代码托管平台如 Github、Gitee 上，项目仓库首页默认展示的内容就是这个 README 文件的内容，相当于整个项目的“主页”。
贡献说明（Contributing）
任何一个开源项目，肯定都是希望有更多的社区参与者和贡献者，但是对于参与者如何参与项目贡献，需要遵循哪些基本规则，比如提交问题的规范等，如果是做代码贡献，还有代码相关规范等，以及参与贡献的完整操作流程，这些内容我们可以通过贡献说明文档来说明。另外，我们也可以对项目的社区治理架构及不同等级的贡献者的要求及权力做进一步说明，这些内容整体上构成了本项目在社区参与过程中的一些基本规范。
用户使用文档 （User Guide/ Getting Started）
对于开源项目来说，自身的功能与非功能特性固然重要，但如果使用体验不佳甚至很难上手，那么对用户来说门槛会变得很高，特别是对于有意向参与开发的用户来说，如果上手使用都不是很容易，那么参与开发的热情就会受到打击。因此，一份系统完整、条理清晰的用户使用文档，既能帮助普通用户快速上手使用，也能提升潜在开发人员的体验和好感度，进一步增强他们对该项目的兴趣和信心；而且通常开发人员都是从使用开始，发现 Bug，或者待改进的“痛点”，从而很自然地提出 Issue，并给出建议的解决方案。最后，这里的用户使用文档也可以是项目的技术文档（Document）或者教程（Mannuel）的一个重要入口，让对项目细节感兴趣的用户，可以进一步了解。
具体的开源项目推广方式比较多，宣传和更新维护都是一个漫长的过程，如果你不是明星账户，如 Google 或者 Twitter 或者 Gitee 上高 Star 项目作者，我们新人能做的只能是坚持。以下列举一些常见的方式。
1、选择一个平台作为你博客的唯一主页。例如使用 WordPress 搭建自己的站点，但考虑到建站还需要购买服务器或者空间，国内建站需要备案等，你可以考虑使用 Gitee Pages 或者 Github Pages 来搭建属于自己的个人网站。
2、写作投稿。将你博客的文章推送到各大流量较高的社区，比如国内比较活跃的知乎问答社区、前端人员聚集的掘金社区，以及 Segmentfault 和博客园等。回答别人的问题时尽力做到用心和详细，回答字数不宜过少，最好图文并茂，语言风趣幽默效果更佳，但切记胡乱回答，尤其专业问题没经过自己验证和测试就凭主观猜想回答。另外，在文章中给出项目地址、说明参与方式，通过这些方式也能够较低成本地将对项目内容感兴趣的开发人员引流到项目社区中，并吸引志同道合的开发者加入项目开源计划。
3、迭代更新。可以借助开源中国，Segmentfault，博客园，V2EX 等社区进行更新推广，以及 QQ 群等内部维护的社交渠道版本发布。在社区推广更新版本信息，可以让未接触过该项目的人对项目本身有一个初步了解，可能就会吸引到新的使用者，对已经使用的用户也可以接收到一个版本迭代更新的进度以及内容。
4、建立微信群、 QQ 群、钉钉群、微博、公众号、TG 群/频道等沟通渠道，还可以在项目文档中引入 Gitter 这类即时通讯沟通软件方便快捷。通过社交工具，可以更精准及频繁的传递项目信息，建立与社区参与者更高的黏度，充分挖掘社区参与的活跃分子并且通过各种活动方式，让项目社区逐渐形成并壮大；
5、参与或举办线上线下活动。开源推广跟其他产品或业务推广一样，需要通过不断的曝光、扩大影响范围等方式让项目覆盖更多受众，并且通过各种活动逐步培养项目的灵魂人物和大牛形象，从而吸引更多参与者；
6、让社区参与者参与宣传。在社区里面，一般有开发者、使用者、项目核心成员等不同角色，我们可以通过各种活动充分利用社区中除项目发起人之外的其他成员的现身说法以及经验分享，一方面鼓励社区内部自由充分的交流，另外这也是对参与者开源精神的认可和赞赏，对于其他参与者也有积极的引导作用。
7、社区联合推广。可以尝试与其他社区互动，联合组织上文提到的各种线上或线下活动，以便相互促进。选择联合社区时，优先考虑与本项目在生态上的可集成性、互操作性、兼容性较强的项目社区，且不限于开源项目社区，也可以考虑本地化的知名或热门技术社区。总的原则是目标群体聚集的社区，一般都是比较好的潜在联合对象。
项目被提交 Issue 时应该怎么做？
当我们的开源项目上线之后，后期是需要维护和版本迭代的。Issue 是记录各类 Bug、需求的方式，也是开发者之间非常重要的的交流工具。参与者可以通过各种状态的 Issue，看到针对各种问题或者需求的详细内容，也可以通过提交 Comment 的方式参与沟通讨论。 Issue 的数量、打开和关闭的比例以及针对 Issue 的处理是否及时等，这些都成为衡量一个开源项目是否健康且受欢迎的重要指标。
下面我们来探讨一下在不影响工作、生活的情况下如何有效率的持续迭代，如何将用户的提问引导到项目的 Issue 上来。因为：
1、你没有那么多精力去很多个平台回复问题。这一点与上一章节并不产生矛盾，项目宣传的时候可以去大流量平台做推广，但是当用户对项目有疑问或者 Bug 反馈时，尽量引导他们到项目的 Issue 上来。
2、你没有那么多时间天天盯着 QQ 群解答问题。刚开始入群的新人遇到问题会直接在群里艾特你，尤其是一些伸手党看都没看过别人是否提问过该问题，就想让你做他的客服。所以你不必理会，引导他们到你项目的 Issue 上来，这样久而久之用户就知道下一次遇到问题的时候先去你的项目提交 Issue。
3、问题应该被集中起来，供使用者反复查阅。
当项目维护者看到有 Issue 提交时，最重要的是迅速反馈，无论是 Bug 还是需求，都可以跟提出者通过 Comment 方式进行充分的沟通，达成共识，也可以对 Issue 打上标签，便于分类管理。另外，还可以将 Issue 分配给其他参与者，或者将 Issue 添加到项目的看板，关联到某个里程碑等操作，当 Issue 中的问题被解决后，应该及时做关闭。
当用户量增多，Isssue 中会提到各种各样奇葩的需求，这时候就需要你判断该需求是否应该被添加，以下是可以几个可以参考的指标：
1、该 Isssue 是用户提出的 Bug,则应当给与解决。
2、Issue 是很多用户提过的需求，即大众需求。我们的产品只需要满足 90%以上用户需求即可，我们不可能把产品做的面面俱到。当用户提出的是大众需求时，可以把该 Issue 纳入下一版本的更新。
3、你判断这个需求对大部分用户是否有用。
4、需求符合产品的定位以及未来发展方向，或者该需求能抹平和竞品的差距，或者能和竞品差异化竞争。
符合上述条件的 Issue 可以纳入下一版本的升级计划，如果不符合可以予以拒绝。总之是围绕 Issue 能够展开积极互动和响应，这样才可以让社区始终保持活跃，形成一个良性循环。
项目被提交 Pull Request 时应该怎么做？
当项目有 Pull Request 提交时，上面处理 Issue 时的一些原则同样适用，关键是能够快速反应，坦诚沟通，对提交的 PR 进行 Code Review，最终决定是采纳或者拒绝。当然做必要的自动化检查及测试，这是 Code Review 的前提，一个好的开源项目，应该利用各种工具链做好持续集成持续发布服务（CI/CD），尽量先用自动化的方式完成一些测试和验证，这样也可以提高代码输出的质量及 Code Review 的效率，同时，也可以在贡献说明中对代码要求规范、PR 提交规范等做好说明，避免让参与者在贡献过程中由于这些方面的原因感觉到挫败。
总之，对于开源项目的运营来说，非常重要的一个原则就是透明化，包括各种规则的透明、交流过程的透明等。
