Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 十个月过去，纷争仍未平息
Ruby Central 事件 — 一条可核实的时间线
双方的说法 — 哪些是事实，哪些是定性
Artichoke Ruby 的终止 — 同一时期，不同的原因
三根支柱 — 商标、包基础设施、资金
同一种模式的反复出现
工程师真正应该检查的事
结语 — 能 fork 的东西，和不能 fork 的东西
参考资料

引言 — 十个月过去，纷争仍未平息

2026 年 7 月 30 日，Bundler 的作者 André Arko 发布了Ruby Central's Destructive Legacy。次日该文登上 Hacker News，获得 43 点赞、23 条评论。

2025 年 10 月，松本行弘(Matz)与 Ruby 核心团队接手 RubyGems 与 Bundler 仓库的管理时，多家媒体报道称这场纷争已经结束。这个说法只对了一半。代码层面的管理权理清楚了，但纷争本身并未解决。 据 Arko 的说法，2026 年 3 月 Ruby Central 的律师向 FBI 举报了他，而他在 4 月提出的和解方案，过了 30 多天也没有得到实质性的回应。

本文无意评判谁对谁错。双方都公开了第一手陈述，事实本身也确有分歧之处。这里想做的，是读出这件事背后的结构，因为同样形态的危机会在 core-js、event-stream、xz-utils、Nix，以及 Redis 和 Terraform 身上反复出现。原因就在于，三根支柱最终分散到了不同的主体手中。

Ruby Central 事件 — 一条可核实的时间线

先从双方陈述大体一致的事实说起。来源是Ruby Central 2025 年 9 月 25 日的声明、2026 年 3 月底发布的自查事后报告，以及Arko 2025 年 10 月 9 日的反驳文章。

先说背景。Ruby Central 是运营 RubyConf 与 RailsConf、并负责 rubygems.org 基础设施的非营利组织，2021 年吸收了曾为 Bundler 与 RubyGems 开发提供资金的 Ruby Together。进入 2025 年后，Sidekiq 的年度赞助(据报道规模约 25 万美元)中断，该组织在财务上对 Shopify 的依赖也在加深。

2025 年 6 月 3 日 — Arko 辞去在 Ruby Central 的顾问职务。他的意思是继续在开源方面提供建议，但不再代表这个组织。
2025 年 8 月 18 日 — Ruby Central 全职聘用的安全负责人 Samuel Giddins，提前两周通知后离职。
2025 年 8 月 25 日至 26 日 — Arko 公开了 Ruby 版本管理工具 rv 和 Spinel 组织。Ruby Central 自己的报告明确将这一时点称为触发事件。
2025 年 9 月 9 日至 10 日 — GitHub 上的 RubyGems 企业账号更名为 "Ruby Central"，Arko(indirect)、Giddins(segiddins)、Martin Emde(martinemde)的管理员权限被移除。
2025 年 9 月 15 日 — 官方对外把这一举动解释为"失误"，部分权限一度恢复。同一周，针对 npm 生态的大规模钓鱼式供应链攻击爆发，Ruby Central 之后将其作为安全考量的佐证引用。
2025 年 9 月 18 日 — 上述三人加上 Ellen Dash(duckinator)被彻底移出 GitHub 组织。同一天，理事会正式表决收回生产环境访问权限与提交权限。
2025 年 9 月 18 日至 19 日 — 六人抗议辞职：Arko、David Rodríguez、Ellen Dash、Josef Šimánek、Martin Emde、Samuel Giddins。
2025 年 9 月 30 日 — Arko 发现自己仍然保留着 rubygems.org 生产环境的 AWS root 访问权限，并发邮件告知 Ruby Central。
2025 年 10 月 5 日 — Martin Emde 发布gem.coop，一个参考 Homebrew 治理模式的合作社形式 gem 托管平台，初期作为 rubygems.org 的实时镜像运行。
2025 年 10 月 17 日 — ruby-lang.org 的公告确认了这一分工：Matz 与 Ruby 核心团队接手 RubyGems 与 Bundler 的代码仓库管理，rubygems.org 的基础设施运维，则继续由 Ruby Central 负责。
2026 年 3 月底 — Ruby Central 公开了由 Richard Schneeman 撰写的事后报告。
2026 年 4 月 19 日 — Ruby Central 的执行董事被解职，该组织以财务危机为由，终止了公关代理合同和 CFO 职位，解除了外部合约人员，并把理事会转为无薪的实务理事会。
2026 年 7 月 30 日 — Arko 发布了最新这篇文章。

以上是带着日期、可以确认的事实。

双方的说法 — 哪些是事实，哪些是定性

Ruby Central 方面的说法大致是这样的。 两个人(Arko 和 Giddins)已经离开了组织，还继续保留生产基础设施的管理员权限，在供应链攻击面不断扩大的背景下难以接受，目标是转向一套符合最小权限原则、也符合理事会受托责任的访问模型。它自己的报告承认的失误，集中在执行层面 —— 没有形成文档化的离职交接流程或清单，权限变更的事实和理由没有妥善传达给当事人，不同的决策者对 GitHub 权限与生产服务器访问之间的关联理解程度也不一致。报告的结尾基调是"这是我们所有人共同的错误"。不过，针对 9 月的权限收回，与外界将其定性为单纯失误不同，Ruby Central 的报告又重新给出了解释：真正的问题出在时机和内部沟通上。

而离开的维护者们的说法则不同。 Arko 将此定性为一次敌意接管，并认为这是针对他个人的行动。他给出的依据是，Ruby Central 自己的报告明确把 rv 和 Spinel 的发布称为触发事件。他写道，自己发现遗留的 AWS root 权限后负责任地做了报告，换来的却是被以"黑客入侵"的指控威胁提起诉讼，而三次独立审计都确认没有造成任何损害。他要求的是：撤回法律威胁、公开确认没有造成损害、补偿他的律师费用，以及为没有证据支持的公开指控道歉。

这里有几层区别，值得如实分开来说。

双方基本一致的部分。 Ruby Central 自己 9 月 25 日的声明就已表明，没有迹象显示 rubygems.org 的数据被未经授权地复制或留存。这与 Arko 自己所说的审计结果方向一致。

只存在于一方陈述中的部分。 FBI 举报，以及和解谈判的具体内容与进展，完全出自 Arko 一方的陈述。我没有找到 Ruby Central 对此予以确认或否认的公开材料。

未经证实的情节。 Shopify 拿资金当杠杆、要求把 Arko 排除出去 —— 这个说法在多篇二手报道和社区人士的文章里反复出现，但我没有找到 Ruby Central 或 Shopify 官方确认或否认过这件事的记录。 Ruby Central 的公开文件只以理事会受托责任和供应链安全作为依据，没有点名任何具体赞助商。这一部分应当被当作一种说法来看待。

解释上存在分歧的部分。 2021 年吸收 Ruby Together 一事，Ruby Central 到底因此获得了对 Bundler 和 RubyGems 的哪些权利。Ruby Central 一方的说法预设了自己拥有管理权(stewardship)，而另一方则认为，那些资产本来就不属于 Ruby Together，所以根本谈不上转移。这不是情绪层面的分歧，而是法律上的所有权问题。 这也是本文下一节要处理的内容。

Artichoke Ruby 的终止 — 同一时期，不同的原因

与这起事件常被相提并论的，是 Artichoke Ruby 的终止。这是一个用 Rust 编写的 Ruby 实现，由 Ryan Lopopolo 在 2019 年的 RubyConf 上首次公开。

把核实到的结果原样写下来。终止公告是Winding Down Artichoke Ruby，发布于 2026 年 2 月 15 日；仓库本身则更早，在 2025 年 11 月 3 日就已被归档。而且，这篇文章完全没有提到 Ruby Central 或 RubyGems 之争。 作者给出的理由全部是个人层面、项目内部的原因 —— 随着年龄增长，重心转向了工作和家庭；目前的工作(OpenAI)足够投入，占据了他的注意力；维护一个语言运行时的机会成本很高；持续追踪与 MRI Ruby 的兼容性是个没有尽头的负担；而这个负担又缺少足够大的用户群来证明其合理性。

在 Hacker News 上的曝光也不高。我找到的唯一一条提交是 2026 年 7 月 25 日的，5 点赞、0 条评论。这两件事只是时间上重合，并没有因果关系。 之所以特意写下这一点，是因为在治理危机的叙事周围，时间相近的事件很容易被事后强行关联在一起。

不过，Artichoke 的终止公告里，有一段与本文主题相通：让维护得以持续的，从来不只是资金，还有用户基础和个人动机。 这一点后面还会再提到。

三根支柱 — 商标、包基础设施、资金

在一个开源项目里，真正带来权力的资产不是代码。只要许可证允许，代码随时可以被 fork。有三样东西是 fork 复制不走的。

商标。 名字在法律上归谁所有。fork 能不能沿用原来的名字，取决于这一点。
包注册表。 实际分发发生的基础设施由谁运营。就算把仓库 fork 出去，用户用 gem install 或 npm install 拿到的东西，依然来自原来的注册表。
资金。 真正给维护者付钱的是谁。

这三样东西如果都握在同一个主体手里，这个主体的性格就会变成项目的性格；如果分散开来，就会产生协调成本。危机往往发生在三者分散、其中一方试图把另一方当作杠杆的那一刻。

生态系统	商标	注册表运营	仓库管理
Ruby	Ruby Association 扮演管理者角色(未能确认存在单一的注册商标持有人)	rubygems.org：Ruby Central	Ruby 核心团队(2025 年 10 月以后)
Bundler	André Arko 个人持有(据其本人说法)	同上	同上
Python	Python Software Foundation	PyPI：Python Software Foundation	核心开发者 + PSF
JavaScript	不适用	npm：GitHub，即 Microsoft	按包分散
Rust	Rust Foundation	crates.io：crates.io 团队 + Rust Foundation	Rust 项目
Java	不适用	Maven Central：Sonatype(一家营利公司)	按包分散

看 Ruby 这一行，问题一目了然。商标、注册表、仓库管理这三者分散在三个不同的主体手中，其中一个 —— Bundler 商标 —— 还握在个人手里。 和 Python 那一行一比，对照非常鲜明。PSF 把商标和 PyPI 一并握在手中，所以至少"谁能拿主意"这个问题是有答案的。

第三根支柱、也就是资金方面的数据，也一并附上。Tidelift 2024 年维护者调查(基于 437 名受访者)显示，60% 的人没有报酬，约 60% 的人曾经放弃过，或者认真考虑过放弃自己维护的项目，其中把原因归结为职业倦怠的比例是 44%。同一份调查还发现，拿报酬的维护者会把更多时间花在安全上，修复漏洞的速度也更快。另一头，则是 GitHub Sponsors 宣布截至 2026 年 7 月 21 日，累计支付已经超过 1 亿美元，支持了 7 万多名维护者和组织。把这两个数字放在一起，情况就看得很清楚了 —— 资金总量在增长，但分配依然集中在少数项目身上，对大多数维护者来说，资金这根支柱实际上并不存在。

同一种模式的反复出现

从三根支柱的角度回看过去的案例，会发现它们能被归到几个类别里。

资金支柱的缺位。 core-js 是典型代表。2023 年 2 月 14 日，事实上的唯一维护者 Denis Pushkarev 发布了《So, what's next?》，写道免费的开源本质上是坏掉的。大意是，他每周要扛住数千万次下载，赞助收入却只有每月几百美元的规模(具体数字各家报道不一，可信度不高)，他表示正在考虑转向付费模式。结果这篇文章传播开后，赞助大幅增加，core-js 至今仍由他独立维护。资金支柱的缺位，不一定会爆炸 —— 它也可能只是安静地磨损下去。

维护者支柱被接管。 event-stream(2018 年)和 xz-utils(2024 年)是同一种形态。在 event-stream 中，原作者 Dominic Tarr 已经放手维护，把提交权限和 npm 发布权限交给了一个主动请缨的账号，那个账号随后添加了一个叫 flatmap-stream 的依赖，在其中植入了针对 Copay 比特币钱包的恶意代码。在 xz-utils 中，则是长达两年半的社会工程 —— 多个虚假身份在邮件列表上持续向已经身心俱疲的原维护者 Lasse Collin 施压，抱怨发布太慢，而借此机会混进来的共同维护者，在 2024 年 3 月植入了一个针对 sshd 的后门。要不是 Microsoft 的 Andres Freund 因为 SSH 登录延迟这个偶然现象发现了问题，事情会走到哪一步，谁也说不好。这两起事件都说明了同一件事：资金支柱的缺位，造就了维护者支柱上的脆弱性，这一点与前面的例子一脉相承。

治理支柱的正当性危机。 Nix 属于这一类。2024 年 4 月，一封有 100 多人签名的公开信要求创始人 Eelco Dolstra 辞职。争议点包括：他破坏了社区的协调程序、他与自己任职的公司之间存在利益冲突，以及他打算接受防务承包商 Anduril 作为 NixCon 赞助商的决定。Dolstra 从 NixOS 基金会理事会退出。代码本身没有任何问题，崩塌的是谁有权决定什么这件事上的共识。

所有权支柱的行使。 Redis、Terraform、Elasticsearch 都是版权持有者更改许可证的例子，也都导致了大规模的 fork。Redis 在 2024 年 3 月从 BSD 改为 RSAL 与 SSPL 双许可证，Linux 基金会随后 fork 出了 Valkey。HashiCorp 在 2023 年 8 月把 Terraform 改成了 BUSL，三周之内 OpenTofu fork 就组织了起来，并于 9 月加入 Linux 基金会。Elastic 在 2021 年转向 SSPL，AWS 则 fork 出了 OpenSearch。

有意思的是，这三起案例后来都在相当程度上出现了回摆。 Elastic 在 2024 年 8 月加回了 AGPLv3，Redis 也在 2025 年 5 月的 Redis 8.0 中加回了 AGPLv3。两次都是在 fork 已经站稳脚跟之后做出的决定。Terraform 这边，HashiCorp 在 2024 年 4 月以代码抄袭为由向 OpenTofu 发出了中止函，但 OpenTofu 详细反驳，指出涉事代码源自 BUSL 之前、MPL 许可下的祖先代码，最终没有走到诉讼那一步。HashiCorp 在 2025 年 2 月被 IBM 收购，这件事也就此告一段落。

由此可以得出一个观察：许可证的变更可以撤回，但信任和人心回不来。 Valkey、OpenSearch、OpenTofu 即便在原项目改回许可证之后，如今依然活得好好的。

工程师真正应该检查的事

这套分析落到实践上，大致是这样的。

审视一个依赖时，去数维护者的人数。 下载量和 GitHub star 数不是风险指标。core-js、event-stream、xz-utils 的共同点是下载量都很高，而不是很低。真正的指标是过去 12 个月里，实际使用过提交权限的人数。 如果这个数字是一，那就是一个只要那个人一旦燃尽、或者遭遇社会工程攻击，就会立刻断掉的依赖。

把注册表和仓库分开来想。 仓库被 fork 之后，分发路径可能维持不变；反过来，仓库不变，分发路径也可能改变。如果你的组织搭了内部代理或镜像，值得确认一下上游注册表是不是真的只有一个。在 gem.coop 这类替代托管平台出现的背景下，这个区分开始变得有实际意义。

许可证变更的风险，能从所有权结构里读出来。 如果版权集中在一家公司手里，并且通过贡献者许可协议(CLA)不断把权利收拢过来，那么更改许可证随时都是一个可选项。反过来，如果版权分散在众多贡献者手中，变更在实际操作上就几乎不可能。Redis、Elastic、HashiCorp 都属于前一种情况。

在核心依赖上花钱。 Tidelift 调查结果说的不是什么煽情的故事，而是风险管理。拿报酬的维护者修复漏洞更快。把你的组织每年花在云成本上的钱，和花在代码真正依赖的核心项目上的钱放在一起比一比，比例通常荒谬得很。

结语 — 能 fork 的东西，和不能 fork 的东西

总结一下：

Ruby Central 事件始于 2025 年 9 月的权限收回；2025 年 10 月仓库管理权移交给 Ruby 核心团队后，代码层面算是理清了，但截至 2026 年 7 月，当事双方之间的纠纷依然没有解决。
双方都公开了第一手陈述，Ruby Central 自己也承认了一些执行层面的失误。Shopify 介入的说法被反复报道，但始终是一个没有得到任何一方证实的说法。
同期发生的 Artichoke Ruby 终止，与这起事件无关。终止公告给出的理由完全是个人层面、项目内部的原因。
反复出现的危机，其结构都在于商标、包基础设施、资金这三根支柱，最终分散到了不同的主体手中。
许可证可以撤回，但 fork 和人心回不来。

在开源世界里，代码永远可以被 fork。不能被 fork 的，是名字、分发渠道，还有人。如果"治理"这个词听起来太抽象，那么把这三样东西分别握在谁手里写下来，就足够具体了。如果你没办法为自己组织所依赖的某个项目填满这张表，那说明危机还没有到来 —— 而不是说明没有风险。