第5章 カネに関する問題

目次

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

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

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

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

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

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

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

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

Crowdfunding: Kickstarter, etc

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 tbd

Kickstarter is the obvious place to start, but there are other funding systems too. Look at campaigns that have used indiegogo, snowdrift (if in production by then), ask around for others. Use Michael Bernstein's tips on how to do it right.