特别说明：本文由开源之道发布并授权转载。
不知何时，互联网增长成了大众喜爱的内容，相关的书籍、讲座、培训层出不穷，仿佛这些人洞悉人性，知道人们的欲求一样。最后则是本末倒置，宛若功夫界的一句老话‘练拳不练功，到老一场空’，不去了解对应的群体，盲目的搞些哗众取宠的活动，是难以实现开发者增长的。
很荣幸，你我都经历了一个开源的黄金时代！如今的互联网公司也好，传统企业也罢，甚至是电信运营商、好莱坞制片厂、国家电网等等，都在拥抱和贡献开源，也有很多公司开源里自己的主导和发起的项目，那么问题来了，这些项目仅仅只是展示吗？这些商业公司显然不是在做慈善活动，那么其中最大的可能就是想利用公司外部的开发者帮助项目成长和发展，那么这些开发者会闻讯赶来？还是避之唯恐不及？
如果你是一名开源项目的社区管理者，该如何实现吸引开发者、留住贡献者、赢得用户喜爱？让我们来看看 Node.js 的社区经理分享的经验。
Node.js 在过去的一年（2015）里的重点工作就是吸引更多的贡献者参与进来，Node.js从创建以来，一直都保持着100%的势头增长着，但是实际上贡献者并灭有在增长。
经过这么几年的苦心经营和社区建设，Node.js社区是非常之健康发展的。项目经过了重组，分了多个组成的部分，而且现在有400多名成员。从大多数的仓库来说，我们可以看到约过半的贡献者都是新手，这意味着我们将用户转换为贡献者的数量比用户社区的增长高了六倍。众所周知，开源项目的健康度、生命力，贡献者的活跃度和增长是重要的指标。
在这其中我们学习、总结了许多，而且也准备好和大家一起分享，其中包括帮助扩展基础设施的工具、以及文化和核心价值观，即 透明度、参与度、效率，我们坚信这些想法和实践也是未来塑造开源的重要力量。
首先要和大家澄清一些概念和词汇，包括我们是如何定义组成社区的人们的。
为了能够使得上述计划实现自我运行和持续发展，我们还需要平衡好以下事项:
对待教育和对待技术问题是有着本质上的不同的。我们无法像解决代码问题那样来解决这个问题。人们一般都会有一个思维上的误区，那就是经常自以为是的认为他人的学习路径会和我们采取完全一样的。然而，现实中仍然有很多人采用这种糟糕的方式。人们来自不同的背景，各自处于生活和事业的不同阶段。为了能够让这些人选择学习如何使用你的软件，并且要留住他们、激励他们，那么就要做到能以他们感到舒适的方式去学习，最好是产生一些共鸣。这就要求社区去了解人们如何学习，并尽可能为他们提供有利的资源，而不是试图将他们引导到我们过去学习的路径上。这意味着你要释放所有的教育资源：从API文档、博客、到研讨会，乃至传统意义上的培训。
这些资源之间并不存在竞争的情况，只要统统都是开放、以社区为导向的方式完成，都是非常受欢迎的。这依然是我们在努力做的事情，因为它实际上永远也不会结束，但你可以看到 NodeSchool 对 Node.js 社区的影响。在 NodeSchool 的支持下可以将 WorkShop 下载下来，然后在家里就可以完成，而且还有一个代码仓库，学员遇到难题可以在此求助。同时，NodeSchool 社区在全球范围内有数百个地方分会，这些分会在当地举办小型实践研讨会。对于很大一部分人来说，编程活动开始的时候还是蛮难得，有了 NodeSchool 的帮助，可以有效解决这个问题。每次的线下活动同时也会录制下来，如果有什么问题的话，在将来可以继续提问。NodeSchool 最终以这样的方式吸引了两种截然不同的入门级用户，更重要的是这些用户已成为发展我们社区的巨大资源。
一定数量的用户成为贡献者，然后是一定数量的贡献者成为项目的领导者，这取决于将它们从一个级别转换为另外一个级别。虽然大多数项目认为之所以缺乏贡献者或领导者，是因为流程的问题，但是我以为他们是错的，其实是一个转换的问题。在开源的世界中，用户往往就是开发者，这些用户或者本身就具备了能够以某种方式作出贡献的能力，或者是稍加点拨学习点东西就可以实现，要完成这些转换，我们需要做的仅仅是降低这些进入的门槛。贡献、审核、发布等这些重要的鼓励和留住开发者的的流程是应该有相应的学习工具和程序的。
GitHub 在这方面做的相当出色，其设计的单个工具链，从修改软件、到修改后发送补丁到项目、再到补丁被接受，优雅而简单，被所有的开源项目所接受。这要感谢 GitHub，它是的开发者从一个项目无缝切换到另外的项目，尽管如此，但是项目之间还是有着许多微妙的差异的，例如如何合并代码、需要何种元数据、获得提交权限、以及在提交之后的整个项目的发布过程等等，当涉及到用户转换为贡献者时，这些策略就会导致项目存在很大的差异。
在 Node.js 项目中，新贡献者占每月所有贡献者的量约为 50％。考虑到 Node.js 用户每月增长率约为 8％，这是令人难以置信的。我们的贡献率不仅仅是 Node.js 总体增长的产物，而实际上是我们所谓的自由贡献政策的胜利。
Rod Vagg（现任Node.js的技术委员会主席）几年前实验了一个针对新晋贡献者的政策，他称该政策为：开放的开源项目，并从本质上强调：
在这一点上Node.js和很多传统的开源项目的做法是完全不一样的，传统上习惯于保护只有少数人才能是 Committer。他们之所以这么做是因为过去的版本控制系统容忍错误的程度太小，这和现在使用的Git分布式版本控制系统是不可同日而语的。在 Git 当中，几乎不可能存在一个人犯了错，而其它人完全无法修复或失去控制。这也就是说，新时代的 GitHub，赋予了 Commiter 更大的自由度。当然，赋予 Committer 权限也意味着一份承诺，尤其是对于新晋的贡献者而言。因为它为参与者提供了明确的证据，证明他们拥有项目的共同所有权。
增加更多的 Committer 也就意味着增加了更多的代码审核人员，这反过来又简化了处理更过贡献者的过程。当然，每个项目都是不一样的。某个运行良好的项目流程未必适合其它的项目，事实上，Node.js 核心是非常特别的，然而这也导致了各个工作组和仓库创建了多个不同的自由贡献策略。在设计这些流程当中，我们总结出来一个不成文的规则，即所有成功的政策都是在如下三个价值观之间的平衡：参与度、透明度、以及效率，这些值都不是绝对的，比如说不可能做到拥有100%的参与，同时还100%的高效，但是只用用心，总能找到三者之间的平衡，从而获得较高的转化率，反过来对项目有促进作用，保持更加健康的发展。
我们以实际的例子来阐述一番，Node.js 站点和 Node.js 核心的贡献策略绝对是天壤之别，在 Node.js 核心社区是工作在主干上的，即未来 Node.js 发布的基础版本，而其它的版本，如当前发布、长期支持 LTS、维护版本等从主干 Cherry pick 即可，这就要求代码提交必须是拥有清晰精炼的提交以及明确的提交消息，方能使得工作有效完成，因此，提交者无法使用 GitHub 站点提供的合并按钮，并且通常需要手动执行其他工作。虽然这么做某种程度上是有参与上的障碍的，但是这是项目有效发展的必要条件，但是，Node.js 网站项目就没有这些技术上的要求，也就是说，Node.js 网站的代码是可以使用 GitHub 提供的合并按钮的，而且代码提交也毋须做到拥有清晰精炼的提交以及明确的提交消息，这样对于贡献者的要求是相当低的。开源的开发流程，往往让新入门的生手望而却步，我们采取了一些必要的措施，希望这些政策能够有效鼓励大家的积极贡献，而不是让开发者敬而远之。
Node.js 的代码仓库是在不同的策略下进行的，或许看官会认为这么做会为项目贡献、参与带来一定的障碍，但事实上，这么做对项目参与是有益处的。事实证明，那些文化上障碍对于开发者的参与来讲，要远远大于技术的障碍，我们做到了消除这些文化障碍，结果就是有许多贡献者，在开始的时候做一些简单的工作甚至是“降维”性质的，但是，随着时间的推移，他们能够发挥自己应有的水平，而且还进入了诸如 Node.js 核心这样的工作组。
对某些人来说，为开源做贡献比其他人更容易。很多人担心因为没有做正确的事情或者没有适应而被大吼大叫。这些情感上的处理是项目中最为难以解决的事情，但是为贡献者提供一些较为低的进入门槛（文档、基于 Makedown 的网站内容等），可以大大减少这些顾虑，并且至少可以消除与他们自我感知的技术能力相关的问题。一旦人们对一个工作组感到满意，他们对其他工作组甚至核心的担忧就会明显地降低，因此，我们就看到了从本地化工作组、网站建设工作者等顺利的迁移到了核心工作者的例子。
采用“自由贡献政策”的成果是显而易见的，打破了常见的偏见，我们在许许多多的开源项目中看到，对于一个采用更具参与性的结构的项目来说，根本没有足够的“合格”或“熟练”的开发人员。并不是没有足够的潜在贡献者，而事实上往往是那些潜在的贡献者不想花时间在项目上，只因为这些项目缺乏恰当的参与激励措施，而且还设置了进入的门槛，而这些门槛对于那些已经是提交者的人来说视而不见。
对于项目来说，贡献者实行责任共担。而在这些贡献者当中，还有一小部分人比较特殊，那就是他们担当着决策者的身份，参与式治理的目标是确保贡献者对于决策组的信任实际上是赋予决策者的所有权，而且让责任尽可能的分散而不是集中。在Node.js 项目中，我们拥有由 TC（技术委员会）管理的顶级项目（TLP）。Node.js Core 是由 CTC（核心技术委员会）管理的顶级项目。
正如我们在前面讨论过的那样，当出现意见分歧而无法达成共识的时候，该组即是处理升级问题的机制，这也就意味着大多数的决策实际上是由贡献者共享的，至今还没有上升到到需要核心技术委员会来处理的问题。只有在极少数情况下无法达成共识时，才会将其发送给核心技术委员会。核心技术委员会还将许多责任委托给称为工作组的小组。这些工作组拥有自己的治理结构，以及自身的贡献者，工作组毋须向核心技术委员会报告，核心技术委员会成员无权对他们委派给这些工作组的任何事项作出决策。这种无政府主义的方法消除权威而不是将其集中在传统的层次结构中。顶级项目技术委员会与核心技术委员会一样，也有一些基本治理规则，可以保护项目免受不当影响。
寻求共识一直都是 Node.js 项目中最为有效的工具，它鼓励人们一起工作并达成协议，它不会像纯粹的共识那样奖励坚定的人或者不采取行动。纯粹的共识是给了每个人一个否决的权力，这样就会导致参与者在他们不希望发生某些事情时说服他们的同事的动机很小。如果无法达成共识，不去投票就意味着任何有利于改变的人都必须说服他们的同行，就像那些支持改变的人一样。
现实是较为乐观的，也是令人难以置信的，因为我们从未真正因为缺乏共识而被迫去进行投票。之所以这么说，并不是说我们就没有分歧，而是说总是能够找到妥善的处理办法，最后但同样重要的是，所有决定都是在 GitHub 平台上做出的。这样的透明度对于从贡献者转变为领导者（未来的 TC 成员）至关重要，因为他们可以看到所有正在发生的全部过程。核心技术委员会每周都会召开一次电话会议，从而强制对有争议的问题做出决定，以为贡献者的前进扫清障碍，只有在 GitHub 上进行了长时间的讨论，才能将这些内容升级到 CTC。电话会议以及详细的会议记录会一并发布，大多数工作组会议也是这么做的。
大多数项目在一开始新建的时候，都希望从过去的老的项目中获得灵感和指导。就在我们考虑将更多的项目纳入 Node.js 基金会的时候，我们发现开源界很多基金会都为进入基金会项目规定了一个流程，我们暂时还没法做到像其他基金会那样，我们都是一些发展非常短暂的项目，唯一的做法就是只能走一步看一步，所以没有人觉得这些规定是否合适。
相反，我们开始更多的考虑为什么这些政策对于我们是有效的，以及我们为何因为一些假设的价值而去创造它们。其实道理很简单，那就是项目是一个孵化的过程，其旨在指导，确保参与者能够采用项目、保持透明度、以及效率提升的过程，而不是眼睛光是盯着那些规章制度和流程。
以上就是我们要和开源世界的大家所分享的有价值的内容以及我们最佳实践，希望各位看官能有所收获，尽管仅仅是我们的成功经验。当然，事情不可能就此止步，未来我们可以在开源的世界中进行更为广泛的思考和讨论，以更好的方式让人们参与并融入到开源社区中来。
Mikael Rogers ，他是 Node.js 基金会的社区经理，Mikael 长期以来都在Node.js 和 JS 方面保持活跃，也是对应开源项目需求的积极贡献者，他也是NodeConf 和 JSFest 会议的发起人，他曾在DigitalOcean，CouchOne，Mozilla，Yammer 以及其他科技公司任过职。
本文由作者Mikael Rogers 发表在Opensource.com上：Growing a contributor base in modern open source。开源之道精心翻译共享。本文在Creative Commons BY-SA 4.0许可证下发布。欢迎转载！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。