开源的治理形式Forms of Open Source Government

终身仁慈独裁者。创始人按照惯例（而非成文规定）永远对项目方向拥有最终决定权。Python 一直采用这种方式，直到 Guido 于 2018 年卸任，而 Linux、Ruby、Rails 和 Laravel 至今仍在沿用。“永远”这一说法心照不宣的上限就是人类的寿命，该类别中著名的项目目前都还没有面临过这种考验。

终身恶毒独裁者。这与前者是相同的架构，只不过“仁慈”已经荡然无存，创始人依然在位，而周围没有人具备相应的权限或精力去改变现状。从外部来看，这种现象表现为长期贡献者逐渐销声匿迹，以及在通常不会发生分叉的地方出现了项目分叉。

指导委员会。这是 BDFL 项目在独裁者退休或被要求下台后演变而成的模式。通常的形式是一个由选举产生的小型委员会，席位轮换，没有终身成员；正如 Guido 卸任后，Python 通过 PEP 13 和 PEP 8016 过渡到了由五人组成的指导委员会。大多数 BDFL 项目都不会提前制定继任计划，最终只能在促成交接的危机中临时抱佛脚。

常任核心团队。这是一个由公认的维护者组成的长期团体，通过邀请加入，且没有固定的任期限制，有时隶属于某个基金会之下，有时则不然。PostgreSQL 的核心团队就是典型的例子，新成员由现有成员提名，没有正式的投票或竞选流程。与轮换委员会相比，这种模式能更好地积累机构记忆。代价是，加入团队的标准是不成文的，完全取决于现有成员碰巧达成了什么共识。

Apache 之道。这是一条从贡献者到提交者，再到项目管理委员会成员的标准化晋升阶梯，设有轮值主席，决策则在开发邮件列表中通过惰性共识或投票的方式做出。所有 Apache 项目的结构都完全一致，而这正是该基金会的真正产品。它不依赖于任何个别维护者在明年是否仍有兴趣，其代价则是流程相对缓慢。

供应商中立基金会。基金会拥有商标和法律实体，技术监督委员会向各维护者进行授权，成员公司支付会员费来为工作人员提供资金。CNCF、Eclipse、OpenJS 以及 Linux 基金会旗下的伞形项目都采用了这种模式的变体。中立性意味着没有任何单一成员可以独占项目，这是通过成员协议来强制执行的，而不是依靠代码中的任何结构设计。基金会本身就是该架构的参与者，而非单纯的中立平台；除了任何单一项目的议程外，它也将自身的存续和发展列入了议事日程。

设有下属小组的技术指导委员会。TSC 负责处理跨领域的决策，而特别兴趣小组或工作组则拥有代码库中特定领域的所有权。Kubernetes 是这种模式的最极致版本，每个 SIG 都有一份成文的治理文件；而 Node.js 则运行着同款架构的较小规模版本。该模式能较好地随项目规模进行扩展，但在应对雇主集中度方面表现较差，因为一旦大多数 SIG 负责人都在同一家公司工作，组织架构图上是根本看不出来的。

实干治理结合惰性共识。谁干活谁拍板，只要在某个时间窗口内没有异议，提案就算通过。Debian 的包维护机制就是这样运作的；在 Apache 社区，一旦你越过正式的投票结构，大多数情况也是如此。只要参与度足够广泛，这种模式就能奏效；而当某个人在不声不响中完成了大部分工作时，它就会退化为一种未公开宣布的 BDFL（终身仁慈独裁者）模式，与公开宣称的 BDFL 相比，它表面上的好处是没人需要承认这一点。

Discord 驱动开发。项目的历史沉淀全靠聊天服务器，通过在 GitHub issue 中链接聊天消息来追踪决策，而持久的记录仅限于那些在频道消息被刷走之前截图保存了内容的人。这在 JavaScript 框架和加密货币项目中很常见，其 README 中直接附上了社区服务器的链接，以此来取代 CONTRIBUTING 文件，并且 issue 讨论串最终往往以一个指向聊天记录的链接而被关闭。

会议驱动的路线图。年度会议是维护者们唯一齐聚一堂的时刻，因此本年度的路线图就在某个周二下午敲定了，依据仅仅是哪些建议被写进了幻灯片里。会议是由项目最大的用户赞助的，他们的反馈在规划电话会议中就已经被采纳了。这种模式的典型结果就是：下一个版本中出现了一个没人提交过 issue 的功能，而且这个功能可以追溯到一份没人保存副本的幻灯片。

粗略共识与可运行代码。这是 IETF 的原则，被明文编纂在 RFC 7282 中。在该原则下，不进行正式投票，可运行的实现代码比主观意见更有分量，主席在异议得到解决（而不是清点票数）时宣布达成共识。这种模式更适合标准制定机构而不是代码库。它往往会产生由那些站出来提出异议的人所主导的决定，而这些人通常并不是受决定影响的人。

单一供应商开源。一家公司掌握着版权、商标和发布密钥，贡献者在加入时签署 CLA，而路线图完全取决于公司的需求。在其历史的大部分时间里，MongoDB、Elastic、HashiCorp 和 Redis 都符合 OSI 对开源的定义，但一旦战略考量发生变化，它们就会通过更换许可证来脱离开源。社区对这种模式的制衡与对独裁者的制衡相同（离开并分叉），而代价则是重建公司原本出资维护的项目所需的成本，这正是 OpenTofu 和 Valkey 目前正在用实际行动证明的。

狂热分叉季。项目极其有规律地经历治理危机，以至于积累了一系列的分叉版本（project、project-ng、project-next、project-classic），每个版本都声称自己才是正统继承者。每次分叉本应是为了平息争议，结果却只是在消歧义页面上又增加了一行。每一个新的 README 都会长篇大论地解释自己“不是”其他哪些分叉，而下游用户则根据他们现有的 lockfile 来决定采用哪个。

代币治理。由代币持有量对链上提案进行加权，并通过智能合约执行，例如 Uniswap 和 MakerDAO。这是本清单中唯一具备真正意义上选举的模式，其影响力与资本成正比，且比例公开记录在公共账本上。

终身代码代理。自主编码代理（Autonomous coding agent）创建代码库，注册托管账户，编写代码，开启并审查自己的 pull request，然后在无人签核的情况下自行合并。对项目的影响力归属于任何能够把 issue 描述得足够有说服力、从而引导代理集群采取行动的人，这比清单中任何其他模式的选民基础都要广泛。