社区对于开源项目至关重要。一个活跃且支持性的社区是项目的核心。然而，仅仅拥有一个开源许可证并不足以将用户和开发者吸引到您的项目并构建社区。本文档探讨了成功开源社区的要素。
为什么开源项目会启动？
开源软件项目的启动方式与其他类型的软件项目并没有真正的不同。它们的启动要么是因为有人想要构建某些东西，要么，在产品开发的情况下，有人打算满足他人的未来需求。在前一种情况下，可能从未考虑过共享最终结果的可能性，而在后一种情况下，则有共享软件的明确意图。
什么是社区？为什么开源项目想要构建社区？
社区仅仅是具有共同兴趣的个人群体。封闭和开源项目都有用户社区，其中大多数用户在与其他社区成员的互动方面相对被动。另一方面，任何类型的社区都可能拥有成员，他们决定承担更积极的角色，例如，报告错误、帮助其他用户、编写文档或进行宣传。最活跃的成员甚至可能因其努力而获得奖励。例如，微软通过最有价值专家 (MVP) 计划奖励其用户社区中帮助人们充分利用微软技术的人。在开源社区中，活跃成员倾向于通过获得对项目的额外访问和控制权来获得奖励。
尽管封闭源代码项目中也有一些奖励，但社区成员可以做出的奖励贡献类型显然受到限制。由于代码不对外开放检查，用户最终无法实际进行并修复问题或开发新功能并贡献代码。相比之下，在开源社区中，信息（代码和文档）有可能从社区的任何成员流入中心，尽管是以经过审核的形式。更重要的是，对于任何给定的问题，有可能有大量的“眼球”关注它，从而利用整个社区的智力。在封闭源代码项目中，关注任何给定问题的最大人数始终受限于受雇开发人员的总数。
开源社区的典型路径
在其初期，开源社区可能非常小，可能只有一两个开发人员，几乎没有用户。根据项目的类型，这种情况可能会持续一段时间，甚至数年，作为一个“孵化期”，在此期间，初始团队努力使一些可运行的东西落地。《大教堂与集市》一书的作者埃里克·雷蒙德指出，成功的必要先决条件是拥有“可运行和可测试的东西来玩”。应该注意的是，“可运行”并不意味着完美甚至完整。“尽早发布，频繁发布”是开源开发的一个众所周知的口头禅，尤其因为这样做可以吸引宝贵的早期反馈并建立对项目的信心。因此，社区不应害怕或犹豫尽早发布材料；只要明确且如实地管理期望，早期发布就可以实现重大的好处。
如果软件最终要吸引用户，那么演示和品牌塑造必须使潜在用户相信该软件在某些方面比竞争对手做得更好。一旦获得兴趣，进入门槛必须很低：例如，安装过程等简单的事情需要非常流畅。注册用户并不是故事的结局；从长远来看，也需要开发人员，至少要处理可能拖累单个开发人员的较小贡献。开发人员可能来自直接用户群，但也可能来自其他地方，被技术挑战、声望或提高或宣传其编程技能的机会所吸引。
以这种方式开放项目可能会增加全新的复杂性。卡尔·福格尔在《生产开源软件》中指出，“开放意味着安排代码以便完全陌生人能够理解，建立开发网站和电子邮件列表，并且通常是第一次编写文档。所有这些都是大量的工作。当然，如果任何感兴趣的开发人员确实出现，那么在看到他们的存在带来任何好处之前，还需要承担一段时间回答他们问题的负担。” 然而，额外的努力至少部分被 Github、Google Code 和 StackExchange 等现成的协作工具所抵消。此外，开放项目并不一定意味着失去控制。许多项目在其早期阶段都作为仁慈的独裁统治运行，由一个人负责开发主要的新功能和审查贡献的代码。
根据福格尔的说法，仁慈的独裁者不需要拥有最伟大的技术技能，但他们将拥有“识别良好设计的能力”。然而，福格尔接着指出，他们的主要责任是确保参与者继续持有他们“可以比单独行动做得更多”的信念。如果领导者能够使项目成为他们想要不断回来的地方，开发人员才会留下来。这意味着通过在适当的地方给予荣誉来奖励辛勤工作，并为那些想要的人提供更重要的工作责任。开源项目的管理已被描述为积极、非正式和低调的。
避开陷阱
社区领导者的责任是确保条件继续适合充分发挥开源的潜力。这不会自动发生，必须进行仔细管理。
在早期阶段，项目最重要的问题可能是处理不可避免的支持负担。如果处理不当，最坏的情况可能会导致用户离开，最坏的情况可能会导致创始人放弃。如果要取得成功，领导者最终必须找到人来完成这项工作。雇用人员是一种选择；另一种选择是鼓励用户通过编写文档和修复错误来互相帮助。但是，如果要实现这一点，则必须建立允许他们这样做的基础设施。需要积极鼓励贡献，领导者还需要确保贡献是有帮助且质量足够高的。
重要的是，已建立的项目继续满足其成员的需求。如果情况不再如此，那些觉得自己的利益没有得到项目服务的人可能会决定复制代码库，并在自己的治理下继续开发。此过程称为分支。重要的是要注意，分支不一定是坏事，可能仅仅是您的社区的一部分人有特定的需求，他们认为这些需求无法与更广泛社区的需求相平衡。也可能存在已建立的治理模型不再符合项目最佳利益的情况，因此社区决定在新项目的新的治理结构下继续开发。但是，应避免因人格冲突或简单分歧而导致的分支，因为它们可能会分裂社区并给用户造成混乱。为了避免此类分支，项目领导者应努力确保所有贡献者都感到在决策过程中被授权，即使决策不符合他们的意愿。
何时分支不是分支？
随着分布式版本控制系统的兴起，特别是通过 GitHub 等托管站点，术语分支的含义发生了新的变化，即单个开发人员获取已发布代码库的自己的副本，根据自己的需求进行更改，并经常将更改提交回原始代码（称为拉取或合并）。这与上面描述的分支类型有很大不同，后者是项目周围的社区分裂，而不仅仅是代码。
放手
为了被认为是健康的，开源社区必须有能力在其创始人的原始兴趣消退后继续存在。如果他们严重依赖独裁者，他们可能会在领导者离开或退休时面临分裂和瓦解的风险。
在大多数社区中，即使是那些受独裁统治的社区，创始人以外的人也会越来越多地负责做出关键决策。这种自然的结果是朝着基于共识的民主制度迈进。这种新安排并不意味着所有决策，无论多么微小，都由委员会做出。大多数时候，提案都是在“懒惰共识”的基础上决定的，即“沉默表示同意”。为了处理未达成共识的提案，大多数社区都实行某种形式的投票。
这些习惯和程序变得越复杂，就越有必要帮助新人了解他们如何开始参与并在决策过程中拥有发言权。年轻的社区可能会退回到邮件列表线程中建立和捕获的知识体系，但这并不总是有助于新人，并且可能会让他们感到困惑。需要的是一些书面形式的东西，一个“治理模型”，以简洁的文档形式捕获这种共同的理解。形式化安排有助于确保社区拥有自己的生命力——独立于任何个人——只要对项目的产出有真正的持续需求，社区就能生存和蓬勃发展。
结论
围绕开源软件构建社区可能是一项缓慢而艰苦的工作，成功取决于许多因素。然而，没有社区，就根本没有项目。社区建设不会自动发生，必须进行仔细管理。所有社区都从用户开始，他们被软件的包装和品牌塑造或口口相传的推荐所吸引。然而，一旦他们到来，挑战就变成了不辜负这些高期望。一个蓬勃发展的开发者社区可以满足甚至超越这些期望，但这只有在他们的领导者能够将社区团结在一起并确保参与者不会自行其是的情况下才能实现。从长远来看，社区需要有开放式开发机制来确保当包括创始人在内的关键贡献者离开时，他们的角色被其他人接替。
最初发布于 OSS Watch 网站。根据知识共享许可协议重新发布。
3 条评论