对一个开源项目来说，社区是至关重要的。活跃而强大的社区无疑是项目的心脏。然而，只有开源许可是不足以吸引用户和开发者参加项目并共同建立社区的。本文介绍如何建立一个成功的开源社区。
事实上，启动开源项目与启动其他类型的软件项目并没有什么不同。开源项目的启动，或者是因为某人想开发某个软件，或者是在产品开发中，某人想满足别人的未来需求。在前一种情况下，开发者可能永远不会考虑共享最终成果，而在后一种情况下，开发者会出于某种目的而共享软件。
社 区就是有共同兴趣的一群人。开源项目和闭源项目都有用户社区，大部分用户不会积极地与社区其他成员互动。而另一方面，无论是开源社区还是闭源社区，都会有 成员愿意更积极地参与，例如，报告 bug、帮助其他用户、撰写文档或进行推广。最活跃的社区成员甚至可以得到回报。例如，微软通过最有价值专家 (MVP) 项目奖励帮助人们充分利用微软技术的用户社区成员。在开源社区中，活跃的成员往往会获得额外的项目访问权和管理权。
虽然闭源项 目也有奖励，但通过奖励社区成员而取得项目贡献毕竟有明确限制。由于不能公开验证代码，因此用户无法真正深入项目、解决问题或开发新功能，或者贡献代码。 相反，在开源社区中，信息（代码和文档）可以从任何社区成员流入社区中心，尽管管理者会加以调整。更重要的是，一旦出现任何问题，社区中会有很多“眼球” 盯着它，以便集思广益、群策群力。在闭源项目中，解决某个问题的最多人数总是由受雇的开发者人数决定的。
社 区创建之初可能非常小，可能只有一两个开发者，几乎没有用户。根据项目的类型，这种情况可能会持续一段时间，甚至几年，在此“孵化期”，初始团队会努力工 作打下基础。Eric Raymond 在《大教堂与集市》中指出，成功的一个必要条件是，开发出可运行、可测试的东西，让游戏继续下去。注意，“可运行”并不意味着完美，甚至可以不完整。“早 发布，多发布”是一条众所周知的开源开发准则，主要是因为这样做可以获得宝贵的早期反馈，帮助项目团队建立自信。因此，社区不应对早期发布存在顾虑或迟 疑；只要能够明确、如实地管理期望值，早期发布将使项目受益良多。
软件要最终吸引用户，软件的演示和品牌推广必须让潜在用户相信，该软件与 竞争性产品相比有显著优势。引起用户的兴趣后，必须要降低进入的门槛：例如，安装等简单操作必须非常顺畅。用户注册并不是故事的结尾；从长远来看，还需要 更多开发者的参与，他们至少可以完成少量工作，如果仅依赖个别开发者，他很可能被这些琐碎的工作压垮。开发者可能直接从用户中产生，但也可能来自其他地 方，如为了挑战技术难题、为了声誉，或为提高或展示自己的编程水平而参与到项目中。
以这样的方式开放项目会带来新的复杂度。Karl Fogel 在《开发开源软件》一书中指出，“开放意味着以完全陌生的人可以理解的方式编写代码，建立开发网站和邮件列表，并往往需要撰写文档初稿。所有这些是很大的 工作量。当然，如果真的出现了感兴趣的开发者，在他们作出贡献之前，还需要一段时间来回答他们的问题，这也是额外的负担。”而 GitHub、Google Code、StackExchange 等协作工具至少可以部分分担这些额外工作。此外，开放项目并不一定意味着失去控制权。许多项目在初期采用贤明君主模式，由一个人负责开发主要新功能并审核 贡献的代码。
贤明君主的技术水平不必最强，但 Fogel 认为，他们应该“有辨别好的设计的能力”。但 Fogel 进而指出，他们的主要职责是确保参与者始终相信“团队合作胜过单打独斗”。团队领袖必须有足够的凝聚力，让开发者愿意持续参与项目，只有这样，开发者才会 留下来。这意味着，应适当回报努力工作的人，如给予适当的肯定，或根据开发者的意愿赋予更重要的工作职责。人们已将开源项目管理描述为一项活跃、灵活而低 调的工作。
社区领导者的责任是，确保环境条件始终有利于充分发挥开源的潜力。这样的条件不会自动形成，而需要悉心管理。
在 项目早期阶段，最重要的问题可能是如何应对不可避免的支持负担。如果处理不善，至少将导致用户流失，而最坏的可能是创始者放弃项目。要取得成功，领导者最 终必须找到能完成工作的人。雇佣人员是一种选择；另一选择是鼓励用户通过撰写文档和修复 bug 来相互帮助。然而，要做到这一点，首先基础设施必须到位，这样参与者才能在此基础上为项目作出贡献。项目领导者必须积极鼓励参与者作出贡献，同时应确保贡 献是有帮助、高质量的。
项目启动后应持续满足成员的需求，这一点很重要。如果项目不再能满足成员的需求，那么那些认为自己的利益未被满足的 成员可能拿走代码库，转而自行开发。这一过程称为分化（“fork”）。需要注意的是，分化不一定是坏事，它可能只是因为社区的部分成员有一些特殊需求， 他们认为自己的需求无法与更广泛社区的需求达到平衡。另一种可能的情况是，已确立的治理模式不再符合项目的最大利益，因此社区决定以新的治理结构进行新项 目的开发。然而，应避免因个人冲突或简单分歧造成的分化，因为此类分化会导致社区分裂，令用户感到困惑。为避免此类分化，项目领导者应努力确保所有贡献者 感觉到他们可以自由参与决策过程，即使最终他们的意见未被采纳。
随着分布式版本控制系统，特别是 GitHub 等托管网站的兴起，“分化”这一术语有了新的含义，表示个人开发者获取己发布代码库的副本，进行更改以满足自己的需求，并往往将更改交回原始代码（称为拉 ‘pull’或合并‘merge’）。这种意义上的分化与前述分化大不相同，前述分化指围绕项目的社区被分割，而不仅仅是代码的分割。
为保持社区的健康发展， 开源社区必须能够超越创始人原有的个人兴趣而可持续发展。如果社区在很大程度上依赖于“君主”，那么当领导人离开或退休时，社区也将面临分裂或瓦解的风险。
在 大多数社区，甚至是贤明君主模式的社区，创始人以外的其他参与者将在关键决策过程中发挥越来越重要的作用。其必然结果是，社区转向以共识为基础的民主治 理。这种新的模式并不意味着所有决定，甚至是小决定，都由委员会作出。大多数时候，提议是根据“懒惰共识”来决定的，即“沉默表示同意”。对于未能达成共 识的提议，大多数社区坚持采用某种投票形式来决定。
这些惯例和程序越复杂，它们在指导新加入者如何参与项目、如何在决策中取得发言权方面就 越重要。新社区可以依赖于逐渐积累、并以邮件列表形式获取的知识体系，但这种知识体系并不总能帮到新加入者，甚至会让他们感到困惑。我们需要的是书面形式 的治理模型，以便将已取得的共识以简明文档的形式呈现。规范化有助于确保社区有自己的生命——独立于任何个人的生命——只要对项目产出的真实的、持续的需 求存在，社区即可延续下去并不断发展壮大。
围绕开源软件建立社区可能是一项缓慢而艰巨的工作，其成功取决于很多因 素。然而，没有社区也就没有项目。社区不会自动建立，社区的建立需要悉心管理。所有社区都始于被软件的包装、品牌推广或口碑推荐所吸引用户。一旦有了用 户，不辜负用户的高期望又成为新的挑战。一个繁荣的开发者社区能够满足并超越这些期望，但前提是他的领导者具有凝聚力，能确保参与者不偏离轨道。从长远来 看，社区需要落实开放开发机制，以确保包括创始人在内的关键贡献者离开时，他们的角色可由他合适的人选填补。
原文来自：OSS Watch 作者：Matthew Mascord
本文由CODE翻译社区翻译，译者：跳蚤图，审校：微软开放技术的齐捷
原文：http://www.cnblogs.com/Impulse/p/4373643.html