Javaとオープンソース
Javaのオープンソース化に関する最近の議論では、プログラミング言語特有のある事実が見落とされている。すなわち、多くの場合、言語そのものがオープンソースであるか否かよりも、その言語で書かれたオープンソースのコードのほうが重要であるということだ。そこで本稿では、Java言語についての疑問はさておいて、数あるテクノロジ企業が、Javaで行われている大量のオープンソース・プログラミングとどのように付き合っているかを見ていきたい。
無料であるおかげで、Comprehensive Perl Archive Network（CPAN：参考資料2を参照）の4000人もの作者の手による、7000を超えるモジュールが作成される結果となった。また、SourceForge.net（参考資料3を参照）に5000以上のPerlプロジェクトが作成されているのも、この点によるものだ。
しかし、だからといってPerlがSourceForge.netのプロジェクトで最もよく利用されている言語かといえば、決してそんなことはない。CとC++は、それぞれ1万3000以上のプロジェクトがあるし、Javaが僅差で3位（1万3066プロジェクト）となっている。
プログラミング言語をビジネスにする
Javaは、「オープンソースである」という条件以外はすべて満たしている。無料で入手でき、プロプライエタリとオープンソースの両方において、Javaベース・ソフトウェアという巨大かつ重要な世界を構築した。オープンソースに関連したビジネス・パラドックスの主なものは、Javaにとっても無縁ではない。Sunやその他の企業は、無料で配布されているものからどのように収入を得ることができるだろうか。Bill Gatesがオープン・レターで投げかけた問いに、30年近く経った今も、答えは出ていない。
再配布自由の製品は、3つの異なるビジネスモデルを生む。
市場の成長
製品を無料で配布することは、消費を促進する。その製品の消費が拡大すれば、製品の市場の規模が拡大するだけでなく、その製品に関連するすべての製品とサービスの市場が拡大される。Linuxは無料で入手可能であることによりOS市場においてシェアを伸ばし、その結果、Linux関連の製品やサービスの市場規模も拡大した。これにより、たとえばIBMのような企業は、Linuxを宣伝して、Linuxを走らせているハードウェアの市場を拡大すれば、収入を伸ばすことができる。また、Linuxを宣伝して、IBM Global Servicesで提供しているLinuxの専門知識へのニーズを高めれば、サービスからの収入も期待できる。
Javaのユビキタス化を推進しようとするSunの試みも、同様の動機によるものだ。Sunの収入源は、当初はSunハードウェアであった。Javaの「write once, run anywhere（一度書けば、どこでも動く）」哲学を広めることで、エンベデッド・システムのような新しいハードウェア市場にJavaを浸透させ、Javaの専門知識を元にこれらの新しい市場でビジネスを拡大するのが狙いである。
しかし、「Write once, run anywhere」は諸刃の剣である。Javaが問題なく動作できるのは、Intel互換のx86プラットフォーム・ファミリである。つまり、x86でJavaをサポートするプラットフォームを提供することは、Sunの核である、SPARCベースのビジネスに真っ向から対立することになる。BEAをはじめとして、このとおりのビジネス戦略を採用している企業もある。
さらに、Sunと同じ（つまり、競合する）戦略をとっている企業もある。Sunの当初の思惑のいかんにかかわらず、Javaは現在、エンタープライズ・ソフトウェア開発市場における開発言語の1つとして他言語と競合している。おそらく、Javaに次ぐエンタープライズ言語は、MicrosoftのC#だろう。以前からのオープンソース開発者たちの中でさえ、C#に関してはMicrosoftはよくやっていると考える人もいるのだ（参考資料4を参照）。
市場でのシェア拡大
Java周辺のビジネスの戦いは、エンタープライズ・ソフトウェアのソリューションとしてのJavaの市場を拡大することと密接に関連している。最も熾烈な競合は、いま、Sun（Java、J2EE）とMicrosoft（C#、.NET）との間で繰り広げられている。
しかし、ビジネスの戦いには、市場での浸透力もかかわってくる。すでにJavaによって占有されているエンタープライズ市場において、Javaベースの製品やサービスを提供する企業たちが、シェアを奪い合っているのだ。ここでは、SunやBEAのような企業が競合している。
その結果、奇妙な協力関係（協力と競争）が生まれた。SunとBEAは両社とも、JavaがC#を超えるエンタープライズ・ソフトウェア・ソリューションとなることを望んでいるので、ある意味仲間でもある。とはいえ、BEAのWeblogic Platform（参考資料5を参照）とSun Java Enterprise System（参考資料6を参照）は競合関係だ。
オープンソースのJava開発は、このような競争の力関係に大きな影響を与えるだろう。無料で入手可能なJavaプログラムの存在は、企業がC#などの言語ではなくJavaを選ぶ動機になりうる。オープンソース開発者がJavaを積極的に採用することも、高品質で無料のJavaソフトウェアの普及に役立つはずだ。これらの要素すべてが、Java市場の成長のための戦いに影響している。
市場でのシェアは、企業がオープンソース製品とその他の製品をどのように位置付けるかに大きく左右される。Javaソフトウェアのニーズが、オープンソースプロジェクトによってどれだけ代替されるだろうか。これが、マーケティング戦略の第3の要素につながってくる。
市場での代替
特定のテクノロジ市場に高品質のオープンソース・プロジェクトが存在する場合、それはプロプライエタリ・ソフトウェアよりも優先して採用されるだろう。
Sleepycat Software（参考資料7を参照）は、Berkeley DBエンベデッド・データベースで長年成功を収めている。Berkeley DBはオープンソースで、無料で入手可能なため、これと肩を並べる製品を参入させるのは、どのようなベンダにとっても困難だ。Berkeley DBに価格で勝負することはできないし、品質とサポートはSleepycatが全面的にバックアップしているからだ。
Sleepycatは、おまけのソフトウェアを提供して利益を得ている。そのおまけが、Berkeley DBだ。製品が自らのおまけであるというのはあまり例がないが、可能ではある。オープンソース版のBerkeley DBは「ウイルス」ライセンスで配布されている（つまり、これに組み合わせて使うソフトウェアもオープンソースでなければならない）。これはエンベデッド・ソフトウェアであり、必然的に他のソフトウェアと組み合わせて使うことになるが、Berkeley DBを大規模な製品の一部として採用したくても、このウイルス型ライセンスが邪魔になる。
最終的にこのような企業は、ライセンス所有者、つまりSleepycat Softwareからライセンス供与を受けることになる。
これは、オープンソース・ビジネスの極端な例だ。より一般的な言い方をすれば、オープンソース・プロジェクトが特定のテクノロジ市場でシェアを独占した場合、その製品に関連する市場に、付随する製品やサービスを提供できれば、そのプロジェクトによって利益を得ることができる。
SunとBEAはどちらも、Javaとオープンソースに関して、マーケティング戦略を注意深く選択した。しかしながら、採用されたのは、2つの異なるビジネス要件を反映した、2つの大きく異なる戦略であった。
市場を広げる
SunのJava関連のオープンソース戦略について考える上で、Sunが力を入れているプロジェクトを見てみよう。
JOGLは、OpenGL API（参考資料8を参照）にJavaラッパーを提供する。プロジェクトを始動したのはSunのエンジニアたちだが、プロジェクト成功のためには、異なる目的を持つ複数のグループによる協力が不可欠だった。たとえば、ゲーム・プログラミングにおけるグラフィックの技術的問題は、以前はJavaで対処することが不可能であった。しかしこのプロジェクトにより、問題解決のためにJavaプログラマの人材を投入できるようになるため、ゲーム制作会社にとっては重要なプロジェクトである。また、Javaプログラマにとっても、ゲーム・プログラミングへの門戸が開かれる。そしてSunにとっては、Javaがゲーム市場にも進出できるというメリットがあるのだ。この、最後の点が鍵となる。
Javaの生みの親であるSunが最優先したいのは、市場の成長、つまり、Javaベース・ソリューションのニーズを高めることだ。より多くのJavaオープンソース・プロジェクトが生まれ、より多くのオープンソース開発者がJavaを選択すれば、Javaの市場での競争力が高まる。
Sunは今、Java言語そのものをオープンソース化しなかったことによる、大きな問題に直面している。Sunが、Java開発者を特定の方向に誘導しようとすると、それが実際以上に独裁的に捉えられてしまう可能性があるのだ。Sunは、一方では統制と所有、もう一方では援助と指揮という表裏一体の立場において、バランスを取りそこねるかもしれない。Javaをオープンソース化すれば、Sunからの色よい提案の裏には、開発者たちの力の及ばないJavaライセンスの変更という意図が隠されているのではないかという不安が軽減されるだろう。
Javaのオープンソース化をよしとしないSunは、独裁的に映らないよう、注意深くJavaの成長を促進する他の手段をとることにした。このうち、最も広く知られているのがJava Community Process（参考資料9を参照）である。Java Community Processは、Internet Engineering Task Force（IETF：参考資料10を参照）のベスト・プラクティスをJavaコミュニティにそのまま取り入れたものだ。
JOGLの開発は、対象となる市場のいずれかで集中的に進めることもできた。また、Sunの社内プロジェクトにすることもできた。しかしこれでは、OpenGLのメンバとの連携が困難だ。また、ゲーム・プログラマの協力もあまり得られなかっただろう。SourceForge.netなどの第三者にプロジェクトを委託する方法もあった。しかし、Sunは、プロジェクト・ホスティングとしてSourceForge.netをほとんど利用していない。おそらく、開発プロセスに、より緊密な連絡とより厳しいコントロールを必要としているためだろう。とはいえ、何らかの中立地帯が必要である。中立地帯を確立することで初めて、異なる（場合によっては、食い違った）目的を持つ者同士（OpenGL、ゲーム・プログラマ、Sun Engineering）が協力しあうことが可能になる。
このジレンマに対するSunの解決策が、Java.net（参考資料11を参照）。Java.netの目的は、サイト内の文言を借りれば「Javaテクノロジに関連する、有益な意見交換と独創的な開発プロジェクトのための共有スペースを提供する」ことである。Sun Engineeringは、サイト内のプロジェクトに最も大きな刺激を与えている。Java.netは、登場から1年半で、相当量の参加者を獲得し、現在は1300以上のオープンソース・プロジェクトがホスティングされており、登録メンバは9万人を超える。
JOGLは数あるプロジェクトのうちの1つにすぎないが、Sunの戦略を如実に反映したものとなっている。Sun Engineeringは、外部のJava開発者や、Javaテクノロジのさまざまな側面で既得権を持つ他企業との活発な意見交換を必要としている。外部の開発者たちは、Javaの今後の方針についてのロードマップを必要としている。同じ問題を扱っている複数のグループがある場合は、同じことを1からやり直すようなことがないようにしなければならない。つまり、一本化したアプローチによって解決策を探る必要がある。Java.netのようなコミュニティ・ポータルは、これらを可能にするコミュニケーション手段と、共通のゴールを提示してくれる。
SunにとってJava.netは、オープンソースJavaコミュニティを歩み寄らせるための友好的な手段であり、ことさらに所有権を主張することなくリーダシップを発揮するための手段であるといえる。このようなアプローチが可能なのは、Java.netはSunの所有物でありながら、世話役としてO’Reilly、Collab.net、Daniel Steinberg編集主任（元IBM Developer Works）という第三者が加わっていることによるものだ。
市場を引き寄せる
BEAのオープンソース・プロジェクトは、Sunとは異なる筋書きと戦略の下で進められている。
Beehiveは、Apache内の公式プロジェクトである。BeehiveはJ2EE用のアプリケーション開発環境であり、主に3つの部分で構成されている。
BEAは、Java市場の拡大によって恩恵を受けてはいるが、より重視しているのは、Java市場において第1位になることである。つまり、他市場への進出よりも、市場でのシェア拡大のほうが優先なのである。しかし、優れたオープンソース・プロジェクトがプロプライエタリに代替することによって、市場でのシェア拡大はさらに複雑になる。
WebLogic Platformは、Sun製品（Sunに限らず、IBMやOracleなどのJava市場での競合他社の製品）と競合関係にあるだけでなく、ApacheのJakartaプロジェクトから派生した、Tomcat（参考資料13を参照）などのソリューションとも、多少競合している。これを考慮すれば、BEAはオープンソースから距離を置き、サービス、サポート、使い勝手などの面で付加価値を提供することで差別化を計るだろうと考えるのが自然だ。実際、オープンソースとの競合関係に身を置いている他の多くの企業は、この戦略を採用している。
しかし、BEAの戦略はその正反対で、オープンソースととことん付き合うことを決めた。しかも、Sunのように誘導しようとするのではなく、草の根レベルから参加したのだ。
BEAの標準/オープンソース戦略の製品マネージャを務めるCliff Schmidtは、インタビューで、オープンソースへのBEAのアプローチについて明らかにしている（参考資料14を参照）。BeehiveについてSchmidtは次のように述べている。「Beehiveをオープンソースにして、オープンソース・コミュニティのメンバと協力し、これをBEAだけのものではなく、Java全体にかかわるものにする理由は山ほどあった」Schmidtは具体的には、BEAがオープンソースにコードを提供する「アウトバウンド」のプロジェクトと、BEAがオープンソース・コードをテクノロジに統合する「インバウンド」のプロジェクトを区別している。
アウトバウンド戦略の一部は、Java全体の他市場への進出と関係する。Schmidtは、「我が社のビジネスが大きく依存しているJavaコミュニティが望んでいるという理由で、（…）このBeehiveプロジェクトをオープンソース・コミュニティに提供することは、大筋でJavaの市場拡大に貢献しているように思う。当然、Javaの市場拡大は我が社の利益でもある」
インバウンド戦略に関してはさらに詳しく説明されている。Schmidtは、プロジェクトへのオープンソースの統合には、リスクがないわけではないと言う。たとえば、「知らず知らずのうちに自らを危険な立場に追い込んでしまうような、法的な問題がある。注意を払わず、盲目的にオープンソースのコードを入手して製品に取り込んでしまうと、自分自身も、プロジェクトの関係者もリスクを負うことになる」しかし彼は、このようなリスクを利用している企業もあると指摘する。「FUD（不安、不確実、嘘）によって、自分たちの製品を売り込んでいる」
Schmidtはこれを、BEAの方針と比較している。「ソフトウェア企業は（…）コミュニティという言葉を喜んで振りまいているが、本当に顧客の幸せを考えるなら、活発で大規模、そして、できるだけ多くのリソースが手に入るコミュニティに入ってもらうほうがいい」活発なコミュニティ、つまりオープンソース・コミュニティの一員であるBEAは、コミュニティの産物を顧客のために活用し、不足しがちな企業の後援という安定と安心を、オープンソースに提供している。彼は、「オープンソースが生き残ることは我が社にとって重要だが、BEAがいてもいなくても、生き残るだろう」と結んでいる。
つまり、BEAの考えはこうだ。他の企業が無視しようが、FUDを広めようが、オープンソースの成功が継続することには疑いがない。したがって、オープンソースを支持・推進して、エンタープライズ・ソフトウェア・スタックのコンポーネントを共有化すると同時に、さらに上のスタックに価値を付加するのが最善の選択肢である。他の企業（Microsoft）は、オープンソースを支持しようとしなかったがためにシェアを下げることになるだろう。BEAは、オープンソースによって共有化されたコードに付随するソフトウェアを開発していく。
BEAが、Beehiveから直接利益を得ることはない。しかしBeehiveは、強力なマーケティング・ツールの役割を果たしてくれるだろう。Beehiveの有用性が認められるにしたがって、Weblogicの生みの親であるBEAの評価も上がる。そうすれば、Beehiveでソリューションを自作する時間やスキルのない顧客が、ソリューションとしてWeblogicを選択する可能性が高くなるのだ。
結論
Javaはオープンソースか否か、または、オープンソース化されるか否かを議論しているビジネスや開発者は、問題の核心を見誤っている。Javaが無料で入手可能であること、そして、エンタープライズ・ソフトウェア市場をほぼ独占していることを考えれば、Javaがオープンソースであるかどうかよりも、Javaで開発されるオープンソース・ソフトウェアのほうがはるかに重要だとわかるはずだ。
Javaソフトウェアをベースにビジネスを展開している企業は、オープンソース戦略をよく練らなければならない。単に「無視する」「支持する」ではいけない。SunとBEAは、いずれもオープンソースにビジネス上の価値を見出していながら、まったく異なるアプローチでオープンソースに接している。今を生き抜くには、自らのビジネスの方向性と、オープンソースとをどのように結ぶかを知っていなければならない。
参考資料
参考資料1：「An Open Letter to Hobbyists」、http://www.blinkenlights.com/classiccmp/gateswhine.htmlに再掲
参考資料2：CPAN、http://www.cpan.org
参考資料3：SourceForge.netプロジェクト（言語別）、 http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
参考資料4：「A Conversation with San Mehat」、 http://webservices.devchannel.org/webserviceschannel/03/05/28/0821232.shtml
参考資料5：BEA WebLogic Platform、http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/platform
参考資料6：Sun Java Enterprise System、http://www.sun.com/software/javaenterprisesystem/index.html
参考資料7：Sleepycat Software、http://www.sleepycat.com
参考資料8：JOGLプロジェクト、http://today.java.net/pub/a/today/2004/10/15/jogl.html
参考資料9：Java Community Process、http://www.jcp.org
参考資料10：Internet Engineering Task Force、http://www.ietf.org
参考資料11：Java.net、http://www.java.net
参考資料12：Apache Software Foundationとそのプロジェクト支援ポリシー、 http://incubator.apache.org/incubation/Incubation_Policy.html
参考資料13：Apache Tomcat、http://jakarta.apache.org/tomcat/
参考資料14：Cliff Schmidtのインタビューhttp://dev2dev.bea.com/trainingevents/dev2devlive/cliffschmidt.jsp
開発を可能にするプラットフォームとしての言語
開発者にとって何よりも重要なのは、コンピュータをプログラミングする能力である。このように言うと、Linuxは、Linus Torvaldsが、Cコンパイラを搭載したコンピュータが自宅に欲しかったという理由で生まれたではないかと思う読者もいるだろう。しかし開発者たちは、パーソナル・コンピューティングの初期段階からずっと、プログラミング言語を無料かつ自由に利用できることを必要としてきたのだ。この要求は、若き日のBill GatesがAltair BASICの開発および配布でビジネスを始められるほどに、そして、Altair BASICのコピーのほとんどが、結局、彼の会社への支払いなしで流通するようになるほどに大きかった。
Gatesは1976年、趣味のプログラマたちに宛てたオープン・レターで次のように回答している（参考資料1を参照）：「プロとしての仕事を、無報酬でする人間などいない。趣味であっても、3人年かけてプログラミングし、すべてのバグをつぶし、製品のドキュメント化を行った製品を、無料で配布する人間がいるだろうか？」彼は、Altair BASICを無料で流通させることは、結果的にソフトウェア開発に打撃を与えると結論付けている。「あなたたちがしていることは、優れたソフトウェアの開発を阻む行為だ」
そして時が経ち、Gatesは間違っていたことが証明された。プログラミング言語は、開発を可能にするプラットフォームであり、そのプラットフォームの利用が自由であればあるほど、そして、普及率が高ければ高いほど、よりよいソフトウェアが開発されるのだ。Microsoftですら、Altair BASICの無料再配布の元は取った（ひょっとしたらお釣りが来たかもしれない）。しかし、Gatesが直面した難問はいまも、テクノロジ企業が無料再配布というマーケティング・メカニズムと、ビジネスモデルとを融合させようとする際の悩みの種だ。
自由？無料？
オープンソースには2つの主要な柱がある。
- 自由に変更できる（リブレソフトウェア――free as in speech（「言論の自由」の「フリー」））
- 変更点も含め、無料で再配布することができる（無料ソフトウェア――free as in beer（「ビール無料」の「フリー」）
無料であるおかげで、Comprehensive Perl Archive Network（CPAN：参考資料2を参照）の4000人もの作者の手による、7000を超えるモジュールが作成される結果となった。また、SourceForge.net（参考資料3を参照）に5000以上のPerlプロジェクトが作成されているのも、この点によるものだ。
しかし、だからといってPerlがSourceForge.netのプロジェクトで最もよく利用されている言語かといえば、決してそんなことはない。CとC++は、それぞれ1万3000以上のプロジェクトがあるし、Javaが僅差で3位（1万3066プロジェクト）となっている。
プログラミング言語をビジネスにする
Javaは、「オープンソースである」という条件以外はすべて満たしている。無料で入手でき、プロプライエタリとオープンソースの両方において、Javaベース・ソフトウェアという巨大かつ重要な世界を構築した。オープンソースに関連したビジネス・パラドックスの主なものは、Javaにとっても無縁ではない。Sunやその他の企業は、無料で配布されているものからどのように収入を得ることができるだろうか。Bill Gatesがオープン・レターで投げかけた問いに、30年近く経った今も、答えは出ていない。
再配布自由の製品は、3つの異なるビジネスモデルを生む。
- 市場の成長
- 市場でのシェア拡大
- 市場での代替
市場の成長
製品を無料で配布することは、消費を促進する。その製品の消費が拡大すれば、製品の市場の規模が拡大するだけでなく、その製品に関連するすべての製品とサービスの市場が拡大される。Linuxは無料で入手可能であることによりOS市場においてシェアを伸ばし、その結果、Linux関連の製品やサービスの市場規模も拡大した。これにより、たとえばIBMのような企業は、Linuxを宣伝して、Linuxを走らせているハードウェアの市場を拡大すれば、収入を伸ばすことができる。また、Linuxを宣伝して、IBM Global Servicesで提供しているLinuxの専門知識へのニーズを高めれば、サービスからの収入も期待できる。
Javaのユビキタス化を推進しようとするSunの試みも、同様の動機によるものだ。Sunの収入源は、当初はSunハードウェアであった。Javaの「write once, run anywhere（一度書けば、どこでも動く）」哲学を広めることで、エンベデッド・システムのような新しいハードウェア市場にJavaを浸透させ、Javaの専門知識を元にこれらの新しい市場でビジネスを拡大するのが狙いである。
しかし、「Write once, run anywhere」は諸刃の剣である。Javaが問題なく動作できるのは、Intel互換のx86プラットフォーム・ファミリである。つまり、x86でJavaをサポートするプラットフォームを提供することは、Sunの核である、SPARCベースのビジネスに真っ向から対立することになる。BEAをはじめとして、このとおりのビジネス戦略を採用している企業もある。
さらに、Sunと同じ（つまり、競合する）戦略をとっている企業もある。Sunの当初の思惑のいかんにかかわらず、Javaは現在、エンタープライズ・ソフトウェア開発市場における開発言語の1つとして他言語と競合している。おそらく、Javaに次ぐエンタープライズ言語は、MicrosoftのC#だろう。以前からのオープンソース開発者たちの中でさえ、C#に関してはMicrosoftはよくやっていると考える人もいるのだ（参考資料4を参照）。
市場でのシェア拡大
Java周辺のビジネスの戦いは、エンタープライズ・ソフトウェアのソリューションとしてのJavaの市場を拡大することと密接に関連している。最も熾烈な競合は、いま、Sun（Java、J2EE）とMicrosoft（C#、.NET）との間で繰り広げられている。
しかし、ビジネスの戦いには、市場での浸透力もかかわってくる。すでにJavaによって占有されているエンタープライズ市場において、Javaベースの製品やサービスを提供する企業たちが、シェアを奪い合っているのだ。ここでは、SunやBEAのような企業が競合している。
その結果、奇妙な協力関係（協力と競争）が生まれた。SunとBEAは両社とも、JavaがC#を超えるエンタープライズ・ソフトウェア・ソリューションとなることを望んでいるので、ある意味仲間でもある。とはいえ、BEAのWeblogic Platform（参考資料5を参照）とSun Java Enterprise System（参考資料6を参照）は競合関係だ。
オープンソースのJava開発は、このような競争の力関係に大きな影響を与えるだろう。無料で入手可能なJavaプログラムの存在は、企業がC#などの言語ではなくJavaを選ぶ動機になりうる。オープンソース開発者がJavaを積極的に採用することも、高品質で無料のJavaソフトウェアの普及に役立つはずだ。これらの要素すべてが、Java市場の成長のための戦いに影響している。
市場でのシェアは、企業がオープンソース製品とその他の製品をどのように位置付けるかに大きく左右される。Javaソフトウェアのニーズが、オープンソースプロジェクトによってどれだけ代替されるだろうか。これが、マーケティング戦略の第3の要素につながってくる。
市場での代替
特定のテクノロジ市場に高品質のオープンソース・プロジェクトが存在する場合、それはプロプライエタリ・ソフトウェアよりも優先して採用されるだろう。
Sleepycat Software（参考資料7を参照）は、Berkeley DBエンベデッド・データベースで長年成功を収めている。Berkeley DBはオープンソースで、無料で入手可能なため、これと肩を並べる製品を参入させるのは、どのようなベンダにとっても困難だ。Berkeley DBに価格で勝負することはできないし、品質とサポートはSleepycatが全面的にバックアップしているからだ。
Sleepycatは、おまけのソフトウェアを提供して利益を得ている。そのおまけが、Berkeley DBだ。製品が自らのおまけであるというのはあまり例がないが、可能ではある。オープンソース版のBerkeley DBは「ウイルス」ライセンスで配布されている（つまり、これに組み合わせて使うソフトウェアもオープンソースでなければならない）。これはエンベデッド・ソフトウェアであり、必然的に他のソフトウェアと組み合わせて使うことになるが、Berkeley DBを大規模な製品の一部として採用したくても、このウイルス型ライセンスが邪魔になる。
最終的にこのような企業は、ライセンス所有者、つまりSleepycat Softwareからライセンス供与を受けることになる。
これは、オープンソース・ビジネスの極端な例だ。より一般的な言い方をすれば、オープンソース・プロジェクトが特定のテクノロジ市場でシェアを独占した場合、その製品に関連する市場に、付随する製品やサービスを提供できれば、そのプロジェクトによって利益を得ることができる。
SunとBEAはどちらも、Javaとオープンソースに関して、マーケティング戦略を注意深く選択した。しかしながら、採用されたのは、2つの異なるビジネス要件を反映した、2つの大きく異なる戦略であった。
市場を広げる
SunのJava関連のオープンソース戦略について考える上で、Sunが力を入れているプロジェクトを見てみよう。
JOGLは、OpenGL API（参考資料8を参照）にJavaラッパーを提供する。プロジェクトを始動したのはSunのエンジニアたちだが、プロジェクト成功のためには、異なる目的を持つ複数のグループによる協力が不可欠だった。たとえば、ゲーム・プログラミングにおけるグラフィックの技術的問題は、以前はJavaで対処することが不可能であった。しかしこのプロジェクトにより、問題解決のためにJavaプログラマの人材を投入できるようになるため、ゲーム制作会社にとっては重要なプロジェクトである。また、Javaプログラマにとっても、ゲーム・プログラミングへの門戸が開かれる。そしてSunにとっては、Javaがゲーム市場にも進出できるというメリットがあるのだ。この、最後の点が鍵となる。
Javaの生みの親であるSunが最優先したいのは、市場の成長、つまり、Javaベース・ソリューションのニーズを高めることだ。より多くのJavaオープンソース・プロジェクトが生まれ、より多くのオープンソース開発者がJavaを選択すれば、Javaの市場での競争力が高まる。
Sunは今、Java言語そのものをオープンソース化しなかったことによる、大きな問題に直面している。Sunが、Java開発者を特定の方向に誘導しようとすると、それが実際以上に独裁的に捉えられてしまう可能性があるのだ。Sunは、一方では統制と所有、もう一方では援助と指揮という表裏一体の立場において、バランスを取りそこねるかもしれない。Javaをオープンソース化すれば、Sunからの色よい提案の裏には、開発者たちの力の及ばないJavaライセンスの変更という意図が隠されているのではないかという不安が軽減されるだろう。
Javaのオープンソース化をよしとしないSunは、独裁的に映らないよう、注意深くJavaの成長を促進する他の手段をとることにした。このうち、最も広く知られているのがJava Community Process（参考資料9を参照）である。Java Community Processは、Internet Engineering Task Force（IETF：参考資料10を参照）のベスト・プラクティスをJavaコミュニティにそのまま取り入れたものだ。
JOGLの開発は、対象となる市場のいずれかで集中的に進めることもできた。また、Sunの社内プロジェクトにすることもできた。しかしこれでは、OpenGLのメンバとの連携が困難だ。また、ゲーム・プログラマの協力もあまり得られなかっただろう。SourceForge.netなどの第三者にプロジェクトを委託する方法もあった。しかし、Sunは、プロジェクト・ホスティングとしてSourceForge.netをほとんど利用していない。おそらく、開発プロセスに、より緊密な連絡とより厳しいコントロールを必要としているためだろう。とはいえ、何らかの中立地帯が必要である。中立地帯を確立することで初めて、異なる（場合によっては、食い違った）目的を持つ者同士（OpenGL、ゲーム・プログラマ、Sun Engineering）が協力しあうことが可能になる。
このジレンマに対するSunの解決策が、Java.net（参考資料11を参照）。Java.netの目的は、サイト内の文言を借りれば「Javaテクノロジに関連する、有益な意見交換と独創的な開発プロジェクトのための共有スペースを提供する」ことである。Sun Engineeringは、サイト内のプロジェクトに最も大きな刺激を与えている。Java.netは、登場から1年半で、相当量の参加者を獲得し、現在は1300以上のオープンソース・プロジェクトがホスティングされており、登録メンバは9万人を超える。
JOGLは数あるプロジェクトのうちの1つにすぎないが、Sunの戦略を如実に反映したものとなっている。Sun Engineeringは、外部のJava開発者や、Javaテクノロジのさまざまな側面で既得権を持つ他企業との活発な意見交換を必要としている。外部の開発者たちは、Javaの今後の方針についてのロードマップを必要としている。同じ問題を扱っている複数のグループがある場合は、同じことを1からやり直すようなことがないようにしなければならない。つまり、一本化したアプローチによって解決策を探る必要がある。Java.netのようなコミュニティ・ポータルは、これらを可能にするコミュニケーション手段と、共通のゴールを提示してくれる。
SunにとってJava.netは、オープンソースJavaコミュニティを歩み寄らせるための友好的な手段であり、ことさらに所有権を主張することなくリーダシップを発揮するための手段であるといえる。このようなアプローチが可能なのは、Java.netはSunの所有物でありながら、世話役としてO’Reilly、Collab.net、Daniel Steinberg編集主任（元IBM Developer Works）という第三者が加わっていることによるものだ。
市場を引き寄せる
BEAのオープンソース・プロジェクトは、Sunとは異なる筋書きと戦略の下で進められている。
Beehiveは、Apache内の公式プロジェクトである。BeehiveはJ2EE用のアプリケーション開発環境であり、主に3つの部分で構成されている。
- 「PageFlows」――struts用メタデータ管理
- 「Controls」――軽量なコンポーネント・フレームワーク
- JSR-181を実装するWebサービス・レイヤ
BEAは、Java市場の拡大によって恩恵を受けてはいるが、より重視しているのは、Java市場において第1位になることである。つまり、他市場への進出よりも、市場でのシェア拡大のほうが優先なのである。しかし、優れたオープンソース・プロジェクトがプロプライエタリに代替することによって、市場でのシェア拡大はさらに複雑になる。
WebLogic Platformは、Sun製品（Sunに限らず、IBMやOracleなどのJava市場での競合他社の製品）と競合関係にあるだけでなく、ApacheのJakartaプロジェクトから派生した、Tomcat（参考資料13を参照）などのソリューションとも、多少競合している。これを考慮すれば、BEAはオープンソースから距離を置き、サービス、サポート、使い勝手などの面で付加価値を提供することで差別化を計るだろうと考えるのが自然だ。実際、オープンソースとの競合関係に身を置いている他の多くの企業は、この戦略を採用している。
しかし、BEAの戦略はその正反対で、オープンソースととことん付き合うことを決めた。しかも、Sunのように誘導しようとするのではなく、草の根レベルから参加したのだ。
BEAの標準/オープンソース戦略の製品マネージャを務めるCliff Schmidtは、インタビューで、オープンソースへのBEAのアプローチについて明らかにしている（参考資料14を参照）。BeehiveについてSchmidtは次のように述べている。「Beehiveをオープンソースにして、オープンソース・コミュニティのメンバと協力し、これをBEAだけのものではなく、Java全体にかかわるものにする理由は山ほどあった」Schmidtは具体的には、BEAがオープンソースにコードを提供する「アウトバウンド」のプロジェクトと、BEAがオープンソース・コードをテクノロジに統合する「インバウンド」のプロジェクトを区別している。
アウトバウンド戦略の一部は、Java全体の他市場への進出と関係する。Schmidtは、「我が社のビジネスが大きく依存しているJavaコミュニティが望んでいるという理由で、（…）このBeehiveプロジェクトをオープンソース・コミュニティに提供することは、大筋でJavaの市場拡大に貢献しているように思う。当然、Javaの市場拡大は我が社の利益でもある」
インバウンド戦略に関してはさらに詳しく説明されている。Schmidtは、プロジェクトへのオープンソースの統合には、リスクがないわけではないと言う。たとえば、「知らず知らずのうちに自らを危険な立場に追い込んでしまうような、法的な問題がある。注意を払わず、盲目的にオープンソースのコードを入手して製品に取り込んでしまうと、自分自身も、プロジェクトの関係者もリスクを負うことになる」しかし彼は、このようなリスクを利用している企業もあると指摘する。「FUD（不安、不確実、嘘）によって、自分たちの製品を売り込んでいる」
Schmidtはこれを、BEAの方針と比較している。「ソフトウェア企業は（…）コミュニティという言葉を喜んで振りまいているが、本当に顧客の幸せを考えるなら、活発で大規模、そして、できるだけ多くのリソースが手に入るコミュニティに入ってもらうほうがいい」活発なコミュニティ、つまりオープンソース・コミュニティの一員であるBEAは、コミュニティの産物を顧客のために活用し、不足しがちな企業の後援という安定と安心を、オープンソースに提供している。彼は、「オープンソースが生き残ることは我が社にとって重要だが、BEAがいてもいなくても、生き残るだろう」と結んでいる。
つまり、BEAの考えはこうだ。他の企業が無視しようが、FUDを広めようが、オープンソースの成功が継続することには疑いがない。したがって、オープンソースを支持・推進して、エンタープライズ・ソフトウェア・スタックのコンポーネントを共有化すると同時に、さらに上のスタックに価値を付加するのが最善の選択肢である。他の企業（Microsoft）は、オープンソースを支持しようとしなかったがためにシェアを下げることになるだろう。BEAは、オープンソースによって共有化されたコードに付随するソフトウェアを開発していく。
BEAが、Beehiveから直接利益を得ることはない。しかしBeehiveは、強力なマーケティング・ツールの役割を果たしてくれるだろう。Beehiveの有用性が認められるにしたがって、Weblogicの生みの親であるBEAの評価も上がる。そうすれば、Beehiveでソリューションを自作する時間やスキルのない顧客が、ソリューションとしてWeblogicを選択する可能性が高くなるのだ。
結論
Javaはオープンソースか否か、または、オープンソース化されるか否かを議論しているビジネスや開発者は、問題の核心を見誤っている。Javaが無料で入手可能であること、そして、エンタープライズ・ソフトウェア市場をほぼ独占していることを考えれば、Javaがオープンソースであるかどうかよりも、Javaで開発されるオープンソース・ソフトウェアのほうがはるかに重要だとわかるはずだ。
Javaソフトウェアをベースにビジネスを展開している企業は、オープンソース戦略をよく練らなければならない。単に「無視する」「支持する」ではいけない。SunとBEAは、いずれもオープンソースにビジネス上の価値を見出していながら、まったく異なるアプローチでオープンソースに接している。今を生き抜くには、自らのビジネスの方向性と、オープンソースとをどのように結ぶかを知っていなければならない。
参考資料
参考資料1：「An Open Letter to Hobbyists」、http://www.blinkenlights.com/classiccmp/gateswhine.htmlに再掲
参考資料2：CPAN、http://www.cpan.org
参考資料3：SourceForge.netプロジェクト（言語別）、 http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
参考資料4：「A Conversation with San Mehat」、 http://webservices.devchannel.org/webserviceschannel/03/05/28/0821232.shtml
参考資料5：BEA WebLogic Platform、http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/platform
参考資料6：Sun Java Enterprise System、http://www.sun.com/software/javaenterprisesystem/index.html
参考資料7：Sleepycat Software、http://www.sleepycat.com
参考資料8：JOGLプロジェクト、http://today.java.net/pub/a/today/2004/10/15/jogl.html
参考資料9：Java Community Process、http://www.jcp.org
参考資料10：Internet Engineering Task Force、http://www.ietf.org
参考資料11：Java.net、http://www.java.net
参考資料12：Apache Software Foundationとそのプロジェクト支援ポリシー、 http://incubator.apache.org/incubation/Incubation_Policy.html
参考資料13：Apache Tomcat、http://jakarta.apache.org/tomcat/
参考資料14：Cliff Schmidtのインタビューhttp://dev2dev.bea.com/trainingevents/dev2devlive/cliffschmidt.jsp
