当金主伸手拿走开源仓库：RubyGems 事件给所有技术决策者的提醒

事情是怎么发生的

九月初，Ruby 核心成员、同时也是 RubyGems 维护者的 HSBT 把 RubyGems 的 GitHub 组织改名为 Ruby Central，加入了一位新的组织所有者，并下调了多名维护者的权限。九月十八日，这些维护者被彻底移出组织、rubygems.org 邮箱被停用、也失去了 bundler 与 rubygems-update 这两个 gem 的 owner 权限。其中一位维护者当时正在为 RubyGems.org 服务做值班支持，访问权限在他值班期间被撤销。

据公开复述的会议记录，这次接管并非社区共识。Ruby Central 的董事会投票通过了接管决议，理由是 "为了加强供应链安全"。而维护者此前已经明确区分过两件事：RubyGems 的源码仓库是社区共有、由社区维护的公共资产；Ruby Central 运营的是 RubyGems.org 这个具体服务——域名、服务器、部署。运营一个服务，不等于拥有这套代码。

钱的结构决定了话语权的结构

事件的关键背景是资金。Ruby Central 此前在一场大会上的决定，导致他们失去了每年二十五万美元的赞助，此后几乎完全依赖单一赞助方。当基金会的主要收入来源集中到一家公司时，"谁在治理这个项目" 这个问题，答案往往不由章程决定。

对使用开源的企业意味着什么

大多数企业不会因此停止使用 Ruby、Bundler 或者任何开源组件——依赖太深，替换成本太高。但这件事至少该带来三个动作。

第一，把关键依赖的治理结构纳入评估：谁有发布权限，资金来自哪里，是否有明确的运营协议（operator agreement）把访问权限和责任绑定。第二，给自己的技术栈准备 "最坏情况" 预案：如果某天上游改了许可、删了包、或者被接管，你的构建还能不能跑起来——本地镜像、供应商托管、版本锁定，这些成本远低于一次供应链事故。第三，如果企业本身在赞助开源项目，想清楚赞助的边界：钱可以买影响力，但把公共资产变成私有资产，会连带损害所有依赖者，包括赞助方自己。

一句话

开源说的是源码可见，从来不是治理民主。技术选型时多问一句 "这个项目谁说了算"，比事后追问为什么被接管要便宜得多。