开源治理的5种模式 原创

初次参与开源代码项目时，我们首先需要确定项目的众多参与者中有哪些人有权协助做出贡献。而这种在开源软件项目中定义谁能做什么、应该怎么做的规则与惯例，就被称为项目的治理模型。只有了解这些规则与惯例，才能帮助大家顺畅对接项目运作、成功做出自己的贡献。

每个开源项目与社区都根据治理模型保持运行，但不同项目之间的治理模型仍有高下之分。本文将向大家介绍一些最常见的开源项目与社区治理模型，并为采用各种模型的项目提供入门性指导。

“专制政体”模式

采取“专制政体”治理模式的开源项目，往往不会发布正式且详尽的治理公约，而是将绝大部分决策权集中在特定人员手中。换句话说，专制项目的成员需要通过稳定且一致的贡献帮助自己赢得权威地位。在这种模式下，同行评议工作仍然普遍存在，但个人贡献者更倾向于保留项目中特定组成部分，通常是其接触最多部分的客观决策权。

因此，有些专政项目会强调自己根本没有治理模式，而是依靠各利益相关者结合自身权限做出决定。但这种“无需治理”的思维明显是错的，任何开源项目都必然拥有自己的一套治理模型。多数情况下，这种治理模型隐含在项目成员的日常交互当中。结果就是，老成员可能把新生力量视为潜在威胁，新人则发现自己难以融入，甚至不知道该怎么立即参与、或者如何为贡献内容申请核准。

要在项目中建立治理模型，第一步就是设定一个存在改进空间的特定点位。我们可以回顾项目的变更历史记录，借此确定如何让自己的贡献成果赢得老成员们的青睐。随着贡献接纳量的增加，大家将逐渐在社区中累积起影响力。

“创始人/领导者”模式

“创始人/领导者”治理模型在新项目、或者贡献者较少的项目中最为常见。在这类项目中，创始个人或团体同时也负责项目管理，包括确定发展愿景、控制代码合并权限，并承担起在公共场合代表项目发言的权利。也有一些项目将创始人/领导者称为“传递的独裁者”。在这类项目当中，权利与权限的边界通常非常明确。而一切重要的项目事务，最终决策者都由创始人/领导者担任。

随着项目增长至一定规模，这种模型的局限性也变得显而易见。最终，创始人/领导者的个人偏好会与项目设计的最佳决策区分开来，这时候创始人/领导者反而成为项目决策中的瓶颈。在极端情况下，创始人/领导者模型可以在项目中创建一种“种姓制度”，因为非创始人会逐渐感受到自己根本无力改变创始人的意愿与思路。这种分歧可能导致项目分裂，甚至一旦创始人/领导者出于心理倦怠或计划内退休等理由而选择离开，项目也许会瞬间土崩瓦解。

对于采用这类治理模型的项目，大家可以首先浏览项目的通信邮件列表，或者访问讨论论坛与项目创始人/领导者建立初步联络，而后一一解决该如何提交贡献成果的问题。这会帮助我们对项目需求建立起全面了解，并据此分析自己最擅长、或者最适合在哪个方面做出贡献。另外，您需要明确理解创始人/领导者对项目的基本构想，否则一旦与构想有所抵触、我们提议的变更恐怕会被直接否决。在起步阶段，不要指望提出任何不利于创始人/领导者基本愿望的项目修改方案。

自我任命的理事会或董事会模式

认识到“创始人/领导者”模式的缺点，自我任命的理事会或董事会模型希望建立起更顺畅、更稳定的领导者继任制度，借此推动社区走向成功。在这种模式下，开源项目的成员可以任命多个领导小组来管理项目中的各项工作。此类小组可能包括督导委员会、提交者委员会、技术运营委员会、构建委员会或者董事会等。各个小组大多拥有自己的一部分决策惯例与继任规程。

如果项目缺乏赞助基础、而且很难建立起选举机制，那么这种自我任命理事会或董事会治理模型往往能够发挥良好作用。但请注意，如果自我任命的领导小组被项目社区所孤立、或者代表性不足时，这种模型的弊端就开始显现。在这种情况下，成员的甄选过程往往会引发激烈冲突，而之后建立的领导文化可能带来一定抵触。此外，社区成员可能觉得自己处于被挑选的消极地位，因此对贡献工作也许缺乏充分的积极性。

要在使用这种治理模型的项目中展开探索，我们不妨先从入门文档起步。首先需要明确，这种治理模型在较为成熟的开源项目中相当常见，因此社区往往会整理出比较全面的贡献者入门说明素材。请认真阅读这些材料，再结合项目的治理文档确定治理模式的运作方式。在大多数情况下，您都可以联系理事会或董事会了解项目贡献中的具体问题。组织内将有专人监督您的贡献，并回答您可能抱有的疑问。

选举人制度模式

一部分开源项目会采取选举人制度进行治理。例如，社区成员会组织各类职务选举，也可以通过投票进行项目政策及规程的批准或更新。在选举人制度下，社区将建立并明确记录下得到成员们普遍认可的选举规程，而后将这些程序制定为常规决策流程。

这种模型在大型开源代码项目中较为常见，这里众多通过资质认证且抱有浓厚兴趣的贡献者共同参与治理工作。此外，拥有稳定赞助方的项目（例如基金会）也普遍采用选举人制度，这是因为选举流程能够提升赞助方资源的分配透明度。选举型治理倾向于对项目中的各角色、规程与参与方式做出精确记录。在如此明确的制度依托之下，新的贡献者将在项目中最大程度发挥自己的力量与热情。

但选举人制度也有问题。对于全体项目成员，无论其是否实际参与贡献，投票结果都可能引起争议、耗费精力与时间。也有部分社区会在选举当中要求为某些知名项目成员提供无限期的领导职务；但一般除非项目中明确规定了任期限制，否则选举与管理团队成员变动往往没有关系。

要融入采取这种治理模型的项目，大家可以参考项目网站上公布的选举结果与领导团队名单。请认真阅读这些文档，确定项目指定的联系人。拥有良好治理质量的开源社区，一般会在项目网站上阐明关于提议及社区审查的投票流程。随着您对项目做出有益贡献、建立坚实的声誉，您最终有望成为项目中特定领导职位的候选人。请确保与其他贡献者开展富有成效的互动与协作，可能有一天他们会用自己手中的投票权向您表达支持与敬意。

单一供应商模式

有时候，个别企业或行业协会可能也会遵循某些开源代码许可条款发布软件，借以吸引潜在的开发者与用户。但这类项目往往并不接纳受众做出的项目贡献。这种方式可能是为了加快工作速度、激励软件平台上的开发活动、支持插件生态系统，或者避免社区在吸纳外部开发者方面投入大量资金。

在这种模式下，理事机构通常不接受任何外部人士的贡献。相反，开源代码与封源代码创新只发生在项目边缘。因此，也有评论者将这种治理模型称为“围墙花园”。有时候，遵循此类模型的项目会采用更严苛的公共版权许可证，厂商方面希望以这种方式向其他商业竞争对手表示威慑（即迫使具有生产要求的竞争者及客户购买这款软件的非开源版本，这种方式也被称为双重许可法）。但在这种模型下，项目在事实上没有开放社区，因为其整体归企业或财团全资拥有。

要融入采用这种治理模型的项目，大家首先可以考虑自己雇主与项目发起公司之间的关系。接下来，评估项目中的许可条款，并回顾历史变更记录与错误跟踪机制，确定您能否以自己喜欢的方式为项目中的特定方面做出贡献。根据项目的特定规则，您可能会接触到这些特定方面，但并不算是直接为项目做出贡献。

基金会支持模式

为了更好地控制资源与项目代码，某些开源项目会选择由NGO（非政府组织）专门管理，例如慈善性非营利组织或贸易协会等。这种方式将让项目拥有相关服务方、商标、专利与保障等资源的明确所有权。

在某些情况下，基金会领导与项目领导将形成单一的治理结构，共同管理开源项目的各方面工作。但也有一些基金会会直接管理部分事务，例如商标与线下活动，并由项目领导团队负责代码核准等其他治理事务。

这种规模较大的开源项目，往往需要遵循一系列资金与法律要求。但也有一些小型项目会选择加入较大的保护性基金会，例如Software Freedom Conservancy或者Linux基金会，借此获得支持型治理模式的优势。对于需要与第三方建立法律关系，或者要求在关键人物离开后仍可顺利过渡及运行的项目，这种治理模型无疑是最佳选择。这套方案也有助于防止单一厂商支持的项目过度转向商业化。

但基金会支持治理模型的显著缺点，在于高昂的运营开销，不仅是严格的财务考量，在贡献者时间投入方面同样巨大。部分基金会会以行业协会的形式存在，并由赞助企业在组织内进行管理。不同的协会对于项目贡献者的参与度也有不同的要求。某些协会相对开放，而某些则把权利牢牢限定在企业管理者手中。

要融入采用这种模型的开源项目，如果基金会方面不参与管理日常项目贡献活动，请直接参阅入门文档并遵循内容要求（具体参考自我任命理事会或董事会部分）。但请注意，虽然基金会管理的一切项目都遵循某些基本的贡献流程，但不同基金会下不同项目可能也会设置自己的专项管理者。要确定项目负责人，您可以向基金会成员邮件列表发送申请。您也可以查阅项目的历史变更记录，明确哪些成员贡献频率最高（请参阅「专制政体」部分）并与他们联系。多数基金会还设有基于贡献的投票系统，因此请熟悉成为基金会正式投票成员的必要流程。如果基金会为仅限成员参与的行业协会，请确定您的雇主是否是其中成员。如果不是，请与上级领导讨论项目对工作的重要性，并询问您的雇主是否考虑加入。无论哪种情况，基金会项目都可能需要签署书面的贡献者申请文件。请在法律部门的协助下审查并签署此份文件。