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

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

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

CollabNet は Subversion プロジェクトで専ら働いてもらうために Mike を雇いました。 彼を知っている人達のうち、 彼のコーディング技術やプロジェクトですぐに働けるかどうかについて疑う人は誰もいませんでした。 それに、ボランティアの開発者は CollabNet に雇われている開発者達ととても良い関係を築いていて、 CollabNet が彼を雇った段階でコミット権限を与えてもほとんどの人は多分反対しなかったでしょう。 しかし、CollabNet はそうすることで悪しき前例を作ってしまうことを知っていました。 仮に Mike に CollabNet が独断でコミット権限を与えてしまうと、 CollabNet はプロジェクトに一番カネを出しているという理由だけで、 プロジェクトが設定したガイドラインを無視する権利があると宣言することになってしまいます。 それによる影響はすぐには顕在化しないでしょうが、 カネを貰っていない開発者がコミッターを選ぶ権利を奪われたと感じてしまう事態が徐々に出てくるでしょう。 CollabNet に雇われていない人がコミット権限を得るには、 それなりの努力をしなければなりません。 — しかし、CollabNet はカネを出すだけでコミット権限を手に入れているのです。

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

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

(コミット権限に関する似たような話として、Danese Cooper のブログエントリ http://blogs.sun.com/roller/page/DaneseCooper/20040916 を見るとよいでしょう。 Cooper は そのとき サン・マイクロシステムズ の "オープンソースの部署" にいました — それが彼女の公の肩書きだと思います — このブログエントリでは、 Tomcat の開発コミュニティーが、どのようにして自分たちと同じコミット権限に関する基準を サン・マイクロシステムズ に守らせたかについて説明しています。)

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