ECMA 標準の利用 : Miguel de Icaza インタビュー

Dare Obasanjo

December 2001
日本語版最終更新日 2002 年 5 月 20 日

要約 : このインタビューでは、Ximian の創設者で GNOME を立ち上げた Miguel de Icaza 氏が、UNIX コンポーネント、Bonobo、Mono、および Microsoft® .NET について語ります。

Dare Obasanjo: Ximian (英語) が Microsoft .NET 開発プラットフォームのオープンソース実装の開発を発表したことで、このところ報道にお名前が出ていますね。最近の騒ぎよりも以前から、あなたは GNOME (英語) と Bonobo での実績で注目されていました。Mono (英語) 以前のプロジェクトでフリーソフトウェアに関わってこられた経緯を簡単に説明していただけますか。

Miguel de Icaza: この 4 年間は、GNOME プロジェクトで構成、ライブラリ、アプリケーションといったさまざまな領域に関わっていました。それ以前は Linux カーネルに関わっていました。このときは、SPARC ポートに長く取り組んだ後にソフトウェア RAID を担当し、Linux/SGI の取り組みにも一部参加しました。その前は、Midnight Commander ファイルマネージャを開発していました。

Dare Obasanjo: ご自身が書かれた「Let's Make Unix Not Suck」 (英語) の中で、コードが再利用されないことが UNIX の開発を長い間妨げてきたと述べられていました。特に、Brad Cox 氏 (英語) がソフトウェア集積回路について提唱した、ソフトウェアは基本的に再利用可能なコンポーネントを結合して構築されるという概念を、コードの再利用がいかに必要かを示す理念として取り上げていますね。あなたの主張には多くの人が反発し、再利用可能なコンポーネントは、小さなプログラムの出力をパイプでつないでプログラムを構築するために使うのが UNIX の基盤概念だと言っています。この反論に対してどのようなご意見をお持ちですか。

Miguel de Icaza: その論点については、先の論文でも詳しく取り上げていますが、"パイプ" は決して完全なコンポーネントシステムではありません。パイプは搬送メカニズムとして、一部の主要なプロトコル (ライン、キャラクタ、バッファ) と併用されて情報を処理します。情報フローを扱うのはプロトコルだけなのです。

これについては、この論文 (英語) で詳しく述べています。(Dare 注 : 「Unix Components: Small is Beautiful」というセクションを参照してください。)

Dare Obasanjo: Bonobo は、CORBA を基盤として UNIX コンポーネントアーキテクチャを構築しようという試みでしたね。そこから Mono へと焦点を移すことにしたのはなぜでしょうか。

Miguel de Icaza: GNOME プロジェクトの目的は、UNIX に欠けている技術を補って、デスクトップアプリケーションの市場における UNIX の競争力を高めることでした。また、言語に依存しないことが重要であると早くから気付いていたため、ほかの言語に対して容易に API をラップできるようにする標準を使って GNOME の API をコーディングしました。この API は、UNIX 上のほとんどのプログラミング言語 (Perl、Python、Scheme、C++、Objective-C、Ada) で利用できます。

その後、より優れた方法で API をカプセル化することになり、CORBA を使った対コンポーネントインターフェイスの定義に着手しました。これを、ポリシーと一連の標準 GNOME インターフェイスで補完し、再利用可能で言語に依存しないコンポーネント、コントロール、そしてコンパウンドドキュメントを簡単に作成できるようにしました。この技術が Bonobo として知られています。Bonobo へのインターフェイスは、C、Perl、Python、Java の各言語に対して用意されています。

CORBA は大まかなインターフェイスの定義に適しており、Bonobo のインターフェイスもほとんどが単純なものです。唯一の問題は、Bonobo/CORBA のインターフェイスが小さなインターフェイスに適していない点です。たとえば、XML を解析する Bonobo/CORBA コンポーネントは、C の API に比べて不十分です。

以前に次のようなことも書きました。

私が .NET に興味を持ったのは、GNOME プロジェクトで .NET の次の特性を実現しようとしたときです。

複数の言語に公開された API
言語間の統合
コントラクト/インターフェイスベースのプログラミング

何といっても、いろいろな点で Java が気に入っていました。ただ、程度の差はあれ好まれるはずの Java コンボは好きになれませんでした。

私たちは、API を多くの言語に公開しようと、共通のオブジェクトベース (GtkObject) を設定し、API コントラクトとフォーマットに従って、他者が自分のプログラミング言語に対して API を簡単にラップできるようにしました。ラッパーをその場で生成できるように、API のスキームベースの定義まで用意しました。ただ、このソリューションは、多くの理由から最適とは言えませんでした。

CORBA を使って COM のような言語間の統合を図りましたが、これはマーシャリングの面で不便でした。非 inProc コンポーネントではうまく機能するのですが、inProc コンポーネントではまったくだめでした。使用できる CORBA ABI がなかったため、散々な結果に終わったのです。

この問題を踏まえて、私たちはライブラリを増設しました。ライブラリのほとんどは、私たちが定めたコーディング規則に忠実に従っています。ときには、ライブラリがこの規則から逸脱していたり、第三者の作成したライブラリを採用することもありますが。その結果、ライブラリが混在することになります。この状況は、結果的には有効ですが、複数のプログラミングモデルが実装され、場合によっては実装される割り当てポリシーと所有権ポリシーも異なります。さらにしばらくすると、5 種類の "ref/unref" 動作 (CORBA ローカル参照、Unknown オブジェクトでの CORBA オブジェクト参照、オブジェクトラッパーでの参照カウント) を処理することになるため、大きな混乱を招いていました。

私たちはこれらすべての問題を解消しようと努め、状況は改善されつつあります (GNOME 2.x プラットフォームは、すべてはありませんが、これらの問題の多くを解決します)。

私には、.NET が Win32® 開発者のためのアップグレードのように思われます。長年にわたって設計されてきた Win32 の API にはあまりにも一貫性がなく、それを使用する Win32 の開発者は私たちと同じ問題に直面していました。そこで、この新しい "外からの空気" を一部取り入れて、独自のアプリケーションを構築しようと考えたのです。

Dare Obasanjo: Bonobo のベースにはわずかながら COM と OLE2 が取り入れられていますね。これは、Bonobo のすべてのインターフェイスが Bonobo::Unknown インターフェイスに基づいているという事実からもわかります。Bonobo::Unknown インターフェイスは、オブジェクトの有効期間の管理およびオブジェクトの機能検出という 2 つの基本的なサービスを提供するもので、次の 3 つのメソッドのみを含んでいます。

   module Bonobo {
      interface Unknown {
         void ref ();
         void unref ();
         Object query_interface (in string repoid);
      };
   };

これは、次のメソッドを持つ Microsoft の COM IUnknown インターフェイスときわめてよく似ています。

HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();

.NET が COM の終焉を暗示しているように、Mono も Bonobo の終わりを告げるのでしょうか。また、.NET では半透過的な COM/.NET の相互運用性 (英語) が計画されていますが、Mono と Bonobo にも同じような計画があるのでしょうか。

Miguel de Icaza: そのとおりです。Mono は、GNOME 上の Bonobo を含めた、多数の外部システムと相互運用できなければなりません。

Dare Obasanjo: Microsoft .NET プラットフォームは Java™ プラットフォームの貧相なコピーだと、さまざまな陣営が主張しています。もしそうなら、なぜ Ximian は Microsoft .NET プラットフォームではなく Java プラットフォームを複製する道を選ばなかったのでしょうか。

Miguel de Icaza: CLR に興味を持ったからです。CLR は、私たちが日々直面する問題を解決してくれます。Java VM ではこの問題を解決できませんでした。

Dare Obasanjo: Mono の基本原理に関するページ (英語) には、Microsoft の .NET 戦略が以下を始めとする多数の活動を包含していることが指摘されています。

ソフトウェア開発用の新たなプラットフォームである .NET 開発プラットフォーム
Web サービス
Microsoft サーバーアプリケーション
新しい開発プラットフォームを使用する新たなツール
Microsoft .NET の Passport を中心としたシングルサインオンシステムである HailStorm。これは、Microsoft Windows® XP に統合されています。
(訳注: HailStorm は、.NET My Services の開発コード名です。)

同時に、Mono は単に .NET 開発プラットフォームの実装に過ぎないと述べられていますね。Ximian では .NET 戦略のほかの部分を導入する予定はありますか。

Miguel de Icaza: 今のところありません。現在は、次の開発に専念しています。

x86 CPU 用の JITer を含む CLI ランタイム
C# コンパイラ
クラスライブラリ

これらの開発はいずれも、外部協力者の支援を受けています。理解していただきたいのは、これが大規模な事業であり、さまざまな人が自分の時間を割いて専門知識やコードをプロジェクトに提供してくれないと、たちまち製品を完成させる見込みすらなくなってしまうということです。

このプロジェクトは、利己的な理由で進めています。Linux と UNIX のアプリケーションを開発する優れた手段が欲しいのです。CLI もそのような手段の 1 つと考えています。

とはいえ、Ximian はサービスとサポートを業務としているので、Mono プロジェクトでの新しいプラットフォームへのポートや JIT エンジンの改良などの取り組みには協力を惜しみませんし、Mono の特定の領域に注力する用意もあります。

しかし、この点を除けば、既に発表した 3 つの基本声明以外の活動を行う予定は今のところありません。

Dare Obasanjo: フリープラットフォームで .NET のその他の部分を実装しようとするプロジェクトは他にも多数あり、Mono プロジェクトと反目しているように思えます。「Portable.NET FAQ」(英語) のセクション 7.2 には、Portable.NET プロジェクトが Mono プロジェクトと対立したかのような記述があります。同様に、Martin Coxall 氏は DotGNU メーリングリストから追放されました。これについてどうお考えですか。

Miguel de Icaza: Coxall 氏が DotGNU メーリングリストから追放された件については特に気に留めませんでした。Usenet やインターネットのメーリングリストは独特な文化であり、この件もインターネットで日常起きている事例の 1 つであると思います。まったく残念ではありますが。

Mono と .NET の焦点は、若干異なっています。Mono では、C# のような高度な言語をできる限り多用し、そこから再利用可能なソフトウェアの断片を作り出しています。一方、Portable.NET では C が使われています。

Dare Obasanjo: Ximian と Microsoft の関係については、矛盾した報道がなされてきました。.NET を管理するライセンスと GPL の間に、ライセンシングに関する問題があるかのような報告がある一方で、Microsoft の一部関係者が Mono に乗り気であるという指摘もあります。そこでお聞きしたいのが、Ximian と Microsoft の現在の関係です。また、.NET に対する Microsoft のライセンスが制限された場合に、どのようにして Mono がそれらのライセンスを侵害しないようにするのでしょうか。

Miguel de Icaza: 私たちはすべてをゼロから作り出しています。

特許に関しては、安全な立場でいることを心がけています。つまり、何かを実装するときには過去の手順を踏まえますし、Mono ではそれほど込み入った活動や有効な活動をまだ行っていません。そのような段階にはまだほど遠いのです。ただ、既存の技術や手法を使っているに過ぎません。

Dare Obasanjo: Sun がこれまでに少なくとも 2 回、Java を標準プロセスから撤回したことが指摘されていますが、.NET が何かの理由でオープンスタンダードでなくなった場合に、Mono プロジェクトは継続されるのでしょうか。

Miguel de Icaza: 私たちの開発プラットフォームでのアップグレードには、それが標準であるかどうかとは関係なく価値があります。Microsoft がその仕様を標準団体に提出したことは役に立っています。なぜなら、一連の問題について知っている人は、その問題を検討した経験があり、相互運用性に関する問題を特定できるからです。

Dare Obasanjo: 同様に、Dan Kusnetzky 氏が予測したように、Microsoft が今後 .NET の API を変更したらどうなるでしょうか。Mono プロジェクトはそれに追随しますか。それとも UNIX プラットフォーム上で互換性のない .NET を実装しますか。

Miguel de Icaza: Microsoft は、API の下位互換性を維持する点で非常に優れています。同社がプラットフォームベンダとして大きく成功した理由の 1 つはこの点でしょう。ですから、これは問題にならないと思います。

互換性が問題になったとしても、同じ API の実装を複数用意して、実行時に適切な "アセンブリ" を選んで正しい実装を使うことができます。アセンブリは、ソフトウェアバンドルを扱う新しい方法です。アセンブリの一部であるファイルには暗号化チェックサムを使用できます。また、プログラムを使ってアセンブリの API の互換性をテストできます。(Dare 注 : アセンブリの詳細については、「用語集」を参照してください。)

したがって、API が当初のリリースから逸脱しても、下位互換のアセンブリを提供することは可能です (これは私たちと Microsoft の双方に言えることです)。

Dare Obasanjo: Mono クラスのステータスに関するページ (英語) を見ると、多くの .NET クラスライブラリが Mono に実装されないようですね。たとえば、Windows Forms、ADO.NET、Web サービス、XML スキーマ、リフレクションなどのクラスライブラリが含まれていません。つまり、Mono と .NET が最終的にリリースされた段階で、.NET 向けに作成されたアプリケーションを Mono に移植できない可能性が強くなります。今後、この点を調整する予定はあるでしょうか。それとも、移植可能な .NET プラットフォームを作成することが Mono プロジェクトの目標ではないのでしょうか。これに関連して、Mono プロジェクトの短期的および長期的な目標も聞かせてください。

Miguel de Icaza: ステータスに関する Web ページに示されているのは、実装を "要望された" クラスです。このページでは、コードの重複を避ける目的で "現在作業中のクラス" をお知らせしているだけです。だれかがあるクラスの作業に興味を示して登録し、しばらくたっても作業を行わない場合は、私たちがそのクラスを回収することもあります。

このプロジェクトは始まったばかりなので、エンドユーザー向けのクラスよりも、基本的なクラスに対する取り組みが目立つのでしょう。

プロジェクトのこのような早い段階で、これほど多くの有能なプログラマが協力してくれるとは予想していませんでした。当初の私の予想では、最初の 3 か月間に、公の場でのハッキングを外部の協力を得ず私たちだけで行うはずでした。私の予想は見事に外れたわけです。

Mono プロジェクトの目的は、単に Ximian の目的にとどまらないことをわかっていただく必要があります。Ximian にはいくつかの目的がありますが、プロジェクトの協力者もそれぞれに目的を持っています。学習したい人、C# に携わりたい人、Linux で .NET が完全に互換となることを期待する人、言語への依存を望まない人、コードを最適化したい人、下位レベルのプログラミングを好む人などさまざまな人がいます。また、Microsoft に対抗したいという人や、.NET サービスの仕組みが気に入ったという人もいます。

したがって、プロジェクトの方向を決めるのはプロジェクトの協力者です。多くの人が、非 Windows プラットフォームで互換性のある .NET を実装することに強い関心を持っており、その隔たりを埋めるために協力してくれています。

Dare Obasanjo: Ximian では、Mono の開発費用をどのようにまかなう予定ですか。特に最近では、Indrema や Eazel、Great Bridge のような、フリーソフトウェアを基盤とする新興のベンチャー企業が損失を出し、その他のフリーソフトウェアをベースとする企業も大半が苦境に立たされています。具体的に言うと、Ximian では、フリーソフトウェア全般、および Mono でどうやって収益を上げるつもりなのでしょうか。

Miguel de Icaza: Ximian が提供するのはサポートとサービスです。先日もサービスをいくつか発表しましたし、ほかにもかねてから準備していた製品とサービスを今後半年間に発表する予定です。

最近発表したサービスは次のとおりです。

Red Carpet Express - これは、Red Carpet サーバーへの確実で高速なアクセスを望む利用者向けのサブスクリプションサービスです。
Red Carpet Corporate Connect - Red Carpet アップデータ技術を修正しました。この技術は、Linux ワークステーションネットワークの管理を簡単にすると共に、カスタムソフトウェアパッケージを導入して管理するために使用します。
GNOME デスクトップと Evolution を対象としたサポートとサービス - 最近では、Ximian の各製品に対するサポートサービスを、箱に入った製品にバンドルする形で販売しています。

Ximian では、フリーソフトウェアベースのソリューションを統合する利用者を対象とした、専門的なサービスとサポートも提供してきました。

Mono は特別なケースとしておもしろい存在です。私たちは、開発費用を削減する目的で Mono に取り組んでいます。既に優れた基盤が用意され、ECMA に提出されています。現在は、同じく Mono のパワーを認識しているその他関連団体の支援を得て、Mono ランタイムと開発ツールを開発し、生産性の向上に役立てようとしています。

事実 Ximian では、以前に社内のインフラ整備を担当したチームが Mono に取り組んでいます。

Dare Obasanjo: 一部ではあまり知られていないようですが、あなたは以前、Internet Explorer の SPARC ポートの開発に誘われて Microsoft で面接 (英語) を受けられましたね。それ以降にあなたがフリーソフトウェアの世界で受けた影響を考えると、もし Microsoft に入社していたら自分の人生がどうなっていたか考えたことはありますか。

Miguel de Icaza: あまり考えたことはありませんね。でも、Microsoft で面接したすべての人には、Internet Explorer をオープンソース化するようにお願いしておきました。Netscape Communicator がオープンソース化されるずっと以前のことです。

Dare Obasanjo は、ジョージア工科大学の 4 年生で、コンピュータサイエンスでの理学士号の取得を目指しています。学業の合間に、Slashdot、Kuro5hin、Advogato などのオンラインフォーラムへの投稿や、プログラミングとソフトウェアに関するさまざまな記事の執筆を行っています。これまでに、Radiant Systems、i2 Technologies、Microsoft を始めとするさまざまな企業での実務研修に参加しました。卒業後は大学院への進学も検討していますが、最終的には Microsoft の本社があるレドモンドに落ち着くことになるでしょう。