世界を動かす技術を、日本語で。

Rubyコアが「Rubygems」と「Bundler」の運営を引き継ぐ

概要

  • RubyGemsBundler の管理がRubyコアチームへ移管
  • 長期的な 安定性継続性 の確保が目的
  • オープンソース ライセンスや貢献者の権利は維持
  • Ruby Central との共同運営体制へ移行
  • Rubyコミュニティとの 協力的開発 の継続を強調

RubyGemsおよびBundlerの管理移管について

  • RubyGems および Bundler は、長年にわたりRuby言語に同梱され、Rubyエコシステムの標準ライブラリとして機能
  • これまで両プロジェクトは Ruby Central 主導で、Ruby組織外のGitHubリポジトリで開発
  • 今後、 Rubyコアチーム がリポジトリの所有権を持ち、長期的な安定性とエコシステム全体との整合性を目指す運営体制へ
  • Ruby Central とRubyコアチームによる共同管理体制を構築
  • オープンソースライセンス (現行通り)を維持し、ライセンス条件の変更なし
  • 既存貢献者の 著作権著作者表示 はそのまま継続
  • 今回の移管によって、貢献者の知的財産権への影響なし

コミュニティへのメッセージ

  • 共同開発コミュニティ主導 の開発体制はこれまで通り継続
  • すべてのRubyコミュニティメンバーからの貢献を歓迎
  • この移管は、Rubyエコシステムの健全性・安定性・成長を長期的に確保するための取り組み
  • Ruby Central の長年にわたる尽力に感謝の意を表明
  • Rubyコミュニティ全体と協力し、より明るい未来を築く決意

今後の展望

  • RubyGemsおよびBundlerの 持続的な発展 を目指す運営体制
  • コミュニティとの 対話協調 を重視
  • Ruby言語とエコシステムの さらなる成長 への期待

Yukihiro Matsumoto(Matz) より、Rubyコミュニティへの感謝と今後の協力要請

Hackerたちの意見

これが正しい動きだと思う。Ruby CoreとMatzに感謝!言語やコミュニティ全体に安定をもたらしてくれてありがとう。

Matzは柱だよね。「Matzは優しいから、私たちも優しい」って覚えてる? s/nice/nice and responsible/gc。

Matzがこの難しい状況に立ち上がってくれたこと、本当に感謝してる。日本の開発者として、物事の進む方向に不安を感じてたから、これを見ると安心するよ。

どうやってステップアップするの? 実際、広瀬柴田が一人で勝手に行動してたわけじゃないのは明らかだったよね。結果を知ってたとは言わないけど、いつ「gem」と「bundler」を引き継ぐ決定がされたの? もう数ヶ月前に決まってたんじゃないかって少し疑ってる。 > 「日本の開発者として、物事の進む方向に不安を感じていたので、これを見て安心しました。」 でも、今はもっと心配になってる。アメリカにも日本にも住んでないから、なんか日本とアメリカがRubyエコシステムを完全に支配してるように見える。日本のローカルコミュニティがあるのは理解できるけど(英語圏とは違うし)、アメリカの影響力がこんなに強いのは本当に腹立たしい。どうしようもないんだろうけど。Pythonでもアメリカが支配してるみたいだし、これって本当に最悪だと思う。

長期的には、gem.coopのような複数のソースがあった方が安全で堅牢な解決策になると思う。でも、RubyGemsに関しては、信頼が完全に失われちゃったからね。メンテナやコミュニティのメンバー、スポンサーなど、いろんなレイヤーで。資金やデータプライバシーの問題など、まだ解決すべきオープンクエスチョンがあるけど、Ruby界のほとんどの人はこれを支持すると思うよ。

でも、これはツールの話であって、「rubygems.org」自体はまだ敵対的な団体に所有されてるから、どうやって信頼を回復するのかは分からないな。

何が具体的に起こったのか、まとめてくれない?(もしよければ)最近、Rubyのニュースを追ってなかったから。

同意だね。gem.coopがどれだけの勢いを持てるか、様子を見る必要があると思う。今のところ「未来のためのこと」を約束してるけど、最終的には実現するだろうね。でも、今はまだそこまで行ってない。ベータ版が開放されたら、古いgemを再公開しようと思ってる(全部じゃないけど、いくつかは他のgemに統合したし、コアの部分は戻ってくるよ)。改善すべき点もいくつかあるけどね。ドキュメント(Rubyのドキュメントが別だったのも問題だし)、名前空間(Rubyには主な名前空間の方法がなかったのも一因だし、これは機能でもあるけど、可能なら関心を分ける方法が必要だと思う)。とにかく、すぐに何が起こるか見えてくると思う。半年後くらいに再評価すべきだと思う、例えば2026年の5月末とかね。これがもっと現実的なタイムフレームだと思う。ただ、DHHがgem.coopにとって最大の資産になるかもしれないとも思ってる。彼がブログで皮肉を言うたびに、新しい不満を持った人が集まって、その中の何人かが最終的にgem.coopに貢献するかもしれないから。エンドユーザーにとっては、好きなようにインストールできるから、柔軟性が増すウィンウィンの状況になるかも。多くの人はrubygems.orgに留まるだろうし、他の人はgem.coopを好むかもしれないし、両方を使う人も多いだろうね(これはちょっと難しいかも。gem.coopはgemごとに異なるソースを指定する方法を考える必要があるかも。確かにやるべきことはたくさんあるね)。

分散型パッケージホスティングが唯一の方法だね。

どの言語がこれをうまく取り入れてるの?C++みたいに実質的に「パッケージ」がないのは除外するけど。

ここでの重要な質問は、サプライチェーン攻撃をどうやって防ぐかってことだよね。ライブラリの新バージョンのリリースを何かの取引と考えると、暗号通貨との違いが見えてくる。暗号取引は自動で検証できるけど、ソフトウェアのリリースはそれができないからさ。信頼度が非常に高いホスティングが何百もあるなんて想像しにくいし、リスクが大きくなるか、みんなが信頼できるホスティングが数少ないってことになる。ホスティングの数がユーザー数よりも圧倒的に少ないと、真の分散型とは言えないし、政治的な対立があった場合のリスクも残る。まとめると、分散型が本当に解決策になるのかは分からないな。中央集権的な解決策に対する透明なコミュニティの所有がずっと良いと思う。

Ruby Centralのサイト: https://rubycentral.org/news/ruby-central-statement-on-rubyg...

参考までに、9月19日の彼らの以前の声明も見てみて。これも「Rubyエコシステムの長期的な安定と成長への共通のコミットメントを反映している」って言ってるから:https://rubycentral.org/news/strengthening-the-stewardship-o...

誰かこれを簡単に説明してくれない?ちょっと外部の人には難しいんだよね。

何度か手が変わったけど、移行の詳細はあまりはっきりしてないよね。どうやってこうなったのかは透明性がなかったし、コミュニティ内の緊張も高まってた。なぜなら、一番声が大きくて認知度の高い人があまり人気のない意見を持ってて、それを大声で主張してたから。

詳細はこのスレッドを見てね:https://news.ycombinator.com/item?id=45299170#45300774 特にマイク・マクエイドの要約がいいよ。彼は状況を外部の人にもわかりやすくするために、いろいろ調整やコミュニケーションの仕事をしてた。今の彼の投稿もチェックしてみてね:https://bsky.app/profile/mikemcquaid.com

Rubyに関わる人なら、これが唯一の結果で不満を持つことはないよね。

できない?

どういうこと? まだ質問が山ほど残ってると思うけど。でも、未来がどうなるかは見てみないと分からないよね。例えば、gem.coopがどれだけ人気になるか見ないといけないし(人気になるかもしれないし)。それに、意見が違っても、Rubyプロジェクトのインストールを最初から解決する方が良かったんじゃないかとも思う、例えばRust + cargoみたいに。でも、これはrubygems.orgのようなサービスとは別の話だと思う。機能を誰が開発するかは別問題で、ここに強い好みはないよ。それに、bin/gemとbin/bundleの両方があるのは良くないと思う。統一されたAPIが必要だね(または二つ、Rubyコアが管理するシンプルなものと、みんなが自分のバリアントに追加機能を組み込めるもの)。残念ながら、これもこうなっちゃうかもね: https://xkcd.com/927/ 私がbin/gemに好きだったのはそのシンプルさ。Bundlerは新しいことや簡単なことをいくつか持ってきたけど、「gem」はgem.coopを含むどんなソースでも使いやすくするべきだと思う。

Ruby CentralよりはRubyコアの方がマシだけど、何が起こったのかちょっと疑問に思うし、全体のエコシステムに対して少し気分が悪くなってる。

正直、ドラマは面白いよね。でも、影響を受けてるRubyの人たちには申し訳ないな。最後に、Matzは最高だよ!

じゃあ、この全てはDHHへの嫌悪から来てるの? rubygems.orgが単にrubygemsのコードをフォークして、必要だと思う「セキュリティとガバナンス」の変更を自分たちのフォークで行って、それを運営することもできるんじゃない? それが方向性の違いを扱うオープンソースのやり方じゃないの?

サプライチェーンがどう扱われるか、特にRubygemsとBundlerがサプライチェーン攻撃からどう守られるかについて、もっと安心感が欲しいな。これが蔓延してきてるから。