RailsとMerbの合流についてあれこれ

これって、ある意味、オープンソースプロジェクトの凄みが見えてくるすごく衝撃的なニュースです。そこで、なるべく、IT業界に関係ない人にもわかるように、このニュースの意味をいくつかの側面から考えてみたいと思います。

ビジネスではあり得ないことが起きた

まず何が起きたのかひとことで言うと、RailsというプロジェクトがMerbというプロジェクトと合流して、次のバージョンを共同で開発することを発表したということです。

簡単に言えば、Windowsの次期バージョンをMac OSXベースで開発することになったようなものかな。

Ruby on Railsは、「RubyのWebアプリ開発用フレームワーク」というジャンルで一番メジャーなソフトです。その分野に関係する人ならば誰も知らない人がいないというビッグな存在。

Merbは、Railsと比べると「通」な人が好むソフトで、シェアや知名度は一段劣るけど、評判は高く近頃急に伸びているものです。

ちょうど、その関係は、WindowsとMac OSXの関係のようなものです。普通の見方では、両者は対立関係にあり、ユーザを奪いあうライバル同士です。ただ、MerbもMacと同様に、急速に存在感を増してはいますが、まだ、トップを脅かす所までは行ってない。いくら伸びていても、トップのソフトには膨大な既存ユーザがついていますから、引っくり返すどころか、せり合う段階もまだ見えてない、「ちょっとは気になるけど、先々はともかく今の段階では、比較するまでもない」という感じです。

そのRailsプロジェクトが、次期バージョンのコアとしてMerbを採用し、Merbの開発メンバーをRailsプロジェクトに迎え、共同で次期バージョンを開発すると発表しました。

これは、たとえて言えば、ゲイツが「Windowsの次期バージョンはMac OSXをベースに開発する。その為に、Appleの技術者をマイクロソフトの幹部として迎え入れることになった」と言うくらいの衝撃です。

技術的には正しい決断だと思いますが、世の中には正しくても実際には起こらないことがたくさんあります。

それがあっさり起きて、業界関係者一同、みんな目を丸くしてるということです。

ビジネスとオープンソースプロジェクトは前提条件や制約事項が全く違いますが、たくさんの人が関わる共同作業の場という意味では同じです。そして、こういうドラスティックな改革は、総論賛成各論反対になりがち、実際に、互換性の懸念など問題は山積みです。

こういうことが起こるということは誰も予想していませんでしたが、それが起きた。

これは、ビジネスの論理では困難だったことを、オープンソースプロジェクトが実現させてしまった事例として、注目すべきものになると私は思います。

直接の勝者は周辺の開発者、そしてそれがユーザに波及する

で、この「合流」によって、誰が一番得をすることになるかと言えば、プラグイン等の拡張機能を開発している開発者です。

たとえば、VHS対ベータのビデオ規格戦争が起きている時に、テープやヘッドといった部品を作っている会社は苦労が多かったと思います。二つの規格それぞれに合わせた部品を作る必要があって、設計にしろ製造にしろ、二倍とは言わないまでも余分な手間がかかっていたでしょう。

もし、合流せずにこのままMerbが伸びていき、RailsとMerbが並立するような状況になったら、そうなっていたと思われます。

「Web用アプリケーションフレームワーク」というソフトは、それ単体ではあまり意味がありません。誰にでも必要な汎用的な機能はコアとして実装されますが、「誰もが必要とするわけではないけど、意外と欲しがる人が多い機能」が無数にあり、その部分はプラグイン等の部品として開発されます。

この部品がたくさんあって、ユーザ(アプリケーションの開発者)が自分の必要な部品を組合せて効率的に開発できることが、フレームワークを使うメリットです。

MerbとRailsは、ユーザから見ると似ている所が多いのですが、部品の開発者から見るとかなりの違いがあります。

二つの規格があって、誰もがRails用プラグインとMerb用プラグインの二つを開発しなくてはいけないという悩みが、「合流」によって、一つでよくなります。

そして、RailsとMerbには、それぞれ長所短所があるのですが、部品の規格としては明らかにMerbの方が優れていました。

部品の開発者から見ると、合流しただけでもありがたいのですが、規格として優れているけどマイナーなMerbの規格をベースに規格が整備されていくことになる、ということが特に嬉しいわけです。

コア開発者/部品開発者/ユーザという三層で分けて考えると、「合流」によって一番楽をするのが部品開発者です。コア開発者はむしろ、単独で開発を継続していた方が楽です。「合流」でむしろ難しい課題をたくさん抱えこむことになるでしょう。

ユーザにとっては互換性の問題でデメリットもありますが、部品が整備され充実することで受けるメリットの方が大きいでしょう。

これは、コミュニティの運営で起こりがちなジレンマに似た問題と言えるかもしれません。

どんなコミュニティにも、運営側やそれと近い立場のコアのメンバーと、完全に「お客さん」として外から参加するメンバーがいます。

その中間に、ある程度熱心に参加するけど、他にも別のコミュニティに所属している中間的なメンバーがいます。ちょうど部品開発者に相当する層です。

この層が活発に活動しているかどうかが、コミュニティにとって重要だと思います。

しかし、コミュニティにとって重要な決断をするのはコアメンバーであって、この人たちが、「部品開発者」の立場をどれだけ考慮できるかが、重要なポイントです。

企業に置き換えると、社員の利害とサードパーティの利害の関係。

かって、マイクロソフトはWindowsやVisualBasicの開発において、サードパーティの動向に敏感な会社でした。今のiPhoneも、同じ傾向があると思います。

サードパーティが集まって切磋琢磨すると、コアの優劣が問題でないくらいに、ユーザにとってのトータルなメリットが高くなります。サードパーティは、特定の狭い分野においてユーザが何を求めているか徹底的に追求して、その点で競いあうからです。いわゆる、「かゆい所に手が届く製品」になるわけです。

Merbベースの次期Railsも、そういうフレームワークとなっていくと思います。

これは、社員(=コアメンバー)の力だけではできません。どうやって「部品開発者」を動員するかがポイントとなります。

リーダーが本当にリーダーにしかできない仕事をする

この「合流」を仕掛けることができるには、RailsプロジェクトのリーダーであるDHH以外にはいません。

Railsプロジェクトは多士済々で、凄いプログラマーをたくさん集めていますから、DHHがいないと進まない所はあまりないと思います。個々のプログラミングだけでなく、ロードマップの作成といった長期計画についても、DHHと同等レベルの人はたくさんいるでしょう。

しかし、こういうラディカルな方向転換を行なえる人は他にはいません。他の人がやったら、ついて来る人がいなくて、プロジェクトが分裂してしまうと思います。

特に、Merbの開発チームを説得する仕事は難しかったと思います。

Merbの開発は、もともとRailsというビッグな存在を前提にして始まったプロジェクトですから、自分たちがマイナーであることは気にしてないと思います。だから、「あの有名なRailsの開発に加わる」とか「あのDHHと一緒に開発する」ということは、Merbの開発チームのメンバーには意味がありません。

Merbは、ある部分ではRailsのコピーと言ってもいいくらい猿真似をしていますが、ある部分ではRailsを反面教師として、正反対の設計思想を採用しています。「RailsであってRailsでない」というのがMerbのアイデンティティです。

だから、「合流」はMerbのアイデンティティを無意味にする側面があります。実際、「MerbがMerbでなくなるのではないか」と心配している既存Merbユーザも多いようです。

それで、DHHはどうやって説得したか。

Merb開発者のブログを見ると、どうやら、ひたすら「Merbは素晴しい」と褒めまくったようです。

これは、単なるお世辞ではなくて、冷静に事実を認めたということです。

Railsは、未開の地を手探りで切り開いていったので、紆余曲折や歴史的な事情から内部が非常に複雑になっています。Merbは、いい所も悪い所もRailsという先行するソフトを参考にして設計されていますから、明確にRailsより優れている部分があります。

Merbチームとの話し合いの中で、おそらくDHHは客観的にMerbの優れている所を順番に指摘した上で、「だから、次のRailsはMerbをベースにしたい」と言ったのではないかと、私は想像しています。

技術的なポイントをきちんと押さえて、冷静にそう言われたら、Merbチームは納得するしかなかった、そんな感じではないでしょうか。

両者の比較をできる人はたくさんいますが、それを理由に「合流」を説得できる人はDHHしかいません。

また、オープンソースのプログラマー同士は、互いに相手のコードを読むことで、相手を相当理解することができます。RailsとMerbは、相手のコードを相当研究しているはずですから、コードを通して理解するという暗黙のコミュニケーションが背景にあると思われます。それも重要な要素かもしれません。

いずれにせよ、「リーダーはリーダーにしかできないことすべきである」という教訓の典型的なケースになるでしょう。

鮮やかなアナウンス

この発表に伴い、Railsの公式サイトにMerbのページができました。これを翻訳してみます(かなり意訳しています)。

Merbは、Ezra Zygmuntowicz氏によって2年前に小さなフレームワークとしてスタートした。最初は、ERbテンプレートをMongrelでサービスするだけのものだったが、その後急速に発展して、Railsに代わる一つの有力な選択肢となる所までニッチを拡大していった。Merbistたちは、コアを小さいまま保ち、ORM/JavaScriptライブラリを自由に選択できることと、拡張機能に対して厳格なAPIを定義することに注力してきた。

その野心が膨らむにつれて、MerbとRailsは、アイディアだけでなく実装についても相当重なる部分があるという事実がはっきりしてきた。このままだと、塀の両側で両者が同じ作業をそれぞれ行うことになる。それは本来であれば不必要だったはずのものだ。また、ユーザがコンポーネントを選ぶことにも困難が生じる*1

そこで、12/23、我々はこの問題(作業の二重化と選択の困難)にケリをつけるための一つの決断を行なった。この日、我々はMerbの素晴しいアイディアをRails3(Railsの次期バージョン)に含める意思を宣言した。この日は、我々がこれから一緒に作業することになるというコミットメントを発表した日だ。

この発表の最後の we announced our commitment to という文の5つの単語に、関係者5人(DHHとMerbのコア開発者4人)のブログエントリがそれぞれリンクされています。

「各人が自分の言葉でそれぞれ賛同の意を示し、公式サイトからリンクする」という手法で、この電撃的な決定について、余計な詮索を封じた上で、効果的に意図を説明していると思います。

もの凄い意思決定のスピード

そのブログの一つに次のような記述があります。

I first heard about everything this past Thursday(私がこれについて最初に聞いたのは先週の木曜日だった)

この重大な決断について関係者(それも告知からリンクされる程の重要人物)が最初に聞いたのは、正式発表のわずか5日前だという話。

オープンソースプロジェクトの意思決定がいかに機敏で無駄な根回しが無いものであるかということがよくわかるエピソードだと思います。

まとめ

リナス・トバールズもそうですが、DHHは「ネットを前提としたコミュニケーション、あるいはコミュニティの運営というジャンルにおける天才」と見るべきだと思います。もちろん、プログラマーとしても超一流ですが、重視すべき点はそちらだと。

おまけとして、DHHの講演にリンクしておきます。

この中で「柔軟性(選択できるオプションの豊富さ)はタダでは得られない。大事なのはトレードオフだ」という趣旨の発言があります。これは柔軟性を重視したMerbを暗黙に批判しているのかなあと思っていたのですが、どうなんでしょうか。

それとも、この時点では批判的だったけど、この後で考えを変えたのかな。

それから、技術的な面も含めた詳細については、こちらがよくまとまっていると思います。

おまけ(Merbの優位性をケーキに譬えて説明してみる)

Merbが優れている点として、「プラグインのAPIが定義されている」ということがよく言われています。

これを説明する譬え話を思いついたので、(わかりやすいかどうか自信が無いのですが)ついでに書いておきます(クリスマスだし)。

フレームワークがケーキのレシピだとします。Railsはフルスタック(全部入り)であるというメリットを強調しています。つまり、誰にでも簡単にケーキが作れるレシピということです。

しかし、たとえば、苺の代わりにキーウィを使おうとするとどうなるか。

Railsのレシピには、「スポンジを焼いている間に、苺のヘタを取っておきましょう」と書いてあって、初心者は「キーウィにはヘタが無い」と悩むことになります。

もちろん、ケーキ作りに慣れた人なら、「苺のヘタを取る」→「キーウィの皮を剥く」と変換できるのですが、初心者には難しい。

これに対し、Merbのレシピには「スポンジを焼いている間に、フルーツの下ごしらえをしておきましょう」と書いてあります。

そして、「フルーツ」のAPIが定義されているのです。つまり、「フルーツには適度な酸味と甘味があって、『下ごしらえ』という工程が定義されていなければならない」ということです。

そうすれば、どんな初心者にも「このレシピでは苺の代わりにスイカを使うことはできない」ということがわかるし、「キーウィの下ごしらえが定義されていれば、苺をキーウィで置き換えることができる」ということも明確にわかります。

このように各パーツのAPIをうまく定義しておくと、一つのレシピで、苺のスポンジケーキだけでなくさまざまなケーキを焼くことができます。

MerbでもRailsでも苺のスポンジケーキを作ることは同じようにできますが、凝ったケーキを作る時には、材料を自由に選択できて失敗の少ないMerbの方が優れています。

Merbは、Railsで確立されたレシピを、このように分解し再定義したことで、柔軟性の高いフレームワークとなっています。


一日一チベットリンク→チベットのラサに一人旅中なんだけど何か質問ある？　その２ 働くモノニュース : 人生VIP職人ブログwww

*1:"led to some paradox of choice"の所を超意訳しました