Chaos and Order

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

はじめに — 10か月経っても終わらない紛争
Ruby Central — 検証可能なタイムライン
双方の主張 — 何が事実で何が性格づけか
Artichoke Rubyの終了 — 同時期、別の理由
三つの軸 — 商標、パッケージインフラ、資金
同じパターンの繰り返し
エンジニアが実際に点検すべきこと
終わりに — フォークできるものと、できないもの
参考資料

はじめに — 10か月経っても終わらない紛争

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が、2週間前の通知で退職します。
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ルートアクセス権限が残っていることに気づき、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の事務局長が解任され、団体は財政危機を理由にPR代理店契約とCFO職、外部契約者を整理し、理事会を無報酬の実務理事会に転換します。
2026年7月30日 — Arkoの最新の記事が出ます。

ここまでが、日付付きで確認できる事実です。

双方の主張 — 何が事実で何が性格づけか

Ruby Central側の説明は、大筋でこうです。 二人(ArkoとGiddins)がすでに組織を離れている状態でプロダクションインフラの管理者権限を保持し続けることは、サプライチェーン攻撃の対象面が広がる状況下では受け入れがたく、理事会の受託者責任のもとで最小権限の原則に沿ったアクセスモデルへ移行することが目的だったとされます。自社報告書が認める失敗は実行面に集中しています — 文書化されたオフボーディング手順やチェックリストがなかったこと、アクセス変更の事実と理由が当事者に適切に伝わらなかったこと、意思決定者ごとにGitHub権限とプロダクションサーバーアクセスのつながりの理解度が違っていたことです。報告書は「これは私たち全員の過ちだ」という趣旨で締めくくられています。ただし9月のアクセス権限剥奪については、外部で単純ミスとされたのとは違い、実際の問題はタイミングと社内コミュニケーションにあった、という説明にあらためて寄せています。

一方、離脱したメンテナーたちの説明は異なります。 Arkoはこれを敵対的買収だと位置づけ、自分を狙い撃ちした措置だと見ています。根拠として挙げるのは、Ruby Central自社の報告書がrvとSpinelの公開を引き金となった出来事だと明記している点です。彼はAWSルート権限の残存を発見し責任を持って報告したのに、逆に「ハッキング」の疑いで訴訟を示唆され、三度の監査でいずれも被害がなかったことが確認されたと書いています。彼が求めているのは、訴訟の脅しの撤回、被害がなかったことの公式確認、弁護士費用の補填、そして証拠なしに行われた公開非難への謝罪です。

ここで正直に区別しておくべきことがあります。

両者の見解が事実上一致している点。 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側の説明はスチュワードシップを前提とし、反対側はその資産がそもそも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の終了記事にはこの記事のテーマとつながる一節が一つあります。保守を続けさせるものは資金だけでなく、ユーザーベースと個人的な動機だということです。 この点は後でまた出てきます。

三つの軸 — 商標、パッケージインフラ、資金

オープンソースプロジェクトで実際に力の源泉となる資産は、コードではありません。コードはライセンスが許す限りいつでもフォークできます。フォークでは複製されないものが三つあります。

商標。 名前を法的に誰が所有しているか。フォークが元の名前を使えるかどうかは、ここで決まります。
パッケージレジストリ。 実際の配布が行われるインフラを誰が運用しているか。リポジトリをフォークしても、ユーザーが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では2年半にわたる社会工学がありました — 複数の偽アイデンティティがメーリングリスト上で燃え尽きかけていた原メンテナーLasse Collinにリリースが遅いと圧力をかけ、そうして入り込んだ共同メンテナーが2024年3月にsshdを狙うバックドアを仕込みました。MicrosoftのAndres Freundが、SSHログインの遅延という偶然の観測から発見していなければ、どこまで進んでいたか分かりません。この二つの事件はいずれも、資金という軸の不在がメンテナー軸の脆弱性を生んだという点で、前の事例とつながっています。

ガバナンス軸の正統性危機。 Nixがここに該当します。2024年4月、100人以上が署名した公開書簡が創設者Eelco Dolstraの辞任を求めました。争点は、コミュニティの調整手続きを損なったという指摘、彼が所属する会社との利益相反、そして防衛関連企業Andurilを NixCon のスポンサーとして受け入れようとした決定でした。DolstraはNixOS財団の理事会から退きました。コードには何の問題もありませんでした。崩れたのは、誰が何を決定する権限を持つのかについての合意でした。

所有権軸の行使。 Redis、Terraform、Elasticsearchはいずれも著作権者がライセンスを変更した事例で、いずれも大規模なフォークにつながりました。Redisは2024年3月にBSDからRSALとSSPLの二重ライセンスに変更し、Linux FoundationがValkeyをフォークしました。HashiCorpは2023年8月にTerraformをBUSLに変更し、3週間でOpenTofuフォークが組織され、9月にLinux Foundationに加わりました。Elasticは2021年にSSPLへ移行し、AWSがOpenSearchをフォークしました。

興味深いのは、この三つがいずれもかなりの部分まで揺り戻したという点です。 Elasticは2024年8月にAGPLv3を追加し、Redisは2025年5月のRedis 8.0でAGPLv3を追加しました。いずれもフォークが定着した後に出た決定です。Terraform側では、2024年4月にHashiCorpがコード複製を理由にOpenTofuへ中止要求書を送りましたが、OpenTofuは問題のコードがBUSL以前のMPLライセンスの祖先に由来することを詳細に反論し、訴訟には至りませんでした。HashiCorpは2025年2月にIBMに買収され、この件は終結しました。

ここから一つの観察が出てきます。ライセンス変更は元に戻せても、信頼と人は戻ってきません。 Valkey、OpenSearch、OpenTofuは、いずれも元のプロジェクトがライセンスを差し戻した後も生き続けています。

エンジニアが実際に点検すべきこと

この分析が実務につながる点は次の通りです。

依存関係を見るときは、メンテナーの数を数えてください。 ダウンロード数やGitHubスターはリスクの指標ではありません。core-js、event-stream、xz-utilsに共通するのは、ダウンロードが多かったことであって、少なかったことではありません。本当の指標は、直近12か月間に実際にコミット権限を使った人の数です。 その数が一人なら、それはその一人が燃え尽きるか、ソーシャルエンジニアリングに遭った瞬間に切れる依存関係だということです。

レジストリとリポジトリは分けて考えてください。 リポジトリがフォークされても配布経路はそのままのこともあれば、逆にリポジトリはそのままで配布経路が変わることもあります。社内プロキシやミラーを置いている組織であれば、上流のレジストリが本当に一つしかないか確認しておく価値があります。gem.coopのような代替ホストが現れる状況では、この区別が実質的な意味を持ちます。

ライセンス変更のリスクは、所有構造から読み取れます。 単一企業が著作権を集中的に保有し、コントリビューターライセンス同意書で権利を集めているなら、ライセンス変更はいつでも選べる選択肢です。逆に著作権が多数のコントリビューターに分散していれば、変更は事実上不可能になります。Redis、Elastic、HashiCorpはいずれも前者でした。

中核となる依存関係にはお金を使ってください。 Tidelift調査の結果が語るのは感傷的な話ではなくリスク管理です。報酬を受け取っているメンテナーの方が脆弱性を速く修正します。組織が毎年クラウド費用に使う金額と、そのコードが依存する中核的な依存関係に支払う金額を並べてみると、たいていその比率はばかげたものになります。

終わりに — フォークできるものと、できないもの

まとめるとこうなります。

Ruby Central騒動は2025年9月の権限回収から始まり、2025年10月にリポジトリ管理がRubyコアチームへ移ったことでコードの層は整理されましたが、2026年7月現在、当事者間の紛争は未解決のままです。
双方とも一次証言を公開しており、実行面の失敗についてはRuby Central自身が認めた部分があります。Shopifyの関与という筋書きは繰り返し報じられていますが、当事者の確認がない主張です。
同時期のArtichoke Rubyの終了はこの騒動と無関係です。終了記事の理由はすべて個人的でプロジェクト内的なものです。
繰り返される危機の構造は、商標、パッケージインフラ、資金という三つの軸が別々の主体に分散している点にあります。
ライセンスは元に戻せても、フォークと人は戻ってきません。

オープンソースにおいて、コードはいつでもフォークできます。フォークできないのは、名前と、配布経路と、人です。ガバナンスという言葉が抽象的に聞こえるなら、その三つをそれぞれ誰が握っているかを書き出してみるだけで、十分に具体的になります。自分の組織が依存するプロジェクトについてその表を埋められないなら、それはまだ危機が来ていないという意味であって、リスクがないという意味ではありません。