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

» 2009年09月18日 09時00分 公開
[Karl Fogel, ]
前のページへ 1|2|3       

レビューを行い、変更をソースコードに取り入れる

 契約して仕事をうまく遂行するために、コミュニティーが果たす役割は依然として重要です。変更の規模が大きい機能設計やレビューの過程に、コミュニティーが後付けでかかわることはできません。コミュニティーが参加するのは仕事の一部でなければなりません。このことは仕事を受ける人も必ず受け入れなければなりません。コミュニティーがかかわることが仕事の邪魔になると考えないでください――コミュニティーを仕事とは独立した設計や品質保証の部署として取らえるようにしましょう。コミュニティーがかかわるのを我慢するのではなく、利益になることとして強く追求すべきです。

  • ケーススタディ:CVSパスワード認証プロトコルの場合

 1995年、わたしはCVS(Concurrent Versions System)のサポートと機能強化を行うために2人でチームを組んでいました。パートナーのジムとわたしは、その時点では非公式ながらCVSのメンテナでした。しかし、わたしたちは既にいるCVSの開発コミュニティーとどう連携していくかについて、あまり深く考えたことはありませんでした。ただ、コミュニティーの人たちがパッチを送ってくれば、自分たちはそれを適用するだけ、といった感じでした。

 そのとき、ネットワークを介してCVSを操作するには、rshのようなリモートログインのプログラムを使うしかありませんでした。CVSにアクセスするのにログインパスワードを使うのは、セキュリティ上のリスクがあるのが明らかでした。新しい認証機構を追加することで、CVSを離れたオフィスからネットワーク越しに安全に操作できるようにするために、ある投資銀行がわたしたちを雇ったのです。

 ジムとわたしは契約を結び、新しい認証機構を設計する作業に腰を据えて取り組みした。わたしたちが思いついたのはとても単純なもの(米国合衆国は、当時暗号化に関するプログラムに輸出規制をかけていました。よって、暗号化の強度が高い認証機構を実装できなかったのですが、このことは顧客も理解してくれていました)でしたが、この手のプロトコルは設計したことがなかったので、専門家から見れば明らかな間違いが残っていました。

 この手の間違いは、設計を提案する文書を書いて、ほかの開発者にレビューしてもらえば容易に発見できるものでした。しかし、当時のわたしたちには開発用のメーリングリストをリソースとして使うという考えがなかったため、そうしませんでした。コミュニティーの人たちはわたしたちが何をコミットしても受け入れることが分かっていましたし、それに――自分たちが無知であることが分からなかったので――自分たちがやっていることを他人が見える形にはしなかったのです。例えば、修正プログラムを頻繁に投稿したり、小さな理解しやすい単位で特別なブランチにコミットしたりするなど、です。結果としてできた認証プロトコルは、あまりできがよくありませんでしたし、一度作ってしまったら、互換性の問題を考えると改良も難しいものだったのです。

 問題の根本は、経験不足でした。わたしたちは知るべきことを容易に学ぶことができたはずなのに、学ぼうとしなかったのです。開発コミュニティーに対する態度にも問題がありました。わたしたちは、レビューをしてもらった上で変更を取り入れてもらうことを変更の質を上げるためのプロセスというよりは、障害だと考えていたのです。自分たちがやることはほとんどすべて受け入れてもらえると(当時は)思い込んでいたので、ほかの人を巻き込もうとする努力をしなかったのです。

 契約する相手を選ぶときは、適切な技術スキルと経験を持った人を選びたいのは明らかですが、コミュニティーにいるほかの開発者と建設的なやり取りをした実績がある人を選ぶことも重要です。そうすれば、実質的に1人分以上の成果を得ることができます。つまり、堅固で維持しやすいやり方で仕事をしてくれる、専門家のネットワークとつながりを持ったエージェントを雇うことになるのです。

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


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


前のページへ 1|2|3       

content on this article is licensed under a Creative Commons License.

注目のテーマ