第 3 小节：开源项目的常见治理架构

三种常见的开源项目治理架构

BDFL（独裁者）

BDFL 是英文 Benevolent Dictator For Life 的缩写。中文翻译为「仁慈的终身独裁者」。在此架构下，有一个人（通常是项目的最初的作者，或者是社区选举的一个人）拥有项目中所有最后的决定。较小的项目可能默认就是 BDFL 结构，因为此类项目一般就是一到两位维护者。若是公司组织的项目也极有可能会采用 BDFL 结构，以便掌握项目的决策权。

例如 Python 就是一个非常经典的 BDFL 例子。在此架构下，「独裁者」如何进行权力的交接？如果想扩展阅读也可以关注下 Python 之父 Guido van Rossum 的退位邮件。[python-committers] Transfer of power (opens new window)

Meritocracy（精英制）

在精英制下，活跃的项目贡献者（他们用行动证明自己是“精英”）给出一个正式的决策作用，决定通常会基于纯粹的投票一致性。精英制的概念首次由 Apache Foundation 提出；所有的 Apache 项目都是基于精英制的。贡献者只能代表自己是独立的个体，不可以是公司。

注: 术语「精英制」对于一些社群可能具有消极的含义，其拥有较复杂的社会和政治的历史。

Liberal Contribution（自由贡献）

在自由贡献的模式下，做最多工作的人通常被认为是最具影响力的，但是是基于当前的工作，而不是历史的共享（什么是“历史的共享”，这块说的不清楚）。项目的重大决策是基于寻求共识的过程（对不同的声音要讨论）而不是纯粹的投票，尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有 Node.js 和 Rust。

我们简单看看 Node.js 的自由贡献规则：

1. Node.js 核心库：Node.js 核心代码库在 https://github.com/nodejs/node (opens new window)。你可以尝试通过提 PR 与 Issue 的形式为核心代码库做贡献。
2. Node.js 工作组：工作组与核心代码并非直接关联，而是专注在其周边的一些具体任务，比如站点工作组负责 Node.js 官网事宜，构建工作组负责 Node.js 在各个平台上的编译构建，Benchmark 工作组关注 Node.js 的性能相关问题。
3. Node.js 生态圈：即使你对核心库与工作组的东西不感兴趣，也可以通过参与生态建设的方式做出贡献，例如参加 Node.js 的布道，出席社区聚会等等。

应该选择哪一种模式了呢？每个模式都有优点，也有缺点。如果是非公司开源项目，可以在开始的时候简单定义基本的流程。例如，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。如果是公司开源的项目，在启动之前，应该做一些讨论，如公司将会如何维护项目，随着项目的发展，决策该如何定夺。可以公开的解释一下，开源之后，公司是否还继续参与贡献，还是完全由社区决定，等等。没有最优的答案，一切在于出自内心的选择。

BDFL 治理模型

BDFL 治理模型（Benevolent Dictator Governance Model）的项目由仁慈的独裁者领导，并由社区管理。也就是说，社区积极地为项目的日常维护做出了贡献，但是仁慈的独裁者划定了总体战略方针。如有分歧，则保留最后决定权。解决社区内部的争端并确保项目能够以协调的方式进行，这是仁慈的独裁者的工作。反过来，通过积极的参与和贡献来指导仁慈的独裁者的决定是社区的工作。

主要角色

1. 仁慈的独裁者(Benevolent Dictator):仁慈的独裁者或项目负责人是自任命的。但是，由于社区始终具有分叉的能力，因此此人对社区完全负责。项目负责人的角色是一个困难的角色：他们确定了项目的战略目标，并将这些目标明确地传达给社区。他们还必须了解整个社区，并努力满足尽可能多的冲突需求，同时确保项目能够长期生存。
2. 提交者(Committers):提交者是对项目做出了一些宝贵贡献的贡献者，现在都依赖于将代码直接写到存储库中并筛选其他贡献者。通常，提交者将专注于项目的特定方面，并将带来一定程度的专业知识和理解，从而赢得社区和项目领导者的尊重。
3. 贡献者(Contributors):任何人都可以成为贡献者。没有期望对项目的承诺，没有特定的技能要求，也没有选择过程。要成为贡献者，社区成员只需执行一项或多项对项目有益的行动。

社区治理方向

当项目的团队还比较小的时候，而且用户的社区也比较小，这时仁慈的独裁者会按照传统的自上而下的方式来做出所有的决策。然而，随着社区的增长，这会变得越来越困难，很少有人能够完全理解所要解决问题的所有细节，因此，他们可能会对在不怎么专业的领域所做出的决定不是太有把握。随着项目规模和范围的扩大，人们对于不能有十足把握的模块也会增长，那么作为项目的带头人，就无法做到面面俱到。基于如上原因，一个颇为高效率的独裁者会慢慢转变为协调者，或者叫做仲裁者，他们通常情况下，不会在辩论当中站队，Linux Torvalds 曾经说过，“我宁愿看到的场面是有 15 个人为一个问题而争执的面红耳赤，而不愿意看到 15 个人分成两支队伍，每支队伍都只和自己观点相近的人说话。

精英制治理模型

精英制治理模型（Meritocratic Governance Model）是一种常见的模式，参与者通过承认自己的贡献而获得对项目的影响。Apache Software Foundation（ASF）也许是大规模精英社区最著名的例子。该基金会的运作方式几乎完全是“扁平化”的，这意味着任何愿意捐款的人都可以在任何层次上参与他们的项目。在“控制”范围的另一端是仁慈的独裁者治理模型，该模型由一个人领导。尽管精英制与仁慈的独裁者之间在结构上存在明显差异，但它们都赞同共享代码并鼓励每个人回馈社区的相同开源原则。因此，精英项目管理委员会和仁慈的独裁者都通过忠诚而不是规则来行使其决策权也就不足为奇了。他们都知道成员可以自由获取代码并创建替代项目。实际上，这种分叉的能力对于开源社区的健康非常重要。这是因为它确保参与项目治理的人员努力为社区做出正确的决策，而不是为单个个人或公司做出正确的决策。但是，这两种模型之间存在显着差异，尤其是在社区内部如何进行决策方面。在最极端的情况下，一种精英管理模式似乎可以控制社区成员，以响应他们对项目的贡献。但实际上，如果没有适当考虑，就不会实施控制。精英不是民主。也就是说，并不是每个人都具有约束力。只有那些通过对该项目做出积极贡献而获得收益的人才具有约束力。这使项目负责人可以确保只有拥有共同愿景并愿意为实现共同愿景而努力的人才能获得决策权。

主要角色

1. 用户（Users）

   用户是需要项目的社区成员。他们是社区中最重要的成员，没有他们，该项目将毫无目的。任何人都可以成为用户；没有特殊要求。该项目要求其用户尽可能多地参与该项目和社区。用户的贡献使项目团队能够确保他们满足这些用户的需求。普通用户的贡献包括（但不限于）：

   • 宣传该项目（例如，网站上的链接和口碑宣传）
   • 从新用户的角度通知开发人员优点和缺点
   • 提供道义上的支持（“谢谢”有很长的路要走）
   • 提供财务支持（该软件是开源的，但其开发人员也是需要恰饭的）

2. 贡献者（Contributors）

   贡献者是社区成员，他们以具体方式为项目做出贡献。任何人都可以成为贡献者，并且贡献可以采用多种形式，没有期望对项目的承诺，没有特定的技能要求，也没有选择过程。贡献者可以通过下面的行为对社区做出贡献。

   • 支持新用户（现有用户通常是支持新用户的最佳人选）
   • 报告错误
   • 确定要求
   • 提供图形和网页设计
   • 程式设计
   • 协助项目基础设施
   • 撰写文件
   • 修正错误
   • 增加功能

3. 提交者（Committers）

   提交者是社区成员，他们表明他们致力于通过与社区的持续参与来继续开发该项目。Committership使贡献者可以直接访问项目资源，从而更轻松地进行与项目相关的活动。也就是说，他们可以直接对项目输出进行更改，而不必通过补丁提交更改。这并不意味着提交者可以自由地做他们想做的事情。实际上，提交者对该项目的权限不超过贡献者。虽然承诺表示社区中的一个有价值的成员，已经对项目的目的和目标表现出了健康的尊重，但社区的继续对其工作进行审查，然后才能正式发布。提交者和贡献者之间的主要区别在于何时寻求社区的批准。提交者在做出贡献之后而不是之前寻求批准。做出贡献后寻求批准的过程称为提交然后审查过程。允许受信任的人直接做出贡献会更有效，因为这些贡献中的大部分将被项目接受。该项目采用了各种沟通机制，以确保所有贡献都得到整个社区的审查。到邀请一名贡献者成为提交者时，他们将以用户身份并以参与者的身份熟悉该项目的各种工具。

   任何人都可以成为提交者；提交者可以推荐新的提交者提名。提名之后，项目管理委员会（PMC；请参阅下文）将进行表决。进行表决后，汇总的表决结果将发布在公共邮件列表中。无论投票结果如何，被提名人都有权要求对他们的任何“否”票作出解释。该解释将由PMC主席提供（见下文），并且本质上是匿名的和具有建设性的。提名人可以拒绝任命其为提交人。但是，这是不寻常的，因为该项目不希望社区成员有任何特定的时间或资源投入。提交者角色背后的意图是使人们能够更轻松地为项目做出贡献，而不是以任何正式的方式将他们与项目联系在一起。重要的是要认识到，担任职务是特权，而不是权利。该特权必须获得，一旦获得，在极端情况下，PMC可以将其删除（请参阅下一节）。但是，在正常情况下，只要提交人希望继续参与该项目，就可以存在提交人。提交人对项目的贡献高于平均水平，尤其是在其战略方向和长期健康方面，可以被提名为PMC成员。

4. 项目管理委员会（Project Management Committee）

   项目管理委员会由在开发现场被确定为“项目所有者”的那些人组成。PMC除了提交者的职责外还有其他职责。这些职责确保了项目的顺利进行。预计PMC成员将审查代码贡献，参与战略规划，批准对治理模型的更改并管理项目输出中的版权。PMC的成员没有对社区其他成员的重要授权，尽管是PMC对新提交者进行投票。当无法达成社区共识时，它也会做出决定。此外，PMC可以访问该项目的私人邮件列表及其存档。该列表用于处理敏感问题，例如对新提交者的投票以及无法公开讨论的法律事项。它从不用于项目管理或计划。PMC的成员资格是应现有PMC成员的邀请进行的。提名将导致讨论，然后由现有PMC成员投票。PMC成员资格票须获得当前PMC成员的共识批准。

5. PMC主席（PMC Chair）

   PMC主席是一个人，由PMC成员投票表决。一旦有人被任命为主席，他们将继续担任该职务，直到他们选择退休，或者PMC投三分之二多数票将其罢免。PMC主席对PMC的其他成员没有任何其他权限：该角色是协调者和推动者之一。还期望主席确保遵守所有治理程序，并在项目未能达成共识时进行决定性投票。

社区治理方向

通过与社区的所有成员（从最新用户到经验最丰富的 PMC 成员）进行讨论，可以决定项目的未来。所有不敏感的项目管理讨论都在项目贡献者的邮件列表中进行。有时，敏感讨论会在私人列表上进行。

为了确保该项目不会因无休止的讨论和持续的投票而陷入困境，该项目采用了一种懒惰的共识政策。这样一来，大多数决定都无需进行正式投票即可做出。

懒惰的共识决策通常包括以下步骤：

• 提议
• 讨论
• 投票（如果没有通过讨论达成共识）
• 决定

任何社区成员都可以提出建议供社区考虑。为了启动有关新想法的讨论，他们应该向项目贡献者列表发送电子邮件，或者将实现该想法的补丁程序提交给问题跟踪器（如果具有提交访问权限，则为版本控制系统）。这将促使您进行审核，并在必要时进行讨论。审查和讨论的目的是获得对该文稿的认可。由于项目社区中的大多数人都有共同的愿景，因此通常无需进行讨论即可达成共识。

通常，只要没有人明确反对提案或补丁，就可以认为它得到了社区的支持。这就是所谓的懒惰共识-也就是说，那些没有明确表达意见的人暗中同意该提案的实施。

惰性共识是项目中非常重要的概念。正是这个过程使一大群人有效地达成共识，因为对提案没有异议的人无需花费时间来陈述自己的立场，而其他人则无需花费时间来阅读此类邮件。

为了使懒惰的共识有效，有必要在假设对该提案无异议之前至少保留 72 个小时。此要求可确保每个人都有足够的时间阅读，摘要并响应提案。选择此时间段是为了尽可能涵盖所有参与者，无论他们的位置和时间如何。

并非所有的决定都可以使用惰性共识来做出。诸如影响项目战略方向或法律地位的那些问题必须以投票的形式获得明确批准。鼓励社区中的每个成员在所有讨论和所有投票中表达他们的意见。但是，只有项目提交者和/或 PMC 成员（如上定义）才具有约束力的投票权来进行决策。

参考

• [1] Benevolent Dictator Governance Model (opens new window)
• [2] 开源项目治理模式 (opens new window)
• [3] 精英制治理模型 (opens new window)

本部分内容贡献者

alimoyu (opens new window)、ORH (opens new window)、BaiYunIT (opens new window)、taotieren (opens new window)、zeroTwozeroTwo (opens new window)、阿基米东 (opens new window)

发现内容中的错误？还是想要补充更多符合主题的内容？《开源指北》欢迎你进行贡献，点击贡献指南了解贡献的具体步骤。