この文章について: これは、MicrosoftのLonghornにオープンソース陣営としてどう向き合うか、という議論について、GNOME/MonoプロジェクトのMiguel de Icazaが一石を投じた文書だ（いや、早断かもしれないが）。原文はこちら。当然ながら翻訳公開許諾済。煮るなり焼くなり好きにしたって下さい。
JeffはCringleyの「問題は、Microsoftに高すぎる関心を払うことこそが、Microsoftがゲームを決めることを可能にしている、ということだ。そしてMicrosoftがゲームを決めたときは、い つ も 勝っているのだ。」という声明がお気に入りのようだ。
素晴らしい声明だ。だけど声明以上の何ものでもないし、それ以外の点では、全く正しくない。
Microsoftは、いくつもの要素の積み重ねで勝利をかざってきたし、それは「ゲームをきめた」こととは全く関係ない。多くの中から、いくつかとりあげてみよう：
競争者は、より狡猾に立ち回っていたり、あるいは反競争的だったりした。（"High Stakes, No Prisoners"を読んでみなよ）
[訳注 - この書籍のことか。訳者は読んだことありませぬ]
1993年～1994年、Linuxはベストデスクトップシステムになることを約束していた。僕らには本当のマルチタスクがあったし、本物の32ビットOSがあったし、同じシステムがクライアントにもサーバにもなった。Linuxはサーバにもなったし（ファイル共有[訳注 - といってもFTPのことだろう]やWebサーバとして）、dosemuを使ってDOSアプリケーションを走らせることもできた。X11もあった。巨大なサーバ上のアプリケーションをリモートで実行して、小さなマシンで表示することができた。Linuxは活気に満ちた革新的なコミュニティになり、ウィンドウマネージャ上のバーチャルデスクトップで、Windowsユーザーの10倍速く処理することが出来たんだ。TeXはもちろん「内容にフォーカスを置き、論理的なレイアウトをもっている、Windowsよりずっとマシな存在」だったし、それがお気に召さない人には、"Andrew"ワードプロセッサがあった。Tcl/TkはQuickBasic並みにアプリケーションを作ることができた。
そこに、MicrosoftがWindows 95を出したんだ。
それから何年か経って、みんながコンポーネントを語り出した。NetscapeはIIOPをクライアントとサーバのシステムとして提唱して（ブラウザ上のWebサービスが一般的になるより、ちょっと前の話だ）、Xerox ILU、Bonobo、KPartsといった風に。Borlandは、誰もが納得する小さなコンポーネントシステムを構築するイベントのスポンサーになった。ランゲージ バインディングはその上に立つ存在だった。
当時のコンセンサスは何かって? Microsoftがやっていたのは、僕らが「古い、古い。僕らの方が先進的だね」といっていたような、COM/DCOM/Windows DNAの上に立つthinレイヤーを作っているだけだった。
そして、そこにMicrosoftが.NETで追いついてきた、というわけだ。
XAMLなんかがそんなに重要かって？ そんなことはない。でもこれは、相対的にはキュートなアプリ…より入門的なユーザーにとっては…を作るのが、誰もがWebページをHTMLで作っているのと、同じように簡単にできる。
Avalonがそんなに重要かって？ こいつはキュートなツールキットで、たくさんのウィジェットがある。だけど僕らがウィークエンドにでも出来ない、というようなものじゃあないだろう？
それらが.NETの上に構築されていることが問題だって？ ああ、生産性のアドバンテージやセキュリティ機能や…って言ってると.NET対Javaについての長々しい議論になるんだけど、それはここでは問題じゃない。
誰もがこまごまとしたところで平行線の議論をしている。「おれたちは昔からGladeでずっとやってただろ！」「Gtk/Qtはクロスプラットフォームじゃん！」「僕らは素晴らしいランゲージバインディングで同じ事ができるじゃないか！」「私たちにもウィジェットならあるでしょ！」「Cairoが僕らの全てさ」「ユーザーが本当にほしいものは何さ？」そして当然ながら「あいつらにゲームを決めさせるな！」というわけだ。
それぞれの要点はまことに結構なんだけれども、デスクトップLinuxにとってLonghornが脅威になるというのは、Microsoftのデプロイメント パワー、XAML、Avalon、.NETの組み合わせはキラーだ、ということなんだ。JavaはWebの世界でそれをやろうとしたけど、それをデプロイするチャネルが無かった。それがJavaの失敗から得られた教訓なんだ。
この組み合わせが意味するものは、LonghornアプリがWebライクなデプロイメントの利点がある、ということなんだ：1箇所で開発し、1箇所でデプロイし、きみのブラウザでどんな内容にも安全にアクセスできる、というものだ。
.NETのサンドボックス実行[1] が意味するのは、きみはどんなWebサイトにいっても、Webアプリケーションとはひと味違う、ローカルのリッチアプリケーションを、何のデータセキュリティの心配もすることなく実行できる、ということだ。スパイウェアとか、トロイみたいなやっかいな奴らをだ。
Avalonが意味するのは、それらの新しい"Web"アプリケーションが、きみのOSとビジュアルに統合されて、OSの機能と同じようなネイティブのダイアログ（たとえばローカルにある連絡先の選択みたいなもの）を使えたりする、ということだ。
そしてファットクライアントを作るのが、見栄えの良い、統合された、安全なWebアプリケーションを作るよりも簡単なものであることは、証明されてきた。（アプリケーションだからね。変化しないWebページのことじゃないよ。）
そして最終的に、Longhornはデプロイされるだろうし、XAML/Avalonアプリケーションが作られることになるだろうし、人々はそれを消費することになるだろう。最悪なのは、人々は、彼らのデスクトップが、それらの「リッチな」サイトにアクセスできることを期待するかもしれない、ということだ。90%というマーケットシェアのもとでは、これは起こりそうなことじゃないか。
AvalonはLonghornでしか動作しないんじゃないかって？ 多分そうだろう。でもそいつはあてにならない。MicrosoftはIE4をWindows 98用に作り上げた。で、それを後になってからWindows 95、Windows 3.11にバックポートし、それからHP-UXやSolarisにも動いたんだ。
人々がこれらの問題に賢明にも関心をもち議論しているのは、またぐうたらと眠り込んでいたいとは思わないからなんだ。
これはLinuxやMacにとって、世界の終わりになるだろうか？ そんなことは無いだろう。僕らの多くは僕らの普通のアプリケーションを使い続けるだろうし、便利で一貫性のあるデスクトップを楽しむだろう。でもそれじゃ、（今みたいに）ちょっとしたマーケットだけが残されることになるだろう。
ちなみに、Mozillaの人たちも既に気付いていることなんだけどね。
[1] この事実は、.NETがコードアクセスセキュリティ(CAS)を.NET 1.0でサポートしていた理由の説明としては、分かりやすいんだけどね。現実には全く使われなかった。Longhorn/Avalon/XAMLが出れば、それらが実装された理由がもっと明白になるだろう。
これらの議論の一部が、Gtk+/XULといったネイティブなツールキットで、ISVにセックスアピールできるような競合製品をビルドする、といった感じのまとめになってきているところだけど、それじゃあWebライクなデプロイメントをさせてくれるような、良い基盤にはならない（僕らには、Javaや.NETのように、信頼できないアプリケーションを安全に実行でき、ダウンロードしたコードを検証できるようなスタックが必要だ）。
時は短い。MicrosoftはAvalonを2,3年以内に出荷するだろうし、そのテクノロジーをプレビューすることになるだろう。
2つの選択肢があると思うんだ：
多分、誰かが最終的にはAvalonを実装することになると思う（Monoチームの協力があるか無いかは分からない[訳注 - Windows Formsと同じだ。WinFormsは、Ximianのリソースを使わずに開発された。現在ではNovellの開発担当者が存在する]）。開発者にとっては、多かれ少なかれ楽しいことだろう。
もし僕らが独自の道に進むとすれば、僕らは、市場に素速く到達できるような、頼るべきオープンソースの強みを得なければならない: 要件定義、デザイン ガイドライン、貢献してくれるようなキーパーソンたち、互換性要件、そしてデプロイメント プラットフォーム
僕らはNovell内部で、後者のアプローチを Salvadorプラットフォーム としてきた（こいつをMiggyLonと呼ぶか、Natalonと呼ぶかという長大な議論の結果そうなった）。
これをやるかやらないか、やるならいつやるのか、まだ分からない。でも取りかかってはいる。
Avalonには特許は無いのか？ Microsoftはこいつで何かしらの特許をとるつもりなのかもしれないが、とりあえず今のところ、Avalonには、ほとんど、あるいは全く、新規性のある発明は見られない [訳注 - これは.NET Frameworkが出たときにも言っていたことだ]：