誰がOSSの研究開発をするのか？
OSSのビジネスモデルというのはいまさら指摘することもないが従来の商用ソフトウェアのビジネスモデルと大きく異なる。
商用ソフトウェアであれば自社で開発し、マーケティングし、営業、サポート、サービスを行う。営業を代理店経由でする間接販売をとったにしろとらなかったにしろ基本的には自社開発である。ベースとなる技術が大学の研究室からのスピンオフだったとしても、誰かが研究開発した知的財産権をよりどころにそれを独占することによってビジネスをする。得られた利益をもとにそれをさらに研究開発に投資して価値を高めつつビジネスをまわしていく。ソフトウェアのロードマップを作り、製品をどの方向に発展させていき、どのようにそれから収益を得るかの決定は、その会社が行う。マーケティング活動によって市場とやりとりをしながら方向性を微調整するとしても決定はその会社が行う。
OSSのコミュニティには、明示的なロードマップはないし、そもそも市場という概念もないから、マーケティングと言う機能もない。OSSを利用したビジネスモデルというのは、そのコミュニティがもたらした成果、価値の上に成り立っている。Linuxディストリビューションというビジネスモデルはその意味で微妙なバランスの上で成り立ている。
微妙と言う意味は、コミュニティが生産する価値を市場価値へ転換することがLinuxディストリビューションの一義的な存在意義だとすると、市場価値が高いものをコミュニティが優先度をつけて開発してくれなければビジネス的優位性が失われるわけであるが、誰もコミュニティをコントロールすることができない。
ソフトウェア開発におけるバザールモデルの優位性は、早いリリース、頻繁なリリースによって、迅速にバグを修正し、機能を高めていくところにあるが、誰も必要としていない機能を頻繁にリリースしたとしたら、それはソフトウェアそのものの価値を高めることにはならない。市場で必要とされているものを開発者にフィードバックするメカニズムが働きにくいのである。
自分のビジネスの根幹をコミュニティという自分がコントロールできないところに依存することになることの微妙さ危うさがそこにある。90年代に出現した第一世代にディストリビューションはインターネット上にある様様なフリーソフトウェアを一つのCDに集めインストーラを添付しインストールしやすくしたというのがその起源である。当時のネットワークのバンド幅はダイアルアップに象徴されるような貧弱なものであったから仮に「タダ｣のソフトウェアを集めただけのCDであっても手間隙を考えれば価値はあった。
98年にOracleがLinux版のデータベースを出荷したときの状況はまさにそのような状況であった。Linuxそのものの安定性は向上してきたがSMPのスケーラビリティはなかったし、エンタープライズ領域で使えるにはまだまだの状況だった。
企業が使うOSとしては、ハードウェアベンダーからのサポートがなければならないし、Oracleをはじめとする商用ソフトウェアの動作検証、動作保証が必須になる。OSそのものも3ヶ月毎にアップデートが頻発するというのではその上のアプリケーションの動作検証にコストが掛かりすぎるので、安定的なアップデートや、長期サポート（最低でも数年以上）が必要である。
フリーソフトウェアを集めてパッケージングすることにより価値から、ハードウェアベンダーのサポート、各種ソフトウェアの動作検証、長期サポート等々が提供する価値へビジネスの軸足を移したのがいわゆるエンタープライズ向けLinuxである。（MIRACLE LINUXはその先駆けだと思う。）
基盤となる技術の多くはOSSだが、OSSそのものの価値を編集し動作確認、動作検証、ハードウェアのサポート、OSSの長期サポートなどの価値を付け加えそれをビジネスにした。ビジネスであるから消費者が求めているものと提供しているものの差異を埋めることにビジネスチャンスがあり、それをマーケティングの手法などを用いつつ継続的に提供していく。例えばサポートが弱いということであれば様様なサポートサービスを提供するし、現場での導入を容易にするために、多くの機械での動作確認を行いユーザーに情報を提供したりする。
そのような活動を含めてOSSエコシステム（生態系）といったりするが、ビジネスによってOSS周辺の価値が増大したことは間違いないと思う。
すでに指摘しているとおりLinuxカーネルへの貢献というのは、夜中に趣味でパッチを作っているというイメージのハッカーによる貢献から、IBMを筆頭とした企業に雇用されているプログラマーによる貢献に開発の主力は移行しつつある。かつてのカーネルハッカーの多くも企業に雇用されつつある。
しかしながらLinuxカーネルコミュニティをとっても、どこか一つの会社の意志でどうこうできるものでもなく、コミュニティ総体の意志によって開発が継続している。
ここに一つのパラドックスがある。企業は自らのビジネスでOSSを利用するがそれをコントロールできない。コミュニティはコミュニティで、それぞれの文化、意思決定メカニズムを持つが、その構成員は職業として企業に雇用されている。
コミュニティの開発の優先順位はコミュニティの興味ある順になる。Just for funである。コミュニティの構成メンバーが興味のわかない問題については開発の優先順位は低い。（まったく開発されないこともある）つまりコミュニティに興味のある問題についてはバザール方式で素早く頻繁にリリースされ機能がどんどん開発されるがそうでない問題は放置される。
企業発のソフトウェアであれば、明確な優先順位（市場での競争力、すなわち売れる機能かどうかで）を持ちそれによって開発される。市場での競争力という企業によって都合の良いメカニズムはOSSでは機能しない。
OSSの場合、ソフトウェアのロードマップを作ることの困難さはそこにある。技術的なチャレンジあるいは、誰もが困っていることなんだけど、誰もが率先してやることに直接的なインセンティブが働かない問題は間違いなく放置される。
OSDLではそのようなパラドックスを企業のコンソーシアムを作ることによって解決しようと試みている。Linuxのスケーラビリティを向上させるとか、信頼性を向上させるとか、地味ではあるが重要な研究開発のロードマップを会員企業の間で取りまとめ発表している。実際の開発作業はそれぞれの企業がやるとしてもロードマップを持つことによってある程度の交通整理が可能になる。
日本では今年一月に発足したIPAのOSSセンター（ http://www.ipa.go.jp/software/open/ossc/index.html ）にそのような期待が集まる。
Linuxのディストリビューション企業は編集価値によってOSSエコシステムの隙間を埋めたが、OSSセンターがOSSの中心の部分の開発そのものをすることによって直接的に貢献することを期待したい。
企業にとって直接的経済的インセンティブが働きにくい分野において投資が促進しない。OSSの地道なテスト、信頼性向上、バグ修正、ドキュメント化、等々、OSSの公共財性質によって開発が推進しにくい部分などを積極的に拾っていってほしいと思う。
OSS開発の隙間、すなわちコミュニティによっても開発されないし、企業によっても開発されない部分を埋めるという重要だけど今まで誰もやっていなかった事を、あたり前だけどあたり前にやるということが今まさに求められていると思う。
そして日本という地域でそのような開発をすることは、開発という直接的な貢献でだけではなく、日本にいる優秀な人材の発掘育成にもある。
OSSの開発の一端を公共財的な性質に注目してIPAという政府の出先機関が行うことの意義がそこにある。そしてそれは世界に誇ってもいい新しい協調のモデルである。
