- gem.coopはRubyエコシステム向けの新しいgemサーバー
- RubyGems.orgの元運営メンバーがコミュニティのために構築
- RubyGems.orgのすべての公開gemをリアルタイム同期で提供
- Homebrewに着想を得たガバナンスにより、透明性とコミュニティ参加を重視
- 持続可能でセキュリティを強化したgemホスティングを目指す
gem.coop の紹介
- gem.coopはRubyエコシステム向けに設計された新しいgemサーバーで、より高速かつシンプルなホスティング環境の提供を目標としている
- Bundlerとの完全な互換性を維持しつつ、次世代の開発環境に最適化された性能と安定性を重視している
- このプロジェクトはRubyGems.orgの元管理者および運営メンバーが直接参加し、コミュニティのためのサービスとして開発されている
- すべての公開gemはRubyGems.orgからリアルタイムで同期され、gem.coopでも即座に利用可能
- 既存のGemfileではsourceのアドレスを変更するだけで利用でき、導入方法は非常に簡単
ガバナンスとコミュニティ参加
- Homebrewプロジェクトのガバナンスモデルを参考に、透明性が高く参加しやすい構造を導入
- Mike McQuaidの協力のもとで組織設定と運営方式が整備されており、10月10日までに正式なガバナンス形態が公開される予定
- Rubyコミュニティの誰もが貢献と参加できるよう、オープンな構造で運営する計画
サービス目標と今後の計画
- gem.coopの最終的な目標は、コミュニティ所有型で高速・透明・持続可能かつセキュリティが強化されたgemホスティングプラットフォームを提供すること
- 初期段階ではすべての公開gemのbundlingとインストールをサポートし、今後も機能と品質を継続的に改善していく予定
- gem.coopのニュースレターを通じて月次アップデートを受け取れる
チーム構成
- 開発および運営はGem Cooperativeに所属し、deivid-rodriguez、duckinator、indirect、martinemde、segiddins、simiが主導している
1件のコメント
Hacker Newsの意見
すべての論争はさておき、現時点で元のRubyGemsはメンテナーが全員去った状態であり、新しいプロジェクトには従来の主要コントリビューターの大半が参加していることを確認した。以前はdeividだけが目立つ存在だったが、今は主要人物のほとんどがこちらに来ているようだ。もはやこのフォークの方がより適切に管理されているソフトウェアのように感じる。人々が近いうちにこちらへ移行する可能性や、資金調達モデル、ホスティング費用の負担について情報があるのか気になる。追加情報はこちらにもある
今このフォークの方がよりよく保守されているソフトウェアに見えるとしても、実際に重要なのはソフトウェア自体よりインデックスサービスの保存容量と帯域幅だと思う。単純にgem検索エンジンがハッシュを保存し、ダウンロードは外部、たとえばGitHubのようなリポジトリへリンクする形にしても、うまく機能するのではないかと思う
この状況は少しほろ苦い。もしこのフォークが成功すれば、JSの世界のように「どのパッケージマネージャーを使うべきか？」を考える構図になるだろう。これまでの「bundlerとrubygemsだけを使えばいい」という美しい単純さが失われる。とはいえ、不当な扱いを受けたRubyGemsの既存メンテナーたちが、公に問題提起したあと静かにフォーク作業に着手した点は大いに称賛したい。RubyGemsのフォークなど不可能に見えたが、今は小さくともその可能性を彼らが作り出している。大企業の多くはおそらくShopifyが後ろ盾になっているRC側に残るだろうし、そのような組織ではセキュリティ監査も強化されるだろうが、革新は乏しいだろう。一方でgems.coopが成功するとすれば、それは単に「より良いツール」として定着するからだろう。たとえばAndréが作っているrv.devは、Rubyのバージョン管理、gem依存関係、npxのような機能までサポートする「高速でオールインワン」のツールであり、開発者体験（DX）の面で優位に立つはずだ。名前空間、チェックサム、より攻めた技術的セキュリティアプローチなども議論されており、もしRCが今のまま進むなら、最終的には技術的に優れた側が勝つかもしれない。資金面では、Andréは「OSSインフラの費用を負担できる組織は実際にお金を払うべきだ」と考えているようで、私も同意する。そうすれば、正確に費用を見積もり、支払う企業数で分担する透明な仕組みになると思う。最後に、RCがここまで壊れた根本原因は、少数のスポンサーに資金が過度に集中していたからだと思うので、Ruby Co-opには100人、1000人以上の分散型資金調達モデルを築いてほしい
資金調達モデルはまだ未定とのこと。関連リンク
公式ページには情報があまりにも少ない。なので論理的にいくつか仮定してみると、1) 配布はRubyGemsに依存せざるを得ない。2) gem検索や閲覧のためのUIがなく、RubyGemsに依存する。技術的な詳細はさておき、実質的な移行のきっかけは、自分がフォークのメンテナーたちと思想的に一致しない限りまったくない。業務目的なら移る理由はなく、個人的に興味があれば覚えておく程度だろう。多くのフォークがそうであるように、目的を果たせば統合されるか、まったく新しい標準になるか、忘れ去られるかだ。自分に直接影響がないなら、私はただ見守るつもりだ。彼らの問題提起や作業をけなすつもりはなく、DHHのせいでRailsをフォークする場合よりははるかに説得力のある状況だ
この10年間でruby gemsやbundlerにおいて、記憶に残る、あるいは必要だと感じた新機能は思い浮かばない。もちろん新機能はあったのだろうが、自分は認識していない
Andre Arkoの評判を見ると（最近のこの記事で整理されているように）、今回の動きの動機については少し警戒している
その記事は個人的な遺恨に基づく攻撃的な文章に見える。評価する際にあまり重く受け止めない方がいいと思う
最も否定的なシナリオとしてはこうだ。uvはすばらしいツールだが、Astralは有料サービスとの連携を明らかに計画している。そうしたものが一種の参入障壁になる。そしてAndreとチームがPythonの世界（uvの成功のような）からヒントを得て、同じことをRubyでやろうとしている、という見方だ。rvを発表することでRuby Gemsを自分たちに依存させようとしており、Hashicorpなどの事例を見ても、無料で取り込んで必須機能をエンタープライズ向けのペイウォールの向こう側に置くやり方はますます増えている。Rubyエコシステムが特定の個人や少人数の集団に従属するのは、今のRuby Centralと同じくらい危険だと思う
オープンソースコミュニティがこのように力を合わせて解決策を探している姿に驚かされる。このプロセスに尽力したすべての人に感謝したい
これは自分の考えだが、なぜgitを新しい標準に移さないのか気になる。コミット署名、タグ署名、分散構造など、はるかに優れた代替案に見えないか？
gitプロトコルは複雑度が高く、拡張性に乏しい。特に毎回すべてのパッケージをCIで再ダウンロードするなら非効率だ。単一ファイルのアーカイブの方がはるかに配布しやすい。ダイジェストや署名アルゴリズムはgit固有のものではなく、鍵と身元管理の方が難しい部分であり、gitがそれも完全に解決するわけではない（gitとGitHubを混同するな、という意味だ）
誰かがgitサーバーを運用しなければならず、各gemごとにそのgitサーバーを探してPullしなければならない。すべてのgitサーバーが最新バージョンを持っているわけでもないので、それぞれが個別にスケールしなければならない。中央集権の利点は、すべてが一か所に集まり、スケールも一度にでき、更新も同時適用できることだ。昔はartifactoryなどでNPM、パッケージマネージャ、dockerコンテナをプロキシして使っていたので、中間サービスが止まっても問題なくデプロイできた。しかし小規模な開発者やチームにとっては、こうした管理は不要なオーバーヘッドに感じられる
実際、rubygems（ソフトウェア）はすでに任意のgitリポジトリからパッケージを取得できる。ある程度はすでにサポートされている状況だ
Go言語はすでにそのようなアプローチを採用している
Goのパッケージングエコシステムを見たうえでも、gitへの移行が良い考えだと思うのか疑問だ
最も重要なのは、プロジェクトを保守している様子を外部から見えるように、gitリポジトリのリンクくらいは載せられたはずなのに、今はそれがないことだ。メンテナー一覧はあるのにgitリポジトリのリンクがないので、コードより人を中心にしたプロジェクトという印象を受けた
パッケージリポジトリなら、Ansibleリポジトリのようなリンクが最初の告知にわざわざある必要はないと思う。パッケージリポジトリで最も重要なのは信頼だ。RubyGemsで起きた敵対的買収がその信頼を壊したが、オフライン化された元メンテナーたちが自ら運営する代替案は、むしろ良い変化だ。むしろ君は結論を先に決めて、後から理由を付けているように見える。ちなみに、rubygems.orgのトップにもgitリポジトリへのリンクは目立たない
ソースはここにある
最近の論争を除いて考えるなら、互換性のある代替パッケージソースやマネージャ、バージョン管理ツールがオープンソースエコシステムにとって中立的なのか、プラスなのか、マイナスなのか気になる
フォークが必要なときがあるのは理解できるが、互いに調整できなかったという事実には少し寂しさを感じる。皆がRubyエコシステムを発展させるという共通目標を持っているなら、政治的背景や個人的な意見の違いがあっても協力できないだろうか。過去のMerbとRails、BundlerとRubyGems、RubyTogetherとRubyCentralも結局は統合されたのだから、いつか解決することを願っている
gemの配布・ダウンロード方式を見直せば、こうした問題は解決できると思う。ただし、その変化を起こせる主体は現在ソフトウェアとインフラを支配している側であり、改善する動機があまりないのが問題だ。こんな状況自体がばかげているように思えるし、DHHに対する反感も理由がよくわからない。オープンソースプロジェクトを壊す最も簡単な方法がこうしたドラマやフォークなので残念だ。Rubyは古い言語であるにもかかわらずユーザーベースがそれほど大きくなく、こうした論争がエコシステム全体に害を与えているので、元Ruby開発者として悲しい気持ちになる
RubyGemsのGitHubリポジトリと組織がRuby Centralによって敵対的に乗っ取られた状況に対して、非常にうまく対応した動きだと思う。ホスティング費用のための財政支援が確保されることを願う