http://martinfowler.com/bliki/RubyMicrosoft.html

（更新：反応リンク集を末尾に追加）

RailsConf2007ではJRubyが大盛況だった。 この小さなチームは瀕死のプロジェクトを引き受け、JVM上で動くファーストクラスのRubyプラットフォームに変えた。彼らが多くの賞賛を得たのは当然だ。

JRubyについてはまさにそんな感じとして、注目すべきはもう一つの共通マネージコード・ランタイム——.NETだ。 Rubyに対するマイクロソフトの意図は今のところすごく不透明だ。 彼らはSilverlightのスクリプティング言語としてRubyを発表した——でも未解決の問題が多く残っている。 Ruby言語をフル実装するのか、それともRuby++みたいなもの——Rubyサブセットの拡張——なのか？

JRubyの目的は2つある。それぞれ明確に異なるものだが、相補的なものでもある。 1つ目の目的はJVM用の強力なスクリプト言語である。これによりJavaアプリケーションに動的言語を織り込むことができる。 2番目の目的はJVM上のRubyプラットフォームの実装である。これはRubyアプリケーション、特にRuby on Railsアプリケーションを、MRI(Matz’s Ruby Interpreter、現在のC版ランタイム)で動くのと同じようにJVM上で動かすことができる。

マイクロソフトの”Iron Ruby”に対する大きな疑問は、どのくらい互換性をもつことになるか？だ。CLR上にフル実装されるのか？ 私が受信した電波によれば、John Lam(Iron Rubyの中の人)は完全互換実装にするつもりらしい。でもこれは今の状況だとかなり困難なことかもしれない。もうじきThoughtWorksの中の人になるOla Bini(JRubyのコミッタ)は、MRIのソースコードを見ずにRubyランタイムを実装する方法を知るのはほぼ不可能だと考えている——しかしマイクロソフトは、従業員がOSSのソースコードを見ることだけでなく、ダウンロードすることにも徹底した制限をかけている。 オープンソースコミュニティでは、多くのコミュニケーションがソースコードを通して行われる——このため、マイクロソフトはオープンソースコミュニティとの共同作業が非常に難しくなっている。

これに暗雲を投げかけているのはもちろん、マイクロソフトとオープンソース界との歴史的な難しい関係だ。過去においては、マイクロソフトは盛んにオープンソースコミュニティを中傷したり脅したりしていた。近年、事態は改善されたけれど、マイクロソフトの真の意図については本当に謎だ。最近の特許に関する脅しは、マイクロソフトはオープンソースが死ぬまで戦おうとしていることの証しだと見ている人も多い。

他の多くの技術会社とは違い、マイクロソフトはオープンソース界と共存する方法を発見するのに苦労している。マイクロソフトにとっては難しいことなのだ——SunやAppleやIBMとは違い、彼らは完全にソフトウェア会社なのだから。 LinuxやGNUやOpen Officeのようなオープンソースプロジェクトは、マイクロソフトの重要事業とモロに競合する。 しかし私は、オープンソースに宣戦布告し、それを根絶しにしようすることが、長期的に現実的な解決案だと感じたことはない。 オープンソースはすでに定着している。 問題は、どのように対応するべきかということだ。

Rubyでは、マイクロソフトの立ち位置は先のようなデスマッチ状態とは違う。 Rubyはマイクロソフト製品群の中心的な収益発生源とは競合しない。 それ以上に、Rubyコミュニティはマイクロソフトと協力したいと本当に願っている。 私がRailsConfで話した人たちの大部分は、マイクロソフトが Rubyを全面的に支援するのをとても見たがっていた——そして、どうすればそれを実現させるような提案を持ち込むことができるかについての創造的な意見がたくさん出回っていた。 コミュニティで聞いた意見は圧倒的に、「Rubyは邪悪なマイクロソフトを倒す」ではなく「どうすれば問題を解決してマイクロソフトのRubyを得ることができるのだろうか」だった。

Chris Sellsが指摘したように、「マイクロソフトは何を狙っているのか」という疑問を考慮しないといけない。理由はいくつか思いつく。1つ目は、データセンター内での.NETやWindowsの役割だ。もしマイクロソフトがRubyプラットフォームをサポートしなかったら、Ruby on Railsが成功したときに、サーバーファームにおいて.NET(およびWindows)から人々が去ってしまうリスクを冒すことになる。

もう1つの理由は人だ。マイクロソフトは公式に認めたくないだろうが、アルファギークたちがマイクロソフトプラットフォームから去りつつあるというのが本当に懸念されている。 マイクロソフトのビジョンは指揮管理組織における死の軍隊だという意見が増えている。優秀なエンタープライズ開発者に可能性を与えるツールや、アジャイル開発プロセスに対するあからさまな支障がたびたび見られる。

数年前、レドモンドの（ちょっとした）伝手が、技術リーダーたちがWindowsプラットフォームから実際に離れていっているのを見ていると言っていた。最近、この兆候は増加しているようだ。うちのブログロール（訳注：blog roll）のマイクロソフト関連記事★’softie part★を読んでいると、長い間マイクロソフトのサポーターだった人たちの間に実際に幻滅があるという感じを受けた。 アジャイル指向の開発者たちはマイクロソフトツールの方向性に不満を持っている。マイクロソフトのカンファレンスは、アジャイルプロセスにはほとんど触れず、ウォーターフォールアプローチにかなり傾いている。ツールは、役割の分離が厳密なため、アジャイラーたちが好むぼんやりとした境界を積極的に阻止している。

Tim BrayはRailsConfで、技術についての鍵となる決定はプログラミングコミュニティによってなされると主張した。私はこれに部分的に同意する。 ブロートウェアがIT界に多すぎる理由は、ITの購買が、ソフトウェア開発の現実との大きな接点をなくした人々によって、ゴルフコース上で決定されるのが普通だからだ。 短期的にはゴルフコースでの決定が支配するかもしれないが、時間が過ぎれば、Timの主張が正しいと思う。だからアルファギークを失っても、今年や来年には影響しないかもしれないが、時間とともに容赦なくマイクロソフトに危害をもたらすだろう。

実はマイクロソフトにとってはすでに「来年」が過ぎている。 我たちはマイクロソフトのプロジェクトに対する顧客（特にアメリカの顧客）の関心が著しく減少しているのに気づいた。 オーストラリアでは、.NETは顧客の地盤をまったく得られなかった。このデータから何を受け取ればいいのかはよく分からない。私たちは統計学的に有効なサンプルになるほど大きくはない。ただ、そうは言っても、私たちの顧客は「アルファITショップ」だと考えているから、部分的には役に立つデータポイントだろう。

たぶんもっと重要なのはThoughtWorksの中の話だ。 .NETが登場したときは多くの関心が注がれた。 たくさんの人がJavaプラットフォームに強力な競争相手が現れたことを歓迎し、.NETのプロジェクトに参画したがった。 しかし去年あたりから.NETに見向きもしなくなった。 レドモンドから出てくるものには本当に面白いものもあったにも関わらずだ。 Mike TwoはWindows Workflowツールにすごく熱心だし、私はLINQや他の言語進化にとても感心した。 でも、マイクロソフト技術の全体図にはあくびが出る。 これが重要なのは、Tim O’Reillyが信じるように、アルファギークたちは他の人たちが数年以内にやるであろうことを指し示すからだ★。 そして決定的な点は、マイクロソフトに対する態度が憎悪（多くのギークの一般的な態度）ではなく、退屈であるということだ。 これが、Paul Grahamが「マイクロソフトは死んだ」と言ったことの意味だ。 マイクロソフトはもはや危険な存在ではないのである。

オープンソースに対する態度こそがこの問題の大部分だ。 Javaが現れたとき、そのポートフォリオには大きな隙間があったし、さらに悪いことには APIにはひどい標準ツールがあった(Entity Beansのビジョンが思い浮かぶ)。 これらの隙間やひどいアイディアは、オープンソースコミュニティが修正した。 Antがビルドツールを与え、EJBはSpringとHibernateで置き換えられた。 .NETにもギャップはあって、再びオープンソースコミュニティがギャップを埋めるために力を注いだ。ところがマイクロソフトは、こうした努力に協力することを拒否している。 むしろ台無しにしようと努力しているかのようだ。 特にうんざりしたのはNUnitに対するマイクロソフトの反応だ——優れたxUnitテストツールであり、その設計要素がOOPSLAでAnders Hejlsbergに称賛されたが、マイクロソフトは競合ライブラリを出荷してきただけでなく、故意に非互換にしてきた。これは、人々がプラットフォームに対して時間をつぎこむことを奨励するような反応ではない。

公平に言えば、この大失敗は2年も前のことだ。 Jim HuguninとJohn Lamを雇うといった行動は、あの印象に払拭するのに一役買った。 Chris Sells、Don Box、Jim Newkirkといった技術者は、マイクロソフトがより開かれた環境になるための努力をしている。しかし、大きな組織はどれも同じだが、マイクロソフトは矛盾する勢力であふれており、どれが勝利するのかは私たちには分からない。

同僚のJohn Kordybackは、大切なのはRubyが「もう一つの.NET言語」ということではなく、Rubyのコミュニティやソフトウェア開発に対する態度なのだということに気付くことだと指摘した。 Rubyとは、オープンソース、アジャイル思考法、軽量ソリューションが、価値として、深く浸透したコミュニティなのだ。 彼が言うには、レドモンドの問題は、 「なぜこの考えが重要なのか？」じゃなくて、 「なぜこの言語が重要なのか？」って聞いてるところ だということだ。

まとめると、私がRubyとマイクロソフトに見ているものは、チャンスだ。 Rubyコミュニティは、マイクロソフトとともに働きたがっているようだ。 このことが、レドモンドがオープンソースとともに働くという問題にどう対処するべきか知ることと、将来の協同作業のための模範となる努力のための機会を提供する。 完全なRubyプラットフォームの.NETでのファーストクラス実装は、この共同作業のすばらしい成果となるだろう。 もっといい結果はたぶん、マイクロソフトがオープンとアジャイルを対象にしたコミュニティとどうやって共同作業するかという例を、この作業が示すことだろう——たとえば、プログラマーと顧客にとって、さらに役に立つ姿勢が、マイクロソフト界の中でさらに広がっていくような、そんな跳躍台となりえるだろう。

これについてかなりの反応があった(全リストはTechnoratiにある)。特に読むべきなのは次の人たちからの反応だ: Sam Gentile, Cory Foy, Luke Melia, Jeremy Miller, Rockford Lhotka, John Lam, Evan Hoff, Karl Seguin, Ola Bini, Miro Adamy, Charles Nutter, Peter Laudati, Nick Malik(訳注：リンクするのが面倒なので本家を見てください)。

参考