開発プロジェクトをめぐるお金の流れ、その真相：オープンソースソフトウェアの育て方（2/2 ページ）

[Karl Fogel， ]

プロジェクトへのかかわり方

　オープンソースプロジェクトがお金を出してもらう理由はさまざまなものがあります。以下に示す理由は、相互に排他的なものではありません。つまり、支援を受ける理由は以下の複数、またはすべてが当てはまる場合があります。

• コスト負担を共有する

　関連があるソフトウェアを必要とする組織は、似たようなコードを社内で書いたり、商用ベンダーから似たような商品を購入したりすることで、同じ目標に向かって重複した努力をしていることがよくあります。彼らはそれを知ると、自分たちの需要を調整するため、オープンソースプロジェクトを作る（または既存プロジェクトに参加する）かもしれません。その利点は明らかです。開発コストを分散しつつ、利益は参加したすべての組織が得ることができるからです。このシナリオは、非営利な組織の場合最も分かりやすいのですが、競合関係にある営利組織でも、戦略的には有意義なものです。

例：openadaptor、Koha

• サービスを拡大する

　企業が販売している複数のサービスが特定のオープンソースソフトウェアに依存していたり、それによってサービスの魅力を高めている場合、そのソフトウェアを活発に維持していくことがその企業の関心事になるのは自然の流れです。

例：CollabNetがsubversion.tigris.orgをサポートしていること（お断り：これはわたしのルーチンワークですが、これがこのモデルの最良の例です）

• ハードウェアの営業をサポートする

　コンピュータとその部品の価値は、それが利用できるソフトウェアの量に直接左右されます。ハードウェアベンダー――完成したマシンのベンダーだけでなく、周辺機器デバイスやマイクロチップのベンダーも含みます――は、自分たちのハードウェアを動かせる高品質なフリーソフトウェアが存在していることが、顧客にとって重要であることに気づいているのです。

• 競争相手を弱体化させる

　企業によっては、競合しているソフトウェアの力を弱めることを狙ってオープンソースプロジェクトをサポートするところもあります。競合するソフトは、オープンソースであってもそうでなくても構いません。競争相手の市場シェアを減らすことが、オープンソースプロジェクトに参加する唯一の理由ではないものの、その1つだったりすることはあり得ます。

例：OpenOffice.org（競争相手を弱体化させることがOpenOfficeの唯一の存在理由ではありませんが、このソフトウェアは、少なくともMicrosoft Officeに対する答えの1つです）

• マーケティング

　人気のあるオープンソースソフトウェアにかかわっている企業は、それだけでブランド管理をうまく行うことができます。

• デュアルライセンス

　デュアルライセンスとは、自分のソフトウェアに商用のソフトウェアを組み込んで売りたい顧客向けの伝統的な商用ライセンスと、ソースを公開して使いたい人向けのフリーなライセンスを同時に共存させてソフトウェアを提供するための手法です（章9.ライセンス、著作権、特許のデュアルライセンスの仕組み項を参照してください）。オープンソース開発者のコミュニティーが活発なら、デュアルライセンスされたソフトウェアは、広く多くの人から開発作業やデバッグをしてもらえるという利益を得られる上、企業はフルタイムで働くプログラマーを支援することで、ロイヤリティの収入を得ることができるのです。

　このモデルの例として、よく知られているものが2つあります。同じ名前のデータベースソフトウェアを作っているMySQL、そしてBarkley DBを配布し、サポートしているSleepycatです。これらの例が両方ともデータベースを扱う会社であることは、偶然の一致ではありません。データベースソフトウェアは市場でユーザーに直接売るというよりは、アプリケーションに統合される傾向があるため、デュアルライセンスのモデルによく合っているのです。

• 寄付を受ける

　広く使われているオープンソースソフトウェアのプロジェクトでは、オンライン上で「寄付を行う」ボタンを押してもらったり、コーヒーのマグカップやTシャツ、マウスパッドなどのような、ブランド化した商品を売ることで、個人や組織から重要な貢献を受けることができます。ここで一言注意しておきます。もしあなたのプロジェクトで寄付を受けることにした場合、お金が入ってくる前に寄付されたお金をどう使うかを計画し、それをプロジェクトのWebサイトに掲示しましょう。どうお金を使うかの議論は、実際にお金が入ってくる前の方がうまくいきます。どちらにせよ、お金の使い方に同意が得られない場合は、寄付を受けることが非現実的であると判断した方がよいでしょう。

---

　お金を出す側のビジネスモデルが、オープンソースコミュニティーに対するかかわり方を決める唯一の要因ではありません。お金を出す側とコミュニティーとの歴史的な関係も影響しています。つまり、企業の方がプロジェクトを始めたのか、それとも後から既存のプロジェクトに参加したのか、という点です。

　どちらの場合も、お金を出す企業はコミュニティーから信頼を勝ち取る必要がありますが、後から既存プロジェクトに参加した方が少し信頼されやすい、ということは驚くべきことではありません。必ずしもプロジェクトの方向性を支配するためではなく、導くためだとしても、企業はコミュニティーでリーダー的な存在を維持したり、唯一の発言権を持とうとしているでしょうか。または、ある程度の人数コミッターを送り込み、顧客から報告されたバグを修正し、労せずして製品にそれを取り込みたいだけでしょうか？

　この2つの質問を、以降で説明するガイドラインを読むときによく覚えておいてください。これらはフリーソフトウェアプロジェクトに組織が参加するあらゆる場合に適用できますが、プロジェクトは人間が作るものですので、1つとして同じものはありません。ある程度、なりゆきに任せなければならないでしょうが、これから説明する原則を理解していけば、あなたが望むやり方と似たものが出てくるでしょう。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク