契約は、フリーソフトウェアの世界では注意深く扱う必要があります。 理想を言えば、契約を結んで作業した人の成果物がコミュニティーに受け入れられ、 公のリリースに取り込まれるのが望ましいです。理屈の上では、 成果物の品質が良く、それがプロジェクトのガイドラインを満たしている限り、 誰と契約しようが問題ありません。この理屈と実際は一致することもありますし、 そうでないこともあります。 つまり、品質が良い修正プログラムなら、それが全く知らない人が書いたものであっても、 一般的にはソフトウェアに取り込むことが できる ということです。 困るのは、重要な改良や新機能の追加を行う良質の修正プログラムを全く知らない人に作ってもらうのはとても難しいということです。 作業を請け負う人には、プロジェクトでまず議論してもらわないといけません。 議論にかかる時間は正確に予測できません。 もしあなたが時給単位でお金を払っているのなら、 予想以上のお金を支払うことになるかもしれません。 逆に固定給であれば、その人は貰う金額に見合わない量の仕事をする羽目になるかもしれません。
この問題に対処する方法がふたつあります。望ましいのは、 過去の経験に照らして議論にかかる時間を推測し、誤差を少し足しておきます。 その値に基づいて契約するのです。 これは、問題を独立した多くの小さな断片にできるだけ分割し、 それぞれの断片の予測可能性を増やすのにも役立ちます。別のやり方として、 修正プログラムだけを作ってもらう契約を交わし、 それを公のプロジェクトに取り込んでもらうことを別の問題として扱う方法があります。 こうすると契約書を書くのは楽になりますが、 あなたがプロジェクトに依存する間、 またはそれと同様の機能をプロジェクトの本流に取り込んでもらうまでの間、 契約で作られた修正プログラムを維持するのに四苦八苦することになります。 もちろん、前者の望ましい方法をとったとしても、 修正プログラムが取り込まれることを契約の条件には出来ません。 なぜなら、これは状況によっては売っていないものを売ってしまうことになるからです。 (もし、プロジェクトが対象となる機能をサポートしないと決めたらどうなるでしょう？) しかしながら、変更をコミュニティーに受け入れてもらい、 彼らが承知すればそれをリポジトリにコミットしてもらえるよう、 誠意をもって 努力することを契約の条件にすることはできます。 たとえば、プロジェクトがコード変更に関する基準を持っている場合は、 契約でそうした基準を参照した上で、成果物はそれを満たすように取り決めることができます。 実際、このやり方で契約の当事者全員が望む結果が普通は出てきます。
契約を成功させるために最も良い戦略は、プロジェクトの開発者を雇うことです — 契約の相手としてはコミッターが望ましいです。 これは影響力を買っているように見えますし、実際そうですが、 見た目ほど破綻しているわけではありません。 プロジェクトの開発者は、主にコードの質が高いことと、 他の開発者と交流しているからこそ、影響力を持っているのです。 開発者があることを成し遂げる契約をしたからといって、 彼のそうした地位を高めることにはなりませんし、傷つけることもありません。 ただ、契約をすることで、周囲の人が彼のことをあれこれ詮索するようになるかもしれません。 ほとんどの開発者は、不適切、または多くの人が嫌っている新機能の導入を支援することで、 長い時間かけて築いてきたプロジェクト内での地位を危険に晒したりはしません。 そういう目的で実際に開発者を雇うときは、 どういう変更がコミュニティーに受け入れられやすいかについて、あなたはアドバイスを貰うはずです。 また、プロジェクト内の優先順位をわずかながら変更させることになります。 プロジェクト内の優先順位付けは、開発者が何に時間を掛けるかの問題にすぎないので、 開発者の時間を契約で買うとすると、彼の仕事の優先度が少し変わることになるからです。 これは経験を積んだオープンソースプロジェクトの開発者にとって避け難い現実ですし、 雇い主が課す仕事を単にそれが 先に片付けられそう だという理由だけで、 それだけに注意を向ける開発者も少なからずいます。 彼らはその仕事を早く片付ける後押しをしてくれます。 彼らは全くコードを書かず、設計について議論したり、 コードをレビューしたりしているだけかもしれませんが、これらはとても役に立つものです。 これまで述べてきたすべての理由から、契約相手になる開発者は、 プロジェクトに既に参加している人をランク付けして選ぶのが一番よいのです。
プロジェクトの開発者を雇うとすると、疑問が二つ出てきます。 契約を公にしない方がいいのでしょうか？ また、仮に公にするとして、 特定の開発者以外の人と契約しないことで、 コミュニティーに緊張関係を作ってしまうことを気にかけるべきなのでしょうか。
可能であれば、契約することを公にするのがベストです。仮にできなければ、 契約した開発者の振る舞いがコミュニティーのメンバーからは不自然に見えるかもしれません— おそらく、彼はどういうわけか今まで全く興味を示さなかった機能に、 突然高い優先度を設定するようになるでしょう。 彼がその機能を欲しがる理由を尋ねられたとき、 契約をしている事実を話せないのだとしたら、 どうやってその理由をもっともらしく説明したらいいのでしょう？
また、あなたが関わっている作業がさも重要なことのように振る舞ってはいけません。 開発者を雇っているからというだけの理由で、 自分の投稿を重く扱うべきという厚かましい態度をメーリングリスト上でとる人がいました。 こうした態度は、開発者を雇う人が — 契約することで生み出される コードではなく、契約している事実を重視していることを示していますが、 他の開発者からすれば、コードだけが重要なのです。 どんなときでも、誰が誰にお金を払っているのかではなく、 技術的な問題に注意を払うべきです。 契約にまつわる問題をうまくコミュニティーで処理している、 Subversion の開発者を例に挙げましょう。 彼が自分のコード変更についてIRCで議論しているとき、 彼は小声で (IRC の privmsg というプライベートな会話を使って) 今書いている機能や修正プログラムを書くのに、 お金をもらっていることを他のコミッターに伝えます。 彼はその変更をずっと望んでいたし、 その作業をしてお金を貰えるのが幸せであるかのように一貫して振る舞います。 彼は契約相手の身元を明かすかもしれませんし、明かさないかもしれませんが、 いずれにせよ契約の詳細に立ち入ったりはしません。 契約の話は、どうやって作業を成し遂げるかについての技術的な議論をするときに、 補足的にするだけです。
この例は、契約を公にした方がいいもうひとつの理由を示しています。 契約にお金を出している組織が複数あった場合、 一方が何をしようとしているのかがわかれば、リソースを共同で出資できるからです。 上の場合、プロジェクト最大の出資者 (CollabNet) はこうした出来高払いの契約に関わっていませんが、 誰か他の組織があるバグ修正にお金を出していれば、 CollabNet はリソースを他のバグに振り向けることができ、 プロジェクト全体の効率が上がるのです。
他の開発者は、プロジェクトで契約している人がいることを嫌がるでしょうか？ 一般的には NO です。特に、お金をもらっている人がコミュニティー内で地位を確立し、 尊敬されているメンバーであるときは特にそうです。 契約がすべてのコミッターに平等に行き渡ると思っている人なんて誰もいません。 コミュニティーのメンバーは、スポンサーと長期に渡って関係を築くことが重要だとわかっていますが、 不安なのは、一度あなたが信頼できる人を見つけてしまったら、 公平さを保つために他の人に仕事を振りたがらないことでしょう。 これについては次のように考えましょう: はじめに誰かを雇うとき、必ず 誰かを 選ばなければならないのだから、 反対はでないでしょう — 仮に誰も雇わなくてもあなたの落ち度はありません。 後に、2度目になって同じ人を雇ったとしても、それは常識から外れていません。 あなたは彼を知っていて、直近の仕事は成功しているのです。 どうしてリスクをとる必要があるでしょうか？ こうした理由から、 仕事を皆に平等に振るのではなくて、 コミュニティー内に突出した人がひとりやふたり出てきたっておかしくありません。
契約して仕事をうまく遂行するために、コミュニティーが果たす役割は依然として重要です。 変更の規模が大きい機能設計やレビューの過程に、コミュニティーが後付けで関わることはできません。 コミュニティーが参加するのは仕事の一部でなければなりません。 このことは仕事を受ける人も必ず受け入れなければなりません。 コミュニティーが関わることが仕事の邪魔になると考えないでください — コミュニティーを仕事とは独立した設計や品質保証の部署として捉えるようにしましょう。 コミュニティーが関わるのを我慢するのではなく、利益になることとして強く追求すべきです。
1995年、私は CVS (Concurrent Versions System : http://www.cvshome.org/ を参照してください) のサポートと機能強化を行うために二人でチームを組んでいました。パートナーのジムと私は、その時点では非公式ながら CVS のメンテナーでした。しかし、私たちは既にいる CVS の開発コミュニティーとどう連携していくかについて、あまり深く考えたことはありませんでした。ただ、コミュニティーの人たちがパッチを送ってくれば、自分たちはそれを適用するだけ、といった感じでした。
そのとき、ネットワークを介して CVS を操作するには、rsh のようなリモートログインのプログラムを使うしかありませんでした。CVS にアクセスするのにログインパスワードを使うのは、セキュリティ上のリスクがあるのが明らかでした。新しい認証機構を追加することで、CVS を離れたオフィスからネットワーク越しに安全に操作できるようにするために、ある投資銀行が私たちを雇ったのです。
Jim と私は契約を結び、新しい認証機構を設計する作業に腰を据えて取り組みました。私たちが思いついたのはとても単純なもの (アメリカ合衆国は、当時暗号化に関するプログラムに輸出規制をかけていました。よって、暗号化の強度が高い認証機構を実装できなかったのですが、このことは顧客も理解してくれていました) でしたが、この手のプロトコルは設計したことがなかったので、専門家から見れば明らかな間違いが残っていました。この手の間違いは、設計を提案する文書を書いて、他の開発者にレビューして貰えば容易に発見できるものでした。しかし、当時の私たちには開発用のメーリングリストをリソースとして使うという考えがなかったため、そうしませんでした。コミュニティーの人たちは私たちが何をコミットしても受け入れることがわかっていましたし、それに — 自分たちが無知であることがわからなかったので — 自分たちがやっていることを他人が見える形にはしなかったのです。たとえば、修正プログラムを頻繁に投稿したり、小さな理解しやすい単位で特別なブランチにコミットしたりするなど、です。結果としてできた認証プロトコルは、あまり出来がよくありませんでしたし、一度作ってしまったら、互換性の問題を考えると改良も難しいものだったのです。
問題の根本は、経験不足でした。私たちは知るべきことを容易に学ぶことができたはずなのに、学ぼうとしなかったのです。開発コミュニティーに対する態度にも問題がありました。私たちは、レビューをして貰った上で変更を取り入れてもらうことを変更の質を上げるためのプロセスというよりは、障害だと考えていたのです。自分たちがやることはほとんど全て受け入れてもらえると(当時は)思い込んでいたので、他の人を巻き込もうとする努力をしなかったのです。
契約する相手を選ぶときは、適切な技術スキルと経験を持った人を選びたいのは明らかですが、コミュニティーにいる他の開発者と建設的なやりとりをした実績がある人を選ぶことも重要です。そうすれば、実質的にひとり分以上の成果を得ることができます。つまり、堅固で維持しやすいやり方で仕事をしてくれる、専門家のネットワークと繋がりを持ったエージェントを雇うことになるのです。