カネと開発者とプロジェクトの不思議な関係：オープンソースソフトウェアの育て方（3/3 ページ）

[Karl Fogel， ]

カネで愛は買えない

　あなたがカネをもらって雇われている開発者なら、カネで買えるものと買えないものに関する基準を早い段階から設定するようにしましょう。これは、あなたの気高くて侵し得ない性分について、1日に2回メーリングリストに繰り返し投稿することではありません。カネが作り出す可能性がある葛藤を鎮める機会を探っておくべき、というだけです。そういった葛藤が既にあるものと考える必要はありませんが、起きる可能性があることを知っている、ということは態度で示す必要があります。

　そういった態度を示した良い例がSubversionプロジェクトで起こりました。Subversionは、何人かの開発者（お断り：わたしもそのうちの1人です）に給料を支払っていたCollabNetが始めたものです。CollabNetは、プロジェクト開始時からずっとプロジェクトに一番カネを出しています。プロジェクトが始まってすぐ、CollabNetはマイク・ピラートという別の開発者を雇いました。彼を雇うまでに、コーディングは既に始まっていました。Subversionはまだ開発の初期段階でしたが、既に基本的なルールを備えた開発コミュニティーができ上がっていたのです。

　マイクを雇うことで、面白い疑問が出てきました。Subversionプロジェクトには、新しい開発者にコミット権限をどうやって与えるかに関するルールが既にありました。まず、彼は開発用メーリングリストに修正プログラムを幾つか投稿します。十分な量の修正が彼の修正プログラムによって行われ、ほかのコミッターたちは、彼が自分がしていることをよく理解していることを知ります。その後、コミッターの誰かが彼は直接コミットしたらいいじゃないかと提案します（コミッター項で説明していますが、この提案は非公式に行います）。そして提案をした人の一人が彼にメールを送り、既にいるコミッターたちが同意するものと見做して、プロジェクトリポジトリへのコミット権限を与えるのです。

　CollabNetはSubversionプロジェクトでもっぱら働いてもらうためにマイクを雇いました。彼を知っている人たちのうち、彼のコーディング技術やプロジェクトですぐに働けるかどうかについて疑う人は誰もいませんでした。それに、ボランティアの開発者はCollabNetに雇われている開発者たちととても良い関係を築いていて、CollabNetが彼を雇った段階でコミット権限を与えてもほとんどの人はたぶん反対しなかったでしょう。

　しかし、CollabNetはそうすることで悪しき前例を作ってしまうことを知っていました。仮にマイクにCollabNetが独断でコミット権限を与えてしまうと、CollabNetはプロジェクトに一番カネを出しているという理由だけで、プロジェクトが設定したガイドラインを無視する権利があると宣言することになります。それによる影響はすぐには顕在化しないでしょうが、カネをもらっていない開発者がコミッターを選ぶ権利を奪われたと感じてしまう事態が徐々に出てくるでしょう。CollabNetに雇われていない人がコミット権限を得るには、それなりの努力をしなければなりません――しかし、CollabNetはカネを出すだけでコミット権限を手に入れているのです。

　こうした理由から、マイクはほかのボランティアの開発者と同様に、コミット権限がない状態でCollabNetでの仕事を始めることに同意しました。彼は公のメーリングリストに修正プログラムを送りました。それはプロジェクトのメンバー全員でレビューできる状態にありましたし、また現にレビューされました。CollabNetはメーリングリスト上で、マイクを雇ったにもかかわらずわざとコミット権限を与えていないと宣言したので、行き違いが起こることはありませんでした。マイクは数週間堅実に働き、誰かが彼にコミット権限を与えてはどうかと提案し、それは受け入れられました。これは受け入れられると分かっていたことです。（提案した人がCollabNetが雇った開発者だったかどうかわたしは覚えていません）

　こうした方針を一貫して守ることで、カネでは買えないことがある、ということを人々は信じるようになります。こういう点で信用されることは、技術的な議論をしているときでも通用する価値があります。つまり、後で蒸し返されることを防ぐことにもなるのです。議論が白熱してくると、人は技術的でない点で議論に勝つ方法を探すようになります。プロジェクトに一番カネを出している人は、プロジェクトに深くかかわり、プロジェクトが採る方向性について深い関心があるだけに、ほとんどの人から格好の攻撃の対象とされます。プロジェクトを始めてすぐの段階からガイドラインを実直に守ることで、カネを出す人は自分自身を他と同列に扱っているのです。

　（コミット権限に関する似たような話として、ダネーゼ・クーパーのブログエントリ「A strong OpenOffice.org community is the key」を見るとよいでしょう。クーパーはそのときサン・マイクロシステムズの“オープンソースの部署”にいました――それが彼女の公の肩書きだと思います――このブログエントリでは、Tomcatの開発コミュニティーが、どのようにして自分たちと同じコミット権限に関する基準をサン・マイクロシステムズに守らせたかについて説明しています）

　プロジェクトにカネを出す人が、ほかの人と同じルールを守る必要があることは、誰かがカネを出す場合に優しい独裁者モデル（章4.プロジェクトの政治構造と社会構造の優しい独裁者項を参照してください）がやや機能しにくいことを意味しています。優しい独裁者がプロジェクトに一番カネを出している場合は特にそうでしょう。独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、プロジェクトにカネを出している人がコミュニティーのルールを守っていると証明することは困難です。必ずしも不可能ではありませんが。それには、外部の開発者と同じ視点から物事を見ることができ、適切に行動できる人で、かつカネを出せる人がプロジェクトリーダーになる必要があります。その場合でも、コミュニティーで不満が広がる兆しが明るみに出てしまう場合に備えて、独裁的ではないやり方で提案をするのはよい考えです。

著者：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)

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

原文へのリンク