Open Source as a Business Strategy

ビジネス戦略としてのオープンソース化

Brian Behlendorf
ブライアン・ベーレンドルフ
Translation by Akira Kurahone



　一九九七年から一九九八年にかけて、Ｌｉｎｕｘ、Ｆｒｅｅ ＢＳＤ、Ａｐａｃｈｅ、そしてＰｅｒｌなどのオープンソースシステムが、新しいユーザ層から注目されるようになった。つまり、オープンソースが社内情報システム部門の責任者、経営管理の人たち、情報産業のアナリスト、そして投資専門家の人たちの注目を幅広く集めるようになったのである。
　オープンソースソフトウェアの開発者たちの多くは、このようになったことを歓迎している。世間の注目を浴びるようになったおかげで、彼らは自分たちの成果に誇りを持てるようになった（それに対して、何らかの対価を支払ってもらえる者も多くなってきている）。オープンソースソフトウェアの開発者たちは、自分たちの努力を上司や同僚に対して正当化できるようになりつつある。
　しかし、新しいユーザ層が、オープンソースに対して次のような疑問をいだいていることも現実である。



　結論を先に述べてしまうと、私は、営利目的でソフトウェア開発を進めるうえで、オープンソースを有望な方式としてとらえている。本章では、そのような開発において、オープンソース方式を採用するための前提条件について、まず考えてみたい。次に、オープンソース方式で実行できる開発プロジェクトの種類について考えてみたい。そして、最後に、オープンソース方式の開発プロジェクトに着手する際の手順について考えてみたい。なお、私は本章の読者として、ソフトウェアを営利目的で製造、販売、サポートしている企業の人たちや、ビジネス業務の基幹システムの部分にオープンソースのソフトウェアを使っている技術系企業の人たちを想定している。


プラットフォームについて
　私は、オープンソース方式でのソフトウェア開発を強く支持している。しかし、オープンソース方式が当事者に利益をもたらさない場合もあることは確かだ。つまり、オープンソース方式は、ある程度のトレードオフを覚悟し、結果が保証されていないことを承知のうえで、自社の長期的目標をしっかり見定め、現状の技術的競争力を把握したうえで、採用する、しないを決めるものである。
　それでは、まず、アプリケーションプログラミングインターフェイス（ＡＰＩ）、プラットフォーム、技術標準についての話から始めよう。なお、これ以降、私がプラットフォームと書くときは、（Ａｐａｃｈｅサーバでカスタムモジュールを構築する際に使われる）ＡＰＩや、（ＨＴＴＰのような）通信用プロトコル、（Ｌｉｎｕｘのシステムファイルの配置やＮＴサーバの管理などの方針を含む）オペレーティングシステムコンベンションの総称を意味することとする。
　Ｗｉｎ32は、ウィンドウズ95とＮＴのＡＰＩであり、ひとつのプラットフォームである。これらのＯＳ上で動作するアプリケーションを開発する場合には、マイクロソフト社により提供され、規定されているＷｉｎ32のインターフェイスと機能を使わなければならないからである。したがって、ＩＢＭ社がＯＳ／２で試みたように、ウィンドウズ対応のプログラムを動作させることができるようなオペレーティングシステムを独自に書こうと思ったら、Ｗｉｎ32 ＡＰＩを丸ごと実装しなければならない。ウィンドウズ版のアプリケーションはこのＷｉｎ32のＡＰＩを使うことを前提として開発されている。
　Ｗｉｎ32がプラットフォームであるのと同様、（ウェブサーバの一種の拡張インターフェイスである）コモンゲートウェイインターフェイス（ＣＧＩ）もプラットフォームである。ＣＧＩで書かれたスクリプトやプログラムは、ウェブサーバ上で動作する。ＣＧＩは、Ｗｉｎ32よりシンプルなプラットフォームなので、できることも限られているが、ＣＧＩを使えばどんなウェブサーバ上でも動作する移植性の高いプログラムを開発できる。そのため、ＣＧＩの存在はウェブサーバ市場にとって重要である。ＣＧＩとＷｉｎ32との根本的な違いは、Ｗｉｎ32のほうがＣＧＩよりも数百倍複雑ということ以外に、マイクロソフト社が所有しているＷｉｎ32と違って、ＣＧＩの仕様は誰にも所有されていない。ＣＧＩは、主要なウェブサーバ開発者の間で、お互いのスクリプトを使えるようにするために実装され、実際に使い始められてから数年経った段階で、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のＲＦＣ（Request for Comments）として、その仕様が取り決められた。
　ソフトウェアの基本的性質は、プラットフォームによって決められる（ここでいうソフトウェアには、ネットスケープ・ナビゲータのようなウェブブラウザやＡｐａｃｈｅサーバなども含まれる）。ソフトウェアはいろいろなプラットフォーム上で構築され、いろいろなプラットフォーム上で使用される。プラットフォームの概念は、ＨＴＴＰやＴＣＰ／ＩＰがプラットフォームとなって爆発的な成長を見せているインターネットにとって重要である。それにもまして、最近では、クライアント／サーバ型のコンピュータ環境において、プラットフォームの位置づけがますます重要になっている。
　私の関係しているＡｐａｃｈｅサーバ開発プロジェクトの場合、我われは、なによりも先にＡＰＩを開発した。これによって、Ａｐａｃｈｅサーバのコア部分の機能と周辺部分の機能をはっきり区別できるようになったことは、我われの開発にとって好都合であった。このＡＰＩを使うことによって、我われは、（ＴＣＰコネクション、プロセス管理、ＨＴＴＰリクエストハンドリングといった）ウェブサーバの基本的機能と、（ログイン、ＣＧＩ用モジュール、サーバサイドインクルード（ＳＳＩ）、セキュリティなどといった）その他の機能を区別できるようになったからである。また、このＡＰＩがあったおかげで、我われは、（Ｐｅｒｌ言語をＡｐａｃｈｅサーバのモジュールとして組み込むための）mod_perlや、（Ｊａｖａサーブレット ＡＰＩを実装する）mod_jservなどの機能の開発を、複数の開発グループにまかせることができた。このＡＰＩがあったおかげで、開発プロジェクトの中核メンバーは、Ａｐａｃｈｅサーバのカーネル部分の保守・改良を手がけながら、同時進行的に、要求されるすべての機能に対応できるような「大仕掛けのサーバ」を構築せずにすんだのである。
　ソフトウェアのビジネスによっては、プラットフォームの所有を前提としているものもある。このようなビジネスを営む企業は、自らの所有するプラットフォームの使用に対して料金を請求することができる。彼らは、インストールごとに使用料を請求したり、ユーザ数に応じて使用料を請求したり、あるいは他の方式で請求したりする。プラットフォームは、著作権によって保護されていることもある。誰でも使用できるパブリックドメインに所属すると明記された書類が不備のため、著作権がどこに帰属するかが不明瞭になってしまうこともある。また、技術的以外の理由で進化が急すぎて、開発者や提供者がプラットフォームの整備にまで手が回らず、遅れの原因がプログラミングとはまったく関係がないのに、何か技術的な問題があって、その整備が「遅れている」という評価を世間一般から受けてしまうこともある。
　短期的にみると、プラットフォームの所有を前提とするビジネスモデルは、プラットフォームを所有する企業に利益をもたらしうる。しかし、同じ業界内のその他の企業に対して利益をもたらすものではない。技術革新を促進し、その速度を早めるものでもない。競合企業は、たとえ技術力に優れていても、よりよいサービスをそろえていても、より低コストなサービスを実現していても、そのプラットフォームを自由に使用できないために、自社の利点をビジネスに活かすことができない。消費者の立場はその逆である。消費者は、お金を払えばプラットフォームを使える結果、それに依存するようになってしまい、その価格が上昇した場合、目先少し余分に払ってそれを使い続けるか、大金をはたいて別のプラットフォームに切り替えるかの選択に直面せざるをえない（こちらのほうが、長い目で見れば経費の節約につながる）。
　現在、コンピュータは、日々のビジネスに欠かせないものになっている。そのような状況の中で、ビジネスに不可欠な業務に支障をきたさせないためには、コンピュータやソフトウェアの供給を特定のベンダーに依存すべきではない。しかも、選択肢とは、自由に選べるという意味だけではない。選択肢は、あまりお金をかけずに手に入るものでなければならない。選択の自由においては、選択肢への切り替えがコスト高にならないことが重要である。ソフトウェアの切り替えにおいては、プラットフォームまで一緒に切り替える必要がなければ、出費を最小限に抑えられる。オープンなプラットフォーム上でソフトウェアを使うことが消費者の利益となるのはそのためである。
あまりお金をかけずに選択肢を手に入れられるという状況は、多くの人にとって、想像するのが難しい。なぜかというと、我われが高校で習った需要と供給の関係は従来の経済学に基づいており、その経済学によれば、製品にかかるコストはビジネスの進展とともに増大し得るとされているからである。すなわち、従来の経済学は、製品を十倍売ろうとすれば、費用もほぼ十倍かかるとしている。しかし、これは誰にも予測できなかったことであるが、ソフトウェアビジネスにおいては、数量とコストの関係がこれまでとは劇的に違ったものになっている。ソフトウェア製品の生産にかかる労力と、それを購入して使える人数との間には、直接的な相関関係がほとんど存在しない。
　通信用プロトコルやＡＰＩの参照実装となっているオープンソースソフトウェアは、そのプロトコルやＡＰＩ（つまりプラットフォーム）を長期的に存続させていくことを考えると、同じプラットフォームの参照実装となっている商用ソフトウェアより重要である。なぜなら、商用ソフトウェアは、競争相手の企業によって買収され、市場から引き上げられてしまう可能性が常に存在するからである。そうなってしまうと、そのソフトウェアを参照しながらプラットフォームを実装するという選択肢が市場から失われてしまう。技術標準は、業界全体のものであるという概念が崩れてしまう。なお、通信用プロトコルやＡＰＩの参照実装となっているオープンソースソフトウェアは、実装によるパフォーマンスの違いを比較するときの専門的な評価基準としても有効である。
　ＩＥＴＦやＷ３Ｃ（World Wide Web Consortium−インターネット上で利用される各種標準規格を制定する公認の機関）などは、標準化に関する意見交換の場を提供するという、それなりに有益な役割をはたしている。これらの組織は、全般的に見て、インターネットのよりよいアーキテクチャやスムーズなオペレーションを目的にそれなりに効果的な仕事をしている。しかし、一定の標準を長期間存続させていくことや、そのような標準を普及させていくことは、彼らの管轄外である。彼らには、メンバーに対して、自分たちが明確に標準化したプロトコルを実装するように強要する権限はない。ときには、特定の実装が正しいことを示してみせるには、実際に正しく機能するように実装されたコードを参照させる方法しかない場合もある。
　たとえば、一九九六年十二月、ＡＯＬは、顧客がウェブサイトにアクセスするのに使うＨＴＴＰプロキシサーバをアップグレードした。この変更以降、ＡＯＬのユーザが、Ａｐａｃｈｅ1.2サーバを使っているウェブサイトにアクセスしようとすると、次のようなメッセージが表示されるようになった（新しいＨＴＴＰ／1.1の仕様が実装されたＡｐａｃｈｅ1.2サーバは、その数か月前に登場したばかりであった）。



　Ａｐａｃｈｅ開発グループの主要メンバーは、この問題に対処するため、状況分析を行なった。グループからの問い合わせに対して、ＡＯＬ側は次のような説明を送り返してきた。



　ＡＯＬのエンジニアがこのような返事をよこしたのは、ＨＴＴＰ／1.1がＨＴＴＰ／1.0クライアントおよびプロキシとは下位バージョン互換（バックワードコンパチブル）ではないはずであると、彼らが思いこんでいたからである。しかし、実際のところＨＴＴＰは、マイナーバージョンアップでは、下位互換に設計されていたのである。とはいえ、ＨＴＴＰ／1.0の標準仕様は非常に複雑だったため、よほど注意して読みこまない限り、下位互換ではないと誤解されるおそれがあった。特に、一九九六年頃出回っていたＨＴＴＰ／1.1の仕様に関するドキュメント類についてはそれが言えた。
　そこで、Ａｐａｃｈｅサーバの開発グループは、一歩譲ってＨＴＴＰ／1.0での要請に対してＨＴＴＰ／1.0を返すようにサーバを変更するか、標準仕様に従うかの選択に迫られたが、開発グループの中でＨＴＴＰに詳しいロイ・フィールディング（Roy Fielding）が、その時点でのＡｐａｃｈｅサーバの動きがいかに正確で有効であるかを証明してくれた。つまり、場合によっては、ＨＴＴＰ／1.0のクライアントは、サーバが1.1をサポートすることに気づいてＨＴＴＰ／1.1にアップグレードしようとするかもしれない。さらに、プロキシサーバがオリジン（origin）サーバのために代行した最初の要請が1.0であっても、オリジンサーバが1.1もサポートできるという事実をプロキシサーバに伝えることが重要なのである。
　結局、我われは、一歩も譲らずにＡＯＬ側にソフトウェアの修正を求めることにした。科学的な根拠にも基づいて判断する限り、ＨＴＴＰ／1.1でＡＯＬのソフトウェアに問題が起こるのは、プロトコルに欠陥があるためではなく、ＡＯＬのプログラミングに問題があると考えられたからである。その時点で、インターネット上でウェブサーバを使用しているサイトの40％がＡｐａｃｈｅサーバを使用しており、1.2はそのうちのかなりの部分で使用されていた。そのために、ＡＯＬ側にとっては、次の二つの選択肢のどちらが簡単かを判断することが重要であった。つまり、彼らは、自分たちのプログラムの誤りを正すほうが簡単と結論づけるか、それとも、プロキシサーバ経由ではインターネット上の二割以上のウェブサイトにアクセスできないことをユーザに伝えるほうが簡単と結論づけるかのいずれかを早急に判断しなければならなかった。一九九六年十二月二十六日、我われは、自分たちのウェ
ブページに論争の詳細を掲載するとともに、こういう論争がＡＯＬとの間にあった事実を広く告知するために、
Ｃ／Ｎｅｔやワイアードなどの主要情報発信サイトに対してもことの一部始終を明らかにした。
　ＡＯＬがソフトウェアの修正を決定したのと同じころ、我われは、ＡＯＬの問題が解決するまでの当面の対応策として、その問題を回避したいというウェブサイトのために、「パッチ」が入手可能であることを公表した。このパッチとはつまり、ＡＯＬのために、ＨＴＴＰ／1.0での要請に1.0で応答させるようにするものであったが、我われの考えでは、あくまでも「非公式な」パッチとしてリリースするものであり、公式リリースにはデフォルトととして含ませない性格のものであった。
　似たような事例は、（ネットスケープ社とマイクロソフト社などを含む）ＨＴＴＰ製品のベンダーからも報告されているが、そのような場合、ベンダーは、努力して自分の側のプログラムのバグを取り除くか、そのバグのせいで不都合が発生する可能性のあるサイトへのアクセスを許さなくするかのどちらかを選択できる。たいていの場合、この問題は、ベンダーが、自分のクライアントとサーバにプロトコルを間違った形で実装したために発生している。しかも、自社のクライアントとサーバを対象にした実装では、一貫して間違って実装しているので、それらのマシン間のやりとりでは不具合が発生せず、他社のマシンとの間でやりとりしようとすると、突然おかしくなるという種類の問題であった。この種の問題は、ＡＯＬの問題よりもたちたちが悪い。なぜなら、この種のバグは、ユーザがその存在を関知したときには、すでに手遅れであることが多く、その長期的な悪影響（問題を倍加させる付加的なバグ）がどれだけのものになるかは、実際に問題が発生するまでわからないからである。

　このようなたちの悪い非互換性は、Ａｐａｃｈｅのように広く使われているオープンソースのウェブサーバがなければ、今回のように公表されず、個々のサイトにおける特異なケースとして処理され続ける類の問題である。そういう場合、よく使われるのがお互いに相手に責任をなすりつける方法である。「弊社のテストでは再現しませんので」といった言い訳で責任のがれをはかる方法もよく使われる。「Ｘ社のブラウザとＹ社のサーバを接続したら問題が起こりました」と説明すると、「それではＹ社のクライアントを使ってください。それでもう大丈夫です」という解決策が提案される。もし、こういう状況が実際に存続することになると、結局、世の中には、Ｘ社のウェブサーバで構築されたＷＷＷと、Ｙ社のサーバで構築されたＷＷＷという二つ（またはそれ以上）のＷＷＷが出現してしまう。そして、そのどちらのＷＷＷも、同じ会社製のサーバ／クライアントの組み合わせでなければ正しく動作しないのである。このような「囲い込み」には、標準から逸脱したプラットフォームにユーザを取り込んでしまう効果あるが、こういった技術的囲い込みはソフトウェアメーカーの多くが、基本的なビジネス慣行として、これまでの長きにわたって実践してきた行為である。
　もちろん、複数のＷＷＷが出現してしまうことはすべての第三者にとって不幸である。コンテントプロバイダ、サービスプロバイダ、ソフトウェアベンダーなど、ＨＴＴＰを使わなければならないすべての人が、その目的のために複数の異なるサーバを維持しなければならない。パワーユーザからは「うまく折り合いをつける」ことが求められる一方で、マーケティングの観点からは「技術革新、差別化、主導権の確立、プラットフォーム化」が求められる状況では、Ｘ社もＹ社も自社のプロトコルを商品の一部として提供する気にはなれないだろう。
　現に、我われは、Ｊａｖａスクリプト言語がそのような災難に巻きこまれるのを目のあたりにしてきた。Ｊａｖａスクリプトをライセンス供与された企業がそれぞれの仕様で言語を使用したため、Ｊａｖａスクリプトで作ったウェブページの動作は、ブラウザごとに大きく違っていた。同じ種類のブラウザでもベータ版によって動作が異なった。そのため、Ｊａｖａスクリプトを使っての開発では、Ｊａｖａスクリプトのバージョンを見極めたうえで分岐処理を実行させるようなコードを書かなければならず、そのぶん開発によけいな手間ひまがかかった。Ｊａｖａスクリプトを標準化する動きが本格化したのは、Ｗ３Ｃがドキュメントオブジェクトモデル（ＤＯＭ）の基礎固めをしてからのことである。
　現在のビジネスでは、クローズドな商用ソフトウェアによって仕様が実装されると、その仕様をユニークなものにしようとする力が自然と働くようになっている。そのような状況下では、共通の仕様がうっかり読み違えられた場合でも、すみやかに修正されなければ、読み違えられたままの形で仕様が定着してしまう危険性がある。
　つまり、私が言いたいのは、標準化されたプラットフォームの上に製品やサービスを構築すれば、ビジネスを安定的に展開できるということである。インターネットの成功は、共通のプラットフォームが情報交換を容易にすることを証明した。インターネットの成功によって、企業は、ネットワーク自体を売り物にするよりも、そこで情報交換されるものをどう売っていくかを考えるようになっている。


オープンソースプロジェクトの目標を分析する
　新しいプラットフォームの独占を考えている企業は、そうすることに決める前に、自社の製品がこの新しいプラットフォームをどこまで実装しているかをもう一度考え直してみる必要がある。そのようなプラットフォームを所有することが、自社の利益に本当につながるのかについて自問してみる必要がある。自社の製品とサービスの総体、つまり総収入が、そのプラットフォームにどれだけ依存しているのか、していないのかを、できれば数字ではじきだしてみる必要がある。
　たとえば、あなたのところがデータベース関連の会社で、マルチＯＳ対応のデータベースを販売しているとしよう。そして、それとは別に、グラフィカル管理ツールのパッケージ、アプリケーション速成開発ツール、ユーザが利用可能なライブラリなどを販売している。年間契約での有料サポートサービスも提供している。アップグレードは、最新版の購入によってのみ可能である。有料講習会も開催している。顧客のためにデータベース環境を構築するコンサルタント部隊も順調に成長しつつある。
　そして、あなたの会社の総収益の内訳は、次のようになっている。



　この状況下で、データベースソフトウェアの無料配布を提案するのは、収益の40％をふいにせよということなので、ばかげたアイデアそのものに聞こえるかもしれない。そんなことをすれば、運よく儲かっている会社の、ひょっとすると、総収益の20％ぐらいは儲かっている会社の利益が、まるまるふっとんでしまう。
　もちろん、この計算は、いままで有料だったソフトウェアが無料になるだけで、他は何も変わらないことを前提としている。しかし、この無料提供を上手に利用すれば、いろいろうまいビジネス展開が起こりうるのである。まず第一に、データベースは、（大手コンピュータ販売チェーン店の）ＣｏｍｐＵＳＡから買って、マシンにインストールし、それで終わりというような種類のアプリケーションではない。サポートも必要とされる。コンサルテーションも必要とされる。つまり、顧客は、あなたの会社の提供する各種サービスを必要としている。現に、いままで大金を支払っていたデータベースソフトウェアが無料になったことで、その他の関連サービスに対してもっと高い代価を請求することができるようになるのである。
　つまり、粗っぽい計算でいっても、データベースを無料にしたり安くしたりすることで、導入ベースが二倍になり、そして、顧客がコンサルティングやサポートや開発ツールやライブラリなどに以前と同様の関心を示せば、総収益は20％増えるのである。もっと現実的な予測では、新規ユーザ数はいままでの恐らく三倍から四倍に増えると思われる。その場合、新規ユーザがフリーバージョンの使用だけで満足するか、ライバル企業があなたの会社の製品向けサービスを開始するかのいずれかで、データベース以外のサービスの収益の上昇率は20％増とはいかないまでも、その上昇率がよほどひどくない限り、総収益は増えるはずなのである。
　さらに、適用するライセンスしだいでは、データベースの開発コストを低く抑えることもできる。たとえば、（オープンソースとしてライセンスすれば）顧客がバグを修正してくれるかもしれない。また、自分で拡張した機能のソースコードを、標準機能の一部として使えるように提供してくれるかもしれない。こうして総合的に見れば、あなたの会社の開発費は軽減される可能性がある。
　上記の例のように製品とサービスを組み合わせて提供すれば、データベースを無料で提供することによって、競合企業を利する危険性もほとんどない。いま現在でも、あなたの会社のツールを使ってシステム構築を請け負っているコンサルタントは存在する。あなたの会社のツールについて解説書を出版している人もすでにいる。ユーザの利用できるライブラリにしても、そういった類のものを作ることをいままで様々な会社にすすめてきているはずである。そういう状況がすでに存在することを考えると、ソースコードが入手可能になることで、競合企業がそれほど得をするとは考えられない。それよりも、あなたの会社が手にするであろう独自ブランドのネームバリューに対して、それらの企業は闘いを挑まなくてはならないのである。
　もちろん、いいことずくめというわけではない。ソフトウェアのオープンソース化にかかるコストには、収益に直接つながりにくいものもある。たとえば、このような活動を支えるには、ある程度のインフラを維持しなければならない。金額的には大した出費ではないかもしれないが、そのために、システム管理者やサポートスタッフの時間がとられてしまうかもしれない。開発チームが社外の人たちとやりとりするための通信費もかかる。オープンソース方式で開発できるようにソースコードを変更するのにも余分なコストがかかる。ソースコードを公開してチェックしてもらう準備にもお金がかかるかもしれない。そして、これだけ頑張ったあげく、あなたの製品をオープンソースソフトウェアとして提供するだけの「お呼びが市場からかからない」可能性もある。残りの紙面では、これらの問題について論じることにする。


自社の開発プロジェクトの「市場性」
　企業は、開発プロジェクトの救済を目的としてオープンソースの採用を検討するかもしれない。知名度を上げることを考えてそうするかもしれない。あるいは、ひとつの製品に有終の美を飾らせるためにそうするかもしれない。しかし、これらはいずれも、オープンソース方式を採用する理由としては適切でない。オープンソース方式の採用にあたっては、どのような製品であったらオープンソースとして成功するかを独自に調査し、その結果を厳密に検討しなければならない。
　第一段階は競合製品との比較において、自社製品の市場性を分析しなければならない。その市場規模がたとえどんなに小さいものであっても、市場調査をして、商用ソフトウェアでライバルはあるか？　フリーウェアでライバルはあるか？　といったことを調べる必要がある。その際、自社製品の市場性は、提供単位をコンポーネント化し、コンポーネントごとに個別販売する可能性、他製品とバンドルする可能性、オープンソース化する可能性について慎重に検討しなければならない。同様に、同一の機能性を有するフリーウェアとか商用ソフトウェアとの組み合わで提供するオプションも必ず検討しなければならない。
　今回も、あなたのところがデータベース関連の会社で、データベースを販売しているとしよう。あなたのところのデータベースは、ＳＱＬサーバ、バックアップおよびトランザクションのログなどを管理するモジュール、そして組み込み用ライブラリから構成されている。そのような場合、あなたは、自社製品をオラクルやサイベースのようなデータベースの大手と比較しなければならない。もちろん、大手ではないが成長株のソリッドやベロシスといったところとも比較しなければならない。そして、ＭｙＳＱＬやＰｏｓｔｇｒｅＳＱＬのようなフリーウェアのデータベースとも比較しなければならない。そうした分析の結果、あなたのところのＳＱＬサーバは、その機能性においてＭｙＳＱＬを少し上まわるだけであるということが明らかになるかもしれない。あるサーバ機能については、競争上利点になるようなものではなく、他のデータベースと伍していくのにやっとの仕様にすぎないことがわかるかもしれない。しかし、バックアップおよびトランザクションのログなどを管理するモジュールには、競争相手となるようなフリーウェアがまったく存在しないかもしれない。組み込み用ライブラリについては、ＰｅｒｌのＤＢＩユーティリティには大きくリードされているものの、ＪａｖａやＣの追随は許していない、という分析結果がでるかもしれない。
　その場合、あなたの会社は次のような戦略の展開を考えることができる。


戦略１
　ＳＱＬサーバをＭｙＳＱＬに切り替えたあと、サーバ部分とバックアップおよびトランザクションのログなどを管理するモジュールをパッケージ化し、Ｊａｖａ／Ｃライブラリと一緒に販売する。その一方、フリーのＰｅｒｌライブラリの配布とサポートを実施する。この戦略は、ＭｙＳＱＬパッケージの販売に勢いをつけながら、Ｊａｖａ／Ｃライブラリに含まれているアドオンコードやプラグインモジュールの利用を可能にする。これによって、あなたのところは、自社が特許を有するコードや、特許取得が可能と思われるコードを公開せずに済む。また、競争上非常に有利と思われるコードも公開せずに済む。この戦略においては、小規模用途から大規模用途のＭｙＳＱＬサーバを構築できる会社として売り込むことが推奨される。


戦略２
　自社製のＳＱＬサーバの優れた機能をオープンソース化し、ＭｙＳＱＬに解放する。そのうえで、バックアップおよびトランザクションのログなどを管理するモジュールを様々なデータベースに対応できるように拡張してから、単独製品として販売する−ＭｙＳＱＬとの組み合わせを推奨する。この戦略による収益は、戦略１より少ないが、これによって会社の製品ラインをより絞りこめる。また、顧客の裾野を広めることができる。このような製品はサポートも恐らく容易である。


戦略３
　戦略２とは正反対の方針、つまり、ＳＱＬサーバと組み込み用ライブラリは商用ソフトウェアとして販売しながら、バックアップおよびトランザクションのログなどを管理するモジュールを様々なデータベースに対応できるように拡張したうえで、それをオープンソース化する。これにより、この部分の開発コストを削減しながら、自社製データベースを市場に売り込むことができる。このオープンソース化によって、自社の競争力は多少そがれるが、一部の競合企業がオープンソース化で獲得できる競争力を未然にそぐこともできる。

　上記の１、２、そして３は、すべて妥当な戦略であるが、もうひとつ別の戦略を追加しておこう。


戦略４
　サーバ部分全体をオープンソース化し、ＭｙＳＱＬやＰｏｓｔｇｒｅＳＱＬなどとはまったく別のオープンソースサーバソフトウェアとして提供する。と、同時に、そのサーバのユーザサポートを有料で提供する。バックアップおよびトランザクションのログなどを管理するモジュールは、依然として商用パッケージ販売を継続するが、組み込み用ライブラリはオープンソース化して、新規ユーザの獲得をめざす。このような戦略は大きなリスクをともなう。というのも、ＭｙＳＱＬやＰｏｓｔｇｒｅＳＱＬのような人気パッケージは長く使われている場合が多く、既存のデータベースが正常に機能している限り、ユーザは別のものに交換したがらないからである。この戦略を効果的に推進するには、オープンソース化したコンポーネントが、現在市場に出回っているものより大幅に優れていることを証明する必要がある。ソフトウェアの処理速度が驚くほど速いとか、ソフトウェアに柔軟性があるとか、管理がしやすいとか、組み込みプログラムの利用が簡単であるとか、使ってみたいと思わせるような機能がふんだんに盛り込まれているとかの特徴がないと、この戦略は難しい。いろいろ努力し、より多くの人たちに自社の開発プロジェクトに関心を持ってもらうように仕向けなければならないだろうし、システムインテグレーターに競合製品を使わせないようにする方法も考えなければならないだろう。

　そして、この第四番目のアプローチは、現在想定している企業に推奨できるものではない。ＭｙＳＱＬは、オープンソースのデータベース市場ですでに他のデータベースを大きくリードしている。ＭｙＳＱＬ用のアドオンプログラムもたくさん存在する。ユーザも多い。この現状を考えると、それほど優れものでもない自社製のデータベースをいまさらオープンソース化するメリットはあまりない。したがって、私としては、この戦略を支持しない。
　オープンソースプロジェクトは、いろいろな理由で勢いがしぼんでしまうことがある。プロジェクトの中心となる人たちが意欲的でなくなってしまうかもしれない。開発しようとするソフトウェアの根幹部分に技術的問題があって、新たな要求に応えることができなくなるかもしれない。そのようなソフトウェアを必要とする状況がなくなってしまうかもしれない。そうなったとき、そして、人びとが選択肢を求めていることが明らかになったときには、現状よりもはるかに進んでいることが一目でわかるものでなくても、いずれ注目の的となるようなものに開発対象を切り替えていくオプションも選択肢としてはありうる。
　何が求められているかを分析することは非常に重要である。現に、オープンソースプロジェクトは、そういう要求に応える形で始まるのが一般的である。Ａｐａｃｈｅプロジェクトも最初はそのようにして始まった。ＮＣＳＡ（米イリノイ大学National Center for Supercomputing Applications）のウェブサーバのパッチを共有しあっていたウェブマスターたちがＡｐａｃｈｅプロジェクトを始めることにしたのは、野球選手カードをやりとりするようにパッチを頻繁にやりとりしていては効率が悪く、手違いも起こりやすいと思ったからである。その時点で、彼らは、ＮＣＳＡのウェブサーバに自分たちのパッチを組み込んで、別のサーバとして配布することにしたのである。Ａｐａｃｈｅを商用サーバとして販売するのが目的でこのプロジェクトに参加した人はいなかったが、それが目的であったとしても、それはそれで妥当な理由である。
　オープンソースプロジェクトの市場性を分析するひとつの方法は、関連メーリングリストやフォーラムに参加し、そこで交換される情報をチェックする方法である。様々なフォーラムのアーカイブを調べるのもいい方法である。自社の顧客やその知り合いから情報を収集する方法もある。このような努力をしたあとで、我われは初めて、プロジェクトに協力してくれる人がいるかどうかを現実に即して判断できる。
　Ａｐａｃｈｅプロジェクトの初期段階において我われの分析は次のようなものであった。当時、我われは、交換したパッチをすべてＮＣＳＡに送っていた。ＮＣＳＡが我われのパッチをウェブサーバに反映してくれることを期待していたからである。反映できないとしても、そういうパッチを我われから受け取ったことを告知してくれることを期待していた。しかし、ＮＣＳＡは、開発チームの主要メンバーをごっそりネットスケープ社に引き抜かれてしまい、我われからのメールに対処するどころではなかった。そこで我われは、優れたウェブサーバを新しく作るということより、自分たちの使っているＮＣＳＡサーバを自分たちで守っていくことにし、Ａｐａｃｈｅプロジェクトを開始したのである。オープンソースでは、達成しやすい目標に向かってプロジェクトを始めることが重要である。自分たちのプロジェクトがどれだけ有益なものであるかを把握できる前に、そのプロジェクトで市場を席巻できるかを考えるべきではない。


ソフトウェア全体における自社製品の位置づけ
　自社製品またはそのコンポーネントのオープンソース化を決定するには、それがどのような部類のソフトウェアであるかを明確に把握しなければならない。ソフトウェア全体における位置づけを把握する簡単な方法は、まず、「インフラストラクチャの部類」と「エンドユーザアプリケーションの部類」を左右に割り振る直線を上から下に一本引く。そして、その線の左側に、「インフラストラクチャの部類」に属するものを、上から列挙していく。つまり、フレームワークやプラットフォームを実装するソフトウェア、ＴＣＰ／ＩＰ、カーネル、ハードウェアなどを列挙する。中央の線の右側には、平均的なユーザが使うツール、アプリケーションといった「エンドユーザアプリケーションの部類」に属するものを列挙する。そのうえで、オープンソース化を考えている自社製ソフトウェアの特徴や機能が、ここに列挙されたものの一つひとつにどれれだけ該当するかを相対的にマークし、その結果をひとつの線で結んでみる。このようにしたとき、ＧＵＩのフロントエンドや管理ツールなどは、中央の直線の右端のほうにくることが多い。また、バックアップ管理のプログラムなどは左の端のほうにくることが多い。開発ライブラリはやや右より、ＳＱＬ関連のソフトウェアなどはやや左よりになる。自社製品の分類が済んだら、同じことを競合ソフトウェアに対しても実施する。その際、フリーウェアは色違いのペンで記入するようにすれば、商用ウェアと区別できて便利である。なお、このように分類すると、フリーウェアは左側に、商用ウェアは右側に集まる傾向があることがわかるはずである。
　オープンソースのソフトウェアが左側にかたよる理由をいくつか紹介しておこう。



　オープンソースのソフトウェアが、オペレーティングシステムとネットワークサービスの分野に多く見られる一方、デスクトップアプリケーションに少ないのはこのためである。
　確かにＧＩＭＰ（GNU Image Manipulation Program）などのように、オープンソースとして成功しているアプリケーションもあるので、すべてが前出の例にあてはまるわけではない。ＧＩＭＰは、その機能においてアドビ・フォトショップに匹敵するＸ対応のアプリケーションプログラムであるとも言える。しかし、その優れたプラグイン・ストラクチャのおかげで成功しているＧＩＭＰは、ある意味において「インフラストラクチャ」ツールであると言えるし、プラットフォームであるとも言える。ＧＩＭＰには、いままでに数多くのプラグインが開発されてきたおかげで成功している面もある。そのおかげで、数百ものフィルター効果を実装でき、多様なファイルフォーマットをインポートおよびエクスポートできる。
　さて、自社製品と競合製品の位置づけが済んだら、用紙に描きだされた分析結果をもとに、直線を上下に真直ぐ引いて、オープンソース化する部分としない部分を用紙上で分割する。つまり、この直線こそ、オープンソース化することであなたが標準化しようとしているソースコードの部分と、非公開のままにしながら需要を喚起しようとしているソースコードの部分の境目であり、両者のインターフェイスであり、本当の意味で、あなたの会社の製品のプラットフォームにあたる部分なのである。


隙間が狙い目か？
　ある分野が、複数の商用ソフトウェアがちょうどカバーしえない分野であって、本来、オープンソースがインフラたりうる分野であれば、そういった隙間部分の存在そのものが、オープンソース化をうながす強力な動機づけとなる。二つの有力なオープンソースソフトウェアが商用ソフトウェアによって間をとりもたれているような場合に、オープンソースソフトウェアを開発して、中間部分の商用ソフトウェアにとって代わるものを提供しようとするのもまた自然な考えである。資金と時間が十分あれば、乗り越えられない隙間はない。あなたの会社の開発チームでも克服できそうな隙間は、やる気さえあれば、どこの開発チームでも克服できる。
　今回も、あなたの会社がデータベースを販売していると想定し、ＳＱＬサーバをオープンソース化するか、優れた機能部分をＭｙＳＱＬに公開するかに決定したとしよう。そのうえで、データベースとウェブサーバを動的に連携させる商用ドライバを開発して儲けることにしたとする。その場合、あなたの会社は、データベースでは一銭も稼げないので、ドライバのマージンを通常よりも高く設定することになる。
　データベースとウェブサーバを連携させるのは非常に一般的かつ望ましいことなので、システムインテグレーターはあなたの会社のドライバを使用するか、別の方法を探さなければならない。そういう状況においては、あなたの会社に支払う代金を節約できることが動機づけとなって、あなたのところに頼らなくて済む方法を模索しようとする企業が少なからず出てくる。そして、十分な数の技術者が協力しあって、解決策を編み出すことは考えられる。あるいは、優秀なプログラマが、お金がなくて購入できないドライバ部分を自分で作ってしまうことも考えられる。このようなオープンソースの出現によって、あなたの会社の商用ドライバは、データベースとウェブサーバを連携させるための唯一のソリューションというマーケティング上有利な立場を、一夜にして失ってしまう。
　つまり、あなたのデータベース販売会社の場合、システム構築のキーになる部分を商用ソフトウェアで戦略的におさえて、そのうえでビジネス展開をはかるのは危険なのである。あなたの会社がこの種の危険を回避するには、技術サポートサービスを有料で提供して、ウェブサーバ＋プラグイン＋データベースの組み合わせを支援したり、このデータベースシステム全体を制御するインターフェイスを提供することで稼ぐようにすべきなのである。
　ただし、すべての商用ソフトウェアがこれほど脆弱なわけではない。この種の危険に遭遇しやすいのは、確立した二つのオープンソースの隙間にじかに割りこもうとする商用ソフトウェアである。もし自社製品を商用ソフトウェアとして提供するのであれば、オープンソースのソフトウェアのアドオンとして売るのがより手堅い戦略で
ある。


オープンソースの開発プロジェクトに参加すべきか？
　オープンソースソフトウェアは、いろいろな分野をカバーしている。とりわけ多いのはサーバ側に焦点をあてた次のようなものである−オペレーティングシステム関連、ウェブサーバ関連、電子メール（ＳＭＴＰ、ＰＯＰ、ＩＭＡＰ）関連、ネットニュース（ＮＮＴＰ）関連、ＤＮＳサーバ関連、プログラム言語関連、データベース関連、そしてネットワーク関連のソフトウェア。デスクトップに焦点をあてたものには次のようなものがある−テキストエディタ（Ｅｍａｃｓ、Ｎｅｄｉｔ、Ｊｏｖｅなど）、ＧＮＯＭＥやＫＤＥのような統合デスクトップ環境構築ツール、Ｍｏｚｉｌｌａのようなウェブブラウザ、スクリーンセーバー、電卓プログラム、小切手帳プログラム、ＰＩＭ、メールクライアント、イメージツール等々。すべての分野において、オープンソースがＡｐａｃｈｅやＢＩＮＤのように突出しているわけではない。しかし、商用ソフトウェアの代替物とならないオープンソースが存在しない分野は恐らくないであろう。とはいえ、Ｗｉｎ32のプラットフォーム上には、ＵＮＩＸやＭａｃほどオープンソースが進出していない。オープンソースの文化は、Ｗｉｎ32を、信頼するに足るほど「オープン」なプラットフォームとして受け入れてきていない。
　あるオープンソースパッケージが時流に乗っている場合、それと同じ分野に属する自社製品をオープンソース化する形で、その流れに便乗する戦略も十分考えられる。そうすることで、自社のソースコードを貢献する見返りに、総合的なソースコードの受け取りを期待できる。マーケティングの面で先頭集団に加わることも期待できる。共通のプラットフォームの確立も期待できる。このような戦略が自分の会社に向いているかを判断する際には、下記の諸側面を考慮する必要がある。



　オープンソース方式の開発においては、実際に開発にあたる人たちの協力をいかに仰げるが成功の鍵をにぎっている。彼らの協力は、技術や金でどうこうできるものではない。この方式においては、開発者の一人ひとりがプロジェクトへの自分の貢献度を実感できなくてはならない。自分の関心事に他のメンバーも注意を払ってくれていると感じられることも重要である。アーキテクチャや設計上の問題に関する自分の意見が聞き届けられ、尊重されていると感じられることも重要である。また、個々の開発者の作成するコードがちゃんと利用されることが重要である。利用されない場合には、なぜ利用されないかの理由がちゃんと説明されることが重要である。
「オープンソース方式の開発が成り立つのは、インターネット上のすべてのユーザが開発部隊やＱＡ部隊になるからだ」という意見があるが、これは間違っている。優秀なプログラマたちがいても、彼らの時間を一定の仕事のために無限に使えるわけではない。したがって、一般的に考えて、関係者の間で意見の相違がありそうなところは同時並行的に開発しないほうが得策である。その反面、優秀なプログラマが十分確保できる場合には、同じ部分について複数のアプローチを試みることができたほうが、技術的進展は早い。ひとつのアプローチで試されなかったものが、別のアプローチで試してみると、革新的なアイデアであったりすることはよくある。
　たとえば、最近では、ＳＭＴＰサーバの分野がいくつかのオープンソースが競合するようになったことで技術的に進展している。この分野においては、長い間、エリック・アルマン（Eric Allman）の「sendmail」プログラムが標準的なＳＭＴＰデーモンであった。SmailやZmailerなどもオープンソースとして登場し、sendmailに対抗しようとしたが、最初にsendmailの独占状態にストップをかけたのはダン・バーンスタイン（Dan Bernstein）の開発したqmailである。qmailが登場したとき、sendmailは誕生から二○年をへて古さを感じさせるようになっていた。九○年代末のインターネット用には設計されていなかったため、受信バッファのオーバーフローがしばしば問題になっていた。不正なアタック（使用不能攻撃）が原因のサービス停止も問題になっていた。qmailは、プログラムの設計や管理など、多くの点で画期的だっただけでなく、「ネットワークに対応したＳＭＴＰサーバとは何か」を定義するうえでも画期的であった。アルマンのsendmailプロジェクトからはqmailのようなものは誕生しなかったであろう。彼らが優秀なプログラマでなかったので、qmailのようなものを開発できなかったと言っているわけではない。意欲的な協力者がいなかったので、開発できなかったと言っているわけでもない。ただ、時と場合によっては、現状から決別しないと、新しいことをうまく試せないのである。ちなみに、ＩＢＭが、ウェイスト・ベネマの「Securemailer」のＳＭＴＰデーモンの開発に資金を供給したのも、まったく同じ理由からである。Securemailerも、この文章を書いている今の感じでは、かなり普及しそうである。ＳＭＴＰデーモンの分野は、技術的に何をすべきかがはっきりしているうえに重要度が高いため、多様なオープンソースプロジェクトをサポートすることができる。そして、どのプロジェクトが生きのびるかは、時のみが解決するのである。


プロジェクトを開始するのに十分な人材はいるのか？
　オープンソースは、新しい課題に挑戦し技術的に進化してくようでないと、開発プロジェクトとして順調に展開するのは難しい。ソフトウェアは、作ってしまって、それでおしまいというものではない。主要コンポーネントは、継続的なメンテナンスが必要とされる。機能も拡張し、向上させていかなければならない。オープンソース方式の大きなセールスポイントは、ひとつのグループがすべてを開発しなくて済むことである。逆に言えば、いろいろな人たちに積極的に参加してもらわない限り、この方式は理屈どおりに働かない。
　自社製品をオープンソース化するには、そのようなプロジェクトに対する関心の度合を調べなければならないが、そういう調査をする過程で、あなたのところのプロジェクトに興味や関心を示す企業に出くわすかもしれない。個人的に興味のある人に出会うこともあるだろう。どのような戦略でオープンソース化をはかるかを決定したら、まず、そういう企業や個人に情報を流して、オープンソースのプロジェクトを開始する予定であることを知らせるべきである。とりあえずの方法としては、メーリングリストを使って、簡単な話し合いを始めるアイデアがある。そういう努力をすれば、いろいろな企業や個人が貢献してくれる可能性が高い。プロジェクトを成功させる方法について何か重要なアイデアを出してくれるかもしれない。自分たちがどんなことで協力できるかをリストアップしてくれるかもしれない。
　きわめて簡単なプロジェクトであれば、協力してくれる企業や個人に頼んで、自分のところの製品をまず試してもらう。そして、その製品のオープンソース化に賛同してもらえる企業や個人から、開発プロジェクトのメーリングリストのメンバーとして参加する旨の確約を取り付けることができれば、スタート時点としては準備ＯＫである。しかし、もっと複雑なプロジェクトをオープンソース方式で開始したいのであれば、どれだけの人的資源が開発に投入可能なのかを見極める必要がある。
　ちょっと複雑なオープンソースプロジェクトとして、ウェブショッピングを可能にするプラグインモジュール（common shopping cart plug-in）の開発が考えられる。簡単なプロトコルを実装したネットワークデーモンを開発するのもちょっと複雑な部類に入る。そのようなプロジェクトを推進するのに最低限必要と思われる人的資源を、彼らに求められる役割と技術ごとに記述すると、次の五つに分類される。


　ここにあげた五つの役割は、だいたい常勤者三人分の仕事に相当する。実際のところ、これらの役割の中には、複数の人間が並行的に兼任できるものもある。プロジェクトの種類によっては、初期リリースの最初の山を越せば、中心メンバーの誰かが週平均五時間ほど貢献できれば十分なものもある。しかし、開始直後の段階で重要なのは、開発者たちが時間的余裕と目的意識を持てることである。彼らが、会社の正規の開発業務に従事しているかの意識をもって、設計やプログラミングにあたれることが重要である。
　これら五つの役割は、メンテナンスの部類に属するものであり、開発の実働部隊の仕事とは別ものである。したがって、（新しい人材が集まらないと）これらのメンテナンスに充当する人材と、開発の実働部隊に充当する人材を確保できない場合は、オープンソース方式での開発は再考したほうがいい。


どのようなライセンス形態を適用するか？
　プロジェクトにどんなライセンス形態を適用するかは、簡単に決められるものではない。この種の決定は、恐らく、あなたの会社の法律チームが担当することになるだろう。著作権の問題を詳しく扱っている文献やウェブサイトはほかにもたくさんあるので、本章では、ビジネス的観点からそれぞれのライセンスを概括的に考察することにする。
ＢＳＤ方式のライセンス
　このライセンス形態は、Ａｐａｃｈｅや、（Ｆｒｅｅ ＢＳＤ、ＯｐｅｎＢＳＤ、ＮｅｔＢＳＤなどの）ＢＳＤベースのＯＳプロジェクトで適用されている。かいつまんで言うと、「このソースコードは、自由にお使いいただいてかまいません。ただし、それを商用販売しようとする場合は、著作権表示の告知をして下さい」ということになる。通常の場合、著作権表示は、広告、ＲＥＡＤＭＥファイル、印刷物への掲載などの形で要求される。このような著作権表示については、数が多くなると実施しにくいと考える人たちもいる。彼らは、四十種類のＢＳＤベースのオープンソースモジュールを含む商用ソフトウェアが、四十の著作権表示をするのが大変だと考えているようだが、現実的には、数の多さがこれまで問題になったことはない。それどころか、このような著作権表示には、オープンソースソフトウェアが使われているという意識を一般に浸透させる効果があると考えられる。
　ビジネスの観点からすると、ＢＳＤ方式のライセンスは、今後の使用・再配布の許可や制限について心配する必要がないため、既存のプロジェクトに参加する形でオープンソース化を推進する場合にはうってつけの選択である。あなたは、この種のオープンソースソフトウェアに（自社が知的所有権を持つ）コードを組み合わせて使うことができる。プロジェクトのためになる−したがって自分のためになる−と思うコード以外は提供しない選択も可能である。我われのＡｐａｃｈｅグループもこのライセンスを適用したが、それは、多くのフリーソフトウェアプロジェクトと違って、Ａｐａｃｈｅプロジェクトを開始した人たちが主として、商用ウェブサイトのウェブマスターたちであったからである。もっとよいウェブサーバを希求していた我われは、Ａｐａｃｈｅサーバの開発に目標をおいており、Ａｐａｃｈｅ上で商用サーバを開発することは考えていなかった。しかし、先のことは誰にもわからず、最初から選択肢をせばめるのは得策ではないと考え、ＢＳＤ方式のライセンスを適用したのである。
　このタイプのライセンスは、プロトコルなどを参照実装するソフトウェアに対して適用するのに都合がよい。我われがＡｐａｃｈｅにそれを適用したのもそのためである。Ａｐａｃｈｅグループのメンバーの多くは、ＨＴＴＰプロトコルを存続させて、真のオープン標準（multiple standard）にすることを望んでいた。そのためには、マイクロソフト社やネットスケープ社が我われのＨＴＴＰエンジンやその他の部分のコードを彼らの商用製品に組み込むこともいとわなかった。我われは、ＨＴＴＰの普及にはずみがつくのなら、そうなることを嫌ってもいな
かった。
　ＢＳＤ方式のライセンスは、非常に寛大である。しかし、そこまで寛大になるには様々なリスクを負わなければならない。このライセンスは、自分で独自に機能拡張した部分のソースコードを、元のプロジェクトに還元させるようには書かれていない。そして、Ａｐａｃｈｅにおいても、複数の企業が独自に派生的な技術を開発し、中にはプロジェクトに提供してほしいようなものもあったが、実際には提供されていない。とはいえ、もし独自に機能拡張した部分を還元するようにライセンスで義務づけられていれば、それらの企業がそのような技術の開発に着手するようなこともなかったかもしれない。
　つまり、戦略的に言えば、この種のライセンスが適用されるプロジェクトでは、十分な勢いを維持しながら開発作業を進めていく必要がある。参加メンバーが、（知的所有権を有する部分を含む）自社のコードを提供することで、プロジェクトがより大きな価値を生み出せると思えなければならない。これはなかなか難しい問題である。特に、厄介なのは、参加企業が、コーディングの量を大幅に増やすことにしたときである。その企業が、それだけ貢献する見返りはあるのだろうかと考え始めたりすると、「うちはどの参加者よりも貢献しているのに、なぜそれを共有しなければならないのか」ということになる。もちろん、そのような企業は、第三者の協力をとりつけて自身の技術的な目標を効率的に達成する最善の方法を見出せずにいるので、そう考えたりするのだが、この問題を解決する特効薬はいまのところ存在しない。


Ｍｏｚｉｌｌａパブリックライセンス（Mozilla Public License−ＭＰＬ）
　ＭＰＬは、ネットスケープ社のＭｏｚｉｌｌａチームが自分たちの（ウェブブラウザ開発）プロジェクトをオープンソース方式で推進するために作成した。ＭＰＬは、数年ぶりに公表された新しいライセンス形態であり、ＢＳＤやＧＮＵライセンス形態では扱われていない、いくつかの重要な問題について言及している。形態的にはＢＳＤ方式のライセンスに近いが、それとも二つの点で大きく違っている。
　ＭＰＬでは、ＭＰＬのライセンスのもとに配布されたソフトウェアを修正・変更した場合、その部分はフリーで公開されなければならない。そのため、オリジナルへの変更は、オリジナルの開発プロジェクトに還元されるようになっている。ＭＰＬでは、オリジナルをソースコードとして配布されたファイルと規定している。これは重要である。なぜなら、この規定によって、企業は、商用ライブラリへのインターフェイスを作成しても、インターフェイス部分をＭＰＬするだけで済むからである。ＭＰＬライセンスは、オープンソースのソフトウェアを他の商用ソフトウェアに含ませやすい形で提供できる。
　ＭＰＬにはいくつかの条項があり、プロジェクト全体と開発者の双方を、提供ソースコードの特許にかかわる問題から保護している。ＭＰＬでは、企業や個人がソースコードをプロジェクトに提供する場合には、そのソースコードによって将来発生するであろう特許権に対する主張を放棄することになっている。
　上記の条項はきわめて重要であるが、これを書いている今の時点では、大きな問題を含んでいる。
　特許の問題に気を配るのは「非常によいこと」である。何食わぬ顔でコードをプロジェクトに提供した企業が、そのコードが完全に実装されたとたんに特許使用料を請求しようとする危険性は常に存在する。このようなビジネス戦略は失笑ものの下手なＰＲで見苦しい限りだが、残念ながら、そう思っていない企業もある。この条項は、そのような企業からプロジェクトを保護している。すでに特許されているとわかっているコードを、他人に迷惑をかけるだけの目的で、不正に提供することを防止している。
　もちろん、特許権の問題は、第三者が特許権を所有するコードを、「他の」誰かが勝手に提供してしまった場合にも発生し得る。そして、上記の条項は、この可能性を封じることに有効ではない。この種の問題からプロジェクトや個人を保護する法律もいまのところ存在しない。私は、これこそ米国特許商標庁（U.S. Patent and Trade Office）が担当するのにふさわしい仕事と考えている。彼らには、様々なアイデアやアルゴリズムを、誰かが所有する財産として宣言する権限があるように思える。そこで、それとは逆に、私が提供したコードを「特許権なし（patent-free）」と見なして、特許権訴訟から私を保護してくれるようにできないものだろうか。

　しかし、すでに述べたとおり、一九九八年十二月現在のＭＰＬには欠陥がある。そもそも、第二条第二項では、コードの提供者は自分が提供したコードだけでなく、Ｍｏｚｉｌｌａのどの部分についても特許権を主張してはならないとされている。ひょっとして、これは欠陥ではないのかもしれない。多くの大企業が権利放棄したパッケージを入手できるのはおいしい話だ。
　残念ながら、所有する特許権の数では世界屈指を誇る某大企業は、ＭＰＬの第二条第二項に関してかなり特殊な問題をかかえている。それは、彼らがいずれＭｏｚｉｌｌａから特許権使用料をとってやろうと思っているからではない（それは無謀というものである）。彼らが懸念しているのは、自分たちが特許を持っているプロセスがあって、そこから毎年莫大な収益があがっている部分のコードがＭｏｚｉｌｌａの中に実装されているからである。つまり、彼らがＭｏｚｉｌｌａに対する特許請求権を放棄すれば、彼らに特許使用料を払っている企業は、同じコードが実装されているＭｏｚｉｌｌａからコードを取り出して、自社製品に組み込めるようになる。そうすれば、特許使用料を払わなくて済むのである。第二条第二項の適用が、ブラウザ全体を対象とするのでなく、提供されたコード部分だけを対象とするよう書き換えられれば、ここで取り上げた企業にとっても特許権の放棄は問題とならない。
　この予想外の欠陥を別にすれば、ＭＰＬは非常に堅実なライセンスである。変更部分のソースコードを「コア」に戻さなければならないということは、きわめて重要なバグの修正や移植性の向上がプロジェクトに反映されることを意味している。その一方、付加価値的な機能は商用ソフトウェアとして開発できることを意味している。ＭＰＬは、エンドユーザ向けのアプリケーション開発には最適のライセンスかもしれない。この分野は、他の分野に比べて、特許権の問題がもとで開発プロジェクトが分裂する可能性が高いからである。対照的に、ＢＳＤ方式のライセンスは、オペレーティングシステムやウェブサーバといった、「バックエンドの部分」やライブラリ的な機能を開発しようとするオープンソース方式のプロジェクトにより向いていると言える。


ＧＮＵ一般公的使用許諾（GNU General Public License−ＧＰＬ）
　ＧＰＬは、ビジネスに好都合なライセンスでない。しかし、信じる信じないは別として、営利を追究するうえで魅力的な側面を持っている。
　基本的に、ＧＰＬは、ＧＰＬでライセンスされたソフトウェアに加えられた機能拡張、それに基づいて作成されたプログラム、また、その一部を使用して作成されたプログラムを、元のソフトウェアから派生したプログラムと見なし、そのソースコードをＧＰＬでライセンスすることを義務づけている。この「ＧＰＬの伝播性」を、オープンソース支持派は、フリーとして登場するコードをいつまでもフリーにしておく手段であると唱えてきた。ＧＰＬのソフトウェアから商用版を開発させなくするための手段として広く主張してきた。自身のソフトウェアにＧＰＬを適用する人びとにしてみれば、機能拡張された部分のソースコードが元のように自由に使えないくらいなら、機能拡張されないほうがずっとましなのである。確かにＧＰＬにはアカデミックな魅力がある。たとえば、あのＬｉｎｕｘにしても、ＧＰＬでリリースされていなければ、営利目的で利用したいという誘惑が強くなりすぎ、開発グループがばらばらに分裂してしまって、ここまで大きく成長しなかっただろうという意見もある。
　つまり、一見したところでは、ＧＰＬはオープンソースソフトウェアを商用目的で開発しようという目論みとはうまく折り合わないように思える。既存のソフトウェアに価値を付加して稼ぐという従来の方式が、ＧＰＬのもとで成り立たないのは確かである。しかし、ＧＰＬは、新しいプラットフォームを最初に確立して、同じ土俵で張り合おうという競争心をそいでしまうには効果的である。これによってあなたの会社は、このプラットフォーム対応の製品とサービスの「最初の」提供者という名誉ある地位を手にすることができる。
　そのよい例がシグナスソリューションズ社である。同社は、毎年かなりの数、多種多様なハードウェアにＧＣＣを移植している。移植コードの保守もしている。同社は、移植や保守作業の過程で発生したコードをすべてＧＰＬしているので、新しく作成されたコードはＧＣＣプロジェクトに還元され、誰でも自由に無料で入手できるようになっている。シグナスソリューションズ社は、移植作業とメンテナンス作業に必要な労力に対して支払いを請求する。しかし、コードそのものに対しては何も請求しない。この分野における経験とリーダーシップによって、同社は、この種のサービスを目指す企業の手本となっている。
　仮に、ライバル企業が出現してシグナスソリューションズ社に対抗するとしたら、その企業もＧＰＬに基づいてコードを配布しなければならない。つまり、ライバルが、ＧＣＣを利用を利用してシグナスソリューションズ社に対抗するためには、自社の開発した技術をシグナスソリューションズ社にも利用させる必要があるということである。シグナスソリューションズ社のライバル企業は、膨大な金とエネルギーを投入してＧＣＣ以外のプラットフォームを開発しない限り、技術開発の面でシグナスソリューションズ社と自社を差別化できない。
　ＧＰＬは、商用目的での使用者からは料金を徴収したいが、技術的なバージョンはオープンソースにしたいというような場合に、ビジネス的に利用可能なライセンスである。あなたの会社は、ＧＰＬのライセンスポリシーにそって配布される技術的なバージョンとは別に、商用バージョンを有償で提供できるのである。たとえば、あなたの会社が、インターネット上でＴＣＰ／ＩＰ接続を暗号化するプログラムを所有しているとする。あなたは、それが非営利目的で使われるか営利目的で使われるかということには関心がない。あなたの関心は、営利目的でそれを製品に埋め込んだり再配布したりする企業や個人に対して、使用料を請求する権利を確保しておくことにある。あなたがそのプログラムにＧＰＬを適用すれば、商用利用を計画しているユーザは、自分たちの製品にもＧＰＬを適用しなければならない。そうしなければ、あなたのプログラムを自由に使うことができない。しかし、自分たちの製品にＧＰＬを適用することは、商用デベロッパーが普通したがらないことである。そのような場合、ＧＰＬでないバージョンを残しておけば、そのソースコードを営利目的で自由にライセンスすることができる。ただし、この方法が効果的に機能するためには、第三者から提供されたコードも、この商用バージョンに必ず含むことができるようになっていなければならない。これを確実にする方法のひとつは、このソフトウェアのためにコードを書くのはあなた（またはあなたに雇われている従業員）だけであると断言してしまう方法である。もうひとつの方法は、オープンソースの開発プロジェクトに参加しているすべてのメンバーから、彼らのコードを商用バージョンに含めてもいいという承諾を得ておくことである。
　これをビジネスモデルとして実行している企業もある。たとえば、カリフォルニア州バークレーにあるトランスバーチャル社は、このモデルを採用して、Ｊａｖａ仮想マシンや完全なクラスライブラリを含む商用バージョンのＪａｖａ開発キット簡易版を開発している。このような開発モデルに対しては、プロジェクト参加者の多くから反感を買いやすいとか、ＧＰＬバージョンと商用バージョンが別々のコードを持つようになってしまう危険性があると指摘する人たちもいる。しかし、プロジェクト参加者を公正に扱い、彼らの努力と貢献に対して金銭などでの見返りを申し出れば、このモデルは機能し、（結局、増収につながる）というのが私の意見である。
　オープンソースライセンスの形態は、これからの数年間で、機能する内容とそうでないものをはっきりさせながら、よりよき方向へ変化していくことは間違いない。実際のところ、あなたは、ＢＳＤ方式とＧＰＬのライセンスポリシーの間で、自分の設けたい条件を盛り込んだライセンスを自由に作ることができる。そして、自分独自のライセンスポリシーを作成する人は、利用者に対する自由を認めれば認めるほど、あなたに協力して役に立ちたいという彼らの気持ちもそれだけ強くなるということ覚えておくべきである。


オープンソースプロジェクトで利用可能なツール
　Ａｐａｃｈｅプロジェクトでは、分散型の開発をうまく機能させるために、一連の有益なツールが使われている。
　中でも特に重要なのは、バージョン管理システムＣＶＳ（Concurrent Versioning System）である。ＣＶＳは、分散環境でのプログラム開発においてソースコードのバージョンを管理するツールで、プログラムの追加・変更部分を名前と日付で管理するデータベースにより成り立っている。ＣＶＳは、同じプログラムの開発を共同で担当している人たちが、お互いに他の人の担当している領分を犯したり、邪魔したりすることなく、全員一緒にそのプログラムの「著者」になれる点で非常に優れている。バグフィックスの際も、追加・変更部分を一つずつチェックし、どの時点でバグが入り込んだかを正確に調べることができるので、デバッグ作業を効率的に進めるうえでも有効である。クライアント版は、主要なプラットフォームについては、対応バージョンが存在する。ダイヤルアップ回線や長距離電話の接続でもうまく機能する。また、ＳＳＨを使っての暗号化接続でも動作することが保証されている。
　ソフトウェアの管理以外にも、Ａｐａｃｈｅプロジェクトでは、ＣＶＳを使って「ステータス」ファイルなどを管理している。これらの「ステータス」ファイルには、Ａｐａｃｈｅプロジェクトに関する主要な未解決問題が、それぞれについての注釈、意見、はては投票結果つきで記録してある。我われは、Ａｐａｃｈｅグループとして物事を決定するさいの票決の結果もＣＶＳで管理している。ウェブサイトに掲載するドキュメント、開発関連のドキュメントなども管理している。要するに、我われは、Ａｐａｃｈｅプロジェクト用の情報管理ツールとしてＣＶＳを使っている。この種のツールのほとんどは高価なうえに多機能なので、ＣＶＳの単純さは欠点のように見えるかもしれないが、実は、単純さこそがＣＶＳの最大の長所なのである。そして、ＣＶＳは、サーバ版もクライアント版もすべてフリーである。
　オープンソースプロジェクトに欠かせないもうひとつの要素は、メーリングリストを充実させることである。ここでどのようなソフトウェアを使ってメーリングリストのフォーラムを運用するかはあまり重要ではない（我われはmajordomoを使っているが、ezmlmでもSmartlistでも、フォーラムを運用できるものであればなんでもよい）。重要なのは、開発作業ごとに専用のフォーラムを開設して、プロジェクト参加者が自分に興味のあるものを自由に選んで無理なく開発を続けられるようにすることである。また、開発作業ごとに独立した電子メールの宛先リストを作成して、ＣＶＳサーバが新たな修正箇所をメールできるようにしておけば、受け身的ではあるが、より多くのレビューを喚起することにもつながり、ソースコードの内容の維持やバグの発見にも役立つ。実際に開発を担当している人たちと、ソフトウェアを利用している人たちのフォーラムを別々に設けるのもよいアイデアである。また、プロジェクトの規模が大きい場合には、開発の中心メンバーのためのフォーラムと、メンバー全員のためのフォーラムを別々に設けるのもよいアイデアである。最後に、新しいユーザが、特定の問題が過去に取り上げられているかを調べたり、過去にどんな取り組みがなされたかを調べられるように、フォーラムで交されたやりとりのアーカイブを公開することも重要である。
　問題点やバグを常に把握しておくことも、プロジェクトの順調な運営に欠かせない。Ａｐａｃｈｅプロジェクトでは、いままでに寄せられた三千件以上のバグレポートをＧＮＡＴＳ（バグレポート管理システム）を使って効果的に管理している。あなたに必要な管理ツールは、バグレポートへの応対が複数の人間でできるようするものでなければならない。バグレポートの対象を特定のコンポーネントに限定できるツールでなければならない。バグレポートのやりとりをウェブのフォーム形式だけでなくメールででもできるようにするものでなければならない。バグデータベースの最優先課題は、できるだけ簡単かつ自動的にバグレポートに対応できるものである（プロジェクトの開発メンバーとって、これは退屈な仕事であることが多い）。また、特定のバグがすでに報告されているかどうかを調べられるシステムでなければならない。要するに、あなたのバグデータベースは、プロジェクトの現状と将来性に関する情報の宝庫となるものである。リポートされてきた現象が、本当は機能であってバグではないのはなぜか。指摘された問題点は、誰かがすでに取り組んでいるものなのか。優れたバグデータベースは、これらについて答えられるものでなくてはならない。
　オープンソースの開発方式は、特効薬ではない。したがって、すべてのソフトウェアの開発を成功に導けるわけではない。オープンソースのプロジェクトを進めるには、それにふさわしい条件が整っていなければならない。それ自体が生命を持つような勝算のあるプロジェクトに着手するには多大な労力が必要とされる。オープンソースのプロジェクトを提案する人は、いろいろな面で少しだけフランケンシュタイン博士を見習い、こちらで薬品を調合したり、あちらで電圧をかけたりしながら、モンスターに生命を与える必要がある。成功を祈る。