开源项目失去核心领导者之后会怎样

Ryan Dahl 离开 Node.js 后，项目虽然挺了过来，但经历了多年的治理结构调整、一次分叉（io.js）以及后来的重新合并，才终于稳定下来。Guido van Rossum 辞去 Python 的 BDFL（“终身仁慈独裁者”）一职后，社区花了数月讨论治理模式，最终才确定设立指导委员会。Deno 项目面临自身的领导层问题时，影响波及了每一位押注这个运行时的开发者。

这些并不是孤立事件，而是开源开发的结构性特征。大多数重要的开源项目都依赖极少数人，往往只是一个人，其依赖程度远超用户的想象。一旦这个人离开、倦怠、改变优先级或做出有争议的决定，项目就会陷入生存危机，而 GitHub 星标再多也无法避免这种局面。

巴士因子问题

“巴士因子”指的是：要有多少人被公交车撞到，项目才会崩溃。对大多数开源项目而言，这个数字低得惊人。2015 年的一项研究发现，超过 60% 的 npm 包只有一个维护者。近期对关键开源基础设施的分析也发现，许多拥有数百万下游依赖的项目，实际上只由一两个人维护，而且往往是无偿的业余工作。

这并非假设。OpenSSL 是保护互联网大部分加密流量的库，在 Heartbleed 漏洞被发现时，它主要由两个人利用业余时间维护。Left-pad 是一个只有 11 行代码的 npm 包，作者将其删除后，数千个构建随之失败。core-js 每周下载次数超过 2500 万次，却由一位开发者维护，他曾公开表示自己几乎负担不起温饱。

规律非常一致：一个关键项目由一位充满热情的个人发起，逐渐获得采用，成为数百万人依赖的基础设施，而维护负担却始终压在那一两个人身上。项目的重要性呈指数级增长，而支持却没有跟上。

治理模式及其权衡

开源项目的治理方式大致有几种，每一种都有可预见的优缺点和失败模式。

BDFL 模式

由一个人做最终决定。Python（Guido van Rossum）、Linux（Linus Torvalds）、Ruby（Matz）——最成功的项目往往都有一位强有力的技术领袖，他的品味和判断塑造了项目。优点很明显：方向清晰、愿景一致、决策迅速。BDFL 可以对不符合方向的功能说“不”，项目因此能保持专注。

失败模式同样明显：BDFL 一旦离开，又没有继任计划。Python 在 Guido 辞职后的过渡就颇为坎坷，尽管他已经积累了数十年的社区建设经验。社区参与度不高的项目，往往在 BDFL 离开后就直接陷入停滞。

基金会模式

Apache、Eclipse 和 Linux Foundation 等项目隶属于非营利基金会，拥有正式的治理结构：技术指导委员会、提交者选举、决策流程等。这提供了制度上的延续性，即使个人离开，项目也能存续，因为结构依然存在。

其代价是官僚作风和政治博弈。基金会治理可能缓慢、充满争议，还可能被企业利益左右。有些开发者觉得，与灵活的 BDFL 项目相比，委员会流程令人窒息。最糟糕的情况是，基金会的治理变成了组织政治的较量，而不再是技术价值的比拼。

企业赞助模式

React（Meta）、Go（Google）、Rust（最初由 Mozilla 主导，现已成立独立基金会）、TypeScript（微软）——许多主流项目都由雇用核心维护者的公司赞助。这解决了资金问题：维护者能拿到薪水，可以全职投入，项目也能获得企业的工程资源。

风险在于利益是否一致。企业的优先级会变。Mozilla 裁掉了 Rust 团队。当业务重心转移时，Google 也曾降低开源项目的优先级，并减少投入。一旦企业的战略利益与社区利益出现分歧，摩擦就在所难免。近来一些开源项目被赞助企业修改许可证（如 Redis、Terraform、Elastic），足以说明这种模式有多脆弱。

健康的分叉

分叉，即创建一个相互竞争的项目副本，常被视为失败的标志。但在开源世界里，它其实是终极的安全阀。当领导层失效时，分叉让社区能够在不依赖原维护者的情况下继续前行。

Node.js 的 io.js 分叉推动 Node 走向更开放的治理模式和更快的发布节奏，两个项目合并后，Node 因此变得更好。LibreOffice 从 OpenOffice.org 分叉，使项目摆脱了 Sun/Oracle 日渐衰退的投入。MariaDB 在 Oracle 收购 MySQL 后从中分叉，至今仍作为社区驱动的替代方案存在。

近来，许可证变更也引发了富有成效的分叉。Elastic 修改 Elasticsearch 的许可证后，亚马逊推出了 OpenSearch。HashiCorp 修改 Terraform 的许可证后，社区在 Linux Foundation 的支持下分叉出 OpenTofu。这些分叉之所以存在，是因为分叉的权利正是社区对项目领导层的终极制衡。

关键在于，只有当社区（而不仅仅是代码）干净利落地分开时，分叉才最有效。拥有活跃维护者和社区支持的分叉会蓬勃发展；而仅由一个心怀不满的开发者创建、无人跟随的分叉，只会制造混乱。

倦怠的螺旋

大多数开源领导危机并不始于戏剧性的离场，而是始于倦怠。维护者的精力和热情会在问题、拉取请求、功能需求以及理所当然的用户压力之下慢慢被消磨。

这个过程是可以预见的。维护者创建了一个有用的东西，用户随之而来，伴随而来的是 bug 报告、功能请求、支持问题和各种要求。维护者出于责任感，试图回应每一件事。工作量超出了他的承受能力，他开始害怕看到通知。回复越来越慢，语气越来越冲，最后干脆不回。最终他消失了，项目进入一段“僵尸维护”期，技术上还活着，实际上已经被遗弃。

开源维护者的倦怠并非个人缺陷，而是结构性问题：项目会不断产生对少数人时间和注意力的无限需求，而机制上却没有任何办法来管理这种需求。

一些维护者找到了应对方式：严格限定回复时间、把分类工作委托给社区成员、通过 GitHub Sponsors 或 Open Collective 获得有偿维护，或者干脆接受较慢的响应速度。但这些方法都需要有意识地抵制随时在线的压力，而这与许多开源社区的文化背道而驰。

健康的交接是什么样的

一些项目在领导层交接方面处理得很好，它们有一些共同的模式。

知识分散，而不仅仅是代码分散。 项目的“部落知识”（为什么做出某些决定、考虑过哪些替代方案、设计原则是什么）被记录下来，而不是只存在于某个人的脑子里。架构决策记录（ADR）和详细的 RFC 正是为此而生。
多人拥有提交权限和发布权限。 如果只有一个人能发布版本，那这个人就是单点故障。健康的项目至少有 3 到 5 人能够独立发布新版本。
明确的治理文档。 决策如何做出？谁对什么有权限？如何添加新维护者？在危机发生前就回答这些问题的项目，比临时应付的项目更能顺利完成交接。
渐进式交接，而非突然离场。 最好的领导交接，是卸任者在数月内有意识地减少投入，指导继任者，并明确移交权限。突然的离场即使出于善意，也会造成真空。
财务可持续性。 资金稳定的项目（通过基金会、企业赞助或社区众筹）在交接时更能存活，因为新接手的维护者能够获得报酬。让别人接手一份无薪的全职工作，是很难说服的。

用户和企业应该怎么做

如果你的业务依赖开源软件（而几乎所有业务都是如此），那么你所依赖项目的健康状况就与你息息相关。以下是几个实用步骤：

审计你的依赖巴士因子。 看看你技术栈中的关键开源项目：它们有多少活跃维护者？最近一次发布是什么时候？安全问题响应有多快？一个只有一位维护者、且六个月前的安全漏洞仍未修复的项目，是你应该知晓的风险。
为你使用的项目提供资金支持。 如果某个项目对你的业务至关重要，就为它的资金出一份力。GitHub Sponsors、Open Collective 和 Tidelift 都提供了相应渠道。相比关键依赖变得无人维护所造成的损失，资助一位维护者的成本微不足道。
向上游贡献代码。 修复 bug、改进文档、整理 issue，这些工作能减轻维护者的负担，也能让你的团队熟悉代码库。如果项目将来需要新的维护者，你就已经做好了接手的准备。
制定应急预案。 对于关键依赖，要清楚如果项目被弃用你会怎么办。你能分叉并自行维护吗？有没有可以迁移过去的替代方案？这些问题的答案，最好在真正需要之前就准备好。

开源治理算不上光鲜的工作，它不会制造头条，也不会带来 GitHub 星标。但一个项目能否在创始人离开后存续，差别几乎总是取决于治理：记录决策、分散权限、规划交接，这些枯燥却关乎结构的工作。能够长久存在的项目，建设的是制度，而不仅仅是软件。