先週末は島根県の松江を訪れた。島根大の野田哲夫先生にお招き頂いたものだ。島根大の研究プロジェクトとして、今後数年に渡り、外部の実務家や研究者も交えてオープンソースの社会的側面を研究するというようなことになったそうで、その研究グループのいわばキックオフミーティングのようなものに呼ばれたのである。用事の後はたまたま同時期に開催されていたOSC2008 Shimaneに一参加者として顔を出したが、参加者の数も想像以上、松江市長に加えて島根県の知事までお出でになるという具合で、何というか大変な熱気に驚いた。この調子で行くと、来年あたりは松江ではなくてmatz江になっているのではないか。

というわけで、オープンソースの、それもビジネスモデルについてやや真面目に研究しなければならないということになった。白状すると、いつも偉そうなことをほざいているわりに(そして本業は一応経営学を専攻する学生であるにも関わらず)、私はオープンソースのビジネスモデルについてまともに研究したことはない。思えば昔は、私などがいくらオープンソース(というかフリーソフトウェア)商売はちゃんとビジネスとして成立する可能性があるんだと言っても、賛同してくださる方は日本では5人くらいしかいなくて、大体コミュニストかその眷属扱いされて悲しい思いをしたものだが、それが今ではGoogleで検索してみると、「オープンソース ビジネスモデル」で99万1千件、「Open Source Business Model」に至っては139万件も引っかかる。到底常人の読みきれる量ではない。隔世の感というか、この有様では今や何だかありとあらゆる人が今やオープンソースのビジネスモデルについて一家言ありそうである。また、この手の話題を扱った論文や書籍が洋の東西を問わずすでに多数あることも承知している。というか、たまにそういうのをご献本いただくこともあるのだが、読むと、何と言いますか、いろいろ考えこんでしまうのであった。

そんなわけで、一周どころか十周くらい世間から遅れていそうだが、私もオープンソースのビジネスモデルについて勉強することにした。どうせ勉強するならということで、今後ここに私が学んだことを随時書き留めていくことにする。私自身がいわばこの分野での「土地勘」を得、頭を整理するための作業なので、あまり深い話にはならないと思うが、興味のある方はしばらくお付き合いいただきたい。

とりあえずは非常に大まかな話をしよう。ここでの話の前提は、オープンソース・ソフトウェアから、プロプライエタリ・ソフトウェアのようにはライセンス料収入を上げることはできない、ということだ。よって、オープンソース・ソフトウェアそのものではなく、オープンソース・ソフトウェアに関して顧客に提供するサービスで収益を上げる、というのが基本的な構図となる。ではどのようなサービスを、どのように顧客に提供するかという話になるのだが、これに関してはHPのオープンソース部門を率いるKatrik Subbarao氏の分類をベースにするのが分かりやすい。彼は、顧客と企業がどのような関係にあるかという観点に絞って、オープンソース製品に商用サービス(サポート、コンサルティング、アウトソーシングやホスティング、教育など)を提供するいわゆる「オープンソース企業」のタイプを3つに分類している。

企業(Corporate)モデル

企業モデルは顧客と企業の関係性としては最も単純なモデルで、顧客とプロプライエタリなソフトウェアを販売する企業が結ぶ伝統的な関係によく似ている。このモデルでは、ある単一の企業が、あるオープンソース・プロジェクトの運営に関して大半の責任を持つことになる。そうした企業はそのオープンソース・プロジェクトの所有権を有しているか、有している人間を雇用している。そして、そうした企業の従業員が、プロジェクトのアーキテクチャや開発の進め方、製品リリースについて重要な決定のほとんどを下すことになる。

伝統的なソフトウェア企業/顧客間の関係と違うのは、企業が握っている(かのように見える)プロジェクトのソースコードは、オープンソース・ライセンスの下で公開されているということである。言い換えれば、企業の意向と関係なくソースコードは誰でもアクセスできるし、改変も再頒布もできる。ようするに、その企業のやり口が気にくわなければ、プロジェクトの参加者には常にフォーク(プロジェクト分岐)するという選択肢があるということだ。なので、このタイプの企業は常に「優しい独裁者」であることが要求される。

仲介(Intermediary)モデル

オープンソース・プロジェクトの所有権を完全には持っていないが、そのプロジェクトに関して商用のサポートサービスを提供したいという場合、仲介モデルが採用される。顧客に対してそのプロジェクトへの窓口となり、顧客の要望を受けて、プロジェクトを主導している開発者チームとの調整を行う。仲介モデルにおいては、企業はそのプロジェクトのソースコードレポジトリへコミット権限を持つ開発者を数名スタッフとして雇用していることが多いが、常にはそうだとは限らない。自社あるいは自社の従業員が開始したわけではないオープンソース・プロジェクトを種にする場合は、大抵こちらのモデルだろう。また、このモデルの場合、顧客はそれほど技術的知識がない、あるいは少なくともそのプロジェクトにはあまりコミットする気がないというのが前提になると思われる。

仲介モデルにおいて難しいのは、プロジェクトのコードベースに、いかに自らの欲する修正や改良をコミットしていくかということである。複雑あるいは大規模な改変を押し込むことは、しばしばプロジェクトの主導的開発者のチームとの激しい議論や、場合によっては軋轢を引き起こす。それは技術的な問題であると同時に、しばしばビジネス的、人付き合い的な問題ですらある。拙速な行動はしばしばプロジェクトとの関係悪化をもたらすが、一方で顧客は素早い対応と素早い解決を期待している。こうした顧客の要望と開発チームの意向とのすりあわせをいかにうまくやるかが、仲介モデルを採る企業の死命を制することになるだろう。成功する仲介モデル企業にはプロジェクトの開発チームと強力な信頼関係があり、コミュニティ全体に対して有益な存在とみなされている。

世話役(Facilitator)モデル

世話役モデルは仲介モデルの変種であり、顧客が直接オープンソース・プロジェクトとやりとりするのを世話する。仲介モデルの企業は顧客に対してプロジェクトへの一元的窓口としてふるまうが、世話役モデルの企業の場合、顧客は世話役企業を通しても話を付けても良いし、彼ら自身が直接プロジェクトと交渉したり、関与することもできる。世話役モデルの企業と関係を持つ顧客は、通常自分自身にもオープンソース貢献者となるだけの経験や能力があるが、しかしその特定プロジェクトに関しては世話役モデルの企業ほど特化した知識や経験を持ち合わせていない。こうした顧客が節約したがっているのは、ようするに時間だ。なので、世話役モデルの企業には、顧客に自分でやるより速くて良いと思わせるだけの水準のサービスを提供することが求められる。

もちろん仲介モデルの企業は、世話役モデルの企業としても活動できる。どちらのタイプを採るかは、結局のところ顧客次第である。顧客が直接オープンソースプロジェクトに関与したがればしたがるほど、企業はより世話役モデルとして振る舞うことになろう。

と、以上顧客への補完的なサービス提供という観点から3つのモデルが提示された。どれを選べば良いかは、顧客がどこに専門性を持つか、そして顧客があるプロジェクトに関して、時間と金のどちらを重視するかということ次第である。

すでにお分かりのとおり、オープンソースのビジネスモデルを考える上では実にいろいろなことを考えなければならない。プロジェクトの所有権を考える上では著作権やライセンシングに関する議論が必要だし、リーダーシップの議論、組織構造に関する議論、組織文化に関する議論、参加者のインセンティヴに関する議論、開発者とユーザの関係に関する議論など、考えるべきことはいろいろある。そもそも上に挙げた類型が話のすべてではない。ということで、いつになるかは分からないが次回へと続くのである。