DebianのRubyパッケージメンテナ辞任で騒動に
Debian GNU/LinuxのRuby関連パッケージのメンテナだったフランス人のLucas Nussbaumさんが、Rubyパッケージの作成・管理に関わるのをやめると宣言しました。その理由を、やや感情的にブログに列挙したことをキッカケに、日本語・英語のコミュニケーションギャップの問題、OS（ディストリビューション）とRubyなどの言語処理系のパッケージシステムの不調和の問題、コミュニティ運営の成熟度など、さまざまな議論が巻き起こっています。
多くの論点を含みつつ議論が展開
念のために先に指摘しますが、Debian上（Ubuntuでも同様）のRubyパッケージの今後については、Lucasさんのほかに、まだ2人、やまだあきらさんと、森脇大悟さんが関わっているので（リンク）、今回の騒動によってRubyパッケージがDebian上でメンテナンスされなくなったり、将来が不安だということはないと思います。ただ、多くのOSSプロジェクト同様に人的リソース不足のようで、Lucasさんも、特にRuby関連のライブラリやRubyベースのアプリケーションのパッケージについては、「先のことは分からない」と言っています。と、書いたところで、やまだあきらさんがブログにコメントを書かれているのに気付きました。状況把握中だそうですが、メンテナを続ける意思があるとのことです。
さて、一連の騒ぎの発端はLucasさんの1月2日付けのブログ、「Giving up on Ruby packaging」と題したエントリです。
コメント欄には、Rubyの生みの親のまつもとさんがコメントしているほか、Ruby 1.9系のリリースマネージャーであるYuguiさんも登場し、1月4日のお昼現在（日本時間）もまだ少しずつ議論やコメントが続いています。LucasさんはRubyGemsの抱える問題についても指摘しているため、RubyGemsの初期の開発者であるPaul Brannanさんもコメント欄に登場しています。
関連する議論を追いたい方は、まずLucasさんのブログとコメント欄を読んで、次にまつもとさんのTLを見て、LinuxカーネルとRuby双方の開発者としても知られている小崎資広さんとのやり取りあたりにも注目しつつ、各方面からの発言を拾うと良いと思います。関連する論点が集まっているのは、Hacker Newsのこのスレッドです。RubyGems開発の経緯や、現状の問題点については、ミュンヘンのRuby User Groupで昨年10月にRoland Morizさんが発表した（と思われる）「RubyGems - behind the gems」というスライドが参考になります。
何が問題だったのか
Lucasさんの論点を、ブログの登場順に列挙してみます。
- Ruby開発コミュニティは成熟すべきだ
- 日本語のメーリングリスト、ruby-devは閉鎖して、開発に関する議論はすべてruby-coreで英語でやるべきだ
- Ruby開発コミュニティは、ブランチ（異なるバージョン）ごとの状況やリリース予定について理解を共有すべきだ
- Rubyは単に1つの処理系だけの話ではない
- Rubyコミュニティは、RVMやRubyGemsが万人向けツールでないことを認めるべきだ
- Rubyコミュニティの何人かはクソのような振る舞いをやめろ
思うに、Lucasさんがもう辞めたと宣言した理由は6が大きそうです。ボランティアでやっているのに、口さがなく文句を言うヤツが多くてウンザリした、というのが一番大きいのではないでしょうか。これについては、まつもとさんも、
残念に思う。私も過去15年にわたって、trollsにはウンザリさせられてきた
とブログに共感を示すコメントをしています。a trollは日本語で言えば「釣り」に似て、掲示板やMLなどで、わざと挑発的なことを述べてかまってもらいたがる人々のことです。まつもとさんが言うと、説得力がありますね。
Lucasさんは、この点について、オンラインコミュニティで攻撃的な言動を示す人々というのは少数派かもしれないが、時々は声を大にして反論しないと、コミュニティ全体のイメージダウンにつながるとも言っています。
Debianのパッケージは古い？
さて、ではLucasさんが受けた悪口（trolling）の中身はなんだったかというと、5なのだと思います。つまり、Ruby on Rails開発者の多くはRVMやRubyGemsを使っていて、プラットフォーム固有のパッケージシステム（yumやapt-get）のことを軽視する傾向が強まっているのだと思います。「DebianのRubyパッケージなんて使えない」という風に言う人がRubyコミュニティに少なからずいるのでしょう。実際、Debianに限らずOS付属のRubyパッケージはバージョンが古いものが多いように思います。
「DebianのRubyパッケージは古い」と言われて、「おいおい！ ちょっと待ってくれよ！ 1.8系はちゃんと新しいものを出してるだろ！ そもそも……」という指摘が3番の「Ruby開発コミュニティは、ブランチ（異なるバージョン）ごとの状況やリリース予定について理解を共有すべきだ」なのではないでしょうか。昨年10月に出たDebianの安定版リリース、lennyに含まれるCRubyのバージョンは、
となっています。Ruby 1.9系の初の安定版であるバージョン1.9.1は2009年1月にリリースされていて、2010年8月にはRuby 1.9.2も出ています。ところが、DebianのRubyパッケージの1.9系の説明には「開発版」だと入っていて、バージョンも1.9.0と古いままです。RubyやRailsを気にかけている開発者の多くはすでにRuby 1.9系に移行しているか、少なくとも動かしてはいるのではないでしょうか。こういう利用者層からすれば、DebianのRubyパッケージは古く見えてしまいます。
でも、実際のところ1.9系は「安定版」「開発版」の、どちらなのでしょう？ もし安定版だとしたら1.8.7って何？ 1.8.8もあるの？ というのが、Lucasさんが釈然としなかったポイントでしょう。この点について、まつもとさんは、
ご存知のように1.9は大きな飛躍だったので、1.8についてもより長期間維持する必要があったのです
とコメントしています。事実上、現在CRubyには
- 1.8.7（後方互換のためのバージョン）
- 1.9.2（安定版）
- trunk（開発版）
という3つのバージョンがあるのだということです。
今に始まった問題ではない
外部から観察している私の目にも、Rubyのブランチに関するポリシーは、その場その場の空気で決まるもののように見えます。RubyKaigi2010の開発者会議で私は、1.8.8を出すのかどうかという議論を傍観していました。まず第一に、それを決めるプロセスや、何がどうなったら決まったことになるのかというのが、私には分かりません。日本的な緩やかな合意形成のように見えています。たぶん、IRCやオフラインでの雑談の中でも議論は成熟していくのでしょう。それはそれでいいのでしょうけど、Lucasさんが1や2の論点を指摘する気持ちも分かる気がします。このあたり、Rubyコミッタの1人である卜部昌平さんが去年の9月に「Rubyがそろそろ一回終わってみるべき10の理由」というtumblrのエントリで指摘されています。
（日本語と英語という）言語の壁を超えられなかったという指摘と、ガバナンスの不在について、私は卜部さんの見立てが正鵠を射ていると思います。いずれも今回初めて指摘されたようなことではないと思いますが。
Lucasさんの2つ目の指摘、「日本語のメーリングリスト、ruby-devは閉鎖して、開発に関する議論はすべてruby-coreで英語でやるべきだ」という点についてですが、まつもとさんは次のように反論しています。
Rubyのコア開発者のほとんどが英語を理解しますし、英語主体のruby-coreメーリングリストにも登場しています。すべてのドキュメント、ChangeLogが英語だし、英語を話す開発者が自分は二級市民だなどと思うことはありません。
これ以上まつもとさんや日本のRubyコア開発者に対して歩み寄れというのは、筋違いの要求かもしれませんが、Lucasさんの指摘ももっともかなと思います。日本語と英語の壁はとても分厚い、という厳しい現実があるだけなのでしょう。
Yuguiさんは日本語によるruby-devを閉鎖するメリットには同意するものの、そんなことをすれば、多くの日本人開発者によるライブラリやプラットフォームサポートを失うことになるだろうと現実的な問題点をコメントとして投稿しています。そして、それは鶏と卵の問題かもしれないとも指摘しています。日本語の開発メーリングリストを廃止して英語主体にビッグバン移行しても、ちゃんと開発体制は回っていくのかもしれない、という意味かと思います。
ガバナンス不在のほうがコミュニティは活発かもしれない
ガバナンスというのは、例えばJavaならJCPがあり、PythonならPEPがあり、という話だと思います。この論点は「Rubyはどこへいくのだろう」というブログでも触れられています。
ガバナンスとは明文化されたルールに基づいて議論や決定を運用するということですよね。私には、Rubyの開発が自然言語的にも、コミュニティの態度としても閉鎖的とは思いません。むしろ非常にオープンだし、日本発のプロジェクトとしてはほかに類をみないぐらいに英語を使っていて、そういう意味では活動がグローバルです。でも、外部からもそういう風に思われているでしょうか？
明文化されたルールを作って、外部にも内部にも明示した上で「私たち」を形作っていくのだ、ということの価値に対する認識に、日本と西洋とでギャップがあるのかなと感じます。日本には文化はあっても文明がないと言った歴史学者の阿部謹也のような人の指摘が私には思い出されます。文明とは、異なる文化的バックグラウンドを持つ人々を対等に受け入れることで、そのための枠組みです。この意味では、日本にはまだ文明的でない面が非常に強く残っていると私は思っていて、Ruby開発コミュニティ問題も、これに通底しているように思えます。
まつもとさんは、この辺のことについて、こうつぶやいてます。
改めて「ルール」と言われて感じたのは、そんなの決めようとする人はOSS(とコミュニティ)の本質を理解してない。そんなの決めたら、楽しくないじゃん。
なるほどなぁと思います。Debianは1997年と早い段階から、「Debian社会契約」という一種の憲章を掲げていましたし、リーダー選出などのプロセスも非常に明文化した形で、投票システムが作られていると聞いています。
追記：私の目は節穴でした。Debianには、ちゃんと日本語にも翻訳されたDebian憲章というものがあったのでした。この機会に一読しましょう！（読んでなかったのに偉そうにスミマセン）
そんなことだからDebianはUbuntuの後塵を拝することになったのだ、という言い方はできるかもしれません。Debianプロジェクトの創始者で、DebIANと名前にも入っているIan Murdockさんが、Debianプロジェクトは民主的になり過ぎた、それが常態化したリリースの遅延の根本にあると指摘していたのを思い出します。
まつもとさんも、小崎さんとのTwitter上でのやり取りで、
kosaki55tea kosaki @yukihiro_matz ええと、Debianはわりときっちりルール決めてると思いますよ。ただ僕の意見はそれは中の人間が決めた時のみに有効に機能すると思っているので反対なのですが ﾟ+.(･ω･)ﾟ+.ﾟ
Yukihiro Matsumoto @kosaki55tea だからDebianは(比較的)停滞してるのでは？ とか言ってみる。Debian好きだけど。
と指摘しています。JavaもJCPによって活動が活発になったかというと、むしろ逆に停滞したようにも思われます。それが成熟なのだという見方はもちろんできると思います。
もう1つ、小崎さんが面白い指摘をされています。
kosaki55tea オレに言わせると日本語MLを閉鎖して議論を英語にしたぐらいで、コミュニティが「成熟」して意志決定の過程が透明化されると考えてしまうナイーブさには失笑を禁じ得ないのだが。LKMLを半年ROMってから出直すべき ﾟ+.(･ω･)ﾟ+.ﾟ
Linuxカーネルが、活発で成功している開発コミュニティであるのは疑いようがありません。そのLinuxカーネルの開発コミュニティも、英語を主言語としているからといって、コミュニティが成熟していたり意思決定の過程が透明化されているわけではない、という意味かと思います。結局のところ、（国や会社と違って）OSSプロジェクトぐらいのサイズであれば、大事なのは明文化されたルールよりも、その場に関わる人間全体の人間臭い関係性を、当事者やトップが上手くまとめたり、まとめなかったりすることにあるのかもしれません。
もう1つ、今回の騒動で重要な見方として、ここで付け加えておかないといけないと思うのは、LucasさんがRubyに対してあまり前のめりでなかっただけではないかという指摘があることです。RubyConfに参加したわけでも、まつもとさんの意見を聞こうとしたわけでもないという指摘です。これはLucasさんも認めていますね。
追記：前のめりかどうかという論点については、Slashdot上のnaruseさんのコメントが参考になると思います。
パッケージ管理のインピーダンスミスマッチ
RubyもRailsも進化が速く、RVMやRubyGemsといったツール類の消長も激しいです。そういう、ちょっとした混沌の中で進化を続けているホットな世界と、安定していてセキュアなコンピューティング環境を提供するべきディストリビューションとでは、自ずとポリシーやアプローチが異なってくる、ということかもしれません。
Lucasさんの「Rubyコミュニティは、RVMやRubyGemsが万人向けツールでないことを認めるべきだ」という論点について、まつもとさんは、
RVM and gems. Conflict between packaging system for the language, and general purpose packaging system like Debian is common problem; Perl has CPAN, PHP has PEAR and Ruby has RubyGems. I am not yet sure there’s good solution for it. Probably we can work together.
とコメントしています。Rubyに限らず、PerlのCPAN、PHPのPEARのように、汎用パッケージシステムと、言語ごとのパッケージシステムが異なるのはよくある問題だと指摘した上で、じゃあほかに良い解決があるかというとよく分からないねと言っています。not yet sureとやんわりと言うあたりがまつもとさんの優しい独裁者としての真骨頂だと思います。文句があるなら代案を出せとか、ほかにやりようなんてないんだよッと顔を真っ赤にして反論するようでは、15年もRubyの開発は続いていなかったのではないかという気がします。まつもとさんは、Debianのようなパッケージシステムと言語ごとのパッケージシステムの開発者は、協力することで一緒にこの問題を解決していけるかもしれないよね、と前向きです。
Lucasさんは「車輪の再発明をするな」と、RubyGemsに対してちょっと否定的です。もちろん、それが良いツールであり、ある種の人々には良い選択であるだろうと認めた上で、RVMやRubyGemsが万人向けツールであるかのように言う人々は笑止千万だと指摘しています。
これはRuby on RailsにWordPressのような大ヒットアプリケーションなぜ存在しないか、というのに似た問題かなと思います。WordPressなどPHPの優れたツールが普及した理由は、システム管理者が簡単に導入、運用できたからでしょう。一方、Railsはどうでしょう。Ruby on Railsのイシュー・トラッキングシステムであるRedmineを入れて動かすために、一般的なシステム管理者にRVMやRubyGemsを使えというのは酷です。「apt-get install redmine」とやってパッケージが入って動き出すなら、それがベストですが、そういう感じではありませんよね。
Railsなら15分でブログシステムを「作れる」のだと喧伝はしていますが、3分で立ち上げられるRailsベースのブログって、ちょっと思いつきません。それは、自分で作るものだからなのでしょう。
RVM、RubyGems問題というのは「システム管理者というパッケージ利用者」と「Rails開発者」の間にあるギャップに、Rubyコミュニティはあまり自覚がないのではないかという指摘なのかなと思います。
車輪の再発明は必要不可欠？
Rubyライブラリの次世代管理システム「Bundler」は、文字通り車輪の再発明です。多数のパッケージのバージョンの依存関係を解決するのは、実は計算量的に難しい問題で、組み合わせの数が膨大なために、高速なCPUを使っても、なかなか最適解が出せないのだそうです。Bundlerの開発者の1人、Carl LercheさんがRubyKaigi2010で講演されていましたが、実はBundlerはapt-getのアルゴリズムを真似たのだそうです。先に確定できるメジャーなパッケージの組み合わせを確定することで組み合わせ数を大幅に削減している、ということです。本当の意味で車輪を再発明していたのです。
車輪の再発明は無駄かというと、そんなことはなく、まず、RVMについては解こうとしている問題が違うので比較はできません。RVMは異なるバージョンや実装のRuby処理系を同居させたり、gemsetsという機能により実験的にgem環境を切り替えたりできるツールです。これはOSディストリビューションのパッケージシステムでは解決できない問題です。
もう1つ、gemは古いバージョンのものも明示的に消さない限り残ります。これは依存関係を解決する上での必要悪だったのでしょうか、私にはちょっと事情が分かりません。Debianにはalternativeというメタパッケージの仕組みがあって、これで複数バージョンのライブラリの共存ができそうに思えます。でも、やっぱり目的が違うのですね。例えば、あるソフトウェアパッケージが「MTA」に依存しているという場合、Debian上ではPostfixもSendmailもMTAの機能を満たすパッケージとして一方を入れれば依存関係を満たしているとみなされます。これは25番ポートを叩けば同じSMTPをしゃべるので、当然といえば当然です。とても賢い仕組みです。しかし一方、Rubyのgemだと、例えばTwitterクライアントの実装を取ってみてもAPIはどれも違いますし、同一gemでもバージョン間で互換性がなくなったりするのは普通です。
こうした事情を考えると、cpan2rpmやgem2debといった言語ライブラリのパッケージをOSパッケージに変換するアプローチには限界があるのかなと想像します。
データベースとオブジェクト指向言語の「インピーダンスミスマッチ」に似た話で、言語ライブラリと、OS上にインストールするライブラリにはミスマッチがあるのかなと思えます。進化速度やAPIの安定性、パッケージ間の依存関係の性質がだいぶ違います。
さらに、マルチプラットフォームということを考えると、Debianのパッケージで上手くRuby関連のものがパッケージされていることよりも、WindowsでもMacでもLinuxでも、gemさえ動けばほぼ同じものが使えるという状況のほうが、Ruby／Rails開発者にはメリットが大きいという指摘もあります。Mac上で開発したRailsアプリであってもDebian上に持って行って「bundle install」と実行すれば、必要なライブラリがインストールされて、それで問題なく動くというのは大きなメリットですよね。
という事情があるので、Debianで「gem update –system」を実行したときに出る「RubyGemsではなく、apt-getを使え」という以下のようなメッセージは、多くのRails開発者をがっかりさせたのかなと思います。
ERROR: While executing gem ... (RuntimeError) gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.
RubyGemsはプロトタイプだった。今後の発展に期待？
RubyGemsはエコシステムの規模の割に、不思議なほど実装や運用が原始的だと思ったことがありませんか？ セキュリティにしても、ほとんど誰でもアップロードしてgemを公開できるのに、いきなりroot権限でインストールしていることがあるなど、チキチキマシーン的です（大げさ）。
それもそのはず、私は今回の件で初めて知ったのですが、Paul Brannanさんによれば、RubyGemsは、もともと2時間程度で実装したプロトタイプだったそうです。今のように広く使われるようになるとは想像できなかったといいます。そういうわけで、LFS（Linuxの標準ディレクトリ構成を決める仕様）に準拠しない形で、単一ディレクトリにすべての関連ファイルを入るようなgemの導入方式も、プロトタイピングという意味では、ごく自然なデザインチョイスだったということです。
上記で紹介したスライドによれば、RubyGemsにはミラーが1つもなく（GitHubはありますが）、Amazon S3上にだけバイナリがあるそうです。これはDebianのようにミラーが何百もあるプロジェクトとは好対照で、PerlのCPANともずいぶん違います。GitHubと同様に、SPOF（Single Point of Failure）になっているということですね。これは多くのミラーサイトがrsyncを使っている一方、S3だと同じやり方ができないからという理由が大きいそうです。
こうした状況も、開発者のニーズと、より良い実装やサービスの登場によって、今後もダイナミックに変化していくのだろうと思います。そういう動きが出てくるのが、Ruby／Railsの活力であり面白さなのかなと個人的には思っています。そういうスピード感に、一時的にDebianのようなシステムがキャッチアップできていない（主に人的リソース不足により）のが、今回のような形で表面化したのかなという風にも思われます。