社区对于开源项目至关重要。一个积极和支持性的社区是该项目的核心。然而，只是拥有开源许可证并不足以将用户和开发人员带到您的项目并建立一个社区。本文档着眼于如何造就一个成功的开源社区。

为什么要开始开源项目？

开源软件项目与其他类型的软件项目在启动方式上并没有什么不同。他们开始要么是因为有人想要建造一些东西，要么是在产品开发的情况下，有人打算满足其他人的未来需求。在前一种情况下，甚至可能从未考虑过共享最终结果的可能性，而在后一种情况下，则存在共享软件的特定意图。

个人或组织为何想要开源一个项目，有各种各样的的原因，例如：

  • 协作： 开源项目可以接受世界各地人们的修改。 例如 Exercism 就是一个拥有350多个贡献者的练习平台。
  • 采用和重组： 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如，WordPress 就是派生自一个名为 b2 的现有项目。
  • 透明度： 任何人都可以检查开源项目是否有错误或不一致。

开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。

什么是社区，为什么开源项目想要构建它们？

社区只是一群拥有共同兴趣的个人。闭源和开源项目都有用户社区，其中大多数人在与其他社区成员的互动方面相对被动。另一方面，任何一种类型的社区都可能有成员决定通过报告错误、帮助其他用户、编写文档或传播等方式承担更积极的角色。最活跃的成员甚至可能因其努力而获得奖励。例如，Microsoft 奖励用户社区中那些通过最有价值专家 （MVP） 计划帮助人们充分利用 Microsoft 技术的人。在开源社区中，活跃成员往往会通过被授予对项目的额外访问权限和控制权来获得奖励。

虽然在闭源项目中有一些奖励，但社区成员可以做出的奖励贡献类型有明确的限制。由于代码不开放以供检查，因此用户最终无法实际修复问题或开发新功能并贡献代码。相比之下，在开源社区中，信息（代码和文档）从社区的任何成员流向中心的可能性是存在的，尽管是以适度的形式。更重要的是，对于任何给定的问题，都有可能让大量的“眼球”关注它，利用整个社区的脑力。在闭源项目中，查看任何给定问题的最大人数始终受雇开发人员总数的限制。

开源社区的典型路径

一开始，开源社区可能非常小，可能只有一两个开发人员，几乎没有任何用户。根据项目的类型，这种情况可能会持续一段时间，甚至几年，作为“潜伏期”，在此期间，初始团队努力工作以使其发挥作用。埃里克·雷蒙德（Eric Raymond）在《大教堂与集市》（The Cathedral and the Bazaar）一书中指出，成功的必要先决条件是拥有“可运行和可测试的东西”。应该注意的是，“可运行”并不意味着完美甚至完整。“尽早和经常发布”是开源开发的一个众所周知的口头禅，尤其是因为这样做可以吸引宝贵的早期反馈并建立对项目的信心。因此，社区不应对尽早分发材料感到恐惧或犹豫；只要对预期进行清晰和真实的管理，早期发布就可以实现显著的好处。

如果这款软件想要最终吸引用户，其展示和品牌必须能够让潜在用户相信，该软件在某些重要方面明显胜过竞争者。一旦激发了用户的兴趣，接下来的入门门槛也必须设置得低：比如，安装过程等简单环节需要非常流畅。不过，仅仅吸引用户还不是全部；从长远来看，也需要开发者的参与，至少要有人处理那些可能会让单个开发者陷入困境的小型贡献。这些开发者可能源自现有的用户群，也可能来自其他地方，被技术挑战、声望或是提升及展示他们的编程技能的机会所吸引。

在《Producing Open Source Software》一书中，卡尔·福格尔（Karl Fogel）深刻指出，以这种方式开放项目，无疑会带来一系列新的复杂挑战。他阐述道：“开放不仅仅是让代码对外人易于理解，还包括建立开发网站、电子邮件列表，以及往往还要首次撰写文档等工作。这一切无疑是艰巨的任务。而且，一旦吸引到感兴趣的开发者，还需要在他们真正贡献之前，花费时间解答他们的问题，这是另一重负担。”但幸运的是，像Github 等协作工具的便捷可用性，在一定程度上减轻了这种额外的努力。此外，开放项目并不意味着必然失去控制。很多项目在早期，往往以一种仁慈的独裁形式运行，由某位负责人来开发重大新功能和审查提交的代码。

福格尔在其著作中提到，仁慈的独裁者并不需要掌握最顶尖的技术技巧，但他们必须具有一种特殊的洞察力——“识别优秀设计的能力”。更重要的是，福格尔强调，他们的核心责任在于确保所有参与者始终相信一个理念：“集体的力量远胜于个体的奋斗”。开发者们只有在他们的领袖能够将项目打造成一个他们愿意不断重返的地方时，才会选择留下。这意味着要通过适时地认可和赞扬来回馈辛勤的努力，对于那些渴望挑战的人，还需要赋予他们更加重要项目部分的责任。对于开源项目的管理，其方式被描述为积极主动、非正式而低调。

避开陷阱

社区领导者肩负的重任是确保各种条件持续处于最佳状态，以便开源的全部潜能得以充分发挥。这并非一个自然发生的过程，而需要通过周密的管理来实现。

在项目的早期阶段，最紧迫的挑战可能是处理不可避免的支持任务负担。若处理不得当，轻则可能导致用户的流失，重则可能迫使创始人选择放弃。为了走向成功，领导者必须最终找到人员来负责这些工作。雇用人手是一种选择，另一种则是鼓励用户通过撰写文档和修复漏洞来互助互助。不过，要使这成为现实，就必须有一个支撑他们行动的基础设施。需要积极地鼓励贡献，并且领导者还要确保这些贡献既有实际帮助又具备相应的质量水平。

对于一个成熟项目来说，持续地满足其成员的需求是至关重要的。如果项目未能做到这点，那些认为自己的利益未被项目考虑的人或许会选择复制代码库，并在自己的监管下继续开发，这个过程称作“分叉”（forking）。重要的是要明白，分叉并非总是不利的现象，有时它仅仅反映了社区中某些群体有着无法与更广泛社区需求相平衡的特殊需求。同样，可能会出现这样的状况：既有的治理模式不再适合项目的最佳利益，因此社区选择在一个新的治理结构下的新项目中继续发展。但是，由于个性碰撞或简单的分歧而引发的分叉应该被避免，因为这可能导致社区的分裂和用户的困惑。为了避免这样的分叉，项目领导者应努力保证所有贡献者在决策过程中感到有话语权，即便有时候决策并不符合他们的期待。

放手

一个健康的开源社区，其生存能力必须超越创始人最初的兴趣。如果社区极度依赖于其独裁者式的领导，那么一旦这些领导人离职或退休，社区就可能面临分裂和瓦解的危机。

在大多数社区中，即使在那些由仁慈独裁者领导的社区中，除了创始人以外的成员也将日益承担起作出关键决策的责任。这自然而然地促成了向基于共识的民主过渡。这种新型安排并不意味着所有决策，无论多小，都必须通过委员会来做出。在大多数情况下，提案是基于“懒惰共识”的原则来决定的，即“沉默即为同意”。为了处理那些无法达成共识的提案，大多数社区引入了某种投票机制。

随着这些习惯和程序变得更为复杂，向新成员提供指引，使他们能够开始参与并在决策过程中发表自己的声音变得愈发重要。尚处于初期阶段的社区可能回溯到邮件列表中积累的知识体系，但这种做法并不总是对新成员有益，有时甚至会引起他们的困惑。所需的是一种书面记录，一个“治理模型”，用简洁的文件形式固化这种共识。通过正式化的安排，可以帮助确保社区拥有独立于任何个人的自主生命力，只要对项目产出的需求持续存在，它就能够存续并蓬勃发展。

结语

在开源软件周围构建一个社区可能是一个缓慢且艰巨的任务，其成功依赖于众多因素。但是，没有社区的存在，项目本身就无从谈起。社区建设不会自动发生，它需要精心的管理。所有社区都是从吸引用户开始的，无论是通过软件的包装和品牌，还是通过口耳相传的推荐。然而，一旦他们成为社区的一部分，挑战便在于满足这些高期望。一个繁荣的开发者社区可以实现甚至超越这些期望，但这仅在领导者能够维护社区的凝聚力并确保成员不各自为政时才成为可能。从长期来看，社区需要建立开放的开发机制，以确保当包括创始人在内的关键贡献者离开时，他们的角色可以由其他人接替。