開発プロジェクトをめぐるお金の流れ、その真相:オープンソースソフトウェアの育て方(2/2 ページ)
フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。お金でプロジェクトへの影響力を買うことはできませんが、影響力につながるものを買うことはできます。実際のところ、企業はどのようにしてオープンソースプロジェクトにかかわっているのでしょうか。この点を明らかにします。
プロジェクトへのかかわり方
オープンソースプロジェクトがお金を出してもらう理由はさまざまなものがあります。以下に示す理由は、相互に排他的なものではありません。つまり、支援を受ける理由は以下の複数、またはすべてが当てはまる場合があります。
- コスト負担を共有する
関連があるソフトウェアを必要とする組織は、似たようなコードを社内で書いたり、商用ベンダーから似たような商品を購入したりすることで、同じ目標に向かって重複した努力をしていることがよくあります。彼らはそれを知ると、自分たちの需要を調整するため、オープンソースプロジェクトを作る(または既存プロジェクトに参加する)かもしれません。その利点は明らかです。開発コストを分散しつつ、利益は参加したすべての組織が得ることができるからです。このシナリオは、非営利な組織の場合最も分かりやすいのですが、競合関係にある営利組織でも、戦略的には有意義なものです。
- サービスを拡大する
企業が販売している複数のサービスが特定のオープンソースソフトウェアに依存していたり、それによってサービスの魅力を高めている場合、そのソフトウェアを活発に維持していくことがその企業の関心事になるのは自然の流れです。
例: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)
よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。
関連記事
- 合意と投票で構築されるOSS開発の社会構造
プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、より開かれた民主主義的なプロセスに移行します。これはグループ主体の統治の方が、“進化的に安定している”からです。このプロセスに移行すると、グループはほとんどいつも合意に基づいて動き、合意に達しないときは投票の仕組みを用いるようになります。 - “優しい独裁者”はこんな仕事に追われている
オープンソースプロジェクトの世界では「優しい独裁者」と呼ばれる存在がプロジェクトを成功に導いているケースがたびたび見られます。では、彼らはどんな方法でプロジェクトを運営しているのでしょうか。優しい独裁者の特性を考えます。 - 開発プロジェクトを支える名脇役たち
多くの開発プロジェクトでは、IRCやRSSフィード、Wikiといったツールを駆使して開発が進められています。本稿では、そんな名脇役たちにスポットを当てていきます。 - バグ追跡システムのライフサイクルを再考する
バグ追跡システムは、はじまりと終わりの状態があるすべてのもの、存在している間に情報が発生するすべてのものを追跡するためによく使われます。本稿では、バグの追跡にかんするライフサイクル、そして、それをつかさどるソフトウェアのさまざまな側面を考えます。 - バージョン管理システムのすすめ
バージョン管理システムは昨今の開発プロジェクトにおいて、欠かせない存在となりつつあります。ここでは、バージョン管理システムの意義と、コミット、ブランチなどを深く掘り下げていきます。 - バージョン管理システムが分かる13のキーワード
開発者同士のコミュニケーション、リリース管理、バグ管理、コードの安定性の確保、安心して新機能を実験できる環境、各開発者の権限の管理など、あらゆる場面でバージョン管理システムが利用されています。本稿では、どのバージョン管理システムでも共通に使われる13の用語を紹介します。 - メーリングリストを120%活用するテクニック
メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです。本稿では、メーリングリストを徹底的に活用し尽くすためのテクニックを余すところなく紹介します。 - コミュニケーションを促進する技術的な仕組み
- フリーソフトウェアの公開、その心構え
- フリーソフトウェアプロジェクトはなぜ失敗するのか
- 今日のフリーソフトウェア文化の始まった背景を知る
- 「フリー」と「オープンソース」の違い
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――概論
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――各論
- OSSライセンスの選択と適用――クイックスタート
- OSS開発、“はじめの一歩”で抑えておくべきポイント
content on this article is licensed under a Creative Commons License.