オープンソース開発者との好ましい“契約”：オープンソースソフトウェアの育て方（1/3 ページ）

契約は、フリーソフトウェアの世界では注意深く扱う必要があります。ここでは、契約を成功させるために最も良い戦略を考えるとともに、契約相手をいかにして選べばよいのかについて考えます。

[Karl Fogel， ]

契約する

　契約は、フリーソフトウェアの世界では注意深く扱う必要があります。理想を言えば、契約を結んで作業した人の成果物がコミュニティーに受け入れられ、公のリリースに取り込まれるのが望ましいです。

　理屈の上では、成果物の品質が良く、それがプロジェクトのガイドラインを満たしている限り、誰と契約しようが問題ありません。この理屈と実際は一致することもありますし、そうでないこともあります。つまり、品質が良い修正プログラムなら、それがまったく知らない人が書いたものであっても、一般的にはソフトウェアに取り込むことができるということです。

　困るのは、重要な改良や新機能の追加を行う良質の修正プログラムをまったく知らない人に作ってもらうのはとても難しいということです。作業を請け負う人には、プロジェクトでまず議論してもらわないといけません。議論にかかる時間は正確に予測できません。もしあなたが時給単位でお金を払っているのなら、予想以上のお金を支払うことになるかもしれません。逆に固定給であれば、その人はもらう金額に見合わない量の仕事をする羽目になるかもしれません。

　この問題に対処する方法が2つあります。望ましいのは、過去の経験に照らして議論にかかる時間を推測し、誤差を少し足しておきます。その値に基づいて契約するのです。これは、問題を独立した多くの小さな断片にできるだけ分割し、それぞれの断片の予測可能性を増やすのにも役立ちます。

　別のやり方として、修正プログラムだけを作ってもらう契約を交わし、それを公のプロジェクトに取り込んでもらうことを別の問題として扱う方法があります。こうすると契約書を書くのは楽になりますが、あなたがプロジェクトに依存する間、またはそれと同様の機能をプロジェクトの本流に取り込んでもらうまでの間、契約で作られた修正プログラムを維持するのに四苦八苦することになります。

　もちろん、前者の望ましい方法を採ったとしても、修正プログラムが取り込まれることを契約の条件にはできません。なぜなら、これは状況によっては売っていないものを売ってしまうことになるからです（もし、プロジェクトが対象となる機能をサポートしないと決めたらどうなるでしょう？）。しかし、変更をコミュニティーに受け入れてもらい、彼らが承知すればそれをリポジトリにコミットしてもらえるよう、誠意をもって努力することを契約の条件にすることはできます。例えば、プロジェクトがコード変更に関する基準を持っている場合は、契約でそうした基準を参照した上で、成果物はそれを満たすように取り決めることができます。実際、このやり方で契約の当事者全員が望む結果が普通は出てきます。

　契約を成功させるために最も良い戦略は、プロジェクトの開発者を雇うことです――契約の相手としてはコミッターが望ましいです。これは影響力を買っているように見えますし、実際そうですが、見た目ほど破たんしているわけではありません。プロジェクトの開発者は、主にコードの質が高いことと、ほかの開発者と交流しているからこそ、影響力を持っているのです。

　開発者があることを成し遂げる契約をしたからといって、彼のそうした地位を高めることにはなりませんし、傷つけることもありません。ただ、契約をすることで、周囲の人が彼のことをあれこれせんさくするようになるかもしれません。ほとんどの開発者は、不適切、または多くの人が嫌っている新機能の導入を支援することで、長い時間を掛けて築いてきたプロジェクト内での地位を危険にさらしたりはしません。そういう目的で実際に開発者を雇うときは、どういう変更がコミュニティーに受け入れられやすいかについて、あなたはアドバイスをもらうはずです。

　また、プロジェクト内の優先順位をわずかながら変更させることになります。プロジェクト内の優先順位づけは、開発者が何に時間を掛けるかの問題にすぎないので、開発者の時間を契約で買うとすると、彼の仕事の優先度が少し変わることになるからです。これは経験を積んだオープンソースプロジェクトの開発者にとって避け難い現実ですし、雇い主が課す仕事を単にそれが先に片づけられそうだという理由だけで、それだけに注意を向ける開発者も少なからずいます。彼らはその仕事を早く片づける後押しをしてくれます。彼らはまったくコードを書かず、設計について議論したり、コードをレビューしたりしているだけかもしれませんが、これらはとても役に立つものです。

　これまで述べてきたすべての理由から、契約相手になる開発者は、プロジェクトに既に参加している人をランク付けして選ぶのが一番よいのです。