オープンソース対オープンスタンダード

　技術を提供するベンダーが“オープン”という言葉を多用するようになって数十年が経過したが、今度はユーザー側がこの言葉を使い始めたようだ。

　今日、“オープン”という言葉は、ソフトウェアソースコード、業界スタンダード、開発コミュニティ、ライセンスモデルの4つとともに用いられている。だが、この4つはそれぞれ異なるものであるにも関わらず、はっきりと区別されずに混同されているようだ。

　この4つにはそれぞれの役割がある。だが、ここでまず重要なのは、それぞれが一体何であって、また何ではないのかを正しく理解することだ。この4つのうち、最も重要度が高いのはオープンスタンダードだろう。というのも、一度オープンスタンダードに関する決断をすれば、その後の選択肢も大きな影響を受けるからだ。

　これこそがオープンスタンダードのすべてなのである。オープンスタンダードとは、異なるプログラム同士の連携を目指して同意した取り決めのアウトラインを示したドキュメントと、プロセスやテストなど、実際に連携が可能であることを保証する手段とで構成される。オープンスタンダードでは、企業は数あるベンダーの中から自由に技術を選ぶことができ、一社に囲い込まれる心配はない。

　一方のオープンソースソフトウェアに関しても、オープンスタンダードと同じような長所を持つと勘違いしている人が多いようだ。しかし、必ずしもそうではない。

　オープンソースとは、ただ単にソフトウェアコードが閲覧および変更可能であるだけだ。最も有名な例はLinuxのカーネルだが、それだけではない。Apache Webサーバ、Gnome Window環境、ブラウザのMozilla、リソース管理のGrid Engine、OpenOffice.orgなど挙げれば切りがない。実際、このオープンソースの歴史は古く、20年以上前にBill Joyが開始したUNIXとBSDライセンスに遡ることができるのだ。

　最高のオープンソースプロジェクトとは、標準の幅を拡大し、市場での受け入れ枠を広げ、クロスプラットフォーム環境における互換性を高めてくれるようなものだ。私の勤務するSun Microsystemsが、上に挙げた例をはじめとする各種プロジェクトに800万行以上のコードを提供してきた理由はまさにここにある。

　オープンソースで注意すべき事項は、各プロジェクトによりライセンス条件が異なる点だ。CIOならば、GPL、Lesser GPL、Apache、Mozilla、BSD、modified BSDなど、オープンソースの各種ライセンスがどのようになっているかを正確に把握しておきたいところだ。そうすれば、現在抱えている仕事にどのオープンソースプロジェクトが適当かどうかを判断できる。

　例えばある企業が、自社開発の取引アプリケーションと各種のオープンソースコードを組み合わせたいとしよう。もちろんそれは可能だが、その後そのアプリケーションを誰でも自由に利用できるよう、コードの開示が必要となる可能性がある。もしくは、ある程度互換性があればそれでよいかもしれない。このような条件はすべてライセンスにより異なる。Sun Microsystemsでは、ユーザーのあらゆる状況にマッチできるよう、ソフトウェアのさまざまなライセンス形態を用意している。

　オープンスタンダードとオープンソースに共通していえることだが、最も大切なことはバックにオープンなコミュニティが存在していることだ。そのコミュニティのプロセスはどのようなものか。競合他社、顧客、学生、誰もが参加できるものか。技術革新というものはどこからでもやってくる。実際、思いかげないところから起こった技術革新は数多い。

　私は、今日のオープンソースソフトウェアの人気の理由は、包括的なプロセスと技術に豊かさをもたらす点の2つにあると思っている。もちろん、無償でダウンロードが可能だという特徴も、何ら危害を与えるものではない。だが、このプロセスは今後の課題にもなっている。

　コードを提供する人や企業はたくさんいるが、そのコードが全てメインストリームになるわけではない。中にはある企業の一製品で終わるものもあるだろう。ソースコードをオープンにし、誰もが利用できるようにするというのは素晴らしい考えだ。しかし、コミュニティが作り出すもの全てに互換性があるとは限らない。

　もう一度言うが、だからこそスタンダードが重要となる。CIOはスタンダードがあるからこそテストができ、互換性と自分の選択を保証できるのだ。

　最終的にカギとなるのは、自社の選択肢をオープンにしておくこと、これにつきる。