第5章 カネに関する問題

目次

プロジェクトへの関わり方
開発者を長期に渡って雇用する
企業の人間としてではなく、個人として振る舞う
動機を隠し立てしない
カネで愛は買えない
契約する
レビューを行い、変更をソースコードに取り入れる
ケーススタディ: CVS パスワード認証プロトコルの場合
プログラミング以外の活動を支援する
品質保証 (テストの専門家など)
法律上の助言、権利の保護
ドキュメントやユーザビリティの改善
ホスティングサイトや接続回線を提供する
マーケティング
見られていることを意識する
競合するオープンソースプロジェクトを攻撃しない

この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきます。 ここでは、フリーソフトウェアプロジェクトでお金を貰って雇われる開発者だけでなく、 開発する環境が置かれる社会力学を理解する必要があるプロジェクト管理者も対象にします。 以下のセクションでは、読者(あなたです!) はお金を貰って雇われる開発者か、 開発者を管理する人であることを想定します。 この章でのアドバイスは、両者に当てはまることもありますし、そうでないこともありますが、 対象となる人は文脈の中で明らかにしていきます。

フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。 多くの開発が、いつも非公式に奨励金の対象になってきました。 システム管理者が業務の遂行を助けるためにネットワーク分析ツールを書き、 オンラインにそれを投稿し、 バグ修正や機能追加の貢献を他のシステム管理者から受けた場合、 非公式に団体が設立されていきました。 団体を維持するための資金は、システム管理者達の給料から出ており、 オフィススペースやネットワークの帯域は寄付によって賄われました。 こうした組織は、はじめのうちは制度的に認知されることはありませんでしたが、 もちろん投資することで利益を得ていたのです。

当時と今の違いは、こうした努力の多くが公に認められるようになったということです。 企業はオープンソースソフトウェアから得られる利益に関心を示すようになり、 その開発に直接関わりはじめました。 開発者達も、本当に重要なプロジェクトには少なくとも寄付や、 可能であれば長期のスポンサーを期待するようになっています。 お金があるからといって、 フリーソフトウェアの基本的な開発力学が変わるものではありませんが、 開発者の数や、開発者ひとり当たりの作業量の規模は劇的に変わりました。 お金は、プロジェクトが組織化される方法や、 関係者のプロジェクトでのやりとりの仕方にも影響を与えました。 問題は、単にお金がどう使われるのかとか、 投資に対する見返りをどのように測るか、ということにとどまらず、 プロジェクトの管理やそのプロセスにも及びます。 つまり、企業の階層的な命令系統と、 緩やかに分散したフリーソフトウェアプロジェクトのコミュニティーが、 お互いに生産的に動くにはどうしたらいいでしょう? そもそも "生産的に" という言葉がどういう意味なのか、 について企業とコミュニティーは一致するのでしょうか?

金銭的な支援を受けることは、 オープンソース開発コミュニティーでは一般的に歓迎されています。 支援を受けることで、 軌道に乗る前に多くのプロジェクトを潰してきたコミュニティーの弱点を無秩序の力に変えることができます。 それゆえに、人々はソフトウェアを世に送り出したいと強く願うようになります。 — つまり、これから向こう6ヵ月間は自分の時間をそこらへんに転がっている何かに使おう、 と人々は考えるのです。結局、何かを信じる心は、ある程度までは他の人に伝染しやすいものです。 たとえば、IBM がオープンソースプロジェクトを支援したとき、 このプロジェクトに失敗は許されないと人々は強く思いましたし、 失敗しないようプロジェクトに注力しようと思う心が、 プロジェクトが実際に失敗しない状況を作ったのです。

しかし、お金を出すことは、人を支配する感覚を生むものでもあります。 注意深く扱わないと、お金はプロジェクトを、仲間内の開発者とそうでない開発者に分裂させてしまうかもしれません。 ボランティアの開発者が、一番お金を出している人が機能追加や設計上の決定を行えるんだと思ってしまうと、 実力志向が強く、それでいて他人の利益のために無給で働くことを好まないプロジェクトに移ってしまうでしょう。 彼らは、決してメーリングリスト上で大声で不平を言ったりはしません。 そのかわり、ボランティア達が真剣に取り組むことをやめてしまうため、 外から口を出す人がどんどん少なくなっていくだけです。 バグ報告や小規模な修正をたまに行う形で活動は続きますが、 大規模なコードの貢献や、設計上の議論に外部から人が参加するといったことはなくなってしまいます。 人々は自分に何が期待されているのかを感じ取り、期待に応えようと動いたり、 それを裏切ったりするのです。

お金は注意深く扱う必要がありますが、 そうしたからといってプロジェクトへの影響力を買えるわけではありません。 ほとんどの場合は、買えるのですが、 プロジェクトに直接影響力を行使できるわけではない、というのがミソです。 単純な商取引では、欲しいものとお金を交換します。あなたが追加して欲しい機能があれば、 契約にサインし、お金を払い、作業をしてもらいます。 オープンソースプロジェクトでは、事はそう簡単ではありません。 あなたは開発者達と契約することが出来ます。しかし、彼らがもし、 お金を払うだけで開発コミュニティーにその有償の成果を取り込んでもらえると保証したのなら、 彼らは — そしてあなたも — 勘違いをしています。 コミュニティーは、成果物そのものの利点と、 それがどの程度ソフトウェアのビジョンに合っているかに応じてそれを受け入れるのです。 あなたはソフトウェアのビジョンについて口を出す権利はありますが、 あなたの意見が唯一の声というわけではないのです。

よって、お金でプロジェクトへの影響力を買うことはできません。しかし、 影響力に 繋がるもの を買うことはできます。 もっとも明快な例はプログラマーを買うことです。 優れたプログラマー達を雇えば、彼らはソフトウェアに関する経験を積み、 コミュニティーで信頼を得るまでプロジェクトに張り付きます。 そうすれば、他のメンバーと同じ手段でプロジェクトに影響を与えることができます。 彼らはそれぞれが投票権を持つ場合もあれば、人数が多い場合にはブロック投票権を持つこともあります。 彼らがプロジェクトで尊敬を得れば、投票権以上の影響力を持つことになるでしょう。 雇われている開発者は自分の動機を偽る必要はありません。 結局、ソフトウェアに変更を加えたい人は誰でも、それぞれに理由があるものです。 企業がソフトウェアを変更したい理由が、他より正しくない、ということはありません。 企業の目標がプロジェクトで重視されるかどうかは、 企業規模や予算、もしくはビジネスプランによって決まるのではなく、 企業を代表している人たちのプロジェクト内での地位によって決まるのです。

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

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

コスト負担を共有する

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

例: http://www.openadapter.org/, http://www.koha.org/

サービスを拡大する

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

例: CollabNethttp://subversion.tigris.org/ をサポートしていること(お断り: これは筆者のルーチンワークですが、これがこのモデルの最良の例です)

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

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

競争相手を弱体化させる

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

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

マーケティング

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

デュアルライセンス

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

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

寄付を受ける

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

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

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