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

直接の勝者は周辺の開発者、そしてそれがユーザに波及する で、この「合流」によって、誰が一番得をすることになるかと言えば、プラグイン等の拡張機能を開発している開発者です。 たとえば、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は、相手のコードを相当研究しているはずですから、コードを通して理解するという暗黙のコミュニケーションが背景にあると思われます。それも重要な要素かもしれません。 いずれにせよ、「リーダーはリーダーにしかできないことすべきである」という教訓の典型的なケースになるでしょう。