ハクソク

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

ルビーセントラルを離れます

244日前原文(gist.github.com)

概要

  • Ruby Central による一方的な運営方針の問題提起
  • コミュニティとオープンソースの本質から逸脱したガバナンス批判
  • RubyGems GitHub組織の強制的な管理権移譲の経緯説明
  • コミュニティ分断と今後の課題の指摘
  • 今後は新たなコミュニティ主導の活動への意欲表明

Ruby Centralから離れる理由

  • Ruby Central の行動は「deus ex machina」的、コミュニティへの貢献ではなく強権発動
  • オープンソースの理念から逸脱した運営体制
  • 透明性を重視し、当初は情報公開を予定していたが、 Joel Drapper の「Rubygems Takeover」記事を推奨
  • Ruby Central関連の事実については複数の独立した情報源から個人的にも確認済み
  • 批判の矛先は個人ではなく プロセス に向けられている点を強調
  • Shopify は主要スポンサーとして唯一実名で言及、同社のRuby貢献は評価

実際に起きたこと

  • Ruby Centralは運営者（自分含む）を通じて RubyGems GitHub組織 全体を一方的に掌握
  • 一部運営者が危険だと主張し、全プロジェクトからメンテナーレベルの権限を剥奪
  • 実際にはプロジェクトの所有権を主張し、元のメンテナーも排除
  • コミュニティや運営者への事前相談や通知は一切なし

個人的な結論

  • 様々な立場の関係者と対話し、コミュニティの再統合を目指して尽力
  • Ruby Central 側が歩み寄りを拒否する姿勢を確認
  • RubyGems の組織が元のメンテナーに返還されない現状は容認できず
  • 元の権限復帰・ガバナンスモデル（RFC #61）確定・歴史的に排除された人々の再招集が最善策だった
  • Ruby Centralは独裁的に「コミュニティのため」と称して強制的に決定・実行
  • スポンサー（特にShopify）からの圧力も影響と推測
  • オープンで協働的な運営モデルからの逸脱

Ruby Centralの失敗

  • Ruby Centralと理事会によるコミュニティ軽視の運営失敗
  • MINASWAN （Matz is Nice And So We Are Nice）の理念喪失
  • 理事会にはShopify関係者が多く、コミュニティ理解やオープンソース運営経験が不足
  • 長年尊敬してきた人物も単なる人間であり、理想像ではなかった現実
  • 公式声明は虚偽であり、実際にはシステムを危険な状態に陥れた
  • RubyGems.org はほぼ未整備・未運用状態に
  • セキュリティ担当者も排除され、代替不在

理事会の問題点

  • 理事会メンバーの資格は「Rubyが好き」というだけで、運営・保守の力量に疑問
  • Shopify関係者とコミュニティ理解の浅い人物が多い構成
  • 本来必要だったのは、コミュニティ重視・長期的投資・オープンソースガバナンスへの理解・保護の意志
  • 結果としてコミュニティを裏切り、エコシステムを危険に晒す決定

企業利益優先とコミュニティ軽視

  • Ruby Centralはコミュニティより自組織やスポンサー企業の要請を優先
  • RubyGems.orgの維持よりもスポンサー資金や個人的要求を重視
  • セキュリティ担当者を「脅威」として排除し、後任も不在
  • 長年プロジェクトを支えた人々を犠牲にしたコントロール体制

問題の理解とアプローチ拒否

  • 過去にコミュニティ内で実際に問題があったことは認識
  • しかし今回の解決策はコミュニティへの貢献やオープンソースの理念に反する
  • Ruby Centralのやり方には賛同できず、今後の協力を断念
  • 今後はCLA（Contributor License Agreement）必須となるため、Ruby Centralへの貢献も終了

今後について

  • RubyGems.orgは長期的には存続すると予想、新たな運営者・メンテナーが現れる見込み
  • しかしコミュニティの分断は残り、本質的な解決には至らない現状
  • 新たなコミュニティ主導の活動の必要性
  • 自身も引き続きコミュニティツールの開発・貢献を継続予定
  • Rubyエコシステムの未来はコミュニティの手にあるべきとの強いメッセージ

Hackerたちの意見

俺はずっとコミュニティ重視の人間として行動してきたから、実際に何が起こったのか、今の状況はどうなってるのか、そしてRuby Centralがコミュニティの目にどう映っているのかを共有するのが自分の義務だと思ってる。これが俺の視点で、Ruby Centralを自分の意思で離れる理由でもあるけど、BundlerやRubyGems、RubyGems.orgからは追い出される形になってるんだ。

└

参考までに… rubygems.orgは、定期的に貢献していた数少ないオープンソースプロジェクトの一つだったんだ（とはいえ、年に一回か二回だけど）。いつも良い経験だったよ。君や他の人たちにとってこうなってしまったのは残念だね。これを見てると、Engine Yardの圧力でMerbが消えた時の気持ちを思い出すよ。彼らはRuby on Railsのホスティングビジネスを守るためにね。

この投稿はちょっと曖昧なところで論争の中心に飛び込んでるね。これが何についてのものか、短く（できれば中立的な）まとめがどこかにある？

└

この記事の3段落目にリンクがあるよ。

文脈として、Ruby Centralが今日Zoomコールを開いて全てを説明したいと言ってたのに、それをキャンセルしたってことが関係あるかもしれないね。彼らのメッセージはこんな感じ。「こんにちは、Rubyコミュニティの皆さん。元々予定していたQ&Aセッションがロシュ・ハシャナの観察と重なっていて、多くの方にとってはあまり良いタイミングではなかったことを認識しています。この変更についての短い通知をお詫び申し上げます。特に、セッションが明日行われる予定だったので。いただいたフィードバックを受けて、セッションを延期することに決めました。新しい日程と時間は近日中にお知らせします。その間、私たちのエグゼクティブディレクターからのこの声明をご覧いただくことをお勧めします。このアップデートは、皆が同じ情報を受け取れるようにし、都合の良い時間に見ることができるようにするためのものです。」

└

うわぁ。Microsoftからはもっとまともな決定が出ると思ってたよ。家を燃やしてるのに、火を消そうとしたらカーテンが濡れちゃうからそれはできないって感じだね。

ちょっと確認させて。Ruby Centralは資金が足りなくて、Shopifyがそれを利用して、Bundlerみたいなコアコミュニティのリポジトリをいくつか買収させたってこと？それでShopifyが間接的にそれらをコントロールできるように？

└

一言で言うと、そうだね。

└

Ruby Centralは資金が不足していて、Shopifyがそれを利用して、bundlerのようなコアコミュニティのリポジトリをいくつか買収させたんだ。そうすることで、Shopifyが間接的にそれらをコントロールできるように。お金を使って公然と行われたxzの買収のバリエーションみたいだね。

脱線だけど、俺の意見では、リポジトリは自分のアカウントの下に置いておくべきだと思う。グループアカウントに渡すべきじゃない。自分がコントロールを失いたくない、あるいはこういうことが起こるのを気にしないなら別だけど。もしそうなら、もう先に進んでいるか、先に進むことに問題がないなら、グループアカウントにしてもいいと思う。

└

大きな環境では、個人アカウントを使うのは本当に安全じゃないよ。誰かが休暇中にハッキングや乗っ取りに遭ったら、解決に数日かかることもあるし。プロジェクトを離れる人、病気になる人、亡くなる人が出ると、プロセスや所有権に混乱が生じる。何千人もあなたのプロジェクトに依存するようになったら、本当に他の人と一緒に組織に移すべきだよ。

MINASWANが何を意味するのか分からなかった人のために言うと、これは「Matzは優しい、だから私たちも優しい」という意味だよ。

└

彼がここで本当に力を持っているわけじゃないけど、Matzにこの件についてどう思ってるか聞いた人はいるのかな？

誰かがサプライチェーンを引き継いだ…それって、誰かにサプライチェーンを奪われないようにするため？

解決策は、パッケージマネージャーを統一リソース識別子に基づいて設計することだね。オンライン資産を見つける方法で、ほとんど（DNSを無視すれば）分散型で、全てのパッケージを一つの組織が所有するよりもいいと思う。

└

それ、面白いアイデアだね。具体的な提案はあるの？URL（例えば、gitリポジトリ）を指定することと互換性はあるのかな？

└

Bundlerやgemを使うのに、rubygemsサーバーに触れる必要は全然ないよ。別のrubygemsホスト（自分で運営しているものでも）や、gitリポジトリ、ローカルのgemファイルソースを指定できるからね。

└

これは「モノリス」と「マイクロサービス」の議論に似てるね。パッケージを何千ものドメインやホスト、プロバイダーに分散させると、信頼性がめちゃくちゃ悪くなるし、制御も効かなくなる。理論的には、RubyGemsはアップロードされたコードを全て解析してマルウェアを検出できるけど、他の場所にホストされているリポジトリやパッケージのインデックスしか持ってないなら、運が良くないとね。

└

PyPIをパッケージの中心地とすると、彼らの帯域幅の請求書は月に180万ドル以上になることが知られてる（https://dustingram.com/articles/2021/04/14/powering-the-pyth...）。Fastlyが100%の割引を提供してくれなかったらね。そんな規模で運営されている信頼できる分散型パッケージ配布システムってあるのかな？悪意のあるパッケージや名前の占有といった管理問題をどう扱ってるんだろう？標準の更新は？正しいメタデータの強制は？パッケージインデックスが対処しなきゃいけない他の一般的なことも含めて。正直懐疑的だけど、実際の成功事例にはすごく興味があるな。

私の批判はプロセスに向けられていて、人に対してではない。人は川に浮かぶ丸太じゃない。人は決定を下し、物事を動かすんだ。彼らがプロセスを作り、運営しているのであって、その逆じゃない。批判は人に向けられるべきだ。

└

そうだね、人々は自分たちを守るために「無責任マシン」を作るんだ。それは正当なものから悪意のあるものまで様々だね。

完全に外部の人間として、追い出された人たちに法的手段があるのかどうかが気になるな（Ruby Centralが所有するサービスと、Ruby Centralが法的に権利を持たない可能性のあるコードとの明確な区別に注目して）。