オープンソースソフトウェアの育て方

　本書の英語版（『Producing Open Source Software』）が世に出たあと、この本は翻訳者のコミュニティーに翻訳してもらえるようになりました。これは名誉なことですし、私にとって予想外のことであり、喜ばしいことです。翻訳作業にあたっては、私は彼らの翻訳のほとんどを受動的に受け入れていただけでした。残念なことに私は日本語が読めないので、この日本語版の翻訳についても同じことが言えます。

私は翻訳の中身についてはコメントできませんが、少なくとも翻訳してくれた人たちについてはコメントできます。彼らは初めから終わりまで翻訳を楽しんでくれました。私の仕事はといえば、彼らが作業するための環境（リポジトリやメーリングリストなど）を整えて、必要なときに質問に答えたら、あとは彼らの作業の邪魔をしないようにするだけでした。　私が整えた作業環境も、特に作業しやすいというわけではありませんでした。翻訳作業にあたっては、コンピューターの言語と人間の言語の中間にあたる、文書を生成するための言語をXMLで記述する必要がありました。さらに、文章を記述したファイルというよりはむしろ、プログラムのファイルを管理するのに向いているチェックイン／チェックアウト方式のシステムを使わなければなりませんでした ^[1]。　彼らはこうした負担に文句も言わず我慢してくれましたし、翻訳をしながら英語版の間違いまで修正してくれる人もいました。ちょうどフリーソフトウェアのように、コードに対して多くの眼を光らせることで、オリジナルの作者が見逃していたバグ（間違い）を発見していたのです。

　もちろん、オリジナルの作者が見逃していた間違いが見つかるのは、些細な副作用にすぎません。それ以上に、300ページを超える本全体が日本人の読者の母国語で読めるようになっているということが重要な成果です。オンラインで無料で読むこともできますし、お好みであれば、プロの手で印刷されて製本されたものも有償で読むことができます。

この意味について、ちょっと考えてみましょう。

　相対的にみて、この本の対象読者は多くありません。私はこの本をミリオンセラーにしようとは思っていませんし、それは出版元も同様でした。それにもかかわらず、フリーという考え方とオープンソースソフトウェアに関心があったからという理由で、2人の人間がこの本全体を日本語に翻訳しようと一歩を踏み出したのです。彼らの努力のおかげで、翻訳しなければ読めなかったであろう何百万人もの人々が、この本を読むことができるようになっています。おそらく彼らのほとんどは決してこの翻訳を読むことはないでしょうが、きっと読む人もいるでしょう — ちょうど私が、この本がどの言語に翻訳されるかは予想できないのと同様に、翻訳する人も私も、新しい読者が翻訳をどのように使うかは予想できないのです。

これは英語版がフリーで、制限のないライセンスで、オンライン上に公開されていたからこそ起こったことです。翻訳する人たちは、オリジナルを日本語に翻訳しようと自分たちで決めました。彼らは誰の許可も得る必要がありませんでしたし、私の協力がなかったとしても（もちろん、私は喜んで協力しましたが）すべての翻訳をやり遂げることができたでしょう。ここで述べていることは、オープンソースソフトウェアそのものと明らかに似ています。何かがフリーで公開されていて、外見がボランティアを惹きつける魅力を持っていた場合には、どんなことでも可能になるのです。私は自分の小さな本がこんなに多くの潜在的な新しい読者を獲得するとは思いもしませんでしたが、2人の翻訳者によって、それが成し遂げられたのです。

　フリーでないライセンスでリリースされた本の場合、つまり、伝統的な著作権に基づく制限があった場合はどうでしょうか？　残念ですが、そうした本は翻訳される多くの可能性の芽を摘んでしまっていると思います。たとえば、この本は日本語だけでなく、約60人の翻訳者によって8つの言語に翻訳されています。翻訳が既に完了している言語もありますし、まだ現在進行中のものもあります。そしてこの本は相対的にマイナーな本なのです！　本屋に並んでいるほとんどの本は（オリジナルの言語の範疇では）私の本より人気がありますが、翻訳されることは少ないのです。

これは少々残念に思えます。私はこの本で、フリーソフトウェアプロジェクトがどのように動いているのかをわかりやすく説明しようとしていますが、フリーソフトウェアやオープンソースの原理が社会的または道徳的にどのような意味合いを持つのかについては、触れていません。しかしこの日本語版に向けた序文の中で、ちょっとだけ直接触れておくことにします。日本語版の翻訳は、オリジナルの本がフリーであることを2人のボランティアが最大限に活用したからこそ可能になりました。仮に同様の自由が多くの本に広まれば — むしろ、なぜすべての本に広まらないのでしょう？ — 日本人は、より多くの洋書を日本語で読めるようになるでしょう。他の国の人々だって同じです。

　フリーソフトウェアの世界で何年も働いてきて、私は本の翻訳を出版するのにいちいち許可を求めなければならないのは変だと思っています。私の本で起こっていることは、ほとんどのフリーソフトウェアのドキュメントで起こっていることとまったく同じです。つまり「駄目」と言う人が誰もいないので、翻訳は自然発生的に始められます。あなたがこの日本語版を読むときには、この本に書いてある力学と同じ力が働いた結果として、この本があるのだということを心に留めておいてください。力学とは、既存の作品を自分たちの都合に合わせて改変する完全な自由が与えられていて、他人と協力するのも自由な場合に人々は何をするのか、ということです。日本語版が存在することで、こうした自由がソフトウェアだけでなく、書籍や他の種類の作品にも広まっていけば、とても素晴らしいことです。

日本語版の訳者である高木正弘氏と高岡芳成氏には心からお礼を申し上げます。彼らの忍耐強さと熱意を多くの読者が評価してくれることを願っています。

^[1] 実際は DocBook と呼ばれる文書用のマークアップ言語を XML で記述し、Subversion で管理していました。 XML や Subversion に慣れない翻訳者もいたので、苦労していた人もいたのは事実です。

序文

この本を書いた理由は？
どんな人たちに読んでほしい？
情報源
謝辞
免責
日本語版について

この本を書いた理由は？

パーティの場で「フリーソフトウェアを書いているんです」と言っても、以前のように怪しげな目を向けられることはなくなりました。「あぁ、オープンソースね。Linuxみたいなものでしょ？」とみんなすぐにわかってくれます。「そうそう！　そうなんだ」。もはや完全な辺境でなくなったのは嬉しいことです。次にくる質問は、ちょっと前までは「それで、どうやってお金を稼いでいるの？」に決まっていました。答えとして、私はオープンソースの経済学について手短に述べたでしょう。すなわち、あるソフトウェアが存在することで利益を得る組織があるのですが、その組織はそのソフトウェアを販売する必要はなく、ただそのソフトウェアが利用可能であり保守されているということを確かめたいのです、商品ではなく道具として。

しかし、最近は「オープンソースでどうやって儲けるの？」的な質問は少なくなってきました。いまやオープンソースソフトウェア ^[2] でお金を稼ぐことは不思議でも何でもなくなったのです。オープンソースを仕事にしている人たちがいるということを、開発者以外でも多くの人が理解しています—あるいは少なくとも驚かないようになってきています。最近は、こんな質問に変わってきました。「オープンソースって、いったいどういう仕組みになっているんですか？」

当時の私は、その質問にうまく答えることができませんでした。考えれば考えるほど、その話題が複雑なものであるように思えてきたのです。フリーソフトウェアのプロジェクトを運営するというのは普通の商売とはちょっと違います（たとえば、会ったこともないボランティアのグループを相手にして自社の製品についての交渉を毎日のように行うなんてことは普通はありませんよね？）。また、ごく一般的な非営利組織を運営したり政府を運営したりというのとも少々異なります。　まぁそれぞれ似ている点もあるのですが、徐々にわかってきたのは、フリーソフトウェアは独特 （sui generis） だということです。比較対象となるものはいくらでもありますが、その中のどれとも違うのです。実際のところ、フリーソフトウェアプロジェクトを「運営することができる」という仮定さえも確かではありません。フリーソフトウェアプロジェクトを「始める」ことはできます。また、さまざまな人たちがそのプロジェクトに影響を与えることができます。中には強烈に影響を及ぼす人もいるでしょう。しかし、そのプロジェクト自体は特定の個人の所有物とすることはできません。そのプロジェクトに興味を持つ人がどこかにひとりでもいる限り、一方的にそのプロジェクトを終了することもできません。誰もが限りない力を持っています。と同時に、誰もが無力だという一面もあります。興味深い話です。

といったわけで、私は本書を執筆することになったのです。フリーソフトウェアプロジェクトは独特の文化を発展させてきました。ソフトウェアに思い通りの仕事をさせる自由が主要な信条となる気風です。それでなおその自由の結果、個々人がばらばらにコードとともに我が道を行くのではなく、熱狂的な共同作業が行われているのです。実際、協調性というのはフリーソフトウェア界で最も評価されるスキルのひとつです。プロジェクトを運営していくということは、ある種の肥大化した共同作業に従事するということです。そこでは他人と作業をする能力だけではなく、共同作業を進めるための新たな手法を創り出す能力により、ソフトウェアに具体的な利益をもたらすことができるのです。本書では、このようにプロジェクトをうまく進めていくための秘訣を説明します。決して完璧なものではありませんが、初めの一歩としては十分だと思います。

よいフリーソフトウェアを作ることは、本質的に価値のある目標です。その方法を模索している読者のみなさんが、本書で何かのヒントを得てくだされば幸いです。またそれだけでなく、実際にオープンソース開発者たちのチームに参加して、一緒に作業を進めていただけるようになることも望んでいます。志の高いメンバーとともに作業を進め、ユーザーと直接対話するのは非常に楽しいことです。うまく動いているフリーソフトウェアプロジェクトでの作業はほんとうに 「楽しい」 ものです。そして結局のところ、その楽しさがあるからこそプロジェクトがうまく進むのです。

どんな人たちに読んでほしい？

本書が対象としている読者は、これからオープンソースプロジェクトを始めようと思っている、あるいは始めてはみたもののどうすればいいのかわからないというソフトウェア開発者や管理者たちです。「オープンソースのプロジェクトに参加したいんだけれど、どうしたらいいんだろう？」という人たちにとっても役立つことでしょう。

プログラミングに関する知識は必須ではありません。ただ、ソースコードやコンパイラ、パッチといったソフトウェア工学の概念の基本は知っておく必要があります。

オープンソースソフトウェアを開発したり使用したりといった経験の有無は問いません。過去にフリーソフトウェアプロジェクトに参加した経験がある人にとっては、本書の内容の中に「そんなの当たり前じゃん」と思われる箇所がいくつも見つかることでしょう。そのように読者の経験に大きな差があるので、各セクションのタイトルはできるだけわかりやすいものにすることを心がけています。また、既によく知っている場合に読み飛ばしてもかまわない箇所についてはそれを明記しています。

情報源

本書で取り上げているネタの大半は、 5年にわたる Subversionプロジェクト（http://subversion.tigris.org/）での経験です。 Subversion はオープンソースのバージョン管理システムで、何もないところから作り上げたものです。オープンソースコミュニティーにおけるバージョン管理システムの デファクトスタンダードの座を、CVSから奪い取ることを目標としています。もともとこのプロジェクトは、私の雇用主であるCollabNet （http://www.collab.net/）が2000年の初めに開始したものでした ^[3]。 CollabNet は当初からこのプロジェクトを真に協力的なものとし、さまざまな人たちが参加しやすくするための方法を理解していました。そのおかげで、開始当初から多くのボランティア開発者の協力を得られるようになり、現在では50人以上の開発者がプロジェクトに関わるようになっています。その中にCollabNetの社員はほんの数人しかいません。

Subversion は、いろんな意味でオープンソースプロジェクトの典型例といえます。本書では、当初想定していたよりもかなり多くの材料をSubversionプロジェクトから得ました。そうなった原因のひとつは、そのほうが好都合だったからです。何か特定の問題についての例が必要になったとき、私の頭の中に最初に浮かんでくるのはいつもSubversionプロジェクトだったのです。それだけではありません。いいかげんな情報を書かないためにという一面もあります。これまでに私はいろいろなフリーソフトウェアプロジェクトに参加してきました。深く立ち入ったものもあればほんのちょっと関わっただけというものもあります。また同じような立場の友人や知人とも数多く話してきました。ただ、いざその内容を出版するとなると、その話の内容が正しいかどうかを改めて確かめる必要があります。公開されているメーリングリストのアーカイブの内容を読んだだけで他のプロジェクトに起こったいろいろな出来事について語るわけにはいきません。誰か他の人が Subversion について同じようなことをしたとしましょう。私がそれを読めば、おそらく半分くらいは間違った内容が書かれていると気づくことでしょう。そこで、私が直接関わったことのないプロジェクトに関することを例に出すときには、まずその当事者に直接話を聴き、そのとき何が起こっていたのかを知るようにしました。

私は過去5年間Subversionに関わってきましたが、それ以前も含めるとかれこれ 12 年ほどフリーソフトウェアに関わっています。 Subversion 以外に本書に影響を与えたプロジェクトには、次のようなものがあります。

フリーソフトウェア財団（FSF）の「GNU Emacs」テキストエディタプロジェクト。私はちょっとしたパッケージをいくつか保守しています。
CVS（Concurrent Versions System）。 1994–1995頃、Jim Blandyとともに熱心に取り組んでいました。しかし、それ以降はたまにしか参加できていません。
Apacheソフトウェア財団(Apache Software Foundation) のさまざまなオープンソースプロジェクト、特にAPR（Apache Portable Runtime）やApache HTTP Server。
OpenOffice.org、SleepycatのBerkeley DB、MySQLデータベース。これらのプロジェクトに対しては親密に関わっているわけではないのですが、よく観察しています。そして時にはプロジェクトの参加者と会話をすることもあります。
GNU Debugger (GDB) (同上)
Debian プロジェクト (同上)

もちろんこれがすべてというわけではありません。他のオープンソースプログラマーと同様、単に大まかな流れを把握するという目的でいろんなプロジェクトの動きをゆるやかに追いかけたりもしています。それらのプロジェクトの名前をすべてここで挙げることはできませんが、必要に応じて本文中で名前を出すようにします。

謝辞

本書を書き上げるには、当初の予定の4倍くらいの時間がかかってしまいました。その間の苦しさといったら、まるで朝から晩まで頭の上にグランドピアノがつるされているかのようなものでした。多くの方々の助けがなければ、本書を書き上げる前に頭がおかしくなってしまっていたことでしょう。

O'Reillyの編集者であるAndy Oramは、執筆者にとっては夢のような存在でした。彼はこの分野について熟知していました（実際、本書で扱ったトピックの多くは彼の助言を参考にしています）。また、それだけでなく、彼は「人が何を言おうとしているのかを察知し、それをみんなにわかりやすく伝えるにはどうしたらいいのかを助言する」という類まれな才能の持ち主だったのです。彼と仕事をすることができて、大変光栄でした。また、本書の出版の提案をAndyにすぐ伝えてくれたChuck Toporekにも感謝します。

Brian Fitzpatrick は私が書いた内容を逐一レビューしてくれました。おかげで本書の内容がよりよいものとなっただけでなく、どこかコンピューターのないところへ行ってしまいたいと思ったときでも、私を執筆作業にとどまらせてくれました。 Ben Collins-Sussman と Mike Pilato も執筆の進み具合を気にかけてくれ、その週に書き終えようと思っていたあらゆるトピックに関して、いつでも喜んで、ときには長々と相談に乗ってくれました。彼らはまた、私の執筆ペースが落ちたときに声をかけてくれたり、必要なときには優しく小言を言ってくれたりしました。ありがとう。助かったよ。

私が本書を執筆しているのと同じころ、Biella Coleman は自分の学位論文を作成していました。毎日すわって執筆するということがどういうことかを彼女は知っています。彼女は自分の論文を書きつつ、私にいろいろな興味深い例を教えてくれました。またよい相談相手となってくれました。彼女はまた、人類学者としての視点からフリーソフトウェア運動に関する意見を述べてくれました。彼女が教えてくれたアイデアや参考文献は、本書を執筆する上で大きく役立ちました。 Alex Golub—彼もまた人類学者で、フリーソフトウェア活動にも足を踏み入れており、同じころに学位論文を書いてました—も、執筆を開始した当初からずっと私を助けてくれました。

Micah Anderson はどういうわけか彼自身の執筆にあまり圧迫感を感じているように見えなくて、そのことが病的で妬みを生むようなやり方で影響を与えてくれたのだけど、でも彼はいつでも友好的で、会話をしてくれて、（少なくとも一度は）技術的なサポートもしてくれました。ありがとう、Micah！

Jon Trowbridge と Sander Striker は、私を勇気付けてくれるだけでなく具体的な助言もくれました —フリーソフトウェアにおける彼らの幅広い経験は、かけがえのない資料を提供してくれました。

Greg Stein に感謝します。よき友として私を勇気付けてくれただけでなく、常にコードレビューをすることがプログラミングコミュニティーにおいてどれだけ重要であるのかということを私に教えてくれました。 Brian Behlendorf にも感謝します。彼のおかげで、公の場で議論をすることの重要性を知ることができました。この原則が本書全体に反映されていることを望みます。

フリーソフトウェアとその政治的な問題についていろいろ語ってくれた Benjamin "Mako" Hill と Seth Schoen、忙しい中スケジュールを調整してインタビューに応じてくれた Zack Urlocker と Louis Suarez-Potts、Slashcode メーリングリストへの投稿を引用することを許可してくれた Shane、そしてさまざまなホスティングサイトの比較を行ってくれたHaggen、みなさんに感謝します。

Alla Dekhtyar、Polina そして Sonya。みなさんのたゆまぬ励ましに感謝します。私はもう、帰宅して「本」を執筆するためにみんなとの夜を早々と打ちきる（あるいはむしろ、打ち切ろうとして失敗する）必要はないんだ。とっても嬉しいよ。

Jack Repenningの友情と助言に感謝します。彼は、私が安直な分析によって誤った結論を導き出そうとしていたときに厳しくそれを指摘してくれました。「ちょっとしんどいけれど、もう一度分析し直してみようよ。きっと違う結論になるから」と。彼はソフトウェア開発だけでなくソフトウェア産業に関しても長い経験の持ち主です。彼の経験が本書に反映されていることを願います。

CollabNet は、私が本書の執筆のために不規則な勤務スケジュールになることを特別に認めてくれました。そして当初の予定よりそれが長引いたときも文句ひとつ言いませんでした。経営陣がそれを許してくれるまでにどんな困難な道のりがあったのかはわかりませんが、 Sandhya Klute や Mahesh Murthy はきっといろいろ苦労したことでしょう。2人に感謝します。

Subversion 開発チームでの過去5年にわたる経験から、私は多大な影響を受けました。本書の内容のほとんどは、このプロジェクトでの経験をもとにしています。メンバー全員の名前を挙げることはしません（人数が多すぎるので）。が、もしあなたがどこかで Subversion のコミッターに出会ったら、お茶の1杯でもおごってやってください—私もそうするつもりです。

本書の内容について、Rachel Scollon に対してグチをこぼすことも多々ありました。彼女はいつもそれを受け入れてくれました。彼女とひとしきり話をしたあとは、いつも「思っていたほどたいした問題じゃなかったな」と感じたものです。助かったよ。ありがとう。

Noel Taylorには感謝してもしきれません。本書の内容について私が散々グチっていたのを聞いて「前回の執筆のとき散々グチをこぼしておいて、なんでこいつはまた別の本を書こうとしてるんだ？」と思っていたことでしょう。彼の友情と Golosá のリーダーシップのおかげで、忙しくてたまらないときでも音楽と友情だけは忘れずにいることができました。 Matthew Dean と Dorothea Samtleben にも感謝します。彼らは長年苦楽をともにしたミュージシャン仲間ですが、練習に付き合えないという私の言い訳を受け入れてくれました。 Megan Jennings は常に私に協力してくれました。自分にとってあまりなじみのないトピックについても熱心に気にかけてくれました。心細い作家にとって、これほど勇気付けられることはありませんでした。友よ、ありがとう！

Yoav Shapira、Andrew Stellman、Davanum Srinivas、Ben Hyde の4人は本書の内容をレビューしてくれました。彼らの助言があったことで、本書はよりよいものとなりました。もし彼らの素晴らしい助言をすべて取り入れることができていれば、この本はもっとよいものになっていたでしょう。時間の制約のためいくつかピックアップして取り入れざるを得なかったというのが現実ですが、それでも改善は目をみはるものになりました。

私の両親である Frances と Henry は、いつも通り私を温かく見守ってくれました。前著が技術寄りだったのに対して今回は技術面以外の内容も多く含んでいるので、きっと彼らも楽しんで読んでくれるものと思います。

最後に、Karen Underhill と Jim Blandy に謝意を表します。 Karenの友情と理解は、本書の執筆作業にとどまらずこの7年間私をずっと支えてくれました。彼女の助けがなければ本書を作り上げることはできなかったでしょう。 Jimも同じです。彼は真の友人、そしてハッカーの中のハッカー。鳥の飛び方を参考にして飛行機が発明されたのと同様に、私も彼の姿を見てフリーソフトウェアの何たるかを学んだのです。

免責

本書で表明した考えや意見は、あくまで私の個人的なものです。 CollabNet や Subversion プロジェクトの見解を代表しているとは限りません。

日本語版について

このページの正誤表、購入情報、ダウンロード情報などを「サポートページ」として、http://producingoss.com/ja/ja-support.html で公開しています。宜しければご利用ください。

『オープンソースソフトウェアの育て方』は、「Producing Open Source Software」（Karl Fogel著、2005年10月、 O'Reilly Media発行、ISBN0-596-00759-0）のオンライン版を底本にして日本語訳が行われました。原文は http://producingoss.com/en/index.html で公開されています。

^[2] ここでは「オープンソース」と「フリー」をほぼ同じ意味で使用しています。詳細は、1章導入の「「フリー」と「オープンソース」の違い」で説明します。

^[3] 日本語版注：Karl Fogel氏のウェブサイト（http://www.red-bean.com/kfogel/）などによると、 2009年7月現在は CollabNet ではなく、Ubuntuプロジェクトのコマーシャルスポンサーでもある Canonical社（http://canonical.com/）で、ソフトウェアプロジェクトのホスティングサービス Launchpad （http://launchpad.net/）などに関係しているようです。本書の本文では、氏とCollabNetの雇用関係に基づいた記述がいくつかありますが、すべて執筆時点のものとしてお読みください。

第1章導入

歴史

独占的なソフトウェアとフリーソフトウェア

意識的な抵抗
無意識な抵抗

「フリー」と「オープンソース」の違い

現状

ほとんどのフリーソフトウェアプロジェクトは失敗します。

しかし、失敗例について聞くことはあまりありません。みんなの気を引くのは成功したプロジェクトだけだからです。世の中には途方もない数のフリーソフトウェアプロジェクトが存在する ^[4] ので、たとえ成功するプロジェクトがその中のごく一部に過ぎなかったとしても、多くのプロジェクトが成功しているように見えてしまうのです。また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも私たちが失敗について聞くことがない理由のひとつでしょう。「そのプロジェクトが消滅した瞬間」というのを特定することはできません。参加者が少しずつ他へ移っていき、プロジェクトで作業するのをやめるだけなのです。「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、実際にその変更を加えた人は「それがプロジェクトに対する最後のコミットとなる」とは決して思っていなかったことでしょう。また、どれぐらい動きがなければ「止まってしまった」とみなすのかについてもはっきりした定義がありません。目だった動きが半年間なかったとき？ユーザー数の伸びが止まってしまい、結局開発者の数を超えることがなかったとき？自分の参加しているプロジェクトが結局他のプロジェクトの焼き直しであることに気づいた開発者が、現在参加しているプロジェクトを捨ててもうひとつのほうに移動したとしましょう。そして移った先のプロジェクトをどんどん成長させていきました。この場合、元のプロジェクトは「消滅した」のでしょうか？それとも「あるべき場所に移動しただけ」なのでしょうか？

このように複雑な側面があるので、いったいどの程度の割合でプロジェクトが失敗しているのかを正確に知るのは不可能です。しかし、過去10年を超えるオープンソース界での経験や SourceForge.net のデータからの推測、そしてちょっとググってみた結果はどれも同じような結果となりました。プロジェクトが失敗に終わる可能性は非常に高く、おそらく90–95%くらいと見ていいでしょう。かろうじて生き残ってはいるが、まともに機能していないプロジェクトも含めると、この数字はさらに上がるでしょう。ここでいう「まともに機能していない」とは、とりあえず動くコートは存在するが満足に使える代物ではなく、開発が進んでいるようには見えないという状態のことです。

本書の目的は、そのような失敗を避けることです。本書では、「どうやったらうまくいくか」だけではなく「どうやったら失敗するか」についても説明します。それを知ることで、問題が発生したときに軌道修正ができるようになるでしょう。本書を読み終えられた皆さんは、オープンソース開発において陥りがちな落とし穴を避けるさまざまなテクニックだけでなく、成功しているプロジェクトの巨大化や保守をうまく扱うためのテクニックも身に着けていることでしょう。成功というものはゼロサムゲームではありません。本書では、いかにして競合プロジェクトを出し抜くかといったことは扱いません。実際のところ、オープンソースプロジェクトを運営する上では他の関連するプロジェクトとの協調が重要となります。長い目で見れば、どのプロジェクトが成功してもフリーソフトウェア界全体の利益になることでしょう。

フリーソフトウェアプロジェクトが失敗に終わる原因は独占ソフトウェアプロジェクトの場合と同じだと言い切ってしまえれば話は簡単です。実際のところ、ソフトウェア産業におけるよく知られた問題 (たとえば非現実的な要件、あいまいな仕様、まずいリソース管理、不十分な設計フェーズなど) はフリーソフトウェアでも起こりうることです。これらのトピックに関しては既に大量の書物が存在するので、本書ではそれと重複するような内容は避けるつもりです。その代わりに、フリーソフトウェアに特有の問題について説明していきます。フリーソフトウェアプロジェクトが行き詰まる原因としてよくあるのが、開発者 (あるいはマネージャ) がオープンソースのソフトウェア開発に固有の問題を正しく認識していなかったことです。彼らはクローズドソースな開発における問題への対応は慣れていたかもしれません。でもそれだけではだめだったのです。

一番よくある間違いは、オープンソース自体で一儲けしようと非現実的な期待をしてしまうことです。オープンソースにしたからといって、必ずボランティアの開発者が集結してくれるとは限りません。また、すでに問題を抱えているプロジェクトをオープンソースにしたところで、その問題が自然に解決するわけでもありません。実際のところ、まったく正反対になります。オープンソースプロジェクトをはじめると、これまで自分たちだけでやっていたときと比べていろいろ複雑なことを考えなければならなくなります。また、短期的には 費用もかさむ ことでしょう。オープンにするということは、見知らぬ他人が読んでもわかりやすくなるようなコードを書くということです。また開発者用のウェブサイトやメーリングリストを整備したりする必要もありますし、最低限のドキュメントも書くことになるでしょう。これらはどれも大変な作業です。仮にどこかの開発者が「手伝ってあげようか？」と声をかけてきたとしましょう。まだその人がどれほど協力してくれそうかわからない時点でも、その人に対してプロジェクトについての説明をしたり質問に答えたりといった作業をすることになります。 Jamie Zawinski は、Mozilla プロジェクトの初期に発生した問題について次のように述べています。

オープンソースはうまく働くものである。しかし、最も大切なことは、何にでも効くような特効薬ではないということだ。もし、ここに教訓があるとすれば、死にかけたプロジェクトをつかまえて、オープンソースという魔法の妖精の粉をふりかけて、すべてが魔法のようにうまく行くなどということはない、ということだ。ソフトウェアは難しい。問題はそんなに簡単なものじゃない。
(http://www.jwz.org/gruntle/nomo.html より引用。日本語訳は http://cruel.org/jwz/nomo.html)

それに関連する間違いとしては、見栄えの調整やパッケージ作成に手を抜くというものがあります。「そんなのいつでもできるし、もうちょっとプロジェクトが落ち着いてからでいいよ」というような考えです。見栄えの調整やパッケージ作成といってもいろいろな内容が含まれますが、どれも結局はプロジェクトへの参入障壁を下げることにかかわってきます。新参者がプロジェクトに参加しやすくするには、ユーザー向けドキュメントや開発者向けドキュメントを整備したりウェブサイトを開いて初心者向け情報を掲載したりソフトウェアのコンパイルやインストールをできるだけお手軽に行えるようにしたりといった作業が必要となります。残念ながら、世の多くのプログラマーはこれらの作業を二の次にしてコードだけに注力しがちです。理由はいくつかあります。まず、それが彼らにとってあまり重要な作業ではないということです。それが役に立つのはこれまでプロジェクトにほとんどかかわってこなかった人たちであり、今までプロジェクトに参加してきた人たちにとってはあまり意味のない作業だと感じられることでしょう。結局のところ、実際にコードを書いている人にとってはパッケージなんて不要なのです。彼らはそのインストール方法も管理方法も熟知しています。だって自分自身でそれを書いているんですから。次に、見栄えをよくしたり使いやすくパッケージ化したりするのに必要なスキルは、コードを書くスキルとはまったく異なるものだということです。人はみな、自分の得意なところに力を入れたがるものです。苦手なことにちょっと取り組むだけでプロジェクトがよりよいものになるかもしれないとしても。 2章さあ始めましょう では、見栄えをよくしたりパッケージを作成したりする方法について詳しく説明します。そして、それをプロジェクトの最初期から行うべきである理由についても説明します。

次によくある誤解は「オープンソースではプロジェクト管理にあまり気を使わなくていい」とか、逆に「社内開発の場合と同じようにプロジェクト管理をしておけば、オープンソースプロジェクトも問題なく動くだろう」というものです。オープンソースプロジェクトにおいてはプロジェクト管理があまり表に出ることはありません。しかし、成功しているプロジェクトの舞台裏では、何らかのプロジェクト管理が行われています。なぜ？理由を説明するため、ここでちょっとした思考実験をしてみましょう。オープンソースプロジェクトに参加するプログラマーは、いろいろな意味でバラバラです —よく知られているように、一匹狼的な人種です—彼らはお互いに顔をあわせることもなく、そのプロジェクトで何を達成したいのかという目標も個々に異なります。このような集団で、何も管理をしなかったらどんなことになるでしょうか？奇跡でも起こらない限り、すぐにバラバラになってしまうか明後日の方向に向かってしまうことでしょう。私たちが思っているほど物事はうまく進みません。それでは、いったい何を管理すべきなのでしょうか。管理はおおっぴらにやるものではなく、非公式に控えめに行うことになるでしょう。開発者たちを結びつける唯一の理由は、個別にやるよりも協調したほうがよりよいものができるという共通認識です。したがって、管理者の目標は、開発者たちがこの考えを信じ続けられるようにすることとなります。そのためには、標準的なコミュニケーション手段を定めることが大切です。また、有能な開発者が「周りと違う」というだけで仲間はずれにされることのないように注意が必要です。要するに、開発者たちにとって「またここに戻ってきたい」と思わせるようにしようということです。そのための具体的なテクニックについて、本書でこれから説明していきます。

最後に「文化的な導き方の失敗 (failures of cultural navigation)」と言われる一般的な問題について説明しましょう。ほんの10年前くらいまで、いや５年前くらいまでは、フリーソフトウェア文化について語るだなんて時期尚早だといわれていました。でも今はもう違います。徐々にフリーソフトウェア文化が目に付くようになってきました。確かにそれは一枚岩のものではありません— 少なくともごく普通の文化と同様に意見の相違や派閥争いなどが起こりがちです —が、コアとなる部分は一貫しています。うまくいっているオープンソースプロジェクトの大半は、このコアとなる考えかたの一部あるいはすべてを持ち備えています。彼らはよい振る舞いに対しては賞賛し、そうでないものについては非難します。彼らは誰でもプロジェクトに参加しやすくなるような雰囲気作りを心がけています。たとえ時にはそれが現在のメンバー間の連携を乱すことになったとしても。彼らは何が失礼で何がそうでないのかをきちんとわかっています。その基準は他の文化におけるものとは大きく異なっているかもしれません。最も重要なのは、長年そのプロジェクトに参加している人たちがこれらの考えを身に着けており、プロジェクトがどうあるべきかという指針を大雑把につかんでいることです。うまくいっていないプロジェクトはたいてい、無意識のうちにこの基本から逸脱しています。また、デフォルトの振る舞いがどうあるべきかという共通認識を持っていないことが多いです。こうなると、いざ何か問題が起こったときに状態が急速に悪化してしまうようになります。争いを解決するためのよりどころとなるべき確立された文化的行動様式を参加者が持ち合わせていないからです。

本書は実用的なガイドブックであり、人類学や歴史学を扱う学術書ではありません。しかし、こんにちのフリーソフトウェア文化の始まった背景についての基本的な知識を身に着けておくと、本書での実用的なアドバイスがよりわかりやすくなるでしょう。背景となる文化を知っておくと、オープンソースの世界をより広く深く歩き回れるようになります。プロジェクトによっては独特の習慣や方言があったりするでしょうが、そんな場合も気にせずに仲間入りできるようになるでしょう。反対に、そのような背景を知らない人は、プロジェクトを作成したりプロジェクトに参加したりする手続きを見て非常に難しくてびっくりすることばかりだと感じられるでしょう。フリーソフトウェアの開発にかかわる人は依然として飛躍的に増えつづけています。したがって、後者に属する人 (つまり背景を知らない人) がたくさんいるのです。つまり、主として新しい移民による文化だということです。この傾向はもうしばらくは続くことでしょう。もし自分も「背景を知らない人」のひとりだと思われるなら、ぜひ次のセクションを読んでください。ここでは、今後本書やインターネット上で登場することになるさまざまな議論の背景について説明しています (一方、すでにオープンソースの世界での活動経験があり、その歴史についてもよく知っているという方は、次のセクションは読み飛ばしていただいてけっこうです)。

歴史

ソフトウェアを共有するという考え方は、ソフトウェアが誕生した当初から存在しました。コンピュータの黎明期には、各メーカーは「ハードウェアの革新によって競合他社の上を行こう」と考えていました。そのため、ソフトウェアは商売の材料としてあまり重視されていなかったのです。いわば「ハードウェアのおまけ」という存在でしかありませんでした。そのころにコンピュータを使っていたのは科学者や技術者ばかりで、彼らは、コンピュータに同梱されているソフトウェアを修正したり拡張したりすることができました。その修正パッチをコンピュータのメーカーに送るだけでなく、同じマシンを使っている他のユーザーにも送っていたのです。メーカーはそれに目くじらを立てることはなく、むしろそうすることを奨励していました。彼らにとっては、どんな理由であれソフトウェアの品質が向上することはありがたかったのです。そのおかげで自社のマシンがより魅力的なものとなり、新規顧客が増えることになるでしょうから。

当時の状況と現在のフリーソフトウェア文化との間には多くの共通点もありますが、決定的な違いがふたつあります。まず、当時はまだハードウェアが標準化されていませんでした。ちょうどコンピュータ自体が革新的な進歩を遂げつつある時期だったということもその理由のひとつです。さまざまなアーキテクチャのコンピュータが存在するということは、ある機種のために書いたプログラムがその他の機種では一切動かないということです。したがって、ある機種のために書いたプログラムが世界中で使われるということはありませんでした。当時のプログラマーは、特定のアーキテクチャあるいはアーキテクチャファミリーについての専門技術を身につけようとする傾向がありました (一方現在では、特定のアーキテクチャというよりは特定のプログラミング言語に関するエキスパートになろうとする人が多いように思います。何かひとつのプログラミング言語をマスターすれば、ハードウェアが変わったとしてもその知識が応用できるわけです)。たいていの人は興味の対象があれこれ移り変わることがないので、何か特定のコンピュータに力を入れ始めるとずっとそれに力を入れるようになりました。その結果、周囲の人たちも同じコンピュータに興味を持つようになっていたのです。そのマシンでしか使えないコードや知識が広まれば広まるほど、そのマシンを作っているメーカーにとってはありがたかったのです。

そして２番目に、当時はインターネットがありませんでした。当時は現在ほど共有に関する法的規制は厳しくありませんでしたが、それよりも技術的な問題のほうが大きかったのです。あるデータをどこかからどこかへ移動しようとすると、現在に比べて非常に不便でやっかいでした。研究所や企業によっては小さな構内ネットワークを持っており、そこでは構成員の間で容易に情報を共有することができました。しかし情報をどこの誰とでも共有しようと思ったら、高い敷居を乗り越えないといけませんでした。多くの場合、その敷居は実際に乗り越えられました。時にはグループ同士で連絡をとり、ディスクやテープを郵便でやりとりすることもありましたし、時にはメーカー自身が間に入り、パッチの取引所としての役割を果たすこともありました。初期のコンピュータ開発者の多くが大学で働いていたことも幸いしました。大学では、自分の得た知識をみんなに広めることがごく普通に行われていたからです。しかし、データを共有するにあたって物理的な距離の隔たりが常に障害となりました。お互いの地理的な距離、そして組織的な距離が遠くなればなるほど、共有がむずかしくなっていたのです。現在の私たちのように、距離を気にせず情報の共有ができるなんてことはありえなかったのです。

独占的なソフトウェアとフリーソフトウェア

業界が成熟してくるにつれて、相互関係のあるいくつかの変化が同時に発生しました。まず、さまざまなものがあったハードウェア設計が徐々に淘汰され、いくつかの勝ち組に絞られていきました。他より技術的に優れていたもの、他よりマーケティングが上手だったもの、あるいはその両方を兼ね備えていたものなどが残ることとなったのです。と同時に (これは全くの偶然というわけではありません)、いわゆる「高級プログラミング言語」が台頭してきました。これは、その言語で書いたプログラムを自動的に翻訳 (「コンパイル」) し、さまざまなコンピュータ上で動かすことを可能とするものでした。ハードウェアメーカーも、当然このような動きを察知していました。彼らの顧客は今や、特定のコンピュータアーキテクチャに囲い込まれることなくソフトウェアを開発できるようになったのです。これらの変化と同時に、各種コンピュータ間のパフォーマンスの差もほとんどなくなってきました。また効率的でない設計のものは排除されていきました。ハードウェアのみを収入源としているメーカーは、将来の見通しがあまり明るく感じられませんでした。つまり、コンピュータそのものは今や代替可能なものとなってしまい、一方ソフトウェアこそが他との差別化の手段となったのです。そんな流れの中では、ソフトウェア自体を販売したり少なくともソフトウェアをハードウェアの必須部品として販売したりといった考えが出てくるのも当然でした。

ここにきて、各メーカーはソフトウェアのコードに対する著作権をより厳格に適用する必要に迫られることになったのです。もしユーザーが自分たちでコードを自由に共有し改変し続ければ、今やハードウェアの「追加機能」として販売されるようになったものを自前で再実装してしまうかもしれません。さらに悪いことに、そのコードは競合他社の手に渡ってしまうかも知れません。皮肉にも、これらの出来事はちょうどインターネットが誕生したのと同じころに発生したのです。ソフトウェアを共有する際の技術的な障害がようやく解消されたと思ったら、そのときにはコンピュータ業界の常識が変わっていたというわけです。少なくともメーカー側の視点で見れば、ソフトウェアを自由に共有するのは望ましくないこととなっていました。メーカーは規制に走りました。自社のマシンを動かしているコードをユーザーに公開しなくなったり、機密保持契約を結ばせることでコードの共有を不可能にしたりといったことを行いました。

意識的な抵抗

自由にコードを共有できた時代が終わりを告げようとしているころ、少なくとも１人のプログラマーの心の中ではそれに反対する気持ちが固まりつつありました。 Richard Stallman は、マサチューセッツ工科大学の人工知能 (AI) 研究所に 1970 年代から 80 年代の初期にかけて在籍していました。ちょうどそのころが、コードの共有が盛んに行われていた黄金時代でした。 AI 研は「ハッカー倫理」 ^[5] を前面に押し出しており、何かシステムに改良を加えた場合はそれを皆で共有するのが当然のことであるとみなされていました。 Stallman は、後に次のように述べています。

わたしたちは自分たちのソフトウェアを「フリーソフトウェア」とは呼んでいませんでした。なぜなら、そんな用語は存在していなかったからです。しかし、実際はそういうものでした。他の大学や企業からやって来た人がプログラムを移植したり使ったりしたいときはいつでも、わたしたちは喜んで許可していました。もし誰かが珍しくて面白そうなプログラムを使っているのを見たら、いつでもソースコードを見せてほしいと頼んでもいいので、それを読んだり、書き換えたり、新しいプログラムを作るためにその一部を取り出しても構いませんでした。
(http://www.gnu.org/gnu/thegnuproject.html より引用。日本語訳は http://www.gnu.org/gnu/thegnuproject.ja.html)

Stallman の周りにあったエデンの園は、1980 年代に入ってすぐに崩壊してしまいました。周囲の業界で起こっていたさまざまな変化の影響が、AI 研にも到達したのです。研究所にいたプログラマーの多くはスタートアップ企業に就職し、オペレーティングシステムの開発に従事するようになりました。やっていることは研究所時代と似ていますが、今や彼らは独占的なライセンスのもとで働くようになったのです。ちょうど同じころ、AI 研は新しいマシンを導入しました。そこに搭載されていたのは独占的なオペレーティングシステムでした。

Stallman は、何が起こっているのかを広い範囲で目の当たりにしました。

VAX や 68020 のような当時の先進的なコンピューターは専用のオペレーティング・システムを備えていましたが、どれもフリーソフトウェアではありませんでした。つまり、実行可能なコピーを入手するためだけでも非開示契約を結ぶ必要があったのです。
ということは、つまり最初にコンピューターを使うときには、周りの人を手助けしないと約束する必要があるということでした。協力し合うコミュニティーは禁じられてしまうのです。独占的なソフトウェアの所有者によって作られたルールとは「もしお前が隣人と分かち合うなら、お前は著作権法に反していることになる。変更を加えたいのなら、われわれに頼み込んで作ってもらうことだ」というものなのです。

彼は、この風潮に対して抵抗する決心をしました。規模がかなり縮小されてしまった AI 研に残り続けるのではなく、また新興企業でコードを書く仕事を得る (そんなことをしたら彼の作業の成果が一企業に閉じ込められてしまいます) わけでもありませんでした。彼は研究所を退職し、GNU プロジェクトと Free Software Foundation (FSF) を立ち上げました。GNU ^[6] の目標は、完全にフリーでオープンなオペレーティングシステムとアプリケーションソフトウェアを作成することです。ユーザーがコードをハックしたり他人と共有したりすることは決して妨げられません。簡単に言うと、彼は AI 研にかつてあった (そして今は破壊されてしまった) 空気を新たに作り直そうとしていたのです。今度は世界中を巻き込む規模で。そして AI 研の空気が破壊されてしまったのと同じようなことを起こさないように。

新しいオペレーティングシステムの開発のかたわら、Stallman は新しい著作権ライセンスを考案しました。自分のコードが永久に自由であることを保証するためです。 GNU General Public License (GPL) は、法律における見事な柔術です。コードの複製や変更には一切の制限を設けません。コピーしたものやその派生物 (改造したものなど) の配布は同じライセンスのもとで行われなければならず、いかなる制限も付加されてはいけません。このライセンスは著作権法を利用していますが、狙っている効果は伝統的な著作権とは正反対のものなのです。つまり、ソフトウェアの再配布を制限するのではなく、たとえ作者であっても 再配布を制限すること 自体を禁止しているのです。 Stallman にとって、自分のコードを単にパブリックドメインにするよりもそのほうが好都合だったのです。パブリックドメインにしてしまうと、誰かがそれを独占的なプログラム (あるいは、より規制のゆるい別のライセンスを適用したプログラム) に使用してしまうかもしれません。そうされたところで元のコードは自由なままで残り続けるわけですが、でも結局は Stallman の努力した結果が敵陣営 —独占的ソフトウェア—に利益をもたらすことになってしまいます。 GPL は、フリーソフトウェアに対する保護主義の一形式と考えることができます。というのは、自由でないソフトウェアが GPL のコードを完全に好きなように利用することはできないからです。 GPL とその他のフリーソフトウェアライセンスとの関係については、 10章ライセンス、著作権、特許 で詳しく説明します。

数多くのプログラマー (Stallman の思想に賛同する人もいれば、ただ単に自由にコードを使いたいだけという人もいました) の協力を得て、GNU プロジェクトは OS の基幹部品を置き換えるフリーソフトウェアを次々にリリースしていきました。当時はすでにコンピュータのハードウェアやソフトウェアが標準化されていたので、 GNU のソフトウェアを自由でないシステム上で使用することもできました。また実際に多くの人がそのようにしていました。中でも最も成功したのが GNU テキストエディタ (Emacs) と C コンパイラ (GCC) でした。これらは、その思想に共感する人たちだけでなく単にソフトウェアとして優れているからという理由で使う人たちも引き込むことになりました。 1990 年ごろには、GNU は自由なオペレーティングシステムをほぼ完成させつつあり、残っていたのはカーネルだけでした。カーネルとはマシンを実際に立ち上げる部分であり、メモリやディスク等のシステムリソースの管理を行うものです。

不幸にも、GNU プロジェクトが選択したカーネル設計は当初予想していたよりも実装が困難なものでした。カーネルの作成は遅れに遅れ、Free Software Foundation が完全に自由なオペレーティングシステムを公開する日はなかなかやってきませんでした。そこに登場したのが Linus Torvalds です。彼はフィンランド人の学生で計算機科学を専攻していました。彼は世界中の有志と力をあわせ、より保守的な設計のフリーなカーネルを完成させました。彼はそれを Linux と名づけました。Linux を既存の GNU プログラム群と組み合わせることで、完全に自由なオペレーティングシステムを得ることができるようになったのです。ここにきて初めて、独占的ソフトウェアを一切使用せずにコンピュータを立ち上げて作業ができるようになりました。 ^[7]

この新しいオペレーティングシステム上で動作するソフトウェアの多くは、 GNU プロジェクト以外が作成しています。実際のところ、フリーなオペレーティングシステムを作ろうとしていたのは GNU だけではなかったのです (たとえば、後に NetBSD や FreeBSD となるコードはこの時点ですでに開発が進められていました)。 Free Software Foundation の存在意義は、彼らが書いたコードだけにあるのではありません。彼らは政治的メッセージを言葉巧みに伝えました。利便性ではなく、信条としてのフリーソフトウェアを語ったのです。そのため、プログラマーは政治的な面を気にせざるを得ないようになってきました。 FSF と意見が異なる人でさえ、立場が違うということを明確にするためには、政治的な問題に足を突っ込まざるを得なかったのです。 FSF は、彼らのコードに GPL やその他のテキストを同梱することで彼らの思想を効率的に広めました。彼らの書いたコードが広まれば広まるほど、彼らのメッセージも広まることになりました。

無意識な抵抗

フリーソフトウェア運動の初期には、他にも多くの運動が起こっていました。しかし、Stallman の GNU プロジェクトと同じくらいにイデオロギーを前面に押し出したものはほとんどありませんでした。その中でも最も重要なもののひとつが Berkeley Software Distribution (BSD) でしょう。これは、徐々に Unix オペレーティングシステム —1970 年代の終わり頃まで AT&T における半ば独占的な研究プロジェクトでした— を再実装しようという動きで、カリフォルニア大学バークレー校のプログラマーがはじめました。 BSD グループは「プログラマー同士お互いに手を取り合って団結しなければならない」といった政治的な声明は出しませんでした。その代わりに彼らの才能と熱意でもってそのアイデアを実現させていきました。さまざまな場所に散らばった開発者たちが協力し、Unix のコマンドラインユーティリティやコードライブラリ、そしてオペレーティングシステムのカーネル自体についても１から書き直していきました。そのほとんどはボランティアによるものでした。 BSD プロジェクトは、イデオロギーを前面に押し出さないフリーソフトウェアプロジェクトとして最も有名な例です。また、その後オープンソースの世界に残って活躍することになる多くの開発者のための訓練の場としての役割も果たしました。

別の盛んな共同開発の例としては X Window System があります。これはフリーでネットワーク越しに使用できるグラフィック環境で、 1980 年代半ばに MIT とハードウェアベンダーが共同で開発しました。ベンダー側も、顧客に同じようなウィンドウシステムを提供したがっていたのです。独占的ソフトウェアと対立するのではなく、X ライセンスではフリーなコアのコード上に独占的な拡張を施すことを意図的に許可していました。コンソーシアムの各メンバーはデフォルトの X をそれぞれ拡張し、それによって競合する他のメンバーに対する優位を確保しようとしたのです。 X ウィンドウ ^[8] 自体はフリーソフトウェアですが、その主な目的は、いわば競争する参加企業間の試合の場をならすことであり、独占的ソフトウェアの支配を終わらせるといった意図はありませんでした。もうひとつの例を挙げましょう。GNU プロジェクトの数年前に開発が始まった TeX です。これは、Donald Knuth によるフリーで高品質な組版システムです。彼は、誰でもコードを改変して再配布できるというライセンスのもとで Tex を公開しました。ただし、改変したコードを再配布する際には、非常に厳しい互換性テストをクリアしない限り "TeX" の名を使ってはならないという制限をつけました (これは、フリーなライセンスにおける "商標保護" の例です。詳細は 10章ライセンス、著作権、特許 で説明します)。Knuth は、自由なソフトウェアか独占的なソフトウェアかといった問題については特に立場を表明していませんでした。彼は、単に真の目的 (コンピュータプログラミングに関する書籍の出版) を達成するためのまともな組版システムがほしかっただけなのです。そして彼にとって、自分の作ったシステムを一般に公開しない理由はなかったのです。

すべてのプロジェクトやライセンスをここで挙げることはしませんが、 1980 年代後半にはさまざまなライセンスのさまざまなフリーソフトウェアが存在したということはここまでの例でも十分に伝わるでしょう。さまざまなライセンスが存在するということは、フリーソフトウェアを公開する動機にもさまざまなものがあるということを表しています。 GNU GPL を選択したプログラマーであっても、 GNU プロジェクトほどにはイデオロギーを押し出していない人も存在します。彼らはフリーソフトウェアの開発を楽しんでいますが、その多くは、特に独占的ソフトウェアを敵視しているわけではありません。この世から「ソフトウェアの囲い込み (software hoarding)」(Stallman がフリーでないソフトウェアを指すときに使用する用語) をなくすんだ！という道徳的な衝動にかられる人もいましたが、単に技術的な興味からフリーソフトウェアを開発している人もいました。また、同じ趣味を持つ人と共同作業をするのが楽しいとか、有名になりたいとかいう理由の人もいたことでしょう。しかし、このように本質的に異なる動機を持った人たちがお互いに悪影響を及ぼしあうことはありませんでした。小説や絵画と異なり、ソフトウェアには最低限の基準 (きちんと動くこと、バグが存在しないこと) があったことも理由のひとつでしょう。そのため、プロジェクトの参加者が共同で作業する際に技術面以外の適性をあまり気にする必要がありませんでした。

開発者たちが手を取り合う理由がもうひとつありました。フリーソフトウェア界が非常に高品質なコードを生み出していることがわかってきたのです。時には、フリーでない同等製品より明らかに技術面で上回っているものもありました。あるいは、少なくとも同等の機能を持っているものも多くありました。当然、これは低コストで入手することができます。フリーソフトウェアの思想に厳密に従うためにフリーソフトウェアを使用するという人はあまり多くなかったかもしれません。多くの人たちは、単にそちらのほうが高性能だからという理由でフリーソフトウェアを選択していました。そしてソフトウェアを使う人たちの中には、そのソフトウェアの保守や改善のために時間と力を貸してくれる人が常にある程度以上いたのです。

この「よいコードを生み出す」という傾向はまだ普遍的なものとはなっていませんでしたが、徐々に世界中のフリーソフトウェアプロジェクトでも同様の現象が見られるようになってきました。ソフトウェアに強く依存する産業界でも、徐々にそのことに気づき始めました。彼らの多くは、すでに日常の作業にフリーソフトウェアを使用していましたが、それに気づいていませんでした (上級管理職が IT 部門の動きを常に把握しているとは限りません)。企業は、フリーソフトウェアプロジェクトに対してより積極的、公共的な役割を担うようになりました。彼らのために時間や設備を提供したり、あるいはもっと直接的に資金を提供したりすることもありました。うまくいった場合は、そのような投資が何倍にもなって返ってくるかもしれません。そのプロジェクトにフルタイムで専念している一部の専門プログラマーに対して資金を提供することで、プロジェクト全体 (無償のボランティアや他の企業に属するプログラマーなど) の活動の利益を得られることになります。

「フリー」と「オープンソース」の違い

産業界がますますフリーソフトウェアに注目するようになると、プログラマーたちはまた新たな問題に直面することとなりました。そのひとつは「フリー」という言葉の意味についてです。「フリーソフトウェア」という言葉を聞いて、多くの人がそれを単なる「無料のソフトウェア」というように勘違いしてしまいます。確かにすべてのフリーソフトウェアは無料ですが、 ^[9] 無料のソフトウェアがすべてフリー (自由) であるとは限りません。たとえば、1990 年代のブラウザ戦争の際に Netscape と Microsoft はともにブラウザを無償でばらまき、市場のシェアを獲得しようと躍起になりました。このどちらのブラウザも、"自由なソフトウェア" という意味でのフリーではありませんでした。そのソースコードを見ることができなかったり、あるいはたとえ見ることができたとしてもそれを改造して再配布する権利がなかったりしたのです。 ^[10] できることといえば、実行ファイルをダウンロードして動かすことだけでした。これらのブラウザには、店頭で箱売りされているソフトウェア以上の自由などありませんでした。単に価格が安かっただけです。

この「フリー」という言葉が混乱を招く原因は、不幸にもこの英単語がいろいろな意味を持ってしまっていることにあります。他の大半の言語では、価格が安いことと自由であることは簡単に区別できるでしょう (たとえばロマンス諸語を話す人にとっては gratis と libre の違いは明確です)。しかし、英語がインターネット上での標準言語として使われている現状では、英語の問題は、ある意味ではすべての人たちの問題であるともいえます。この「フリー」という言葉の意味の履き違えがあまりにも広まってしまったので、フリーソフトウェア開発者は決まり文句をつくり出しました。 "フリー (free) とは、自由 (freedom) のことです。つまり、フリースピーチ (言論の自由) というときの「フリー」であり、フリービール (無料のビール) というときの「フリー」とは違います。" しかし、何度も何度もこれを説明しなければならないのは大変です。多くのプログラマーが、この「フリー」というあいまいな単語のせいで自分たちのソフトウェアが世間に正しく理解されないと感じるようになりました。

しかし、問題はもっと深いところにありました。「自由」という言葉には道徳的な意味が含まれています。自由であることが目的なのならば、フリーソフトウェアがよりよいものになろうが特定の状況において特定のビジネスで有益になろうが、そんなことはどうでもよかったのです。単にその動機にちょっとしたよい副作用があっただけです。心底は技術的でも商業的でもなく、道徳的な動機だったのです。さらに「自由という意味のフリー」という立ち位置は、フリーなプログラムのサポートもしたいが別の独占的ソフトウェアの商売も続行したいという企業にとってはちょっと不便なものでした。

このジレンマは、すでに自己喪失状態になっていたコミュニティーに突き刺さりました。実際にフリーソフトウェアを書いているプログラマーたちは、仮にフリーソフトウェア運動全体としての目標があったとしてもそのために一致団結することはありませんでした。彼らの考えには両極端のものがあったと言ってしまうのもちょっと違います。そんな風に言ってしまうと、まるで彼らの違いが単一の基準だけにもとづくものだと勘違いされてしまいます。しかし、些細な違いをとりあえず無視するなら、彼らの考え方は大きく２種類に分けることができます。一方のグループは Stallman の考え方に共鳴する人たちです。ソフトウェア自由に共有できて自由に改変できることこそが最も重要で、自由について語ることをやめた瞬間に本質的な問題から離れることになります。もう一方のグループは、ソフトウェアそのものこそが最も重要であると考えており、独占的ソフトウェアを敵視するような考え方は好みません。すべての人がそうだというわけではありませんが、プログラマーの中には、作者 (あるいは雇用主) は再配布権をコントロールできるようにすべきだと考えている人たちもいます。再配布権を考える際に、道徳的な視点は不要だということです。

長い間、これらの違いをきちんと調べたりあえて明確にしたりすることはありませんでした。しかしフリーソフトウェアがビジネスの世界に広まっていく中でこの問題は避けられないものとなってきたのです。 1998 年に、「フリー」にかわる言葉として オープンソース が登場しました。これは、後に Open Source Initiative (OSI) となるプログラマーの集団が定義したものです。 ^[11] OSI は、「フリーソフトウェア」という言葉が混乱の元であるというだけでなく、「フリー」という単語が、より全般的な問題の徴候のひとつであると考えました。フリーソフトウェア運動をより広めるためには、何らかのマーケティング戦略が必要です。しかし、道徳だの社会全体の利益だのといった言葉は決して重役会議で扱われることはありません。 OSI はこのように言っています。

Open Source Initiative はフリーソフトウェアのマーケティングプログラムです。イデオロギーについて熱弁をふるうのではない、手堅く実際的な立場において「フリーソフトウェア」を広めるためのものです。勝算のある中身はそのまま、勝ち目の無い態度や象徴主義を変えたのです。……
ほとんどの技術者にとって、必要なのはオープンソースの概念ではなくその名前についての説明です。なぜ旧来の「フリーソフトウェア」ではなく「オープンソース」なのでしょうか？
直接の理由のひとつは、「フリーソフトウェア」という言葉が誤解を受けやすく、混乱の元になるということです。……
しかし、名前をつけなおした真の理由は、マーケティング上のものです。私たちは、フリーソフトウェアの概念を一般の業界にも広めようとしています。私たちはすばらしい製品を持っています。しかし、過去においては私たちの立場はひどいものでした。「フリーソフトウェア」という言葉はビジネスマンの誤解を招き、反商業主義だとか、時には盗人呼ばわりされることもありました。
大手企業の CEO や CTO は、決して「フリーソフトウェア」を購入することはありませんでした。でも、今までとまったく同じ考えのもとで同じ人たちが作り、同じライセンスを適用したものの名前を「オープンソース」と変えたらどうなるでしょう？彼らはそれを購入してくれるのです。
ハッカーたちにとっては、これは信じがたいことでしょう。技術者というのは、具体的で中身のあるものに置き換えて考える傾向があるからです。しかし、何かを売るときにはイメージというものが重要なのです。
マーケティングにおいては、見た目が重要となります。私たちが進んでバリケードを取り壊し、喜んで産業界と一緒に仕事をしようとしているように見せることは、私たちの実際の振る舞いや信念、そしてソフトウェア自体と同じくらい価値のあることなのです。
(http://www.opensource.org より引用。いやむしろ 以前は そこにあった、というべきでしょう。 — OSI はこのページを削除してしまったようですが、 http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php と http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing で今でも見ることができます。 )

この文には、さまざまなツッコミどころがあります。まず、「私たちの信念」とは書かれていますが、その信念とはいったい何なのかということは巧妙に省略されています。ある人にとっては、オープンソースの手法はよりよいコードを生み出すという信念かもしれません。あらゆる情報を共有すべきだという信念の人もいるかもしれません。「盗人」という言葉は、(おそらく) 違法コピーのことを指しているのでしょう。この言い方には異議がある人も多いことでしょう。元の所有者がまだそれを保持しているのだから「盗人」はおかしいのではないかと思われるかもしれません。フリーソフトウェア運動が反商業主義だと非難される可能性については説明していますが、その非難が何かの事実にもとづくものなのかどうかには触れていません。

別に、OSI のウェブサイトが矛盾していて紛らわしいと言っているわけではありません。そうじゃないんです。これまでのフリーソフトウェア運動が欠いてきたものだと OSI が主張する、まさにそれの例になっているんです。そう、「よいマーケティング」です。「よい」とは、「業界で生き残っていける」という意味です。 Open Source Initiative は、多くの人々に彼らが待ち望んでいたものを与えました。道徳的な十字軍ではありません。フリーソフトウェアによる開発手法や経営戦略を語る上で必要な言葉です。

Open Source Initiative の登場によって、フリーソフトウェア界の情勢が変化しました。長い間うやむやにされてきた両者にきちんとした名前をつけ、内部の政治的な問題と同様に外部的な問題としても認識させるようにしました。現在への影響は、両者が共通の背景を持つようになったということです。多くのプロジェクトは両方の陣営のプログラマーを含んでおり、またどちらに属するかはっきりしない参加者も同じくらい存在します。これは決して、道徳的な話がなくなったというわけではありません。たとえば、例の「ハッカー倫理」は今でもたまに話題にのぼります。ただ、フリーソフトウェア/オープンソースの開発者が、プロジェクトの他のメンバーに対してプロジェクトに参加する動機をおおっぴらに尋ねることはほとんどなくなりました。貢献した人ではなく貢献の内容で評価されるようになったのです。だれかがすばらしいコードを書いたとしましょう。その人に対して「道徳的な理由でそれを書いたの？」とか「金で雇われて書いたの？」「名前を売るため？」といった類のことは聞きません。単にそのコードの内容を技術的に評価し、技術的に答えを返すだけのことです。 Debian プロジェクトは 100% フリー (もちろん「自由」という意味です) なコンピュータ環境を作ることを目標としていますが、このように政治的な態度を明確に打ち出している組織でさえも、フリーでないコードも提供しています。また、方向性が完全に一致しているわけではないプログラマーとも共同作業をしています。

現状

フリーソフトウェアプロジェクトを運営するにあたって、このような重い哲学的な内容を日々の作業で意識する必要はありません。プログラマーも「みんなこの思想に同意すべきだ」なんていうように主張することはありません (そんなことを言うプログラマーは、自分がどんなプロジェクトでもうまくやっていけないことにすぐ気づくでしょう)。しかし「フリー」と「オープンソース」の違いという問題があるということは意識しておきましょう。ひとつには、参加者に反目するような内容の発言を避けるためです。また、開発者の動機を理解するというのは、プロジェクトをうまく取りまとめるための最良の方法 (ある意味、唯一の方法) だからです。

フリーソフトウェアは選択の文化です。成功させるには、まず第一にみんながなぜそれを選択したのかを理解する必要があります。高飛車な態度ではうまくいきません。そのプロジェクトの居心地が悪くなると、すぐに他のプロジェクトに移動することでしょう。フリーソフトウェアは、ボランティア集団の中でもその結びつきの軽さが群を抜いています。ほとんどの参加者は他のメンバーと顔をつき合わせたことがなく、ちょっとした空き時間をつかってプロジェクトに協力しています。人と人を結びつけるもの、プロジェクトを続けさせる要因となるものは、電線を通じて運ばれる書き言葉だけです。そのため、しっかりまとまった熱意のあるグループを育てるには長い時間がかかります。逆に、プロジェクトに協力してくれそうな人たちをそのプロジェクトから離れさせるには、５分もあれば十分です。そのプロジェクトの第一印象が悪ければ、初めて訪れた人は二度とそこに戻ってくることはないでしょう。

参加者同士の結びつきのはかなさ、あるいは潜在的なはかなさが、新しいプロジェクトに立ち向かう際の唯一にして最大の難関となるでしょう。彼らを納得させ、みんなで何かを作り上げようとさせるにはどうしたらいいでしょう？この質問への答えは複雑になりすぎるので本書では扱いきれません。が、一言で言うならこのようになります。

そのプロジェクトとのつながりやプロジェクトに及ぼす影響は、あなたがそのプロジェクトにどれだけのことをしたかに正比例することを実感させよう。

開発者や開発者予備軍が、技術的な理由以外で軽視されているとか差別されているとか感じているようではいけません。特に、企業の支援を受けているプロジェクトや金をもらって開発している人がいるプロジェクトではこれに注意が必要です。詳細は 5章カネに関する問題 で改めて説明します。もちろんこれは、企業の支援を受けていなければ何も心配する必要がないということではありません。カネの問題は、プロジェクトが失敗する要因のうちのほんのひとつでしかありません。どんな開発言語を選択するか、どんなライセンスを選択するか、開発手順はどうするか、どんなツールを使用するか、あるいは新しいプロジェクトをどのように宣伝するかなど、さまざまな要因がほかにも考えられます。では、実際にプロジェクトを開始するにはどうしたらいいのか。それを次の章で取り上げます。

^[4] 有名なホスティングサイトのひとつである SourceForge.net には、2004 年 4 月中旬の時点で 79,225 のプロジェクトが登録されています。もちろん、これがインターネット上のフリーソフトウェアプロジェクトの総数であるというわけではありません。これは単に、その時点で SourceForge を選択したプロジェクトの数に過ぎません。

^[5] Stallman は「ハッカー」という単語を「プログラミングが大好きでそれを楽しんでいる賢い人」という意味で使っています。最近よく使われるようになった「コンピュータに不正侵入する人」という意味ではありません。

^[6] これは "GNU's Not Unix" の頭文字をとったものです。そしてこの中の "GNU" は何の略かといえば…… 同じです。

^[7] 厳密に言うと、Linux が最初だったわけではありません。 IBM 互換機上で動作する 386BSD というフリーなオペレーティングシステムが Linux のほんの少し前に登場しています。しかし、386BSD を動かすのは非常に難しいことでした。 Linux が騒がれた理由は、単にフリーなだけでなくインストールして動作させるのが簡単であったということもあります。

^[8] 彼らは "X ウィンドウシステム" と呼んでほしいようですが、現実には "X ウィンドウ" ということのほうが多いでしょう。だっていちいちそんな長い名前を言うのは面倒くさいから。

^[9] フリーソフトウェアを配布する際に代金を徴収することもあるかもしれません。しかし、購入した人がそれを他人に無料で再配布するのを禁じることはできないので、結局のところ価格は無料同然となります。

^[10] Netscape Navigator のソースコードは、結局は 1998 年にオープンソースライセンスのもとで公開されることとなりました。これをもとにして作られたのが Mozilla ウェブブラウザです。詳細は http://www.mozilla.org/ をご覧ください。

^[11] OSI のウェブページは http://www.opensource.org/ です。

第2章さあ始めましょう

フリーソフトウェアプロジェクトがどのようにして始まるのかについては、 Eric Raymond が説明しています。彼は、今や超有名になった文書「伽藍とバザール (The Cathedral and the Bazaar)」の中で次のように述べています。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。
(http://www.catb.org/~esr/writings/cathedral-bazaar/ より引用。日本語訳は http://www.tlug.jp/docs/cathedral-bazaar/cathedral-paper-jp.html)

Raymond は、決して「開発者の個人的な悩み解決」だけがオープンソースプロジェクトの始まるきっかけだとは言っていないことに注意しましょう。というよりは、プログラマー自身が問題の解決に関心を持っているときによいソフトウェアが出来上がることが多いと言っているのです。フリーソフトウェアを作り始める動機としていちばん多いのが「個人的な悩み解決」だったということでしょう。

現在でも同じ理由で始まるフリーソフトウェアプロジェクトは多いでしょうが、Raymond がこの文章を書いた 1997 年当時に比べるとその割合は少なくなっています。現在では、巨大な中央管理型のオープンソースプロジェクト (営利団体が管理するものも含む) を最初から作ろうとする空気があります。一匹狼のプログラマーが個人的な問題を解決するためにガシガシ書いたコードが結果として広く受け入れられるということは今でもあるでしょうが、いまやそれだけではなくなったということです。

しかし、Raymond の指摘は今でも洞察に満ちています。ソフトウェアの作者自身がその成功に直接的な興味を持っている、なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。もしそのソフトウェアが期待通りに動かなければ、日々それを使用している作者は不満に思うことになるでしょう。たとえば OpenAdapter プロジェクト (http://www.openadapter.org/) を考えてみましょう。これは投資銀行 Dresdner Kleinwort Wasserstein が始めたオープンソースのフレームワークで、さまざまな金融情報システムを統合するためのものです。どう考えても、これは「開発者の個人的な悩み解決」のために作られたものとはいえないでしょう。これは「機関の悩み解決」をするためのものです。しかし、この悩みはその機関とパートナーの経験から直接くるものです。したがって、もしこのプロジェクトがうまくいっていなければ、それと気づくことができるでしょう。このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。なぜなら、フィードバックループが正しい方向に流れるからです。そのプログラムは、見知らぬ誰かに売りつけて、彼らの問題を解決できるよう書かれるのではありません。最初は自分たち自身の問題を解決するために書かれます。そしてそれがみんなと共有されるようになります。「問題」を病気にたとえると、ソフトウェアは薬のようなものです。流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。

本章では、新しいフリーソフトウェアプロジェクトをスタートさせる方法を扱います。しかし、本章にかかれている内容の多くは、保健機関が薬を配布するときの方法と似ていることでしょう。両者の目標はよく似ています。薬の効能ははっきり示さないといけないでしょうし、それを本当に必要とする人に手渡さないといけないでしょうし、またそれを受け取った人は薬の扱い方を知っていなければなりません。しかしソフトウェアの場合はさらに、薬を改良するための研究に参加してもらうように患者を勧誘するという作業もあります。

フリーソフトウェアの配布作業は、２つの側面を有しています。ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。これら２つは必ずしも競合するものではありません。しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。ユーザーと開発者の両方に対して有用な情報もあれば、そのどちらか一方にしか役立たない情報もあります。どちらの情報もスケールするプレゼンテーション (scaled presentation) の原則にしたがっていなければなりません。すなわち、読み手が時間をかけて熱心に読めば読むほど、それにあわせた詳細な情報が得られるようになっていなければなりません。努力すればするほど、それに対する見返りが得られるべきです。両者がきちんと相関していなければ、人はすぐ信頼する心を失い、努力を注ぎ込むのをやめてしまうでしょう。

この系として言えるのが、見栄えは重要である ということです。とりわけプログラマーという人種は、これを信じようとしません。形式を差し置いた本質に対する彼らのこだわりは、ほとんど職人的プライドの域に達しています。多くのプログラマーはマーケティングや広報活動を毛嫌いしているようだし、プロのグラフィックデザイナも「プログラマーって人たちはいったい何を考えているのか」と恐れているようですが、これは全く不思議なことではありません。

これは残念な話です。状況によっては形式こそが本質であり、プロジェクトの見栄えの問題はその状況の１つだからです。たとえば、あるプロジェクトの存在を知った人が最初に目にするのは、そのプロジェクトのウェブサイトの見た目です。実際に何が書かれているかとかどこにリンクされているとかよりも前に、まずそのウェブサイトがどんな感じかということが目に入るわけです。おかしな話だと思われるかもしれませんが、人は第一印象の形成を抑制することができないものなのです。サイトの見た目は、そのプロジェクトの見栄えの構成に配慮が払われたか否かという情報を発信します。そして人間は、配慮の投資を検知するためのおそろしく感度のよいアンテナを備えているのです。たいていの人は、そのサイトが片手間に作られたものかよく練りこまれているものかを一目見て判断することができます。そのプロジェクトを世に出すにあたって最初に見てもらうところがウェブサイトなのですから、その印象は連想によってプロジェクト全体に持ち越されるのです。

したがって、一方で本章では主にプロジェクトを開始するにあたり用意しておくべき内容について取り扱っているのですが、その見栄えも重要であるということは忘れないでください。プロジェクトのウェブサイトは (エンドユーザーと開発者の) ２種類の人たちが利用するものなので、どちらを対象としたものなのかをはっきりさせる必要があります。本書はウェブデザインの専門書ではありませんが、ひとつだけ重要な法則を示しておきます。このようにさまざまな相手 (部分的に重複することもあるでしょう) を対象とするときは特に重要なことです。それは、リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておく、ということです。たとえば、ユーザー向けのドキュメントなのか開発者向けのドキュメントなのかが、 リンク先ではなくリンクそのものを見ただけで 判断できるようにしておくべきです。プロジェクト運営には、情報を提供するという側面が一部にはあります。しかしまた、安心感を提供するという側面もあるのです。期待した場所に決まりきったものが提供されているというだけで、そのプロジェクトに関わるか否か決めようとしているユーザーや開発者は安心します。「このプロジェクトはやるべきことを行い、想定される質問に対応し、その質問に対する答えをできるだけ簡単に得られるようにしている」という努力が見えるからです。このような気合を見せることで「このプロジェクトに関わってもあなたの時間は無駄にならない」というメッセージを送ることができます。それこそが皆が聞きたいメッセージです。

まずは周りを見渡すことから

オープンソースプロジェクトを始める前に、ひとつ忠告しておきます。

まずは周りを見渡して、同じようなプロジェクトが既に存在しないかどうかを確認しましょう。あなたが今まさに解決しようと思っている問題を、あなたよりも前に別の誰かが解決しようと思っていた可能性は大いにあります。そして彼らが実際にその問題を解決し、コードをフリーなライセンスで公開しているのなら、あなたがこれから車輪の再発明をする理由はありません。もちろん、例外もあります。自分の勉強のためにプロジェクトを開始するのなら、既存のコードは助けにならないでしょう。あるいはこれからはじめようとしているプロジェクトがあまりにも特定の分野に特化したものであり、他の人が同じことをしている可能性がゼロに等しい場合などもあるでしょう。しかし通常は、あえて周りを見渡さない理由はありません。見渡すことで得られる利益はかなりのものになるでしょう。一般的なサーチエンジンで結果が得られなければ、 http://freecode.com/ (オープンソースプロジェクトに関するニュースサイト。詳細は後ほど説明します) や http://www.sourceforge.net/、そして Free Software Foundation のフリーソフトウェアディレクトリ (http://directory.fsf.org/) を調べてみましょう。

そのものずばりのものが見つからなかったとしても、よく似たものが見つかるかもしれません。そんな場合は、そのプロジェクトに合流して必要な機能を追加するほうが、１から作り直すよりもいいでしょう。

手持ちのもので始めよう

まわりを見渡してみたけれど望みどおりのものが見つかりませんでした。ということで、結局新しいプロジェクトを始めることになりました。

さて何をしたらいいのでしょう？

フリーソフトウェアプロジェクトの立ち上げ時に最も厄介なのは、個人的なビジョンをみんなにわかる形に置き換えることです。あなた (あるいはあなたの属する組織) にとっては何がやりたいのかは明白でしょう。しかし、そのプロジェクトの目標が何なのかを一般にもわかるように表明することは、それなりに大変な作業です。しかし、かならず時間を割いてそれをやらなければなりません。あなた (そして共同でプロジェクトを立ち上げた他のメンバー) は、まず「プロジェクトが実際何なのか」、すなわち、「何をやるのか」と同時に「何をやらないのか」という限界を決定し、ミッションステートメントを書き上げなければなりません。普通は、これはそれほど困難なことではありません。しかし、この作業によって、プロジェクトの本質に関する暗黙の了解やさらには意見の相違まで浮かび上がってくるかもしれません。それでいいんです。後になってからそれが判明するよりも、早いうちに見つけてしまったほうが解決しやすくなります。この作業が終われば、次にすることは一般公開用のパッケージを作成することです。これは、ぶっちゃけて言うと単純でつまらない純然たる骨折り仕事です。

何がそんなに面倒くさいのかというと、その作業の大半が、既にみんなが知っている —ここでいう「みんな」とは、これまでずっとプロジェクトにかかわってきた人のことです— ことをまとめ上げて文書化するということだからです。つまり、その作業を実際に行う人には直接的なメリットは何もないのです。彼らにとっては「このプロジェクトは……」というような README ファイルは不要ですし、もちろん設計文書やユーザーマニュアルなんかも不要です。ソフトウェアをソースで配布するときにみんなが標準的に使っているようなコードツリーを構成する必要も感じていないでしょう。別にディレクトリ構成がどうであっても彼らは気にしません。だってもうそのコードの内容を熟知しているのだし、コードが動き出せば、あとはどう使えばいいのかも知っているわけですから。彼らにとっては、そのプロジェクトの基本的な設計方針が文書化されていなくても平気です。だってそれは彼らの頭の中にちゃんとあるのですから。

一方、新参者にとってはそのようなドキュメントは必須です。とはいえ、幸いなことにすべてのドキュメントが一度に必要となるわけではありません。プロジェクトを公開する前に、あらゆるリソースを提供できるようにしておく必要はありません。理想を言えば、新しいオープンソースプロジェクトを始めるときには設計文書や完全なユーザーマニュアル (今後実装予定の機能についての説明も含む)、複数プラットフォームで動作するきれいにパッケージされたコードなどがそろっているといいのでしょう。しかし現実的には、これらをばっちりそろえることは手間がかかりすぎます。それになにより、ひとたびプロジェクトが動き出せば、これらの作業に対するボランティアの協力を正当に期待できるのです。

しかし、何が本当に必要なのかといえば、見栄えの調整に十分に力をいれ、新入りさんが不慣れという名の最初の障壁を乗り越えられるようにすることです。この作業をブートストラップ過程の第一段階、プロジェクトをいわば活性化エネルギー最小の状態に持っていくことだと考えてください。新入りさんが「このプロジェクトに対して何らかのかかわりと持とう」と考えるために必要なエネルギーの閾値のことを、どこかの誰かが ハクティベーション (hacktivation) ^[12] エネルギー と呼んでいました。ハクティベーションエネルギーが低ければ低いほどいい、というわけです。あなたが最初に行う作業は、プロジェクトのハクティベーションエネルギーを下げていろいろな人たちがプロジェクトに参加しやすくすることとなります。

以下の各項では、新しいプロジェクトをはじめるにあたって重要となる内容について個別に説明します。そのプロジェクトをはじめて知った人が遭遇するであろう順に並べていますが、もちろんこのとおりの順で作成しなければならないというわけではありません。これらの項目を、チェックリストとして用いるといいでしょう。プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認するか、あるいはもし省略した項目がある場合は、せめて予想される結果が満足のいくものであることを確認しましょう。

名前の決定

どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。おそらく、何かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。彼らが真っ先に目にするのは、そのプロジェクトの名前です。

すばらしい名前をつけたからといって、そのプロジェクトの成功が約束されるわけではありません。また、変な名前をつけたからといってそれだけの理由でプロジェクトが失敗するというわけでもありません —もちろん、あまりにも マズい名前をつけてしまったら悪影響があるかもしれません。しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろうという前提の下で話を進めます。ただ、変な名前をつけてしまうと、真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、そのプロジェクトの利用が低下してしまうかもしれません。

よい名前とは、次のような条件を満たすものです。

そのプロジェクトのやることが多少なりとも分かること、あるいは少なくとも明らかな形でそれと関連があること。そうすることで、名前とやることを知ってもらったあと、その名前をすぐ思い出してもらえるようにするのです。
覚えやすいこと。ここで、インターネットのデフォルト言語が英語となっているという事実を無視することはできません。つまり「覚えやすい」とは「英語が読める人にとって覚えやすい」ということです。英語のネイティブスピーカーの発音に基づくだじゃれを用いた名前などは、英語を母国語としない多くの人たちにとってはわかりにくいものとなるでしょう。ただ、それが人の心をひきつけるほど印象的なものならばだじゃれを使用する価値もあるでしょう。英語を母国語としない人たちからみると、だじゃれを用いたプロジェクト名を見てもその読み方を想像しにくくなるということを覚えておきましょう。
既存の別のプロジェクト名と重複しない、そして商標権を侵害しないものであること。これは、礼儀の問題であると同時に法的にもよい考えです。別のプロジェクトと混同されてしまうようなことは望ましくないでしょう。別々のものが同じ名前を持っていなかったとしても、ネットで手に入るものすべてを追跡するのは既に十分困難なことなのです。
あなたが考えているのと同じ名前のプロジェクトが既に存在するかどうかを調べるには、「まずは周りを見渡すことから」で示したリソースを使用するといいでしょう。登録商標に関する検索は http://www.nameprotect.org/ や http://www.uspto.gov/ で行えます。
できれば、.com や .net、.org のようなトップレベルドメインが利用できる名前を選びましょう。この中のいずれか１つ (おそらく .org でしょう) を選び、プロジェクトの公式サイトとして宣伝します。他の２つのトップレベルドメインについては単純にプロジェクトのサイトに転送させるだけにしておきます。これにより、第三者にそのドメインを悪用される心配をなくします。仮にそのプロジェクトのサイトを別の場所 (「公開場所」を参照してください) におくとしても、プロジェクト名のドメインは取得しておくべきです。そして、それらのサイトからプロジェクトの本来のページに転送させるようにしましょう。そうすることで、覚えやすいシンプルな URL を提供することができます。

明確な目標を掲げる

プロジェクトのウェブサイトを訪れた人たちが次に見るものは、そのプロジェクトについての簡単な説明や目標などのメッセージです。それらを見て (たいていは 30 秒程度で)、人はそこから先に進むか引き返すかを決断します。このメッセージは、トップページの目立つ場所に配置しなければなりません。プロジェクト名のすぐ下に置くといいでしょう。

この声明は、具体的で内容を絞り込み、そしてなによりも簡潔でなければなりません。たとえば、以下に引用した http://www.openoffice.org/ の記述などがよい例です。

To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. (コミュニティーとして、国際的な最先端のオフィススイートを作成します。すべての主要なプラットフォーム上で動作し、そのすべての機能やデータに対してオープンコンポーネントベースの API と XML ベースのファイルフォーマットでのアクセス機能を提供します)

たったこれだけの文章ですが、主に訪問者の予備知識を利用することにより、重要なところはすべてヒットしています。 "コミュニティーとして (as a community)" と明記することにより、どこか１つの企業が開発を支配するものではないことを表しています。また "国際的な (international)" という言葉によって、このソフトウェアが複数の言語や地域で動作することを示しています。そして "すべての主要なプラットフォーム (all major platforms)" とあることから、おそらく Unix、Macintosh そして Windows で動作するであろうことが読み取れます。その他の箇所からは、インターフェイスが公開されていることやファイルのフォーマットが一般的なものであることなどがわかるでしょう。彼らが Microsoft Office の代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。この声明は一見したところ大雑把なようですが、実際にはきわめて絞り込まれたものです。また "オフィススイート (office suite)" という言葉を使用することで、その手のソフトウェアになじみがある人たちにとってかなり具体的な印象を与えることができます。ここでも声明を簡潔なものとするため、訪問者が持っているであろうと思われる前提知識 (この場合は MS Office に関するもの) を利用しているのです。

この声明の本質は、それが対象としているソフトウェアだけではなく「だれがそれを書いたか」にも依存します。たとえば、OpenOffice.org があえて "コミュニティーとして (as a community)" と書いているのがいい例です。このプロジェクトはもともと Sun Microsystems が始めたものであり、現在も同社が主なスポンサーとなっているからです。あえてこの文言を含めることで Sun は「開発プロセスを支配するようなつもりはない」ということを示しているわけです。このように「問題が起こる可能性を認識している」ということを示すだけでも、問題の発生を回避するのに大いに効果があるのです。一方、特定の企業の支援を受けているわけではないプロジェクトについてはこのような文言は不要でしょう。結局のところ、普通はコミュニティーベースの開発になるわけですから、それをわざわざ示す必要はないわけです。

フリーであることを宣言する

プロジェクトの目標についての説明 (ミッションステートメント) を読んで興味が残っているひとたちは、もっと詳細な情報を知りたくなることでしょう。たとえばユーザー向けドキュメントや開発者向けドキュメントなど。そして、何かをダウンロードしたくなるでしょうね。でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。

プロジェクトのトップページで、それがオープンソースであることを明記しておかなければなりません。 当然のことだとお考えかもしれません。しかし、世の中にはそれができていないオープンソースプロジェクトが山ほどあります。私がかつて見たとあるフリーソフトウェアプロジェクトのウェブサイトのトップページでは、そのソフトウェアの配布時にどのライセンスを適用するかが示されておらず、さらにそのソフトウェアがフリーなのかどうかさえ書かれていませんでした。また、このような重要な情報がダウンロードページや開発者向けページなどにしか存在しないというページもよくあります。このような場合は、重要な情報を得るためにさらにマウスクリックが必要となってしまいます。最もひどかった例では、ウェブサイト上のどこにもライセンスが示されていなかったものもありました。ソフトウェアをダウンロードしてその中身を見ない限り、ライセンスの内容がわからなかったのです。

同じようなミスはしないでください。そんなことをすると、せっかくの開発者候補やユーザー候補の多くを失うことになります。トップページのミッションステートメント部の次に、そのプロジェクトが「フリーソフトウェア」あるいは「オープンソース」であることを示し、さらに具体的なライセンスについても記しておきましょう。どのライセンスを適用すればいいかについては「ライセンスの選択と適用」で説明します。また、ライセンスに関するさまざまな問題については 10章ライセンス、著作権、特許 で詳しく説明します。

ここまでの情報を見るのに、訪問者が要する時間は１分かそれ以下でしょう。これらの内容をもとに、彼/彼女らがさらに次を読み進めるかどうかを決断するわけです。次のセクションでは、最初の５分間で訪問者が見るであろう内容について扱います。

機能一覧・要件一覧

そのソフトウェアのちょっとした機能一覧 (まだ完成していない機能を一覧に含めてもかまいません。しかしその場合は "予定" とか "開発中" などとはっきり示して置くようにしましょう)、そしてそれを動かすために必要な要件についての説明が必要です。機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに答えるためにまとめたものと考えるといいでしょう。これは、単にミッションステートメントの内容をより深く掘り下げたものと考えてもかまいません。たとえば、ミッションステートメントで次のように説明したとすると、

豊富な API を備えた全文インデクサー・サーチエンジンを作成します。大量のテキストファイルに対する検索サービスを準備するプログラマーの利用を想定しています。

機能一覧、要件一覧でその詳細を説明することによってミッションステートメントの範囲を明確にします。

機能
プレーンテキスト、HTML および XML の検索
単語あるいはフレーズによる検索
(予定) あいまい検索
(予定) インデックスの差分更新
(予定) リモートのウェブサイトのインデックス化
要件
Python 2.2 以降
インデックス作成用のディスク領域 (元のデータの約２倍の大きさ)

これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうかを判断します。また場合によっては開発者としてプロジェクトに参加することを検討してくれるかもしれません。

開発の進捗状況

そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることでしょう。特に新しいプロジェクトの場合は、そのプロジェクトが掲げている目標のうち現在どれくらいが達成されているのかが気になるところです。十分に成熟したプロジェクトの場合に気になるのは、「そのプロジェクトが現在活発に保守されているのか」「どれくらいの頻度で新しいバージョンがリリースされているのか」「バグレポートに対する反応の速さはどれくらいか」などとなります。

これらの質問に答えるために、開発状況を示すページを作らなければなりません。ここには、直近の目標とそれを達成するために必要なもの (たとえば「ある特定の分野に強い開発者を募集しています」など) を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するといいでしょう。そうすることで、そのプロジェクトが「進捗」というものをどのように定義し、その定義にしたがってどのくらい速く前進しているのか、ということが訪問者にわかるようにしておきます。

まだできあがっていないことを恐れる必要はありません。できあがってもいないことを変にごまかすこともやめましょう。ソフトウェアの開発にはいくつかの段階があることを、みんな知っています。 "このソフトウェアはアルファ版です。既知のバグが存在します。とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにしてください" と言ったところで、何も恥ずかしいことはありません。そのような段階でプロジェクトが必要としている開発者は、「アルファ版」という説明なんかではおびえたりしません。対エンドユーザーという面では、まだできあがってもいないソフトウェアにユーザーが群がってしまうほどまずいことはありません。いったん「不安定」だとか「バグだらけだ」だとかいう評判が出てしまうと、それを払拭するのは大変な話になります。結局のところ、多少保守的なほうがうまくいきます。そのソフトウェアが「ユーザーが期待しているよりも安定していた」ほうが、期待はずれだった場合よりもずっといいでしょう。そしてそのほうが、口コミによる広がりが期待できます。

アルファ版/ベータ版

アルファ版 とは、通常は一番最初のリリースのことを指します。とりあえずは動かすことができ、ひととおりの機能はそろっていますが、まだバグが残っている状態です。アルファ版の主な目的は、利用者からのフィードバックを得ることです。それによって開発者は、何に取り組むべきかを知ることができます。その次の段階となるのがベータ版です。これは、致命的なバグはすべて修正済みとなっていますが、まだリリースに向けての十分なテストが行われていない状態です。ベータ版の目的には２種類あります。１つには、バグが見つからない場合にそれをそのまま公式リリースとすることです。もう１つには、公式リリースを早く行うため、開発者が詳細なフィードバックを受け取れるようにすることです。アルファ版とベータ版の差をどこにおくかは、あなたしだいです。

ダウンロード

標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージはなくてもかまわないでしょう。ただし、ビルド手順が面倒だったり依存性が複雑だったりして、ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は、バイナリ版も必要です (でも、そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。

配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。あなたがある病気の撲滅を狙っているなら、薬を配る際に独自の注射器が必要となるような面倒な手段はとらないでしょう。同様に、ソフトウェアについても標準的な手順でビルド・インストールできるようにしておきましょう。標準から外れれば外れるほど、ユーザー候補や開発者候補は狼狽してそのプロジェクトから離れてしまいます。

当然のことだと思われるかもしれません。しかし、多くのプロジェクトは本当に切羽詰るまでインストール手順を標準化しようとはしないものです。 "ま、リリースに近づいたらそのときにやろうよ。そんなことはいつでもできるんだから。" といった言い訳をしてしまいがちです。彼らはわかっていないのですが、そういった作業を後回しにしてしまうと、結果的にリリースに近づくまで余計に時間がかかってしまうのです。なぜならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでしまうからです。もっとも悪いことに、彼らはそのような開発者を失いつつあることに気づきません。なぜならば、この過程は「誰かがウェブサイトを訪れた→ソフトウェアをダウンロードした →ビルドしようとした→失敗した→あきらめた」という、イベントが発生しなかったことの積み重ねだからです。あきらめた本人以外には、そんなことがあったということはわかりません。もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、そしてそれをプロジェクトのメンバーは誰も気づかないのです。

面倒だが見返りの大きい作業は、できるだけ早めに済ませてしまいましょう。パッケージをきちんと作成すると、プロジェクトへの参加障壁を劇的におろすことができ、結果として大きな見返りを得ることになります。

ダウンロード用のパッケージをリリースするときは、それに対して一意なバージョン番号を与えることが大切です。それによって人は、２つのリリースのうちどちらが新しいのかを知ることになるのです。バージョン番号のつけかたについては 7章パッケージの作成、リリース、日々の開発 の「リリースに番号を付ける」で、そしてビルド手順やインストール手順の標準化については同じ章の「パッケージング」でそれぞれ詳しく説明します。

バージョン管理システムやバグ追跡システムへのアクセス

単にそのソフトをインストールして使いたいだけという人にとっては、ソースパッケージで十分でしょう。しかし、デバッグをしたり機能追加をしたりしたい人たちにとってはそれだけでは不十分です。毎晩最新ソースのスナップショットを作成するという手もありますが、開発が活発に行われているコミュニティーではまだこれでも完璧だとはいえません。常にその時点の最新のソースにアクセスしたいという人たちにその手段を提供するのが、バージョン管理システムです。バージョン管理システム上のソースに匿名でアクセスできるようにしておくと、「このプロジェクトは、新しいメンバーの参加を歓迎しています」というメッセージをユーザーと開発者の両方に送ることになります。もし今すぐにバージョン管理システムを用意できない場合は、近々公開予定であるというメッセージを書いておくようにしましょう。バージョン管理システムについては 3章技術的な問題 の「バージョン管理」で詳しく説明します。

バグ追跡システムについても同じです。バグ追跡システムの意義は、開発者に対する有用性だけでなく、それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。多くの人は、バグデータベースが公開されていると「熱心に開発が進められているようだ」と感じます。さらに、バグデータベースにたくさんのバグが登録されていればいるほど、そのプロジェクトの見栄えはよくなります。ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。バグデータベースに登録されたバグの数が実際何に依存しているかというと、それは次の３つです。まず、そのソフトウェアに存在するバグの絶対数。次に、そのソフトウェアを使用しているユーザー数。そして最後に、ユーザーが新規のバグを登録できるための利便性です。このうち最初の１つよりも後ろの２つの方が重要な要素になります。ある程度の規模と複雑さを持つソフトウェアには、基本的にバグが含まれているものです。本当の問題は、それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。したがって、よく整備された (バグに対する対応がすばやく、重複したバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、バグデータベースがなかったりほとんど機能していなかったりするプロジェクトよりずっと印象がよくなります。

もちろん、そのプロジェクトが本当に始まったばかりなのならバグデータベースに登録される内容はほんのちょっとだけになるでしょう。それについてはどうにもしようがありません。しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、プロジェクトのバグ登録が健全な比率を保っている、ということを読み取ることができます。彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。

バグ追跡システムに登録されるのはソフトウェアのバグだけではありません。機能追加の要望やドキュメントの変更、とりあえず保留になっている作業などが登録されることも多々あります。バグ追跡システムの運用方法については 3章技術的な問題 の「バグ追跡システム」で詳しく説明するので、ここでは深く立ち入りません。プロジェクトの見栄えという観点から見て大切なのは、まずバグ追跡システムが 存在する ということ。そしてそれがプロジェクトのトップページからたどれる場所にあるということです。

連絡手段

プロジェクトの関係者の連絡先を知りたいという人もあらわれることでしょう。関係者と連絡を取れるように、メーリングリストのアドレスやチャットルーム、IRC チャンネル、掲示板などの場所を示しておきましょう。あなた、あるいはその他のプロジェクト関係者がこのメーリングリストに参加していることも明記しておきましょう。そうすることで、「そこに行けば開発者と話すことができる」ということが伝わります。あなたがメーリングリストに参加しているからといって、すべての質問に答えなければならないとかすべての要望に答えなければならないとかいった義務が発生するわけではありません。長い目で見れば、ユーザーのほとんどはこのようなメーリングリストや掲示板には参加しません。とはいえ、必要ならいつでも参加できるということを示すだけで、安心感を与えることができます。

プロジェクトを立ち上げたばかりのころは、エンドユーザー向けと開発者向けにフォーラムを分ける必要はありません。それよりも、プロジェクトにかかわる人たちが１つの「部屋」に集まってわいわいがやがや話をするほうがずっといいでしょう。アーリーアダプター層においては、開発者とユーザーの区別はあいまいです。あえて分類するとしても、プロジェクトの初期には開発者の比率がかなり高くなります。アーリーアダプターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。しかし、少なくともそのプロジェクトの今後の方向性に関する議論には興味を持っていることでしょう。

本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。この段階では「とりあえずコミュニケーション用の場所が必要だ」というくらいで十分でしょう。後で、6章コミュニケーション の「巨大化への対応」においてさらに詳しく説明します。ここでは、掲示板の設置や管理の方法について扱います。また、いつかユーザー向け会議室と開発者向け会議室を分割することになったときに、両者の間に溝を生じさせないための方法も説明します。

開発者向けのガイドライン

開発者としてプロジェクトに参加しようと考えた人は、まず開発者向けのガイドラインを探すことになるでしょう。このガイドラインは、技術的なものというよりもむしろ社会的なものとなります。たとえば開発者同士のやりとりの方法、ユーザーとのやりとりの方法、プロジェクトをうまく進めるためにどのようにしていくかなどです。

このトピックについては 4章プロジェクトの政治構造と社会構造 の「全てを記録しておく」で詳しく説明します。ここでは、そこに含める基本的な内容だけをまとめておきます。

他の開発者とのやり取りのためのフォーラムの場所
バグ報告やパッチの投稿の方法
開発の基本方針— 「慈悲深い独裁者」式でいくのか「民主主義」式でいくのか、あるいはそれ以外の手法をとるのか

ところで、「独裁者」という言い方には、特にそれを批判する意図はありません。特定の開発者だけがすべての変更に対する拒否権を行使できるというような専制政治を行ってもまったく問題はありません。実際、多くのプロジェクトはこの方式で成功しています。大事なのは、そのプロジェクトがそういう方針で運営されているとはっきり示しておくことです。実際には独裁型なのに無理に民主主義っぽく見せようとすると、人は離れていってしまいます。きちんと独裁型であることを宣言しておけば、少なくともその独裁者が有能で信頼できる人である限りはうまく進みます。

開発者向けガイドラインの実例は http://subversion.apache.org/docs/community-guide/ をご覧ください。また、http://www.openoffice.org/dev_docs/guidelines.html には、より一般的なガイドラインがあります。こちらは、技術的な話題よりもプロジェクトの管理体制やプロジェクトへの参加方法に重点を置いています。

プログラマー向けにソフトウェアについての説明を行うことについては、本章の後半の「開発者向けドキュメント」で取り上げます。

ドキュメント

ドキュメントは必要不可欠です。何か読んでもらうものが必要です。たとえそれがごく簡単な未完成のものであってもかまいません。この作業はまさに、先ほど言及した「骨折り仕事」の範疇に属するものです。新しいオープンソースプロジェクトがしばしば最初につまづくのがこの分野です。ミッションステートメントや機能一覧を作成するとか、ライセンスを選択するとか、開発状況をまとめるとかいったことはどれも比較的小規模な作業です。しかも「ここまでできたら完了」という点がはっきりしており、通常は一度作成すればそれ以降は手を加える必要のないものです。ドキュメント作成はこれらとは異なり、決して終わることのない作業です。みんながドキュメント作成を嫌がるひとつの理由がここにあります。

ドキュメント作成において最も注意すべき点は、ドキュメントの書き手にとって有用な内容と読み手にとって有用な内容とはまったく正反対であるということです。はじめて使用するユーザーにとって必要なドキュメントは、基本をまとめたものです。ソフトウェアを手っ取り早くセットアップする方法や動作の概要、そして一般的な作業をするための手引きなどが必要でしょう。しかし、これらの内容はまさに、ドキュメントの書き手 があまりにもよく知りすぎていることです。そのためかえって、物事を読者の視点から眺めたり、また、 (ドキュメントの書き手にとっては) 言及に値しないほど明白な手順を、骨を折って詳細に説明するのが困難になる可能性があります。

この問題を解決するためのマル秘手段は存在しません。誰かが腰を落ち着けてそれを書かなければならないのです。そして、初心者にそれを見せて内容をチェックしてもらわなければなりません。ドキュメントの書式は、たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML といったような、シンプルで編集しやすいものにしましょう。すなわち、ふと思ったときお手軽かつ迅速に更新するのに適した書式です。これらを使用すると、ドキュメントの作成者があとからそれを更新する際の手間も少なくなります。また、後からプロジェクトに合流した人にとっても、作業に参加しやすくなるでしょう。

基本ドキュメントをきちんと整備できるようにするためのひとつの方法としては、ドキュメントで網羅する範囲を事前に限定してしまうというものがあります。このようにしてしまうと、少なくともドキュメントの作成が果てしない作業に思えてしまうことはなくなるでしょう。実際的な目安としては、以下に挙げる最低限の基準は満たすようにすべきです。

読者に対して、ソフトウェアを使用するために必要となる技術的な前提知識を明確に示す。
そのソフトウェアのセットアップ手順を、明確かつ完全に説明する。そしてドキュメントの最初のほうで簡単な動作テストの方法や基本的なコマンドを説明し、セットアップが正常に完了したのかを確認できるようにする。導入に関するドキュメントは、ある意味実際の使用法のドキュメントよりも重要です。ソフトウェアをインストールして起動するためにより多くの努力を注ぎ込んでいればいるほど、そのユーザーはより粘り強く、ドキュメントが不十分な高度な機能を理解しようとするのです。ユーザーが諦めるとしたら、それは初期であることが多くなります。つまり、最も初期の段階であるインストール時にこそ最大のサポートが必要となるわけです。
チュートリアル形式の例を用いて、一般的な作業の方法を示すこと、もちろんさまざまな作業に対するたくさんの例があるにこしたことはありませんが、時間が限られている場合は、どれかひとつに絞ってそれを完璧にするようにしましょう。そのソフトウェアがなにかひとつの場面で 使えることがわかれば、あとは自分自身で他の使い方を見つけてくれるようになります。また、もしかしたら「残りのドキュメントを書いてあげようか？」なんていう幸運なことになるかもしれません。これについては次のポイントで取り上げます。
ドキュメントがまだ出来上がっていないところについては、それを示しておくこと。読者に対し、足りていない部分があることを認識していますよ、ということを示すことにより、あなたは読者の視線に合わせることになります。読者に共感を示すことにより、読者に対し、重要なことをプロジェクトに納得してもらうための苦闘に直面することはない、ということを再保証することになるのです。別に「いつまでにこのドキュメントを仕上げる」と表明する必要はありません。ボランティアの助けを広く求めるものとして取り扱うのも同程度に正当なことです。

この最後に述べた点は、実のところ、より広範囲の重要性があり、単にドキュメントだけに限らずプロジェクト全体にあてはまることです。既知の足りていない部分を正確に会計することは、オープンソースの世界においては当たり前のことだということです。そのプロジェクトの欠点を必要以上に誇張する必要はありません。単に、事情がそれを要求する場合 (ドキュメントやバグ追跡データベース、あるいはメーリングリストにおける議論など) に、それを厳正かつ私情を交えずに明らかにするだけのことです。それを負け犬根性だという人はいないでしょうし、明示的に示さない限りは「いつまでにこれを解決する」という公約だと受け取る人もいないでしょう。ソフトウェアを使用していると、だれでもそのソフトウェアの欠陥を発見してしまうものです。彼らが心の準備をできるようにしておいてあげましょう。すると、そのプロジェクトは自分たちのことがよくわかっているとみなされるようになります。

FAQ の管理

FAQ ("Frequently Asked Questions"、つまり "よくある質問集") は、教育という観点において投資効果の最も高いものの１つです。 FAQ は、ユーザーや開発者が実際に質問する内容 —彼らが質問することをあなたが 期待した 内容ではありません—にチューニングされています。その結果、よくメンテナンスされている FAQ を探した人はたいてい、まさに欲しかった回答が見つけられるようになります。ユーザーは、何か問題に出くわすとまず FAQ を調べます。公式マニュアルよりも FAQ のほうを先に見ることも多いでしょう。そして、他のサイトから最も多くリンクされることになるのも FAQ となるでしょう。

残念なことに、プロジェクトが始まったばかりのころは FAQ を用意することはできません。FAQ は誰かが書くものではなく、徐々に成長していくものだからです。FAQ は、その名前からして反応的なドキュメントであり、多くの人が日々ソフトウェアを使っていくにしたがって成長するものです。これから受けることになるであろう質問を正確に予測することなど不可能なので、有用な FAQ を腰を据えてゼロから書き上げることなどできないのです。

したがって、FAQ を書こうとして時間を浪費することは避けましょう。しかし、ほとんど空っぽの FAQ のテンプレートを用意しておくことは良い考えかもしれません。そうすることによって、プロジェクトが動き始めた後にユーザーが質問と回答を投稿してくれるかもしれません。この段階で大事なのは、完全性ではなく利便性です。 FAQ が追加しやすいようになっていれば、皆がそこに追加してくれるでしょう (FAQ を適切に管理するという作業は決して簡単なものではなく、興味をそそる問題です。これについては、 8章ボランティアの管理 の「FAQ マネージャー」でより詳しく説明します)。

ドキュメントの公開方法

ドキュメントは２通りの方法で公開しなければなりません。オンライン (ウェブサイト上で直接公開するもの)、そして ソフトウェアの配布物としてダウンロード可能なもの (7章パッケージの作成、リリース、日々の開発 の「パッケージング」を参照してください) の２通りです。オンラインで公開しなければならない理由は、人は普通そのソフトウェアをダウンロードする前にドキュメントを読むことが多いからです。ダウンロードに値するかどうかを、ドキュメントの内容で判断するわけです。しかし、それだけでなくソフトウェアにも同梱しておく必要があります。これは、ダウンロードすることでそのパッケージを使用するために必要なものがすべて手に入る (すなわち、ローカルにアクセス可能になる) ようにすべきである、という原則に従ったものです。

ドキュメントをオンラインで提供する際には、ドキュメント全体を単一の HTML ページにまとめたものへのリンクを用意しておくようにしましょう (このページへのリンクには、"完全版" や "すべてをひとまとめにしたもの"、あるいは "単一の大きなページ" といった説明をつけておきます。これによって、そのページの読み込みに時間がかかることを示します)。これは、ドキュメント全体から特定の単語やフレーズを検索したいといった用途において便利です。一般に、そのような場合は何を探したいのかが既にわかっています。単に、それが第何章にあるのかが思い出せないだけなのです。そんな人たちにとっては、あるページには目次だけ、次のページには導入だけ、その次のページにはインストール方法だけ、…… といったドキュメントほどストレスが溜まるものはありません。こんな形式のページ構成だと、ブラウザの検索機能が無意味になってしまいます。個別に分割した形式が便利なのは、必要な内容が第何章にあるのかが事前にわかっている場合です。あるいは、ドキュメント全体を頭から最後まで順に読んでいきたい人にとっても便利でしょう。しかし、ドキュメントにアクセスする人の多くは、このパターンには 当てはまりません。よくあるパターンは、そのソフトウェアの基本的な内容をある程度理解している人が、特定の単語やフレーズを検索するといった使い方です。そんな人たちに対して単一の検索可能なドキュメントを提供しなければ、彼らにとっては非常に生きにくい世界になってしまいます。

開発者向けドキュメント

開発者向けドキュメントを書く目的は、プログラマーがコードを理解するのを助けること、そしてコードの修正や拡張ができるようになるのを助けることです。先ほど説明した 開発者向けガイドライン は技術的というよりも社会的な内容でしたが、今回説明するドキュメントはこれとは少々異なります。開発者向けガイドラインは、プログラマー同士がお互いうまくやっていくための方法をまとめたものです。一方、開発者向けドキュメントはコードそのものとうまくやっていくための方法を示すものとなります。利便性のためにこれらの２つのドキュメントがひとつにまとめられていることもあります (先ほど例でしめした http://subversion.apache.org/docs/community-guide/ のように) が、そうしなければならないというわけではありません。

開発者ドキュメントがいかに有用なものであったとしても、それが原因でリリースを遅らせるようなことがあってはなりません。そのプログラムの作者自身がコードに関する質問に答えられる (そして答える気がある) のなら、当面はそれで十分です。実際のところ、何度も何度も同じ質問に答える羽目になるっていうことがドキュメント作成の動機となることもあります。しかし、ドキュメントを書き始める前であっても、プロジェクトに協力することを決心した人たちは何とかコードと格闘しようとするものです。何が人をそこまでさせるのかといえば、そのコードがきっと何か自分の役に立つだろうと考えているからです。人がそれを信じていれば、自分自身で何とかしようとするでしょう。信じていなければ、大量の開発者向けドキュメントがあったとしてもあまり役立たないでしょう。

なので、もしどちらか一方に向けたドキュメントしか書く時間がないのであれば、まずユーザー向けのドキュメントを作成しましょう。ユーザー向けのドキュメントは、事実上開発者向けのドキュメントでもあります。そのソフトウェアの開発に参加しようとしているプログラマーは、まずそのソフトウェアの使い方を身に着けなければならないからです。後になって他のプログラマーが同じような質問を何度も何度も繰り返すようになったときに、あらためて時間をとってドキュメントを作成すればいいでしょう。

プロジェクトによっては wiki を用いてドキュメントを書き始めるところもあります。それどころか、wiki をメインのドキュメントとしているところもあります。私の経験上、これはあまりうまくいかないものです。もしうまくいくとすれば、それはドキュメントの構成をしっかり把握し、そこに何を書くべきかを熟知した数人の人間が頻繁に wiki を更新している場合のみでしょう。詳細は、3章技術的な問題 の「Wiki」をご覧ください。

使用例とスクリーンショット

そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり、グラフィカルあるいはそうでない特徴的な出力を行ったりする場合は、そのサンプルをプロジェクトのウェブサイトに公開しておきましょう。インターフェイスの場合は、スクリーンショットがこれにあたります。出力の場合は、同じくスクリーンショットか、あるいは実際の出力ファイルとなります。これはどちらも、即座の満足感に対するユーザーの欲求を満たすものです。長々とした説明やメーリングリストでのやりとりよりも、ほんの一枚のスクリーンショットのほうが説得力を持つこともあります。なぜなら、スクリーンショットはまさにそのソフトウェアが 動作した結果であることに疑いの余地がないからです。バグだらけかもしれません。インストールが難しいかもしれません。ドキュメントが足りないかもしれません。でも、スクリーンショットさえあれば、何とかがんばれば動かすことができるんだということの証明になります。

スクリーンショット

作ったことがない人にとっては、スクリーンショットの作成は大変なものに感じられるかもしれません。そこで、ここではその基本的な方法を説明します。Gimp (http://www.gimp.org/) を立ち上げて、メニューから File->Acquire->Screenshot を選び、Single Window あるいは Whole Screen のいずれかを指定して OK をクリックします。その次にマウスでクリックしたウィンドウあるいはスクリーンが、 Gimp に画像として取り込まれます。あとは、必要に応じて画像の一部を切り出したりサイズを変更したりします。その方法は http://www.gimp.org/tutorials/Lite_Quickies/#crop で説明されています。

プロジェクトのウェブサイトに置くことのできる情報は、これら以外にもたくさんあります。最新情報のページやプロジェクトの歴史のページ、関連サイトへのリンク、サイト内検索の機能、寄付の受付などです。もし時間が許したり何か特別な理由があるのなら、これらを作成してもよいでしょうが、プロジェクトの立ち上げ時には通常はどれも不要です。しかし、将来のために心に留めておきましょう。

公開場所

オープンソースプロジェクトのために、ウェブサイト用の領域やバージョン管理機能、バグ追跡システム、ダウンロードエリア、掲示板、バックアップなどの機能を無料で提供するサイトがいくつかあります。詳細はサイトによって異なりますが、基本的な機能はどこでも同じようなものです。これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。

あらかじめ用意されているホスティングサイトを使うことの利点と欠点、ホスティングサイトの一覧などについての詳細は、 3章技術的な問題 の「ツールが一通り揃ったホスティングサイト」をご覧ください。

ライセンスの選択と適用

このセクションでは、ライセンスの選択方法について手っ取り早く大雑把に説明します。個々のライセンスについての法的な意味合いや他のフリーソフトウェアと組み合わせて使用する際に出てくる影響などについての詳細は 10章ライセンス、著作権、特許 をご覧ください。

世の中には、フリーソフトウェア用の優れたライセンスがたくさんあります。ここでは、そのほとんどについては取り上げません。なぜならそれらは特定の人や組織の法的な需要を満たすためだけに書かれたものだったりあなたのプロジェクトには適切でないものだったりするからです。ここで取り上げるのは、よく用いられているものに限定します。ほとんどの場合は、ここで取り上げたものの中からライセンスを選択することになるでしょう。

「何でもできる」ライセンス

あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にならないのなら、 MIT/X スタイル のライセンスを使用しましょう。これは必要最小限のことのみを記したライセンスです。このライセンスは、名目上の著作権 (実際には複製を制限しません) と無保証であるということだけを明記するシンプルなものです。詳細は「MIT/X Window System ライセンス」を参照してください。

GPL

あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にいらないのなら、 GNU General Public License (http://www.gnu.org/licenses/gpl.html) を使用しましょう。 GPL は、おそらく現在世界中でいちばんよく知られているフリーソフトウェアライセンスです。これは最大の利点です。というのも、プロジェクトに参加しようと考えているユーザーの多くはこのライセンスを知っており、そのライセンスについて学習する手間が省けるからです。詳細は、10章ライセンス、著作権、特許 の「GPL」を参照してください。

ライセンスを適用する方法

ライセンスを決めたら、それをソフトウェアに適用しなければなりません。

まず最初にすべきことは、プロジェクトのトップページにライセンスを明記することです。実際のライセンスの本文をここで示す必要はありません。単にライセンスの名前を示すだけにしておき、ライセンスの本文は別のページに置いてそこにリンクするようにしましょう。これにより、そのソフトウェアをどのようなライセンスのもとで提供 するつもり なのかを示すことはできます。しかし、法的な側面からみるとこれだけではちょっと不十分です。さらに、ソフトウェア自身にライセンスが含まれていなければなりません。

標準的な方法は、ライセンスの全文を含んだテキストファイル COPYING (あるいは LICENSE) をソフトウェアのソースコードに同梱し、それと同時に各ソースファイルの先頭に、簡単な説明をコメントとして付加します。この説明に含めるのは、著作権の発生した日付や著作権の保持者、ライセンス名、そしてライセンスの全文がどこで取得できるかなどです。

これにはさまざまなパターンがあります。ここでは、ひとつの例として GNU GPL を見てみましょう。各ソースファイルの先頭には、次のような説明を付加します。

Copyright (C) <年>  <作者名>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>

この文面では、ライセンスの全文がプログラムに同梱されているファイル COPYING あるいは LICENSE に存在することは明記されていません。しかし、通常はこの名前のファイルを使用することになります (上の文面を変更して、このファイル名を明記するようにしてもかまいません)。このテンプレートには、ライセンスのコピーを取得するための手紙の宛先も記載されています。これ以外の一般的な方法としては、ライセンスの本文を記載したウェブページへのリンクを用意するというものもあります。

弁護士の助言にしたがって (そんな金銭的余裕がなければあなたの自己判断で)、ライセンスのコピーが最も恒常的に存在すると思われる場所を使用するようにしましょう。たとえば、あなたのプロジェクトのウェブサイト上のどこかでもかまいません。一般的には、各ソースファイル中に含める注意書きは上のものと全く同じである必要はありません。著作権保有者と日付、ライセンスの名前、そしてライセンスの全文がどこで取得できるのかといったことが含まれていればいいのです。

うまく引っ張っていく

ここまで取り上げてきたのは、プロジェクトの立ち上げ時に一度だけ必要となる作業でした。ライセンスの選択や最初のウェブサイトの作成などです。しかし、プロジェクト開始時に最も大切なのは、それ以外の動的な作業です。メーリングリストのアドレスを決めるなんていうのは簡単なことです。でも、そのメーリングリストでのやり取りを有益で前向きなものに保つのはそれとはまったく別の話となります。これまで何年にもわたって社内の閉じた環境で開発が進められてきたものをオープンにすると、その開発プロセスはこれまでとはかわります。これまでの開発者たちに対して、その変更に対応できるように準備をさせなければなりません。

最も困難なのが、はじめの一歩です。なぜなら、今後の方向性に関する先例もなければ今後どのようになっていくのかもまだはっきりわからないからです。プロジェクトの安定性は、形式張った方針からくるものではなく、開発者の間で徐々にできあがっていく集合知によってもたらされるものです。そして、これはしっかりとらえにくいものです。明文化された規則があることもありますが、それはたいてい、プロジェクトを本当に動かしているこれらの無形の合意をまとめあげたものにすぎません。明文化された方針によってプロジェクトの文化を定義することはできませんし、それに近づくことさえできません。

このようになるには、いくつかの理由があります。成長と変化の速さは、人が考えるほどには文化の蓄積に影響を与えません。変化の速度があまりにも高速にならない限り、新入りさんがそれを学ぶ時間はあります。そして学び終えた後は、自分自身でそのやりかたを補強してくれるでしょう。童謡が、いったいどのようにして何百年も歌い継がれるようになったのかを考えてみましょう。現在の子どもたちが歌っている童謡は、基本的には数百年前の子どもたちの歌っているものと同じです。もちろん、昔の子どもたちが童謡を歌っていた頃には現在の子どもたちはまだ産まれていません。子どもたちはその歌を年長者から聞いて覚えます。そして子どもたちが成長すると、年少者の前でそれを歌って聞かせるわけです。もちろん、子どもたちは意識的にそうするよう指示されているわけではありません。しかし、何百年も同じ歌が歌い継がれているという事実は、このような伝承が常に繰り返し行われていることを示しています。フリーソフトウェアプロジェクトの歴史が今後何百年も続くかどうかはわかりません (どうなるかはまだわかりません) が、この仕組みは似たり寄ったりでしょう。しかし、その回転率はより高速になるので、より活発かつ慎重に伝承を行うようにしなければなりません。

この動きは、人が基本的に社会規範を求めているという性質があるので成功しやすくなります。それこそが人が存在する理由なのですから。一般的な方法でまとめあげられた集団なら、そこに参加しようとする人々は本能的にその集団の一員として振る舞うためのやりかたを見つけようとするものです。より早い時期に先例を確立するには、そのプロジェクトに役立つ「グループとしての」振る舞いを作ることです。いったんできあがってしまえば、あとは勝手にそれが広まっていきます。

以下に示すいくつかの例は、よりよい先例を作るためにできる具体的なことをまとめたものです。これだけを行えば完全だというものではありません。単に、「早いうちに協力的なムードを作り上げておくとプロジェクトを運営しやすくなりますよ」ということを説明するためだけのものです。物理的には、個々の開発者がそれぞれ別の場所で作業をしているのかもしれません。しかし、まるで同じ部屋で一緒に開発しているかのように 感じさせる ために、いろいろなことができます。彼らがこのように感じてくれればくれるほど、プロジェクトに対してより時間をさきたいと思うようになるでしょう。以下の例は、Subversion プロジェクト (http://subversion.tigris.org/) から選びました。私は、開始当時からこのプロジェクトに参加しています。しかし、これらの例は決して Subversion 独特のものではありません。同様の状況は大半のオープンソースプロジェクトで起こりえるでしょう。また、プロジェクトに片足を突っ込む際には意識しておく必要があることばかりです。

個人的な議論を避ける

プロジェクトを一般に向けて公開した後でも、難しい問題についての話し合いは内輪の関係者たちだけで行いたいと考えることもあるでしょう。これは、プロジェクトが始まったばかりのときにはあり得ることです。話し合うべきことは山ほどありますし、通常はその話し合いに参加する資格のある外部の協力者はほとんどいないからです。公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。メールでのやりとりに特有ののんびりした速度、合意を形成するのにかかる時間、本当は何もわかっていないのに「自分はすべてわかっている」と勘違いしているボランティアへの対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれることになるでしょうが、中にはずっと勘違いしたままの人だっています)、ある問題 X がより大きい問題 Y の一部であるときに、なぜ問題 Y ではなく問題 X だけを解決したいのかを理解してくれない人たち、などなど。こんなときに、密室の話し合いで決めた内容を "既成事実 (faits accomplis)"、あるいは少なくとも有力な選択肢として提示できればどんなに楽なことでしょう。

でも、そんなことをしてはいけません。

たとえ公開の場での議論の進行が遅くて厄介だとしても、長い目で見ればそれが一番望ましい方法です。重要な決定を内輪でこっそり行うのは、まるでそのプロジェクトに「貢献者よけスプレー」を振りまくようなものです。秘密の協議会がすべての重要な決定を行うというような環境では、やる気のあるボランティアは決してついてこないでしょう。さらに、公開の場での議論にはよい副作用もあります。

その議論が、新しく参加する開発者の訓練や教育に役立ちます。その議論をいったいどれだけの人が注目しているかは決してわかりません。大半の人たちは単なる傍観者として見ているだけで、黙ってそのソフトウェアについての情報を追いかけているのです。
その議論は、あなた自身 の訓練にもなります。技術的な問題を、そのソフトウェアにあまり詳しくない人たちにもわかるように説明するという技術を磨くことができます。これは実際に必要となる技術であり、すでにそのソフトウェアについて熟知している人たちと話しているだけでは身につけることができません。
議論の内容とその結論が公開されたアーカイブに残るようになります。後に同じような問題が発生したときに、同じ議論を繰り返す必要がなくなります。詳細は 6章コミュニケーション の「アーカイブを目に付きやすくする方法」を参照してください。

最後に、メーリングリスト上の誰かがそのやり取りに対して真の貢献をしてくれるかもしれません。つまり、あなたが思いもしなかった新たな考え方を示してくれるということです。これがどのくらいの頻度で起こるのかは断言できません。そのコードの複雑さがどれくらいか、そしてどの程度の専門知識を要するかによっても異なります。ただ、私のこれまでの経験上、その頻度はみなさんが思っているよりもかなり高くなります。 Subversion プロジェクトで、私たち (プロジェクトを開始した当時のメンバー) は深く複雑なさまざまな問題に直面していました。私たちは何ヶ月も悩み続けました。そして、率直に言って、当時できたてのメーリングリストにいるメンバーがこの手の議論に貢献してくれるとは期待していませんでした。そこで私たちは安易な方法をとることにしました。技術的なアイデアについての議論を個人的なメールのやりとりで行うようにしだしたのです。その様子を嗅ぎ付けた人 ^[13] から「議論は公開されたメーリングリストでしてくれ」と言われるまで、その状態が続きました。私たちはそれを受け入れ、その話題をメーリングリストに移動しました。そのとたん、数々の洞察に満ちた意見や提案が寄せられるようになり、私たちは驚きました。寄せられた意見の多くは、これまで私たちが考えもしなかったものでした。メーリングリスト上には、非常に 優秀な人間がいたのです。彼らはただ、メーリングリスト上にネタが投下されるのを待ちわびていたのです。確かに、すべて密室の議論ですませるのに比べれば時間はかかりました。しかし、時間をかけたのに十分見合うだけの成果が得られました。

"三人寄れば文殊の知恵" だとか "個人よりも集団のほうが常によい判断ができる" とかいうように一般化して逃げてしまうのではなく、集団のほうがよい結果がでる活動としてはどんなものがあるのかを知っておきましょう。大規模なピア-レビューなどがその例のひとつです。あるいは、とにかくたくさんの案を手早く出していくといった作業もそれにあたります。もちろんアイデアの質はそれを考えた人たちの質に依存しますが、困難な問題を皆にぶつけてみるまで、誰がどのような案を持っているかはわからないものです。

当然、内容によっては個人的に議論しなければならないものもあります。本書の中でもそのような例がいくつか登場します。しかし、基本方針として、隠す必要がないものは、すべて公開すべきである ということは常に心においておきましょう。

そのためには何らかのアクションが必要です。あなた自身が常に公開のメーリングリストに投稿しようと心がけるだけでは不十分です。隠す必要がない内容のメールを他の人から受け取ったら、それをメーリングリストにも流すようにしなければなりません。誰かが個人的に議論を始めようとしているとき、もしそれが個人的にする必要のないものなら、それを個人的に行うのか公開で行うのかに関する議論をすぐに始める責任があります。首尾よくその議論を公開の場に持ち出すか、あるいは個人的に話し合うのが適切であることがわかるまで、元の話題にはコメントしないでください。常にこのようにすることを心がければ、人はやがてデフォルトで公開の場を使用することになるでしょう。

炎上を阻止する

プロジェクトを一般に公開したら、フォーラムにおける失礼な振る舞いや侮辱的な発言にはゼロトレランスで (情け容赦なく) 対処しなければなりません。「ゼロトレランスで」とは、何か技術的に特別なことをしなければならないという意味ではありません。別の参加者を罵倒した参加者をメーリングリストから強制退会させる必要はありませんし、人を傷つけるようなコメントをしたからといってその人のコミット権を剥奪する必要もありません (理屈上は、結局のところそういった措置をとらざるを得ないことになるかもしれません。しかし、それはさまざまな対策がすべて失敗したときの最後の手段とすべきです。つまり、プロジェクトの開始当初にはそのようなことは起こりません)。ここで言うゼロトレランスとは、そんな振る舞いを決して見過ごさないということです。たとえば、技術的なコメントといっしょにプロジェクトの他の開発者に対する個人攻撃 (ad hominem) を含むコメントが投稿されたとしましょう。そんな場合は、まずその個人攻撃に対する指摘をしたうえで、技術的な内容についてはそれとは分けて返答するようにしましょう。

残念ながら、これは易しいことではありません。そして、たいていは建設的な議論が不毛な罵倒合戦に陥ってしまいます。人は、面と向かっては決して言えないことでもメールでは平気で言ってしまうものです。また、議論の内容もこの傾向に拍車をかけます。技術的な問題に関して、多くの人は「ほとんどの質問には正解がひとつしかない」と考えがちです。そしてその答えに同意しない人のことを無知で愚かな人だと思ってしまうのです。誰かの技術的な提案を否定すると、その人自身の人格を否定したように受け取られることもあります。実際、技術的な議論が人格攻撃に切り替わる瞬間を見極めるのは非常に難しいものです。厳しめの返答や処罰がいい考えではないひとつの理由がここにあります。そのかわりに、ちょっと雰囲気が怪しくなってきたなと感じたら、議論を友好的に進めるように促す投稿をするようにしましょう。その際に、特定の人物が意図的にそんなことをしているように非難することは避けなければいけません。しかし、そのような "町のおまわりさん" 的な投稿は、時として園児をしつける幼稚園の先生のように見えてしまうという傾向があります。

まず最初にひとこと。個人攻撃につながる (あるいはその恐れのある) コメントは控えてください。たとえば、J が設計したセキュリティ層について "コンピュータのセキュリティに関する基礎知識に欠ける無能な設計だ" と語るようなことです。それが正しいかどうかは別にして、これは議論の進め方としては間違っています。 J は信念を持ってこの提案をしたわけです。もし問題があるならその問題を指摘しましょう。そして皆でそれを修正するか、新しく設計をやりなおせばいいじゃないですか。 M は決して J を個人攻撃するつもりがないことは知っています。でも、その言い方はちょっとまずかった。もっと建設的な議論を進めましょう。
さて、提案内容に話を戻しましょう。私は、M の言うことはもっともだと思います……

ちょっと堅苦しく感じるかも知れませんが、これはかなりの効果があります。何かあったら必ず口を出すが、決して攻撃側に謝罪を要求したり落ち度を認めさせたりしない。そうではなく、そのまま放っておいて次回はよりおだやかに振舞うように促すのです。そうすれば彼らはきっとそれに従ってくれます。これをうまく行う秘訣のひとつは、どっちが悪いかとかどうすべきかといったメタ議論を主題にしてしまわないことです。そうではなく、本題に入る前の前置き程度の扱いにしておくべきです。「ここではそんな振る舞いはやめてください」と指摘した後はすぐに本題に移ります。そうすることで、相手側にも本題に返答する機会を与えることができるのです。もしそれでも「あなたに非難されるいわれはない」といったことを言われたら、もうそれ以上その話題を引きずるのはやめましょう。単にその話題に関する返信をやめておく (単に彼らは自分の主張を振りかざしているだけであり、返事を求めているわけではなさそうな場合) か、あるいは「出すぎたまねをしてしまってごめんなさい。メールではなかなかニュアンスが伝わりにくいので」と謝ったうえで本題に戻ればいいのです。不適切な振る舞いをした人たちの主張は、公開の場であるか否かにかかわらず決して認めないでください。もしかれらの方から謝罪があればすばらしいことですが、こちらから謝罪を要求しても相手をさらに怒らせるだけでしょう。

最終的な目標は、その集団に「礼儀をわきまえる」という空気を作り上げることです。これは、プロジェクトにとって大きな助けとなります。なぜなら、開発者が (自分が好んでサポートしようとしている) プロジェクトで罵倒合戦に巻き込まれる心配がなくなるからです。そんなことが原因で開発者候補がプロジェクトが離れていることに、あなたは気づかないかもしれません。誰かがメーリングリストにひっそり参加してそのプロジェクトの状況を観察し、参加するための障壁が厚いことがわかり、結局参加することをあきらめるということがあるかもしれません。フォーラムを友好的な雰囲気にしておくことが、長期的に生き残るための作戦として有効です。また、これはプロジェクトが小さいうちから心がけておいたほうが実現しやすいことです。いちどそんな文化ができあがってしまえば、あなたひとりがいちいちそれを主張して回る必要もなくなるでしょう。皆がそういうふうに持って行ってくれるからです。

きちんとしたコードレビューの習慣

開発コミュニティーをうまく育てていくために最適な方法は、開発者どうしがお互いのコードを見せ合うことです。これを効率的に行うには、技術的な支援が効果的です。特に便利なのが、コミット時のメール通知です。これについては「コミットメール」で詳しく説明します。コミットメールとは、誰かがソースコードに加えた変更をコミットするたびにそのログメッセージと変更内容をメールで送る機能のことです (「バージョン管理に関する用語集」の差分を参照してください)。 コードレビュー とは、コミットメールがやってくるたびにその内容を確認し、バグや改善点がないかどうかを探す作業を指します。 ^[14]

コードレビューは、さまざまな点で役立ちます。オープンソースの世界におけるコードレビューの最大の効果は、ソフトウェアの品質を一定に保つことです。ソフトウェアにバグが含まれる原因は、コミットされたコードをきちんとチェックしなかったことにあります。コミットの内容を多くの目でチェックすることで、バグを残したまま公開してしまう危険性を減らすことになります。しかし、コードレビューの目的はこのような直接的なものだけではありません。コードレビューによって、自分たちの作業の内容を確認させることができます。コミットの内容をレビューするには、その作業についてよく知っておく必要があるからです。他の人が自分の作業を評価すると知っていれば、人は最善を尽くして作業を行うようになります。

レビューは公開の場で行わなければなりません。開発者同士が物理的に同じ部屋にいる場合であっても、誰かがコミットしたときにそのレビューを部屋の中だけで済ませてしまってはいけません。面倒でも開発者用のメーリングリストに投稿するようにしましょう。そのレビューを見ることで、参加者全員が何かを得ることになります。レビューの結果、何らかのコメントをしたり、場合によっては不具合を見つけたりすることもあります。レビューは日常の作業のひとつととらえましょう。そう。ちょうど皿洗いや芝生の手入れと同じような感覚です。

Subversion プロジェクトの開始当初は、日常的なコードレビューの習慣はありませんでした。すべてのコミットがレビューの対象になるという保証はありませんでしたが、変更されたコードの内容に興味のある人がそれを眺めるということはありました。当時のコードに紛れ込んでいたバグは発見可能でしたし見つけられるべきでした。当時の開発者のひとりである Greg Stein は、過去の経験からコードレビューが役立つことを知っていました。彼は、リポジトリへの すべてのコミット の１行１行の内容を詳細にまでわたってレビューするようになりました。誰かがコミットするたびにそのコミットについての Greg からのメールが開発者用メーリングリストに流れました。メールの内容は、コミットの内容を細かく切り刻んで分析し、起こりうる問題を指摘するといったものです。時には、優れたコードに対して賞賛を送ることもありました。コミットがあるたびに、バグを見つけたり注意しないとつまづくく恐れのあるあまりよい書き方ではないコードを見つけたりしていたのです。彼は、コミットの内容をレビューするのが自分ひとりであることについて、表立っては不平を述べることはありませんでした。かなりの時間をレビューに費やしていたにもかかわらずです。その代わりに、ことあるごとにコードレビューのすばらしさについて発言していました。やがて、私を含めた他のメンバーもコミットの内容を定期的にレビューするようになりました。何がそうさせたのでしょう? 決して Greg が私たちにそれを強制したわけではありません。彼は「コードのレビューが時間をかけるだけの価値のあるものである」こと、そして「他人のコードをレビューすることは新しいコードを書くのと同じくらいに重要である」ことを自身の行動をもって証明したのです。いざそういう習慣が身につくと、自分のコミットに何の反応もなければ逆に不安になります。開発者用メーリングリストで「誰か私のコードをレビューしてくれないかな?」と聞いてみたりなんかして。後に、Greg は別の仕事を得ることになり、 Subversion にあまり時間をかけられないようになってしまいました。彼は定期的なレビューをあきらめざるを得なくなったのです。しかし、そのときにはすでにレビューの習慣が私たちにも深く根付いていました。まるで太古の昔からそれが当たり前であったかのように。

コードのレビューは、最初のコミットの時点から始めましょう。差分を見れば簡単に発見できる問題としては次のようなものがあります。たとえばセキュリティ上の脆弱性やメモリリーク、コメントや API ドキュメントの不足、「ひとつずれちゃった (off-by-one) エラー」、呼び出し元と呼び出し先の規約の不一致などです。また差分の前後を確認することで発見できる問題もあります。しかし、より規模の大きい問題、たとえば繰り返し登場するパターンを一か所にまとめていないことなどは、定期的なレビューをしていないと見つけにくいものです。過去の更新の履歴の記憶を今回の差分と組み合わせることで、このようなの問題も見つけやすくなるのです。

何もコメントすべき点が見つからないんじゃないかとか、すべてのコードについて熟知しているわけじゃないとかいったことを気にしないでください。あらゆるコミットには何かしら言うべきことがあるはずです。何も疑問点が見つからなかった場合は、何か賞賛の言葉を贈ればいいだけのことです。大事なのは、すべてのコミッターに対して「あなたの作業内容を見ているし、理解もしている」というメッセージを伝えることです。もちろん「後でほかの人にレビューしてもらえるから、コミット前のチェックやテストは不要」というわけではありません。本来自分自身で発見すべき問題を、他人のレビューに頼ってはいけません。

もともと非公開だったプロジェクトをオープンにするときには、変化の大きさに気をつけよう

既存のプロジェクトをオープンにする場合は、クローズド環境での開発に慣れきった既存の開発者がいることに注意しましょう。環境が大きく変わることを彼らに理解してもらうこと、また、彼ら側の視点で考えた場合に何がどのように変わるのかをあなた自身が理解することが大切です。

彼らにとってその状況がどのようなものかを想像してください。これまでは、どのような設計でどのようなコードを書くのかを決めるのは特定のプログラマーの集団でした。また、彼らは同じ管理者のもとで働き、同じような重圧を受けていました。そしてお互いのスキルや弱点もよくわかっていました。今やそうではありません。自分の書いたコードをチェックしてもらうためにどこの誰ともわからない人に向かって公開しなければならないのです。彼らは純粋にコードの内容だけをもとにして判断を下します。それ以外のビジネス上の問題などは考慮しません。自分のコードについて、見知らぬ人からさまざまな質問が寄せられることになります。あんなに苦労して作ったドキュメントが、まだ不十分であることが判明して (お決まりのパターンです) 衝撃を受ける瞬間です。新入りさんは、みんな誰も知らない得体の知れない人たちばかりです。もし既存の開発者の中に自分のスキルに不安のある人がいたとしましょう。新入りさんが何も考えずに彼のコードの問題を指摘したら、彼にどのような悪影響を及ぼすでしょうか。特に、彼の同僚の目の前でそのようなことが起こったら、さらに状況は悪くなります。完全無欠のプログラマーが集まったチームでもない限り、このような問題が起こることは避けられません。実際、すべてのメンバーが一度はこのような経験をすることになるでしょう。これは、決して彼らがプログラマーとして劣っているからではありません。ある程度以上のサイズのプログラムには、必ずバグが含まれるものです。そして、コードのレビューによってそれが見つかることになります (本章の前半にある「きちんとしたコードレビューの習慣」をご覧ください)。と同時に、新入りさん自身は最初のうちは自分のコードをレビューされることはないでしょう。というのも、そのプロジェクトにある程度なじむまではコードを書くことができないからです。既存の開発者にとっては「奴らからさんざん批判されるだけで、こちらからは言い返すことができない」という状況になるわけです。そのため、古株の開発者たちに対する総攻撃状態になる危険性があります。

これを避ける最良の方法は、これから何が起こるのかを彼らに説明することです。最初のうちは不快に感じるかもしれないがそれは当然の心理であること、そしていつかはうまくいくようになることを説明しましょう。これらの警告は、プロジェクトをオープンにする前に閉じた場所で行わなければなりません。また、公開されたメーリングリスト上で「プロジェクトの開発方式が新しくなった」「なれるには少々時間がかかる」ということを知らせるのも効果的です。一番いいのは、なにか例を示すことです。既存の開発者たちがあまり初心者の質問に答えていないようなら、彼らに「もっと返事を書いてあげてよ」といってもあまり意味がありません。彼らは単に、どう答えればいいのかがわからないだけかもしれません。あるいは、他人の質問に答えるよりも実際にコードを書くほうが大切だと思っているのかも知れません。彼らを質問に答えさせるようにするには、まずあなた自身がお手本を見せましょう。公開されているメーリングリスト上で、誰かの質問に対して答えてみましょう。その質問をうまくさばくだけの専門知識がない場合は、それに対応できる開発者に明示的に対応を依頼するようにしましょう。そして、彼が確かに答えを返すこと、あるいは少なくとも何らかの返事をすることを確認しましょう。長年プロジェクトにかかわってきた開発者にとってはどうしても閉じた場での議論のほうがやりやすく感じられることでしょう。これまではずっとそうしてきたのですから。そんなことが起こらないように内輪のメーリングリストの動きもチェックし、必要な議論は公開の場で行うように彼らを誘導しましょう。

これまでは閉じた環境にあったプロジェクトをオープンにするにあたっては、これら以外にも長期的な懸案事項があります。 5章カネに関する問題 では、給料をもらって開発に参加している人たちと無償で開発に参加している人たちとをうまく共存させる方法を考えます。また 10章ライセンス、著作権、特許 では、法的な努力の必要性について考えます。他の団体が書いた、あるいは "所有している" コードを含むかもしれないソフトウェアを公開する場合は、それなりの注意が必要となります。

広報

プロジェクトが人に見せられる状態 (完全なものではなく、単にとりあえず見せられるという程度) になったら、それを全世界に向けて公開しましょう。これは、実際には非常に簡単なことです。まず http://freecode.com/ に行ってナビゲーションバーの Submit をクリックし、フォームに内容を入力しさえすれば新しいプロジェクトを宣伝できるのです。 Freecode (以前は Freshmeat.net と呼ばれていましたが、2011 年 10 月に名前が変わりました) は、新しいプロジェクトが気になる数多くの人が見ているところです。あなたのプロジェクトに関するニュースがその中の何人かの目にとまれば、後は口コミでその情報が広まっていくでしょう。

あなたのプロジェクトに関するお知らせを投稿するのに適したメーリングリストやニューズグループがあるのなら、そこに投稿するのもいいでしょう。しかし、投稿するのはそれぞれの場所で一度ずつだけにしておきましょう。その後の議論は、(Reply-to ヘッダを設定して) 自分のプロジェクトの会議室で続ければいいのです。投稿内容は、要点をまとめた短いものにしなければなりません。

To: discuss@lists.example.org
Subject: [ANN] Scanley 全文インデックス化プロジェクト
Reply-to: dev@scanley.org

Scanley プロジェクトが立ち上がったことをお知らせします。
これはオープンソースの全文インデックス作成器およびサーチエンジンで、
豊富な API を持っています。プログラマーは、大きなテキストファイルを
対象とした全文検索機能を自分のプログラムに組み込めるようになります。
Scanley はようやくまともに動くようになった状態のもので、現在も活発に
開発が進められています。開発やテストに参加してくださる方を募集しています。

ホームページ: http://www.scanley.org/

機能:
   - プレーンテキスト、HTML および XML の検索
   - 単語あるいはフレーズによる検索
   - (予定) あいまい検索
   - (予定) インデックスの差分更新
   - (予定) リモートのウェブサイトのインデックス化

Requirements:
   - Python 2.2 以降
   - インデックス作成用のディスク領域
     (元のデータの約２倍の大きさ)

詳細な情報は、scanley.org をご覧ください。

それでは。
-J. Random

(公開のお知らせやプロジェクトのイベントに関するお知らせの詳細については、 6章コミュニケーション の「宣伝・広報」をご覧ください)

フリーソフトウェアの公開を開始する時期について、ある程度動くものができあがった時点で公開すべきなのか、あるいは設計段階から公開してしまうべきなのかについての議論は、まだ結論が出ていません。私は、これまでは「実際に動くコードがあること」が最も重要だと考えていました。それこそが成功するプロジェクトと単なるおもちゃとを区別するものだと思ったからです。そして、具体的に動くものがないと他の開発者をひきつけられないと思っていたのです。

最近、この考えが変わってきました。Subversion プロジェクトを開始したときにあったのは、設計ドキュメントと何人かの気心の知れた開発者、そして大げさなファンファーレだけでした。実際に動くコードは一切なかったのです。驚いたことに、このプロジェクトは開始当初からアクティブな参加者を獲得することに成功しました。そして実際に動くものができはじめたころには、かなり多くのボランティア開発者がコードの内部まで深く知り尽くしているという状態になっていました。 Subversion だけが例外的な存在だというわけではありません。 Mozilla プロジェクトも実際に動くものがない状態から始まりました。そして今や人気のあるウェブブラウザとして大成功を収めています。

これらの事例を前にして、私は「実際に動くコードこそがプロジェクトの立ち上げに必要だ」という主張を曲げざるを得なくなりました。動くコードがあることは成功のひとつの要素ではあります。そして、経験上は、動くものができあがるまではプロジェクトの公開を控えたほうがよいと思います。しかし、とりあえず先に公開してしまったほうがいいこともあります。最低限、しっかりした設計ドキュメントか何らかのコード基盤は必要です —もちろん、これは公開後のフィードバックを受けて改版することになるでしょう。しかし、それだけではなく何か具体的なもの、実際に触って試せるものが必要です。

プロジェクトを公開したからといって、大量のボランティアがすぐにプロジェクトに参加したがるとは思わないでください。普通は、公開した後の反応といえばもっとおとなしいものです。何人かはたいしたことのない問い合わせをくれるでしょう。何人かはメーリングリストに参加してくれるかもしれません。しかし、それ以外の大半の人たちにとっては、そのプロジェクトが公開されたことなんて気にもしていないでしょう。しかし時間がたつにつれて、開発者として参加してくれる人や実際にソフトウェアを利用してくれる人が徐々に増えていくことに気づくでしょう。公開の発表は、種まきのようなものです。そのニュースが広まるには、長い時間がかかります。プロジェクトに参加した人たちが何らかの利益を得ることになると、ニュースがより広まるようになります。自分が見つけたすばらしいものを、周りにも知らせてあげようという気持ちが働くからです。すべてがうまくいけば、そのプロジェクトは指数関数的に大きくなり、複雑なコミュニティーに成長するでしょう。そこまで来れば、もはや個々のメンバーの名前を知っている必要もなくなります。また、メンバー間の会話の内容をすべて追いかけることも不可能となります。次の章では、このような環境を運営する方法を説明します。

^[12] hack と activation を組み合わせた造語？おそらく http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Programming-Overview.html からの引用だと思われます。

^[13] ここまではまだ個人の名前を挙げることはありませんでしたが、これ以降では必要に応じて名前を挙げていきます。ここでいう「嗅ぎ付けた人」とは Brian Behlendorf のことです。彼は、プライバシーの侵害の恐れがない議論はすべて公開の場で行うべきだという一般論を指摘してくれました。

^[14] これは、オープンソースプロジェクトでごく一般的に行われているコードレビューの方法を示したものです。より中央集権的なプロジェクトでは、複数の人が集まってソースコードのプリントアウトを見つめ、特定の問題やパターンを探すことを称して "コードレビュー" という場合もあります。

第3章技術的な問題

プロジェクトに必要なもの

メーリングリスト

スパム対策

投稿のフィルタリング
アーカイブでのメールアドレスの処理

識別しやすいヘッダ

Reply-to はどうすべきか

私のふたつの夢

すべてをバージョン管理する
ウェブで閲覧できるようにする
コミットメール
ブランチの活用
情報の一元管理
承認

バグ追跡システム

議論の場としてメーリングリストを使う
バグ追跡システムをあらかじめフィルタする

IRC / リアルタイムに行なわれるチャットシステム

ボット
IRCの会話を保存する

RSS フィード

Wiki

ウェブサイト

ツールが一通り揃ったホスティングサイト

ホスティングサイトを選ぶ
匿名性とプロジェクト参加

Social Networking Services

フリーソフトウェアプロジェクトを運営していくには、さまざまな情報を取捨選択する技術が必要です。これらの技術を使いこなせばこなすほど、また周りの人に使わせれば使わせるほど、プロジェクトがうまくいく可能性が高くなります。プロジェクトの規模が大きくなればなるほど、この傾向は強まります。うまく情報を管理しないと、オープンソースプロジェクトはブルックスの法則 ^[15] (プロジェクトの終盤になってから人を増やしたところで、かえってプロジェクトの完成が遅れてしまう) の罠に陥ってしまいます。 Fred Brooks は、プロジェクトの複雑度はそれにかかわる関係者の数の２乗に比例するとしています。メンバーの数がほんの数人の時は、簡単にお互いの意思疎通ができます。しかしメンバーが数百人規模に膨れ上がると、もはや他のメンバーが何をしているのかをすべて把握することは不可能です。フリーソフトウェアプロジェクトを管理する秘訣は、お互いがまるでひとつの部屋に集まってともに働いているかのように感じさせることだといいます。では、もし混雑した部屋に詰め込まれたメンバーがみんないっせいに話し始めたら、どんなことになるでしょう?

これは、特に目新しい問題ではありません。たとえ話ではない実際の混雑した部屋では、このような場合の解決法は 議会制、つまり大人数の集団で議論を行う際の手順を決めることです。重要な異議が「異議なし!」の大合唱にかき消されてしまわないようにしたり、いくつかの小委員会を構成したり、議決方法を定義したりといったことです。この制度で重要なのは、その集団が情報管理システムをどのように利用するかというところです。 "正式に記録される" 情報もあれば、そうでないものもあります。記録自体は方向性を決めるためのものです。「何が起こったのか」を単に書き記したものではなく、その集団で何を合意しようとしているのかを表すものと考えます。記録は、目的によってさまざまな形式で行います。個別の打ち合わせの議事録、すべての打ち合わせの議事録をまとめたもの、その概要、議題、コメント、委員会の報告書、その場にいない通信員からの報告、宿題の一覧などが記録に含まれます。

インターネットは実際の部屋とは異なるので、「誰かが発言しているときは他のメンバーは静かにそれを聴く」というようなしきたりにこだわる必要はありません。情報管理技術を駆使すると、オープンソースプロジェクトにおける議論の手順はより効率的になります。オープンソースプロジェクトでは、ほぼすべてのやりとりは文字によって行われます。そこで、情報を振り分けたり適切なラベル付けをしたりするためのシステムが発達してきました。繰り返しを最小限に抑えて間違った方向に進みにくいようにしたり、データを保存して検索しやすくしたり、間違った情報や古びた情報を訂正したり、あちこちに散らばった情報をまとめてそれらのつながりを見出したりといった作業のためのシステムです。オープンソースプロジェクトに積極的にかかわっている人たちは、これらのテクニックを自然に身に着けており、情報が正しくいきわたるように複雑な手作業を行っていることもあります。しかし、プロジェクト全体で考えると、これらの作業にはソフトウェアのサポートが必要です。可能な限り、通信に使用するメディア自身が振り分けやラベル付け、内容の保存といった作業を行うべきです。そして、その情報は、人間が見やすい形式で利用可能にしておかなければなりません。もちろん、現実的にはまだそこまで全自動化されているわけではなく、途中で何らかの人手が必要となるでしょう。しかし一般論として、人間側で振り分けやラベル付けのための情報を一度提供したら、あとはソフトウェア側でそのめたデータを最大限に活用できるようにすべきです。

本章でのアドバイスは、実用的なものばかりです。どれも特定のソフトウェアやその使用例にもとづいたものです。とはいえ、単に特定のテクニックを教えるだけというつもりはありません。ちょっとした例をたくさんご覧いただくことで、あなたのプロジェクトにおける情報管理をよりよくするための一般的な方法を身につけていただくつもりです。これには、技術的なスキルだけでなく社会的なスキルも含まれます。技術的なスキルは必要不可欠です。というのも、情報管理用のソフトウェアは常に何らかの設定が必要となるからです。また、運用中にもある程度の保守作業が必要です (たとえば、大きく成長したプロジェクトをどのように扱うかについて、本章の後半の「バグ追跡システムをあらかじめフィルタする」で取り上げています)。また、社会的なスキルも必須です。なぜなら、人間の集まりについても維持する必要があるからです。さまざまなツールを使用して利益を受ける方法は、すぐに明らかになるとは限りません。場合によってはその使用法をめぐって争いが起こるかもしれません (例として、メーリングリストから配送されるメールの Reply-to ヘッダの設定についての議論を「メーリングリスト」で取り上げています)。プロジェクトに参加している人たちはみな、そのプロジェクトの情報をうまく管理するための方法を必要としています。プロジェクトに深くかかわればかかわるほど、学ばねばならないテクニックは複雑で専門的なものになります。

情報管理には、月並みな解決策はありません。考慮すべき点があまりにも多すぎるのです。最終的に望みどおりの手段が見つかるかもしれません。コミュニティーの参加者のほとんどもその方法を利用してくれるかもしれません。しかし、プロジェクトがさらに成長したときに、その方法がそのまま使えるとは限りません。あるいは、プロジェクトの成長が安定し、開発者とユーザーの両方が現在の情報管理技術に慣れてきたときに、だれかがまったく新しい情報管理サービスを発明するかもしれません。新しくプロジェクトに参加したメンバーはきっとこう言うでしょう。「何であの便利なツールを使わないの?」 Wiki (http://ja.wikipedia.org/wiki/Wiki を参照してください) が登場しだした頃に、当時のプロジェクトの多くでまさにこれと同じことが起こりました。どのような手段を使用するかを決めるには、さまざまな判断材料があります。たとえば、情報を提供する側と情報を利用する側のどちらの利便性を優先させるかも判断材料のひとつとなるでしょう。あるいは、情報管理ソフトウェアの設定の難易度と、それがプロジェクトにもたらす利益とのトレードオフについても考える必要があります。

あまりになんでもかんでも自動化しすぎないようにしましょう。実際、人手がかかわるべきところまで自動化してしまってはいけません。技術的な仕組みは重要ではありますが、フリーソフトウェアプロジェクトをうまく運営するために重要なのは、結局のところ人への気配り—決しておしつけがましくない気配りなのです。技術的な仕組みというのは、この気配りをうまく行うための手段に過ぎません。

プロジェクトに必要なもの

ほとんどのオープンソースプロジェクトは、情報管理用のツールとして少なくとも以下のようなものを用意しています。

ウェブサイト: プロジェクトについての情報を、管理者側から一般に向けて公開する場所です。また、プロジェクトで使用するその他のツールについての管理用インターフェイスもここで提供します。
メーリングリスト: 通常は、そのプロジェクトにおける最も活発な議論の場となります。また、議論の「記録媒体」としての意味合いもあります。
バージョン管理システム: 開発者が、コードの変更点を追いかけやすくするものです。変更内容を元に戻したり、他に移植したりすることもできます。これを見ると、コードに何が起こっているのかを誰もが知ることができます。
バグ追跡システム: 開発者が自分の作業内容を確認したり、他の開発者と作業を調整したり、リリース時期の予定をたてたりするために用います。特定のバグの状況や関連情報 (再現手順など) について、誰もが調べられるようになります。バグだけに限らず、やるべき作業やリリース時期、新機能の追加などについてもここで扱うことがあります。
リアルタイムチャット: ちょっとした議論や質問のやり取りのための場です。議論の内容がアーカイブされないこともあります。

ここであげたツールはどれも異なるニーズを満たすものではありますが、その機能には相関性があります。また、各種ツール群は協調して動作させなければなりません。これ以降では、その方法について考えます。また、より重要なこととして、メンバーにそれを使ってもらうためにはどうすればいいのかも説明します。ウェブサイトについての議論は後回しにします。というのもウェブサイトは、独立したツールというよりは他のツールを組み合わせるための接着剤のようなものだからです。

どんなツールを選択しようかといった問題に悩まされたくないという場合は、出来合いの ホスティング サイトを使用するといいでしょう。たいていはパッケージ化されたウェブサイトのテンプレートが用意されており、フリーソフトウェアプロジェクトの運営に必要なツールもひととおりそろっているはずです。本章の後半の「ツールが一通り揃ったホスティングサイト」で、ホスティングサイトの利点と欠点を取り上げます。

メーリングリスト

メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです。ウェブページ以外にユーザーに見せるものがあるとすれば、まず最初はそのプロジェクトのメーリングリストとなるでしょう。しかし、メーリングリストに参加する前に、ユーザーはまずそのメーリングリストのインターフェイス (たとえば "メーリングリストに参加する" など) に出会うことになります。ここから、次の「メーリングリスト第一法則」が得られます。

メーリングリストの管理は、手作業で行うのではなく、専用のソフトウェアを使用すること。

いきなりそんなことを言われても驚きますよね。メーリングリストの管理用にわざわざソフトウェアをセットアップするなんて、ちょっとやりすぎのように感じられるかもしれません。小規模で流量の少ないメーリングリストは手動で管理するほうが楽に見えます。参加申し込み用のアドレスをひとつ作成してそれをあなた宛てに転送されるようにしておき、届いたメールの内容を見て、アドレス一覧 (おそらく単なるテキストファイル) に追加したり削除したりするだけです。これ以上にシンプルなやりかたなんてないでしょう?

みんなが満足するレベルでメーリングリストの管理を行うということは、思っているほど簡単なことではありません。メーリングリストの管理というのは、単にユーザーを登録したり削除したりするだけの話ではありません。スパムよけのために投稿内容をモデレートするようにしたり、複数の投稿をひとまとめにした形式でメールを配信するようにしたり、メーリングリストやプロジェクトに関する情報を自動返信するようにしたりといったさまざまな内容があります。参加用のアドレスを人手でチェックするというだけでは、最小限の機能しか提供することができません。そしてその最小限の機能でさえ、ソフトウェアに任せるのに比べると信頼性や即時性に欠けるものとなるでしょう。

いまどきのメーリングリスト管理用ソフトウェアなら、少なくとも次のような機能が搭載されているはずです。

メールおよびウェブの両方からの参加受付: ユーザーがメーリングリストへの参加を申し込むと、 すぐに自動返信のメッセージを受け取ります。そこには、参加しようとしているメーリングリストの情報やメーリングリストソフトウェアへの指示の出し方、そして (最も重要な項目として) リストからの退会のしかたなどが書かれています。この自動返信の内容はカスタマイズすることが可能です。ここにはプロジェクトのウェブサイトや FAQ の場所といった情報を含めることができます。
一通ごとの配信かまとめての配信かの選択: ダイジェストモード (「まとめて配信」モード) にすると、参加者が受け取るメールは１日に１通となります。その日に投稿されたすべてのメールの内容が１通にまとめて送信されるわけです。積極的に参加するわけではないが、大まかな話の流れは追いかけておきたいといった人たちにはダイジェストモードがお勧めです。これを使用すると、頻繁にやってくるメールに気を散らされることなくその日のメールの内容をゆっくり見渡せるからです。
モデレート機能: 「モデレート」とは、投稿の内容をいったんチェックし、 a) スパムでないこと、そして b) メーリングリストで扱うのにふさわしい内容であることを確認してから一般向けに配信する作業のことです。モデレート処理は、必ずしも人間が行わなければならないというものではありません。ソフトウェアに任せることで、より簡単に行えるようになります。モデレートについては、後でもういちど取り上げます。
管理者用インターフェイス: これは特に、使われなくなったアドレスを簡単に削除するために有用です。メーリングリストの参加者のアドレスから「このアドレスはもう存在しません」といった自動返信メッセージが毎回届くようになったら、即刻対応しなければなりません (メーリングリストソフトウェアによっては、これを自動検出して該当者を自動的にメンバーから外すようにできるものもあります)。
ヘッダの操作: 多くの人は、メールソフトの仕分け機能などを活用していることでしょう。メーリングリストソフトウェアを使用すると、特定のヘッダをメールに付加することでこれらの機能を使いやすいようにします (詳細は後で説明します)。
アーカイブ処理: メーリングリストへのすべての投稿は、保存されたうえでウェブから閲覧可能になります。あるいは、メーリングリストソフトウェアによっては MHonArc (http://www.mhonarc.org/) のような外部のアーカイブツールへのプラグインインターフェイスを持っているものもあります。 6章コミュニケーション の「アーカイブを目に付きやすくする方法」で説明するように、アーカイブは重要な作業です。

このようにひとつひとつ挙げてみると、メーリングリストの管理というものが思いのほか複雑な作業であることがお分かりでしょう。そして、それらの作業の多くがソフトウェアで自動化できることもわかります。決してこれらのソフトウェアのエキスパートになる必要はありません。しかし、まだまだ常に学ぶ余地があるということ、そしてフリーソフトウェアプロジェクトを運営するにあたってメーリングリストの管理作業は避けて通れないものであることは心においておきましょう。これ以降では、メーリングリストの設定に関するよくある問題についてみていきます。

スパム対策

今、この文章を書いている時点と実際に本書が出版された時点を比べても、スパムに関する問題の深刻度は倍増していることでしょう。少なくとも、そう感じるくらいのレベルにはなっているはずです。つい最近までは、スパム対策をまったく行わなくてもメーリングリストを普通に運営できていました。ごくまれに変な投稿が行われることもありましたが、気になるほどのものではなかったのです。しかし、そんな時代はとっくに終わってしまいました。現在では、スパム対策をまったくしていないメーリングリストはあっという間にゴミメールの山となってしまいます。そんなメーリングリストは使い物にならないでしょう。スパムは決して野放しにしてはいけません。

本書では、スパム対策を２種類に分けて考えます。ひとつはメーリングリストにスパムが配信されないようにすること。もうひとつは、メーリングリストの参加者のメールアドレスをスパム業者に収集されないようにすることです。前者の方がより大事なので、まずはそちらから考えていきましょう。

投稿のフィルタリング

スパム投稿を防ぐ基本的な方法は、次の３つです。ほとんどのメーリングリストソフトウェアは、これらの機能をすべて提供しています。また、これらの方法は、どれかひとつだけを使うのではなく組み合わせて使うと有効です。

メーリングリストのメンバーからの投稿のみを自動配信する
これはある程度は有効で、管理者にはほとんど負担がかかりません。というのも、これを行うには単にメーリングリストソフトウェアの設定を変更するだけだからです。しかし、自動承認されなかった投稿を単に捨ててしまってはいけません。そうではなく、自動承認されなかった投稿は管理者がいったんチェックするようにしましょう。そうする理由は次の２つです。まず第一に、メーリングリストのメンバー以外からの投稿も受け付けたいからです。ちょっとした質問や提案がある人が、いちいちメーリングリストに参加しなければメールを投稿できないというのは不便です。もうひとつ、メーリングリストのメンバーであっても、登録しているアドレス以外のメールアドレスから投稿することがあるかもしれません。メールアドレスは、人を識別する手段としてはあまり信頼できるものではありません。メールアドレスにあまり頼りすぎないようにしましょう。
投稿を、いったんスパムフィルタリングソフトウェアにかける
メーリングリストソフトウェアが対応していれば (ほとんどは対応しています)、投稿内容をスパムフィルタリングソフトウェアに渡すことができます。自動スパムフィルタリングは完璧なものではありません。また、今後も決して完璧なものにはならないでしょう。スパムの送信者とフィルタの作者との戦いは永遠に続くのです。しかし、フィルタリングソフトを使用することで、管理者が手作業で処理すべきスパムを激減させることができます。人手で処理すべき内容が多くなればなるほど、自動フィルタリングは有用です。
ここでは、スパムフィルタの設定方法については説明しません。ご利用のメーリングリストソフトウェアのドキュメントを参照してください (本章の後半の「ソフトウェア」で詳しく説明します)。メーリングリストソフトウェアにはたいてい、自前のスパム対策機能が組み込まれています。しかし、サードパーティのフィルタを使いたいこともあるでしょう。私がよく利用しているのは、SpamAssassin (http://spamassassin.apache.org/) と SpamProbe (http://spamprobe.sourceforge.net/) です。もちろんこれら以外にもオープンソースのスパムフィルタはたくさんありますし、その中にはすばらしいものもあるでしょう。私はたまたまこの２つで満足しているので、他のものをあまり調べていないというだけのことです。
モデレートする
登録されているメールアドレスからの投稿ではないので自動配信はされませんでした。また、スパムフィルタを通した結果、スパムではないと判断されました。そのような投稿に対する最後の手段は モデレート です。メールの内容が特別なアドレスに送られ、人間がその内容をチェックしたうえで承認するか却下するかを決めるのです。
投稿を承認する場合は、「その投稿だけを承認する」あるいは「その投稿を承認し、今後同じアドレスからの投稿があった場合は自動的に配信する」のいずれかの方式となります。ほとんどの場合は後者の方式をとることになるでしょう。そうすれば、将来のモデレートの負荷を下げることができます。投稿の承認方法は、システムによってことなります。よくある方式は、特別なアドレスに対してコマンドを返信することです。たとえば "accept" (この投稿だけを承認する) あるいは "allow" (この投稿および今後のすべての投稿を承認する) などのようになります。
却下する場合は、通常は単に何もせずにモデレートメールを無視します。メーリングリストソフトウェアは、その投稿を承認するという確認を受け取らない限り投稿を配信することはありません。つまり、単にモデレートメールを無視しておけばそれで用が満たされるのです。あるいは、"reject" や "deny" といったコマンドを明示的に返信することもあります。そうすると、同じアドレスから今後投稿があった場合にモデレート処理の前に自動的に却下してくれるようになります。しかし、そんなことをしてもあまり意味はないでしょう。モデレートの主要な目的はスパムの防止であり、スパマーが同じアドレスからメールを何度も送るなんてありえないでしょうから。

モデレートを乱用しすぎないようにしましょう。スパムを防ぐことと、まったく的外れな投稿 (投稿するメーリングリストを間違えたなど) を防ぐことだけに限るべきです。モデレートシステムを使用すると、投稿者にだけ直接返信を返すことができますが、それを使ってメーリングリストに関する質問に答えてはいけません。たとえ即答できるようなものであったとしてもです。そんなことをすると、どんな質問があったのかがコミュニティーに伝わりません。また、その質問に対してより適切に答えられる人がコミュニティーにいたとしても、答えるチャンスがなくなってしまいます。他の人が答えた内容も見ることができません。メーリングリストのモデレートは、ゴミメールや場違いなメールばかりにすることを防ぐためのものでしかありません。それ以上の何者でもありません。

アーカイブでのメールアドレスの処理

メーリングリスト参加者のアドレスをスパマーに抜き取られないようにするには、アーカイブする際にメールアドレスをぼかすのが一般的です。たとえば、

jrandom@somedomain.com

のようなアドレスを

jrandom_AT_somedomain.com

あるいは

jrandomNOSPAM@somedomain.com

あるいはそれと同様な (人間には理解できるような) 形式に変換します。ありがちなメールアドレス収集ソフトは、メーリングリストのアーカイブのウェブページを読み込んで "@" を含む文字列を探します。したがって、アドレスをこのように変換しておけば収集ソフト用の対策になります。これは、メーリングリストに直接送られてくるようなスパムには無意味です。そうではなく、リストの参加者のアドレスに直接スパムが送られるのを防ぐための仕組みです。

このようにアドレスを隠すことには賛否両論があります。この機能を気に入っている人は、アーカイブではそうするのが当然だと思っており、もしそうなっていなければ非常に驚きます。しかし、中にはちょっとそれはやりすぎだと考える人もいます。いくら人間にとっては理解できる形式であるとはいえ、いったん頭の中で変換しないと正しいアドレスがわからないからです。また、まったく無意味だという人もいます。いくらしっかりした符号化を行ったとしても、アドレス収集ソフトはそれを理論上は理解できるはずだからです。しかし、アドレスの変換が有用であるということは実証されています。 http://www.cdt.org/speech/spam/030319spamreport.shtml を参照してください。

理想を言えば、このような処理は個々の好みで切り替えられるようにしておくべきでしょう。つまり、メーリングリストの参加者の個人設定ページで「自分のメールアドレスを符号化する/しない」を切り替えられるようにしておけばいいのです。しかし、そのように投稿者ごとや投稿ごとに設定を切り替えられるソフトウェアを見たことはありません。現状では、メーリングリストの管理者が全員の設定を一括で決めなければならないのです (アーカイブツールがメールアドレスの変換処理に対応していることを前提としていますが、中にはその機能がないものもあります)。私は、個人的にはどちらかというと変換処理を行うほうが好きです。自分のメールアドレスをウェブページなどに表記する際に、アドレス収集用ソフト対策に非常に気を使っている人たちもいます。そのような人たちの努力がメーリングリストのアーカイブによって台無しになってしまうと、きっと非常に悲しむことでしょう。一方、アドレスが変換されていることによってアーカイブの利用者に多少不便を感じさせたとしても、そんなにたいしたものではないでしょう。しょせん、必要なたった一人のアドレスを正しい形式に戻すだけのことなのですから。ところで、メールアドレスの変換作業もまた、終わりのない戦いであることを覚えておきましょう。あなたがこれを読んでいる今まさにこの間にも、アドレス収集ソフトウェアは進化し続けています。ありがちなアドレス変換方法はすでに破られており、私たちはまた別の方法を考えなければならないのです。

識別しやすいヘッダ

メーリングリストの参加者の中には、メーリングリストに投稿されたメールを別のフォルダにわけて管理したいと考える人もいることでしょう。メールソフトの多くは、ヘッダ の内容によって自動的にメールを仕分ける機能を持っています。ヘッダとはメールの先頭にあるフィールドのことで、送信者や受信者、件名、日付、その他メッセージに関するさまざまな情報を保持しています。以下にあげるヘッダはよく知られているものであり、事実上必須であるといえます。

From: ...
To: ...
Subject: ...
Date: ...

その他にも標準的なヘッダはありますが、これらは省略してもかまいません。たとえば、

Reply-to: sender@email.address.here

ヘッダは省略することもできます。しかし大半のメッセージにはこのヘッダがついています。なぜなら、これを使用すると送信元のアドレスを確実に知ることができるからです (ふだんメールを受け取っているアドレス以外からメールを送信する場合などに特に便利です)。

メールソフトの中には、Subject ヘッダの内容をもとにした簡単な仕分け機能を持っているものもあります。このようなソフトを使っている人たちからは、メールの件名の先頭に自動的にプレフィックスをつけてほしいという要望があるかもしれません。それを利用すれば、簡単に仕分けを行えるからです。どういうことかというと、次のような件名のメール

Subject: Making the 2.5 release.

が投稿されたときに、実際にメーリングリストに配信されるメールは次のようになるということです。

Subject: [discuss@lists.example.org] Making the 2.5 release.

多くのメーリングリスト管理用ソフトウェアにはこの機能がついていますが、このオプションは使わないことをお勧めします。このオプションによって解決できるであろう問題は、もっと控えめな方法で解決することができるものです。一方、件名欄が無意味に長くなってしまうという点は無視できません。メーリングリストに慣れたユーザーは、まずその日にやってきたメールの件名をざっと眺め、どれを読んでどれに返信するのかを判断するのです。件名の先頭にメーリングリストの名前をつけてしまうと、件名の後半が画面からはみ出てしまい、見えなくなってしまいます。どのメールを処理するのかを決めるための情報が少なくなってしまうわけで、結果としてメーリングリストの使い勝手が悪くなってしまいます。

Subject ヘッダに手を加えるのではなく、もっと別の方法で仕分けをする方法を教えてあげるようにしましょう。たとえば To ヘッダなどがお勧めです。これはメーリングリスト名そのものとなっています。

To: <discuss@lists.example.org>

Subject による仕分けができるメールソフトなら、まず間違いなく To による仕分けもできるはずです。

これ以外にも必須ではないけれどメーリングリストではよく使われているヘッダがいくつかあります。これらのヘッダをもとにして仕分けをしたほうが、"To" や "Cc" に頼るよりも確実です。以下のようなヘッダはメーリングリスト管理ソフトウェアが直接追加するので、これを使用した仕分けをしている人もいることでしょう。

list-help: <mailto:discuss-help@lists.example.org>
list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>
list-post: <mailto:discuss@lists.example.org>
Delivered-To: mailing list discuss@lists.example.org
Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

これらのヘッダは、それぞれ文字通りの意味を持っています。詳しくは http://www.nisto.com/listspec/list-manager-intro.html をご覧ください。あるいはもっと詳しい厳密な仕様が知りたいのなら、 http://www.faqs.org/rfcs/rfc2369.html を見るといいでしょう。

これらのヘッダを見ると、"list" というメーリングリストの管理用アドレスとして "list-help" と "list-unsubscribe" があることが何となくわかるでしょう。これらに加えて、通常は参加用のアドレスとして "list-subscribe"、管理者への連絡用アドレスとして "list-owner" があるようです。使用するソフトウェアによっては、これら以外にもさまざまな管理用アドレスが設定されるかもしれません。詳細はドキュメントを参照してください。通常、これらの特別なアドレスの一覧は、メーリングリストへの参加時に自動送信される「ようこそ」メールにまとめられています。あなた自身もこのメールの内容を見ることができるでしょうが、もし見られないようなら、メーリングリストのメンバーの誰かに見せてもらってください。この「ようこそ」メールの内容は、常に手元においておきましょう。メーリングリストの使い方に関する問い合わせに答えたり、ウェブページに情報をのせたりする際に役立ちます。メーリングリストのメンバーから「退会するにはどうしたらいいのですか?」という質問を受けたら、そのウェブページの URL を教えてあげればいいのです。

中には、すべての投稿の末尾に退会用の手順を載せられるようになっているソフトウェアもあります。もしそのようなオプションがあるのなら、有効にしておきましょう。これは、メッセージの目立たない場所にほんの数行の内容を追加するだけです。たったそれだけで、あなたの手間は激減するでしょう。「退会方法を教えて!」というメールがあなた宛てに (もっとひどいことには、メーリングリスト宛てに!) 届くことも減ります。

Reply-to はどうすべきか

先ほど「個人的な議論を避ける」で、議論は公開の場で行うということの重要性を強調しました。できるだけそのように心がけておかないと、議論はどんどん個人的なメールのやりとりに収束してしまいます。また、本章で扱っている内容は、ソフトウェアを用いていかにプロジェクト内のコミュニケーションを円滑にするかということです。もし議論をメーリングリスト上で続けされるような機能がメーリングリスト管理ソフトウェアに搭載されているのなら、それを使用しない手はありません。

……とは一概に言い切れないのです。実際そのような機能はあるのですが、無視できない問題点もいくつかあります。この機能を有効にするかどうかについては、メーリングリスト管理に関する議論の中でも最も白熱するものです。７時のニュースで取り上げられるような内容ではありませんが、フリーソフトウェアプロジェクトにおいては何度となく議論されてきました。ここでは、まずその機能について説明し、双方の立場の主張を並べたうえで、個人的にお勧めの方式を示します。

機能そのものは非常にシンプルです。メーリングリストへのすべての投稿に対して自動で Reply-to ヘッダを設定し、返信先をメーリングリストのアドレスにするというものです。もとの送信者がどんな Reply-to ヘッダをつけていたとしても (あるいはつけていなかったとしても)、メーリングリストの参加者に配信されるときには Reply-to がメーリングリストのアドレスに変わっています。

Reply-to: discuss@lists.example.org

一見これはよさげな機能に見えるかもしれません。たいていのメールソフトは Reply-to ヘッダの内容を考慮するので、投稿に対して返信しようとすると、自動的にメーリングリスト宛てに送信するようになります。もちろん返信する人の意思で宛先を変更することはできますが、 デフォルトで メーリングリスト宛てになるということが大事なのです。テクノロジーの力で協調作業をやりやすくする。まさに完璧な例じゃないですか。

ところが残念なことに、この方法にはいくつか欠点があるのです。欠点としてまず最初にあげられるのが、いわゆる Can't Find My Way Back Home (おうちに帰れない) 問題です。何らかの理由で普段とは異なるアドレスからメールを送信する際など、「本当の」アドレスを Reply-to フィールドに指定しておくこともあります。常に同じ場所でメールの読み書きを行うのなら、この問題は起こりません。もしかしたら、そんな問題があることにすら気づいていないかもしれません。しかし、普段とは異なる設定でメールを送信する人やメールの From アドレスを変更できない状況 (職場から送信しており、IT 部門に対する権限がない状況) の人にとっては、返信を自分で受け取るための唯一の手段が Reply-to となるわけです。そのような人たちにとって、メーリングリストに参加しているのとは別のアドレスで投稿する際には Reply-to 設定は必要不可欠な情報となります。メーリングリストソフトウェアがそれを上書きしてしまうと、その人は自分の投稿に対する返信を見ることができなくなってしまいます。

もうひとつの問題は、期待に反する動作をしてしまうということです。個人的には、Reply-to の変更に反対する人が最も強く主張しているのがこの問題だと思います。メールの処理に慣れている人は、reply-to-all (全員に返信) と reply-to-author (送信者に対して返信) の２通りの返信方法を使い分けています。最近のメールソフトは、これらの操作に対してそれぞれ別のショートカットキーを割り当てています。全員 (メーリングリストも含む) に返信したい場合は「全員に返信」を、そして送信者に対して個人的に返信したい場合は単なる「返信」を使えばいいということを知っているのです。あなたとしては返信は可能な限りメーリングリストに送信してほしいでしょうが、返信するほうには個人的に返信する権利があります。たとえば、元のメッセージに対して何か機密情報を含む内容を返信したい場合などは、それが公開のメーリングリストに流れてしまってはまずいでしょう。

さて、メーリングリスト側で送信者の Reply-to 設定を書き換えてしまったらどうなるのかを考えてみましょう。そのメールに対して「送信者に返信」のキーを押したとしたら、当然その人はそのメールが送信者に対してのみ届くものと期待することでしょう。ごく当たり前のことなので、いちいちあて先を確認することもないかもしれません。返信メールの中で個人的な内緒のメッセージ (もしかしたら他のメンバーの悪口かも……) を書き、送信ボタンを押します。予想に反して、数分後には彼の書いた返信が メーリングリストに流れることになるでしょう! ええ、もちろん送信前にあて先をしっかり確認しなかった彼が悪いのです…… 理屈上は。でも、普通は Reply-to は送信者のアドレスに設定されているもの (メールソフトがそう設定しているはず) なので、長年メールを使っている人ほどそう信じ込んでしまう傾向があります。実際、もし意図的に他のアドレス (たとえばメーリングリストなど) を Reply-to に設定した場合は、通常はそれをメッセージの中で明記するものです。

この予期せぬ振る舞いの影響は無視できないため、個人的にはソフトウェア側での Reply-to ヘッダの変更は行わないことをお勧めします。確かにこの機能は共同作業の際には便利でしょうが、私にとってはその副作用の影響のほうが重大に感じます。しかし、もう一方の立場の人たちにもそれなりの言い分があります。どちらを選択したとしても、「どうして○○にしなかったの?」という質問がたびたびメーリングリストに投稿されることになるでしょう。これはきっと、そのメーリングリストで本来扱いたいと思っているテーマとは異なるはずです。そんな場合用に、この問題に関する議論をうまくしずめるようなお決まりの返答を用意しておくといいでしょう。ここで大切なのは、あなたがどちらの設定を選んだとしても、決して それが唯一の正解なんだと主張しないようにすることです (たとえ内心ではそう思っていたとしても)。そうではなく、次のように説明するようにしましょう。「この問題については昔から議論が繰り返されています。どちらの立場の主張にもそれなりの言い分があり、みんなが納得するようにすることは困難です。だから、私は自分がよりよいと思う設定にしたのです。」そして、(まったくの新入りさんが質問してくる場合は別として) もうこの話題はメーリングリスト上で話すのはやめるよう丁寧にお願いし、あとはそのスレッドを放置しておきます。そうすれば、そのスレッドの議論は自然に収まるでしょう。

もしかしたら、誰かが「どっちがいいか投票で決めよう」なんて言い出すかもしれません。あなたさえかまわなければそれでもいいのですが、個人的には、この問題は多数決で決めるような類のものではないと思います。予期せぬ挙動のせいで受ける被害 (個人的なメールを間違ってメーリングリストに送ってしまう) は甚大ですが、 Reply-to を書き換えないことで参加者が受ける不利益はたかが知れています (たまに間違って個人宛に返信してしまった人に対して、メーリングリストに返信するよう伝えるくらいです)。個人的なメールをメーリングリストに送ってしまうような人はほんの一握りかもしれません。でも、たとえそうであっても彼らにそのようなリスクを負わせることが許されるでしょうか?

この問題に関するすべての議論を取り上げることはしません。ここでは、最も重要だと思われるものだけを示しておきます。詳細な議論の内容は、以下の文書でご確認ください。どちらも、この問題が持ち上がるたびに多くの人が引用するものです。

Reply-to はそのままにしておくべきだという主張, by Chip Rosenthal
http://www.unicom.com/pw/reply-to-harmful.html (日本語)
Reply-to をメーリングリスト宛に変更すべきだという主張, by Simon Hill
http://www.metasystema.net/essays/reply-to.mhtml (日本語)

先ほど私の個人的な好みを軽く述べましたが、決してそれが "正解" だと確信しているわけではありません。実際、私は Reply-to を 書き換えている メーリングリストにも多数参加しています。大事なことは、どちらにするのかを早めに決めておくこと。そして、後々この件についての議論に巻き込まれないようにすることです。

私のふたつの夢

いつの日か、どこかの誰かが reply-to-list 機能をメールソフトに組み込んでくれるかもしれません。これを使用すると、先ほど説明したメーリングリスト独特のヘッダの内容をうまく読み取り、メーリングリスト宛てに適切に返信してくれるのです。それ以外の相手にはメールは送られません。だってその人たちほほとんどはメーリングリストにも加入しているんですから。結局のところ、メールソフト側でこのような機能を実装してしまえば、こんな議論をせずにすむようになるわけです (実際、Mutt というメールソフトはこの機能を持っています ^[16] )。

よりよい対応法は、Reply-to を変更するかしないかを各メンバーが個別に設定できるようにすることでしょう。メーリングリスト宛ての投稿は (自分の投稿も他人の投稿も含めて) Reply-to をメーリングリストのアドレスにしてほしいという人はそのオプションを指定し、 Reply-to をそのままにしておいてほしい人はそのように指定します。残念ながら現時点では、これを各参加者ごとに設定できるメーリングリスト管理ソフトは存在しないようです。現状は、全員共通の設定で我慢するしかありません。 ^[17]

アーカイブ

メーリングリストのアーカイブを設定する技術的な方法は、使用するメーリングリスト管理ソフトによって異なるので、本書では詳しくは取り上げません。アーカイブツールを選択したり設定したりする際には、以下のような点に注意しましょう。

迅速な更新

少なくとも、実際に投稿があってから１時間後くらいにはその投稿がアーカイブされていてほしいものです。可能なら、実際に投稿があった瞬間にアーカイブ処理も同時に行なうべきです。そうすれば、その投稿がメンバーに配信されたときには既にアーカイブにも同じ内容が存在するということになります。それが無理だとしても、少なくとも１時間おきくらいの頻度でアーカイブの更新を行ないましょう (アーカイブソフトによっては、デフォルトでは１日に１回しかアーカイブを行なわないものもあります。しかし、メーリングリストのアーカイブ処理としては、事実上これでは使い物にならないでしょう)。

参照の永続性

メッセージがいったんある URL にアーカイブされたら、その後ずっと同じ URL でそのアーカイブにアクセスできるようにすべきです。アーカイブを再構築したりバックアップから復旧したり、あるいはその他何らかの修正を加えたときにも、いったん公開した URL はそのまま変わらないことが望ましいでしょう。同じ URL を保つようにしておけば、サーチエンジンに捕捉されやすくなります。これは、利用者にとって大きな利点となるでしょう。 URL を保ち続けるよう心がけるもうひとつの理由としては、メーリングリストの投稿やスレッドがバグ追跡システム (本章の後半の「バグ追跡システム」を参照してください) や他のプロジェクトのドキュメントからリンクされることが多いということもあります。

理想を言えば、メールをメンバーに配信する際に、そのメッセージがアーカイブされている URL をヘッダに含められるようになっていればなおよいでしょう。そうすれば、そのメールを受け取った人はわざわざアーカイブサイトを訪れなくてもそのメッセージがアーカイブされている場所を知ることができます。ブラウザを開いて何らかの操作をするというのは時間のかかる作業なので、それが省けるだけでも非常に便利です。このような機能を持つメーリングリスト管理ソフトウェアがあるかどうかは、私は知りません。残念ながら、私が今使っているソフトウェアにはそのような機能はないようです。しかし、どこかにそんなソフトウェアがあるのではと期待しています (もしあなたが新たにメーリングリスト管理ソフトウェアを開発するのなら、ぜひこの機能を実装してください。お願いします)。

バックアップ

当然、アーカイブのバックアップとバックアップからの復旧の方法は簡単なほうがよいでしょう。いいかえれば、アーカイブソフトがブラックボックス化してしまってはいけないということです。あなた (もしくはプロジェクト内の誰か) はメッセージが実際にどのように保存されているかを知っている必要があり、また、必要になったときにはそこからアーカイブを復元できるようにしておかなければなりません。プロジェクトにとって、アーカイブの内容は宝物です。万一アーカイブを失ってしまうことがあれば、貴重な記録を失ってしまうことになります。

スレッドのサポート

個々のメッセージから、そのメッセージが属する スレッド (関連するメッセージのまとまり) へ移動できるようにしておく必要があります。また、各メッセージ個別の URL とは別に、スレッドを表す URL もあるとよいでしょう。

検索機能

メッセージの本文や送信者、件名などによる検索機能をサポートしていないアーカイブソフトなんて、使い物にならないといっていいでしょう。アーカイブソフトの中には、単に Google などの外部のサーチエンジンに処理をまかせているだけのものもあります。機能がないよりはましですが、検索機能を自前で実装しているほうがよりきめ細やかな処理ができます。たとえば、タイトルだけを対象に検索したり、本文も含めて検索したりといったこともできるでしょう。

上にあげたのは、アーカイブソフトを選択する際に注意する点として技術的な面にしぼった一覧です。実際にみんなにアーカイブソフトを利用してもらうことにどのような利点があるのかについては、「アーカイブを目に付きやすくする方法」でとりあげます。

ソフトウェア

メーリングリストの管理やアーカイブの作成用に、さまざまなツールがオープンソースで公開されています。あなたのプロジェクトを公開しているサイトで何かのツールが用意されているのなら、それを使えばいいでしょう。しかし、もし自分で新たにインストールする必要があるのなら、いくつかの選択肢があります。私が実際に使用したことがあるのは Mailman、Ezmlm、MHonArc、そして Hypermail です。しかし、それ以外のソフトウェアが劣っているというわけではありません (また、当然のことですが、私が知っているソフトウェアだけがすべてではありません。それ以外にもさまざまなものがあるはずなので、これを完全なリストとはとらえないでください)。

メーリングリスト管理ソフトウェア

Mailman — http://www.list.org/
(Pipermail というアーカイバが組み込まれていますが、プラグイン形式で外部のアーカイバを使用することもできます。 Mailman は標準の座を長年維持しています。その管理インターフェイス、特にスパムのモデレーションや購読のモデレーションに関してはさすがに時代を感じさせ、よりモダンなインターフェイスに慣れた人にとってはもどかしさを感じることがあるかもしれません)
GroupServer — http://www.groupserver.org/
(アーカイバが組み込まれており、ウェブベースのインターフェイスも統合されています。 GroupServer は Mailman に比べて少し導入が難しく、 2012 年はじめの時点では前提条件もかなり厳しいものです。しかし、ひとたび動き出せば、より使いやすさを実感できるでしょう)
Sympa — http://www.sympa.org/
(開発と保守はフランスの大学のコンソーシアムが担当しており、 700000 人を超える大規模なメーリングリストを扱えるように設計されています。また、メーリングリストの数が多くなっても対応できます。依存するツールはさまざまなものが選べ、たとえば sendmail や postfix、qmail、そして exim などをメッセージ配送エージェントとして利用できます。ウェブベースのアーカイブ機能が組み込まれています)
SmartList — http://www.procmail.org/
(メール処理システム Procmail と組み合わせて使用するためのものです)
Ecartis — http://www.ecartis.org/
ListProc — http://listproc.sourceforge.net/
Ezmlm — http://cr.yp.to/ezmlm.html
(メール配送システム Qmail と組み合わせて使用するように設計されています)
Dada — http://mojo.skazat.com/
(なぜかサイト上では隠そうとしているようですが、これはフリーソフトウェアで、GNU General Public License のもとで公開されています。また、アーカイバも組み込まれています)

メーリングリストのアーカイブ用ソフトウェア

MHonArc — http://www.mhonarc.org/
Hypermail — http://www.hypermail.org/
Lurker — http://sourceforge.net/projects/lurker/
Procmail — http://www.procmail.org/
(SmartList に同梱されているソフトウェアです。通常のメール処理システムなのですが、アーカイバとしても使えるようです)

バージョン管理

バージョン管理システム（あるいは リビジョン管理システム）は、プロジェクト内のさまざまなファイルの変更履歴を管理するためのテクノロジーや習慣を組み合わせたものです。たとえば、ソースコードやドキュメント、ウェブページなどがバージョン管理の対象となります。もしこれまでにバージョン管理システムを使ったことがないのなら、まずはバージョン管理システムを使ったことのある人を探してプロジェクトに引きずり込みましょう。いまどきのプロジェクトなら、少なくともソースコードくらいはバージョン管理されていて当然です。また、たかがバージョン管理程度のことすらできていないプロジェクトなど、誰もまともに取り合ってくれないかもしれません。

バージョン管理がこれほどまで一般的になった理由は、プロジェクトを運営していく上でいろいろな場面で役立つということです。開発者どうしのコミュニケーション、リリース管理、バグ管理、コードの安定性の確保、安心して新機能を実験できる環境、各開発者の権限の管理など、あらゆる場面でバージョン管理が利用できます。バージョン管理システムは、これらの内容を一まとめにして管理します。その中心となる機能が、変更管理です。これは、プロジェクト内のファイルが変更されるたびにその変更についてのメタデータ（更新日や更新者など）を収集する仕組みです。そして、あとからその変更の内容を再現できるようにするのです。つまり、変更が発生した単位で情報を管理する仕組みといえます。

このセクションでは、バージョン管理システムのあらゆる機能を説明するわけにはいきません。あまりにもさまざまな機能があるので、本書ではすべてを紹介することができないのです。ここでは、使用するバージョン管理システムを選択して実際に稼動させるところまでに絞って説明していきます。

バージョン管理に関する用語集

本書では、まだバージョン管理システムを使ったことがない人に対してその基本的な使い方を解説することはできません。しかし、いくつかのキーワードを知っていなければ、これ以降の議論についていけなくなるでしょう。ここで説明するキーワードは、どのバージョン管理システムでも共通に使われるものです。これらの言葉については、これ以降でもとくに説明せずに使用していきます。たとえこの世にバージョン管理システムがなかったとしても、変更の管理をどうするかという問題が消えてなくなることはありません。この問題について語る際には、ここで取り上げたキーワードを知っていると便利です。

"バージョン"？それとも"リビジョン"？

"リビジョン" と同じような意味で バージョン という言葉を使う人もいますが、本書の中ではこの使い方はしません。 "バージョン" といってしまうと、ソフトウェアのリリース時の版番号 (たとえば "バージョン 1.0 をリリースしました" などと使用) と混同されてしまうからです。しかし、"バージョン管理" という言葉は既に市民権を得てしまっているので、この言葉は使うようにします (本来なら "リビジョン管理" や "変更管理" と言いたいところです)。

コミット

プロジェクトに変更を加えること。もう少しかしこまって言うと、変更した内容をバージョン管理データベースに格納し、そのプロジェクトが次に公開するリリースに反映されるようにすること。 "コミット" は、動詞としても名詞としても用いられます。名詞として使った場合の意味は、"変更" とほぼ同じです。たとえば次のように使用します。"Mac OS X 上でサーバがクラッシュするバグを修正してコミットした。ジェイ、悪いけどこのコミットの内容をチェックしてくれないかな？もしかしたらメモリを確保する方法を間違っているかもしれないし"

ログメッセージ

各コミットに添付されたコメントで、そのコミットの内容や目的を説明するもの。ログメッセージは、そのプロジェクトのドキュメントの中で最も重要なものです。これは、実際に変更したコードの内容を人間が読んでわかりやすい言葉 ("機能追加"、"バグ対応"、あるいはプロジェクトの進捗状況など) に変換する意味合いがあります。このセクションの後半では、ログメッセージを適切なメンバーに配信する方法を説明します。また、 6章コミュニケーション の「しきたりの成文化」では各メンバーにいかにして有用なログメッセージを書いてもらうかを説明します。

アップデート

他のメンバーの変更 (コミット) をローカル環境に取り込むこと。つまり、ローカル環境を "最新版" にすること。これは非常に頻繁に行われる操作です。ほとんどの開発者は、自分のコードを一日に何度もアップデートします。それにより、自分の開発環境を他のメンバーとほぼ同じ状態に保つようにするのです。また、もし何かバグを見つけたときに、おそらくまだそれは修正されていないものであろうことを予想できるようにします。たとえば次のように使用します。"ねぇ、このコードって、いちばん最後のバイトを読んでいないように見えるんだけど……。バグじゃない？" "うん。でもそれは先週修正したよ。最新版にアップデートしたらバグはなくなるはずだ。"

リポジトリ

変更内容を格納するデータベース。たとえば中央管理方式のバージョン管理システムでは、マスタリポジトリがひとつだけ存在します。すべての変更内容がここに格納されることになります。分散管理方式の場合は、各開発者が個別にリポジトリを所有します。他のリポジトリとの間のデータ交換が、任意のタイミングで発生します。バージョン管理システムは、各変更の内容を記録しています。リリース時期には、特定の時点の内容をリリース用として指定します。中央管理方式と分散管理方式のどちらがよいかについて語りだすと、終わりのない宗教戦争に巻き込まれてしまいます。プロジェクトのメーリングリストでは、できるだけこの問題には触れないようにしましょう。

チェックアウト

リポジトリからプロジェクトの内容を取得する処理。チェックアウトを行うと、いわゆる「作業コピー」（次の項を参照ください）と呼ばれるディレクトリツリーが作成されます。このツリーに変更を加えた結果をコミットし、元のリポジトリに反映させます。分散型のバージョン管理システムの中には、作業コピーそのものがリポジトリでもあるというものもあります。その変更内容を、他のリポジトリとの間でやりとりしたりする構造になっています。

作業コピー

開発者がローカル環境に保持するディレクトリツリーで、この中にはプロジェクトのソースコードやウェブページ、その他のドキュメントが格納されることになります。作業コピーには、バージョン管理システムが使用するメタデータも含まれています。このメタデータの中には、取得元のリポジトリの場所や現在の "リビジョン"（次の項を参照ください）などについての情報が格納されています。一般に、個々の開発者は自分の作業コピーを取得してそこで開発を行います。そして、変更した内容のテストを済ませたうえでそれをコミットします。

リビジョン、 チェンジ、 チェンジセット

"リビジョン" とは、指定したファイルやディレクトリの特定の時点の状態のことです。たとえば、あるプロジェクトのファイル F のリビジョンが 6 であった場合に、誰かがファイル F を変更してコミットすると、 F のリビジョンは 7 となります。システムによっては、一度に行われたある特定の変更群を称して "リビジョン"、"チェンジ" あるいは "チェンジセット" とするものもあります。

バージョン管理システムによっては、これらの用語を明確に定義しているものもあります。しかし、一般的な考え方はどれも同じです。一連の流れの中の特定の時点 (バグ修正が行われた箇所など) を指定する方法を用意しているわけです。たとえば、次のように使用します。 "ああ、それなら彼女がリビジョン 10 で修正したよ。" あるいは "彼女は foo.c のリビジョン10でそれを修正したよ。"

特定のリビジョンを指定せずに話を進めている場合は、一般に最新のリビジョンについて語っているものと考えていいでしょう。

差分

変更内容を表すテキスト。変更があった箇所とその前後数行について、変更前と変更後の状態を表示します。元のコードになじみがある人なら、差分を見ればどこをどう変更したのかがわかります。時にはバグを見つけたりすることもできるでしょう。

タグ

指定したリビジョンを構成するファイルにつけるラベル。タグは、プロジェクトの特筆すべき時点の状態を保護するために使用することが多くなります。特筆すべき点とは、たとえば一般向けのリリースなどがあげられます。リリースごとにタグをつけておけば、そのリリースとまったく同じ内容のファイル群をバージョン管理システムから簡単に取得できるようになります。タグの名前としてよく用いられるのは、 Release_1_0 や Delivery_00456 といったものです。

ブランチ

プロジェクトの一部でありバージョン管理下に存在するが、他とは隔離されている部分。ブランチに対して適用した変更はその他の部分に対しては影響をおよぼしません。また逆も同様です。ただし、明示的に "マージ" した場合は別です (以下を参照ください)。ブランチは、"開発ライン" と呼ばれることもあります。明示的にブランチを作成していない場合でも、 "メインブランチ" で開発を進めているものと考えます。このブランチのことは "メインライン" あるいは "トランク (trunk)" と呼ばれることもあります

ブランチを使用すると、複数の開発ラインを別々に管理できるようになります。たとえば、本流の開発ラインとは別に実験的な開発用のブランチを作成し、本流を不安定にさせる可能性があるような開発はそちらで行うということができます。あるいは逆に、新しいリリース用の安定版ブランチを作成するといった使用法もあります。この方式の場合、リリースが間近に迫っても、通常の開発は本流ブランチ上で途切れなく続けられます。一方、リリース用ブランチではリリース作業に入った段階でコミットを停止し、リリース管理者が許可しない限りはコミットをしないようにします。この方式を採用すると、リリース前にいったん開発を中断する必要がなくなります。ブランチについての詳細は、本章の後半にある「ブランチの活用」をご覧ください。

マージ (あるいはポート)

変更内容を、あるブランチから別のブランチに移動すること。本流の変更内容を他のブランチに適用したり、その逆を行ったりすることも含みます。実際のところ、ほとんどのマージ作業はこのパターンです。本流以外の２つのブランチ間でのマージはほとんどありません。この手のマージについては「情報の一元管理」をご覧ください。

"マージ" にはもうひとつの意味もあります。ひとつのファイルに対して複数人が別々の箇所を変更したときに、バージョン管理システムが行う処理のことです。お互いの変更が相手の変更を邪魔することはないので、手元で修正済みのファイルをアップデートすると、相手の変更内容が自動的にマージされ（取り込まれ）ます。これは、複数の人が同じファイルをハックしている場合によくあることです。万一お互いが変更した箇所が重なっていた場合は、次に説明する "コンフリクト" 状態になります。

コンフリクト

ひとつのコードの同じ箇所を異なる人が変更しようとした際に起こる現象。バージョン管理システムは、コンフリクトの発生を自動的に検出します。そして、変更しようとしたユーザーに対してそれを通知します。発生したコンフリクトを解決するのは、変更しようとした人たち自身の責任です。解決したあとで、それをバージョン管理システムに通知します。

ロック

特定のファイルやディレクトリを、他人に変更されないように宣言する方法。たとえば "ウェブページの変更内容をコミットしようとしたけどできない。たぶん、Alfred が背景画像を修正する間、すべてのファイルをロックしているんだろう" というように使います。中にはロック機能を持っていないバージョン管理システムもあります。また、その機能を持っていたとしても、実際にそれが必要となることはあまりないでしょう。いろんな人が同時に平行して開発を進めるというのが普通の状況なのであり、ロックして他人を締め出すというのはこの理想に相反するものです。

コミットするにはロックが必要となるバージョン管理システムのことを、「ロック - 修正 - ロック解除 (lock-modify-unlock) モデル」といいます。一方、ロックが必要でない方式のことは「コピー - 修正 - マージ (copy-modify-merge) モデル」といいます。２つの方式について深く掘り下げて比較したすばらしい文書が http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html （日本語訳）にあります。一般に、オープンソース開発においてはコピー - 修正 - マージモデルの方が適しています。本書で扱うバージョン管理システムは、すべてこの方式を採用しています。

バージョン管理システムの選択

本書の執筆時点では、フリーソフトウェアの世界で最もよく使われているバージョン管理システムは Concurrent Versions System (CVS, http://www.cvshome.org/) と Subversion (SVN, http://subversion.tigris.org/) の２つです。

CVS には長い歴史があります。ベテランの開発者はすでに CVS についてはよくご存知でしょう。これまでにも CVS がいろいろな場面で役に立ってきたはずです。 CVS の時代があまりにも長く続いてきたので、本当にそれが最適な選択肢だったのかどうかなんて聞くだけ野暮というものでしょう。しかし、CVS には欠点もあります。まず、複数のファイルを一括して変更したときに、それを追いかける簡単な手段がありません。また、バージョン管理下にあるファイルの名前を変えたりコピーしたりすることができません（プロジェクトをいったん開始した後でコードツリーの構成を変更したい場合は、泣きながら大変な作業をこなすことになるでしょう)。そして、マージ機能はかなりお粗末なものです。巨大なファイルやバイナリファイルの扱いも不得意です。そして、大量のファイルを一括して操作しようとすると非常に時間がかかることがあります。

CVS のこれらの欠点は決して致命的なものではありませんが、無視できるものでもありません。ここ数年、新たに立ち上げられたプロジェクトでは Subversion を採用することが多くなってきました ^[18]。これから新たにプロジェクトを立ち上げるのなら、Subversion をお勧めします。

一方、私が Subversion プロジェクトにかかわっていることもあり、私の意見の客観性に疑問を持たれる方もいるかもしれません。ここ数年、新たなオープンソースのバージョン管理システムがいくつか登場しています。付録B フリーなバージョン管理システム に、私が知っているものを挙げておきます。このリストを見てもわかるように、バージョン管理システムにどれを採用するかを決めるには、下手したら一生かかってしまうかも知れません。もしかしたら、あなたには選択の余地がないかも知れません。というのは、ホスティングサイトを使用する場合はホスティングサイト側でバージョン管理システムが設定されているかもしれないからです。もしあなたが自分で選択しなければならない立場になったのなら、まず周りの意見をよく聞いてからどれかひとつを選択し、そして動かしてみましょう。最近のバージョン管理システムは、どれもそれなりに機能します。どれを選んだとしても、致命的な被害を受けることはないでしょう。もしまだ迷っているのなら、Subversion を使ってみましょう。これは簡単に習得でき、少なくとも今後数年は標準的に使われることでしょう。

バージョン管理システムの使用法

この章で説明する内容は、特定のバージョン管理システムに固有のものではありません。どのシステムを選択した場合にも適用できるはずです。詳細は、各システムのドキュメントを調べるようにしましょう。

すべてをバージョン管理する

ソースコードだけでなく、ウェブページやドキュメント、FAQ、設計メモなどなど、編集する可能性のあるものはすべてバージョン管理下におくようにしましょう。これらは、同一リポジトリツリー内でソースコードの隣に置いておきます。書き残した情報は、すべてバージョン管理する価値があります。つまり、あらゆる情報は変化する可能性があるということです。今後変わりようのない内容については、バージョン管理ではなくアーカイブしなければなりません。たとえば、メーリングリストに投稿されたメールの内容は、変わることがありません。このようなものをバージョン管理しても無意味です (もちろん、それが巨大な文書の一部となる場合などは別ですが)。

すべてを同じ場所でバージョン管理する理由は、そうしておけば作業に参加する人がひとつのことを覚えるだけですむようになるからです。たとえば、最初はウェブページやドキュメントの修正から参加しはじめたメンバーが、後にコードそのものの修正にも参加するようになるといったことがあります。すべてを同じ仕組みでバージョン管理しておけば、このような場合に新たにその使用法を学ぶ必要がなくなるのです。また、新機能を追加すると同時にドキュメントも更新したり、コードのブランチを作成すると同時にドキュメントのブランチも作成したりといった際にも便利です。

自動生成されるファイル はバージョン管理する必要がありません。これらのファイルは純粋に編集可能なデータではなく、別のファイルの内容をもとにして自動生成されるものだからです。たとえば、ビルドシステムでよく用いられるファイル configure は、テンプレート configure.in の内容をもとにして自動生成されるものです。もし configure を変更したいのなら、configure.in を編集してから再生成するということになります。つまり、この場合で言う「真に編集可能なファイル」は、テンプレートである configure.in だけということになります。バージョン管理するのはテンプレートだけにします。生成した結果までバージョン管理してしまうと、テンプレートを修正した際にファイルを再生成することを忘れてしまうかも知れません。そうすると、ファイルの整合性が取れなくなってしまって混乱の元となります。 ^[19]

「編集可能なデータはすべてバージョン管理下におかなければならない」という規則には、残念ながらひとつだけ例外があります。それがバグ追跡システムです。バグデータベースは編集可能なデータを大量に保持していますが、技術的な理由により、このデータをバージョン管理することはできません (バグ追跡システムの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。しかし、これはプロジェクトのメインリポジトリとは独立したものとなります)。

ウェブで閲覧できるようにする

プロジェクトのリポジトリは、ウェブ上からも閲覧できるようにしなければなりません。これは、ただ単に最新のリビジョンが見られればいいというレベルのものではありません。前のリビジョンにさかのぼったりリビジョン間の差分を見たり、変更時のログメッセージを見たりといった機能も含みます。

これは、そのプロジェクトのデータに関する便利な入り口となるので、ブラウザビリティ（閲覧のしやすさ）が重要となります。もしウェブブラウザ経由での閲覧ができなければ、そのプロジェクトの特定のファイルを調べたい人（あのバグ修正はどんな風に行われたのかな？など）はまずバージョン管理システムのクライアントソフトウェアをインストールするところから始めなければならなくなってしまいます。ウェブで見られれば２分ですむことなのに、それがないために30分がかりの作業になってしまうということになります。

ブラウザビリティの中には、特定のファイルの特定のリビジョンが特定の URL で見られること、そして特定のファイルの（その時点での）最新リビジョンも特定の URL で見られることといった内容も含まれます。こうしておくと、技術的な議論の際にその場所を示しやすくなるので便利です。たとえば「バグ管理についてのガイドラインは、作業コピーにある www/hacking.html をご覧ください」という代わりに「バグ管理についてのガイドラインは http://subversion.apache.org/docs/community-guide/ をご覧ください」と言えるのです。これは、常に community-guides/index.html の最新リビジョンを指す URL です。URL を指定するほうが、あいまい性を排除するという点でよいでしょう。

バージョン管理システムの中には、リポジトリをウェブで閲覧するための仕組みが組み込まれているものもあります。また、サードパーティのツールを使ってこの機能を実現しているものもあります。サードパーティのツールとして有名なのは ViewVC (http://viewvc.org/)、 CVSWeb (http://www.freebsd.org/projects/cvsweb.html)、そして WebSVN (http://websvn.tigris.org/) です。ViewVC は CVS と Subversion の両方に対応しています。一方、CVSWeb は CVS 専用、WebSVN は Subversion 専用です。

コミットメール

コミットが行われるたびに、その内容をメールで送信するようにします。メールには「だれが」「いつ」「どのファイルやディレクトリを」「どのように」変更したのかを記述します。このメールの送信先は独立したメーリングリストとし、人間が投稿する普通のメーリングリストとは独立させましょう。コミットメールを受け取りたいひとだけがそのメーリングリストに参加することになります。開発者やプロジェクトに興味があるその他の人たちには、このメーリングリストへの加入を勧めましょう。今そのプロジェクトに何が起こっているのかをコードレベルで知るために、このメーリングリストは最適な手段となります。ピアレビューの技術的な有用性については改めて語るまでもありません (「きちんとしたコードレビューの習慣」をご覧ください) が、コミットメールもコミュニティーにおいては有用なものとなります。すべてのイベント（コミット）の内容が共有されることで、他のメンバーがそれに反応したりといったことがしやすくなるのです。

コミットメールの設定方法は、使用するバージョン管理システムによって異なります。しかし、通常はそれ用のスクリプトやパッケージが用意されているはずです。もし見つからなければ、使用しているシステムのドキュメントで フック（hooks）、あるいは コミット後フック（post-commit hook） といったキーワードで探してみましょう。ちなみに CVS では loginfo フック（loginfo hook） と言うようです。コミットがあるたびに自動で特定の作業をさせる際に使用するのがコミット後フックです。これは各コミットの直後に呼び出され、そのコミットに関する情報を受け取って任意の作業を行うことができます。そう。たとえばメールを送信したりなど。

用意されているメール送信の仕組みを使用していると、そのデフォルトの動作をちょっと変更したくなってくるかもしれません。

コミットメールシステムの中には、実際の差分そのものは本文に含めず、それをウェブで見るための URL だけを記載するというものがあります。もちろん URL は大事です。後から変更内容を確認するのにも便利ですしね。でも、差分の内容そのものをメールの本文に含めておくことも 非常に 重要です。多くの人にとって、メールを読むという作業は日常のルーチンワークとして組み込まれているでしょう。変更の内容が直接メールに書かれていれば、一連の流れの中で自然にコミットをレビューすることができます。いちいちメールソフトを終了してブラウザに切り替える必要がなくなるのです。変更を確認するには URL をクリックする必要があるとなれば、ほとんどの人はクリックなどしてくれないでしょう。だって、これまでずっとメールを読んでいたのに、いきなり別の操作が必要となるのですから。さらに、変更点をレビューした人がその内容について質問をしたいときに、そのメールに「返信」すれば自動的に変更内容が得られるので便利です。さもないと、ウェブページを開いて変更点をカット＆ペーストするという大変な手間がかかってしまいます。
(もちろん、新たにリポジトリにコードを追加したなどで変更点が大量にある場合は、差分を省略して URL だけにするというのもわかります。コミットメールのシステムの多くは、何らかの制限値を設定してこの処理を自動化してくれるようになっています。もしそんな機能がついていなかったとしましょう。そんな場合でも、差分をまったく記載しないよりは常に差分を含めるようにするほうがずっとマシです。たまに巨大なメールが送信されることになりますが、許容範囲です。共同開発においては、みんなが他人の変更をレビューしたりコメントしたりすることが重要です。そのための努力は、いくらしてもしすぎることはありません)
コミットメールの Reply-to ヘッダは、コミットメール用のメーリングリストではなく開発者向けのメーリングリストにしておきましょう。そうすると、コミットメールの内容をレビューして何らかのコメントをしたくなった人が「返信」すると、それが自動的に開発者向けメーリングリストに流れることになります。こうしておくべき理由はいくつかあります。まず、技術的な議論はひとつの場所に集約するということ。技術的な議論を行う場として最適なのは、開発者向けメーリングリストです。次に、コミットメール用のメーリングリストに参加していないメンバーにも議論の内容を伝えるということ。３つ目に、コミットメール用のメーリングリストはあくまでもコミットの内容をチェックするだけのものであり、決して「コミットの内容のチェックがメインだけど、たまに技術的な議論もある」というものであってはいけないからです。コミットメール用のメーリングリストに登録する人たちは、コミット内容のメールだけが送られてくることを期待しています。それ以外の内容が送られると、暗黙の了解を裏切ってしまうことになります。最後に、コミットメールの内容を処理して（ウェブページなどに）結果を出力するプログラムを作成するような人のことを考えるということ。この種のプログラムは、コミットメールのようなお決まりのパターンのメールに関してはうまく動作します。しかし、人間が書いたメールを処理させると変な結果になってしまうでしょう。
ここでお勧めした Reply-to の設定は、決して本章の前半で述べた「Reply-to はどうすべきか」の内容と矛盾するものではないことに注意しましょう。先ほども、メッセージの 送信者 自身が Reply-to を設定するぶんには特に問題はないとしています。今回の場合、メッセージの送信者はバージョン管理システムです。バージョン管理システム自身で Reply-to を指定して開発者向けメーリングリスト向けに返信させようとしているのですから、さきほどの説明とは矛盾しません。

CIA: 変更点を公開するための標準化された方法

変更点を公開する方法はコミットメールだけではなく、 CIA (http://cia.vc/) をインストールすることもできます。これは、コミットの状況をリアルタイムで収集し、配信するものです。 CIA の最も一般的な使用法は、コミットの通知を IRC チャンネルに送信するというものです。そのチャンネルに参加していれば、コミットがあるたびに即時にそれを知ることができます。メールに比べたら、技術的に劣っているかもしれません。だって、IRC にコミット通知を送ったとしてもそれを見ている人がいるかどうかがわからないわけですから。それでも、この仕組みは 社会的な面で 面白いものです。参加している人たちはそこで何かが起こっていることが感じられ、開発の進行状況をまさに目の前で見られるというわけです。また、共有空間に通知されるので、チャットルームにいる人たちがリアルタイムで反応し、即座にコミットをレビューしてコメントをしてくれることが多くなります。

CIA を使用するには、コミット後のフックで通知用プログラムを実行します。このプログラムは、コミットに関する情報を XML 形式に変換して中央サーバ (通常は cia.vi) に送ります。するとサーバがその情報を別のフォーラムに配信するのです。

CIA を設定することで、 RSS フィードを送信させることもできます。詳細は http://cia.vc/ のドキュメントをご確認ください。

CIA が実際に動作している例を見るには、IRC クライアントで irc.freenode.net のチャンネル #commits に行ってみましょう。ここでは、 CIA が監視している全プロジェクトの活動状況を見ることができます。

ブランチの活用

バージョン管理システムにあまり慣れていないユーザーは、ブランチの作成やマージ作業を怖がる傾向があるようです。おそらく、これは CVS の悪評の副作用でしょう。 CVS のブランチ作成処理やマージ処理は直感的とは言えず、多くの人がそれを避けるようにしています。

もしあなたもその中のひとりだというのなら、怖がる気持ちを乗り越えてブランチ作成やマージについて勉強してみましょう。いったん作業に慣れてしまえば、そんなに難しいものではありません。また、プロジェクトに参加するメンバーが増えれば増えるほどこの作業の重要性も増します。

ブランチを使用すると、限られた資源（プロジェクトのソースコード中の作業場所）を有効活用できるので便利です。通常は、すべての開発者がひとつの砂場の上で作業をします。みんなでひとつのお城を作っていこうとしているわけです。あるとき、ひとりのメンバーが「ここに跳ね橋をつけましょうよ」と言い出しました。でも、他のメンバーは、それがそのお城にとって本当に有用なのかどうかがわかりません。そのメンバー用に砂場の一角を隔離し、彼女にはそこで作業をしてもらう。ブランチを作成するとは、そういうことになります。もしうまい具合に跳ね橋が出来上がったら、彼女は他のメンバーを呼び寄せてそれを見てもらいます。みんなが納得するようなできばえであることがわかれば、バージョン管理システムを使ってその跳ね橋をみんなのお城に移植（"マージ"）するのです。

共同作業を進めるうえでこの機能がいかに有用かは、言うまでもないことでしょう。この機能を使えば、「他の人に迷惑がかからないかな？」なんて気にせずに思う存分新しいことを試せるのです。同じくらい重要なこととして、バグ修正や安定版リリースのためのブランチを本流から隔離する (7章パッケージの作成、リリース、日々の開発 の「リリースを安定させるプロセス」と「複数のリリースラインを管理する」を参照ください) ということがあります。そうすれば、それぞれの流れを追いやすくなります。

偏見を捨て、ブランチを積極的に使うようにしましょう。そして、他のメンバーにもブランチの使用を推奨しましょう。しかし、不要になったブランチはいつまでも残しておかないようにしましょう。ブランチが増えれば増えるほど、コミュニティー内での注目が散らばってしまいます。そのブランチとは直接関係のない開発者であっても、周りで起こっていることを気にせずにはいられないでしょう。無理もありません。もちろん、ブランチに対するコミットであってもコミットメールは同じように送ります。しかし、ブランチは開発者のコミュニティーを分断する仕組みとなるべきではありません。わずかな例外を除いては、初期の目的を達成して本流にマージした時点でブランチを削除するようにしましょう。

情報の一元管理

ブランチが重要だということは、当然マージ処理も重要になってくるということです。同じコミットを２回繰り返すなんていうことがないようにしましょう。つまり、ある変更がバージョン管理システムに投入されるのは１回だけにしておくということです。そうしておくことで、ある変更に対応するリビジョン（あるいはリビジョン群）が一意に決まるようになります。その変更と同じ内容を別のブランチにも適用したい場合は、そのブランチ上でもまったく同じように手を加えてそれをコミットするというのではなく、最初の変更をマージするようにしましょう。手作業で同じように修正したものをコミットしても結果は同じですが、そうすると正確なリリース管理ができなくなります。

この件に関する実際のアドバイスは、使用するバージョン管理システムによって異なります。あるシステムでは、「マージ」は特別な処理として扱われ、通常のコミットとは別のものとなります。そして独自のメタデータを保持します。また、システムによっては、マージした結果を通常のコミットと同様に適用するものもあります。このようなシステムでは、「マージした結果のコミット」と「新しい変更のコミット」の区別はログメッセージで行います。マージした際のログメッセージには、元の変更の際のログをそのまま繰り返してはいけません。そうではなく、「この変更はマージである」ことと、どのリビジョンをマージしたのかを簡単に記述するようにします。実際の変更内容を知りたければ、マージ元のログメッセージを見るようにするわけです。

ログメッセージの重複を避けるのがなぜそんなに大事なのかというと、ログメッセージは後から修正される可能性があるからです。同じ内容のログを繰り返し記述していると、だれかが元のログメッセージを修正したときにコピー先のメッセージがそのままになってしまう可能性があります。後から見たら、これは非常にややこしい状況になります。

同じ原則は、変更を取り消す (revert) 際にもあてはまります。ある修正が廃案になったときのログメッセージは、単にそれが revert されたということだけを記述します。実際に何をどのように戻したのかまでを書いては いけません。だってそれは、もともとその変更を行った際のログを見ればわかることなんですから。もちろん「なぜ」取り消したのかという理由の説明は必要でしょう。しかし、元の変更の際のログメッセージを一言一句書き写す必要はありません。できれば、元の変更の際のログメッセージも修正し、それが結局取り消されたことを記述しておくとよいでしょう。

これまで説明してきたことからも何となくお分かりでしょうが、特定のリビジョンを参照する際の表記方法は統一しておいたほうがいいでしょう。これは、ログメッセージだけでなくメールやバグ追跡システムなどでも同じです。 CVS を使っているのなら、 "path/to/file/in/project/tree:REV" という形式をお勧めします。ここで、REV は CVS のリビジョン番号 (たとえば "1.76" など) を指します。 Subversion を使っているのなら、(たとえばリビジョン 1729 の場合の) 標準の表記法は "r1729" となります (ファイルのパスは不要です。 Subversion はリポジトリ全体でリビジョン番号を管理するからです)。それ以外のシステムでもきっと、チェンジセットを表すための標準形式があることでしょう。ともかく、メンバーには標準の形式を使ってもらうようにしましょう。この表記法を統一しておくと、後からプロジェクトの流れを追うのが簡単になり (6章コミュニケーション や 7章パッケージの作成、リリース、日々の開発 で説明します) ます。これらの管理を行うのはたいていはボランティアなので、できるだけ簡単に進められるようにしておくことが重要です。

7章パッケージの作成、リリース、日々の開発 の「リリースと日々の開発」もご覧ください。

承認

たいていのバージョン管理システムには、特定のユーザーに対してリポジトリ内の特定の場所だけのコミットを許可したり逆に拒否したりといったことをする機能があります。「ハンマーを与えられたら、人はみんな周囲の釘を探すようになる」という原則どおり、多くのプロジェクトでこの機能が使われてきました。アクセス権を注意深く管理し、特定の場所にだけコミット権を与えて他の場所は触らせないようにするといった具合です (8章ボランティアの管理 の「コミッター」で、コミット権の管理方法について説明しています)。

このように厳格に管理してしまえば、悪影響が出る可能性を減らせることでしょう。しかし、もうすこし緩やかな方針でもかまいません。プロジェクトによっては、緩やかな方針を採用しているものもあります。たとえリポジトリの一部分のみへのコミット権を与えられたユーザーであっても、設定上はリポジトリ全体を変更できる権限を与えるというものです。ただ「コミットするのはこの範囲だけにしておいてね」とお願いするだけです。こうしたところで、実害はないことを覚えておきましょう。ふつうのプロジェクトなら、すべてのコミットは何らかの形でレビューされます。誰かが予期せぬコミットをしたら、それを見つけた人が何かコメントすることでしょう。その変更を取り消すべきだと判断したのなら、やることは簡単です。すべてバージョン管理されているのだから、単にその変更を取り消せばいいだけのことです。

緩やかな方針にしておく利点はいくつかあります。まず、ある開発者の権限を拡張する（プロジェクトに長年かかわっていると、よくあることです）場合に一切手間がかからないということです。単に「今日からは、ここもコミットしていいよ」というだけで、後はすぐにコミットできるようになります。

次に、より緻密な方法で権限の拡張ができるようになります。一般に、エリア X のコミッターがエリア Y にもコミットしたいと考えた場合は、まず Y に対するパッチを投稿してレビューしてもらうことになります。すでに Y へのコミット権を持つメンバーがそのパッチをレビューして承認したら、パッチを投稿した人に対して「直接コミットしてもいいよ」と伝えます (もちろん、誰がレビューして承認したのかという情報はログメッセージに残しておきます)。この方法だと、実際にパッチを書いた人がコミットをすることになります。これは、情報管理の面でも功績をたたえる意味でも重要です。

最後に、最も重要なのが、この緩やかな方式を採用するとお互いに信頼し、尊重しあう空気が生まれるということです。この方式の場合、「君はこの部分にコミットする能力があることがわかった。ぜひコミットしてくれ」というようにとられます。厳格に管理してしまうと「君のできることには制限があるんだ」ということを強調するだけでなく「間違って変なことをしてしまわないかどうかが心配なんだ」と疑っているように感じられてしまいます。できればこのようなことは避けたいでしょう。だれかを新たにコミッターとして迎え入れるということは、みんなの信頼の輪の中に新しいメンバーを加えるということです。その際には、本来必要なもの以上の力を与え、「それをどう使うかはあなたしだい。でもこれ以上のことはしないでね」としたほうがいいでしょう。

Subversion プロジェクトでは、かれこれ 4 年以上この「緩やかな管理」方式を採用しています。本書の執筆時点で、フルコミッターは 33 人、一部にだけコミット権限のあるメンバーが 43 人います。この管理方式では、システムが管理するのは「コミッターかそうでないか」だけです。その詳細 (どの部分にコミット権があるかなど) は人間が管理します。今のところ、コミット権のない部分について故意にコミットするなどといった問題は発生していません。コミット権に関する誤解が生じたことも何度かありましたが、いつも速やかに円満解決していました。

このような自己管理方式が明らかに現実的でない場面もあるでしょう。当然、そんな場合は厳格な管理が必要となります。とはいえ、そんな状況はまれです。たとえ何千人の開発者が何百万行のコードを扱っていたとしても、そのコードに対するすべてのコミットはだれか他の人によるレビューを受けます。おかしなコミットがあればすぐに指摘されるでしょう。もしコミットをレビューしあう習慣ができていないのなら、それは認証システムがどうのこうのいう以前の問題です。

まとめると、よっぽどの理由がない限りはバージョン管理システム上のアクセス権限にあまり気を使う必要はないということです。厳密に管理したところで得られる具体的なメリットはあまりありません。それより人間による管理に頼ったほうが得られるものは多いでしょう。

もちろん、制限をすること自体が無意味だといっているわけではありません。権限のないところへコミットさせるようなことは、あまりしたくないでしょう。さらに、多くのプロジェクトでは「フルコミッター (制限のないコミッター)」には何らかの特権 (たとえばプロジェクトの運営に関する投票に参加できるなど) が与えられています。コミット権の扱いに関する政治的な意味合いについては 4章プロジェクトの政治構造と社会構造 の「誰が投票するのか?」で詳しく説明します。

バグ追跡システム

バグ追跡が扱う範囲は多岐にわたります。この本ではバグ追跡についての様々な側面を議論しています。ここではバグ追跡システムをセットアップすることと、その作業に関する技術的な考察に集中しようと思います。その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか?

バグ追跡システム は、誤解を招きやすい用語です。バグ追跡システムは、新しい機能要望や、一度限りのタスク、送られてきたパッチ — はじまりと終わりの状態があるすべてのもの、存在している間に情報が発生するすべてのものを追跡するためによく使われます。このため、バグ追跡システムは、 問題追跡システム、 不具合追跡システム、 影響追跡システム、 要望追跡システム、 チケットシステム などとも呼ばれています。バグ追跡システムのソフトウェアの一覧は、付録C フリーなバグ追跡システム を参照してください。

この本では "バグ追跡システム" という用語を、バグを追跡するソフトウェアを指すものとします。なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、問題という用語を使います。これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、バグの発見、診断、解決の記録を区別できるからです。殆どの問題は実際に起こったバグに関するものですが、他のタスクに関することでも問題という用語が使えるということを覚えておいてください。

問題の典型的なライフサイクルは次のようなものです。

誰かが問題をバグデータベースに記録します。この記録には、問題の要点、問題の説明(もしあれば、問題を再現させるための手順も。ユーザーに優れたバグ報告をさせる方法については、 8章ボランティアの管理 の「すべてのユーザーの協力を得るために」を参照してください) 、バグ追跡システムが求めているその他の情報が全て含まれています。問題を報告した人は、プロジェクトについて全く知らないかもしれません。— ユーザーのコミュニティーと開発者達から、同じくらいの割合でバグ報告や機能要望があがってきます。
いったん問題が報告されると、その問題は 保留中 の状態にあるといいます。なぜなら、それに対して何らアクションがとられていないからです。システムによっては、 未確認 とか 未着手 といったラベルを付与するものもあります。まだ誰もこの問題を担当していません。システムによっては、担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。この時点では、問題は一時的な領域に置かれています。つまり、システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。
誰か他の人が問題を読み、コメントを付けます。おそらく問題を報告した人に、不明な点について説明を求めるでしょう。
問題はやがて 再現済み という状態になります。これは問題のライフサイクルの中で最も重要かもしれません。これは、まだ解決されたわけではないが、報告した人以外の誰かが問題を再現でき、この問題が本物だと証明したことをいいます。そして同じくらい重要なことですが、報告した人が本物のバグを報告することで、プロジェクトに貢献したと確認することでもあります。
そして 診断済み という状態になります。問題の原因が特定され、可能なら解決に必要な労力が見積もられます。これらのことは必ず追跡システムに記録するようにしましょう。原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、誰かが穴を埋められるようにしておくべきだからです。
この段階か、もうひとつ前の段階で、開発者が問題を "自分が解決することにして"、自分自身を 担当者にする するかもしれません。 (担当者を決める手続きをさらに詳細に調べるには 8章ボランティアの管理 の、「作業依頼と担当者の決定を明確に区別する」を参照してください) この段階で、問題に優先度 も割り当てられるかもしれません。たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、その事実は早い段階で確認する必要があります。よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。
問題をいつ解決するかという予定が立てられます。予定を決めるということは、いつまでに直すという日程を決めることとは限りません。将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、特定のリリースで直すと決めない場合もあります。バグが素早く直せる場合には、予定を立てないこともあります。
問題が解決されます。（タスクが終了したり、パッチが適用されたりとか、そういったものです）行った変更は、問題の 処理が済んだ り、 解決済み とマークされたあとに、コメントとして記録するようにしましょう。

問題のライフサイクルには共通のバリエーションがいくつかあります。問題によっては、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることがあります。プロジェクトが多くのユーザーを獲得するにつれ、バグではない問題が報告される回数も増えていき、開発者は次第にぶっきらぼうな返事をして問題を処理済みとするようになります。こういう風潮にならないよう努力しましょう。ぶっきらぼうに問題を処理済みにしてもいいことは何もありません。バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。それに報告される問題が統計的にどういった傾向にあるかは、開発者のみわかることで、ユーザーにはわからないことです。 (この章の後半の「バグ追跡システムをあらかじめフィルタする」で、バグではない問題の数を減らすテクニックについて見ていきます) また、異なったユーザーが繰り返し同じような誤解をする場合は、誤解を生む部分を再設計する必要があるということかもしれません。この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。 8章ボランティアの管理 の、「バグマネージャー」を参照してください。

別のバリエーションとして、 1. のすぐ後で問題が 重複している として処理済みにされる場合があります。重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。重複した状態は保留中の問題で発生するとは限りません。解決したあとで再び報告される(この状態を リグレッション（回帰） と呼びます)こともあります。こういう場合は、重複の元となった問題を再度保留中の状態にして、重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。バグ追跡システムは、問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、問題同士の関連を追跡しているはずです。

開発者が問題を処理済みにする3つ目のバリエーションは、問題を解決したと思い込んで処理済みにするパターンです。これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、問題を再現する手順に正確に従ってテストをしなかったために発生します。

これらのバリエーションのほかにも、バグ追跡システムによって細かい部分が変わる場合はありますが、基本的なパターンは同じです。問題のライフサイクルそのものもオープンソースソフトウェアに特有のものではありませんが、オープンソースプロジェクトのバグ追跡システムの使い方に影響を与えています。

1. が暗に示すとおり、バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。誰でも問題を報告し、調べることができますし、現在保留中とされている問題の一覧を見ることができます。よって、報告されている問題の進捗を何人の人が知りたがっているのかが、開発者にはわからないということになります。問題が解決される割合は開発者コミュニティーの規模やスキルに左右されますが、プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。たとえ問題が解決されずにしばらく残り続けても、開発者が返答すると、問題を報告した人は引き続き参加したいと考えます。なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、たとえば電子メールを送ること以上に労力がいることを思い出してください) それ以上に、問題をいったん開発者が見れば、報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、プロジェクトが問題を認識したことになります。

適切なタイミングで問題に応答するには、次の二つが必要です。

バグ追跡システムをメーリングリストと接続しなければいけません。これは、問題を報告することを含めた、問題の状態を変更するあらゆる行動が、メールで投稿されるようにするためです。このメーリングリストは通常使う開発用のものとは違うのが普通です。なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。
問題を報告するときの記入フォームは、報告する人の電子メールアドレスの欄にフォーカスを当てておくべきです。 (しかし、匿名で報告したいと思う人もいるので、電子メールアドレスを必須にすべきではありません。匿名の重要性については、この章の後半にある「匿名性とプロジェクト参加」を参照してください。

議論の場としてメーリングリストを使う

バグ追跡システムがディスカッションフォーラムにならないようにしましょう。バグ追跡システムに人間が顔を出し続けることは大事ですが、それがリアルタイムに議論するのに適しているわけではありません。バグ追跡システムは、起こった事実や他の議論に対する参照、メーリングリストで起きた議論をまとめるアーカイバと考えるようにしましょう。

こうした区別をするのはふたつの理由があります。ひとつめは、バグ追跡システムがメーリングリストに比べて（ついでにいうと、リアルタイムに会話ができるチャットシステムと比べても）使いにくいからです。これはバグ追跡システムのインターフェイス設計が悪いからではなく、単にメーリングリストやチャットシステムが、連続していない状態、つまり自由に流れていく議論を取り込めるように設計されているからです。ふたつめは、ある議論に参加している人が、バグ追跡システムを見ているとは限らないからです。よい問題管理のやり方(8章ボランティアの管理 の、「技術的な作業だけでなく管理作業もみんなで」を参照してください)は、開発者全員に起こっている問題全部を追いかけさせるのではなく、適切な人の注意をひくようにすることです。 6章コミュニケーション の「バグ追跡システムでは議論しない」では、適切なフォーラム以外に偶然議論が波及しないようにする方法や、バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。

バグ追跡システムによっては、メーリングリストをモニタし、既知の問題に関する電子メールを全て自動的に記録するものがあります。通常、こうしたシステムはメールの件名の行にある問題の番号を、特別な文字列として認識することでこれを行います。開発者達は、バグ追跡システムの注意を引くために、電子メールにこうした文字列を含めることができるようになります。バグ追跡システムに電子メール全体を記録させてもいいですし、 (よりよいのは)通常のメーリングリストのアーカイブにあるメールへのリンクを記録させてもよいでしょう。どちらの方法でも、これはとても役に立つ機能です。あなたが使っているバグ追跡システムにこの機能があるなら、それを有効にして人々が利用するように知らせておきましょう。

バグ追跡システムをあらかじめフィルタする

ほとんどのバグ追跡システムは結局同じ課題に悩まされます。バグを報告した経験が少なかったり、肝心な部分を知らない善意のユーザーが、既に報告されている問題やバグではない問題を大量に報告してくるのです。この傾向に対処するはじめのステップとして、バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。そこで本当にバグかどうかを区別する方法や、既に報告されている問題かどうかを検索する方法、そして最後に、本当に新規のバグであった場合に効果的に報告する方法を説明しておくのです。

こうすることでしばらくは報告されてくる問題のノイズは下げられますが、ユーザーが増えてくるにつれてこの課題は結局再燃します。このことでユーザーを責めることはできません。ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、たとえ彼らのバグ報告がはじめは役に立たなかったとしても、あなたは彼らにひき続きプロジェクトに参加してもらって、将来はよりよいバグ報告をして欲しいと思うでしょう。しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。

この課題を避けるために何より実行すべきことがふたつあります。バグではない問題や、重複したバグ報告を報告されたらすぐに処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。そしてバグ報告システムにバグを報告する前に、他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。

はじめのテクニックはあらゆるところで使われているようです。巨大なバグデータベースを持つ（たとえば http://bugs.debian.org/ にある Debian のバグ追跡システムは、執筆時点で 315,929個のバグ情報があります）プロジェクトでも、バグが報告されるたびに 誰かが 見張るようにシステムを改造しています。問題のカテゴリによって見張る人は違うかもしれません。たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、自動的にそれぞれの問題を適切なパッケージメンテナーに転送しています。もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。そういう場合は、そのバグははじめは間違った人に転送されるので、転送された人が再度転送し直さなければなりません。しかし重要なのは、その負担が共有されているということです — ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。よって問題が報告されるたびに、適切なタイミングで応答できるのです。

ふたつめのテクニックは広く使われているわけではありませんが、これはおそらく自動化が難しいからでしょう。アイディアの要点は、新しく報告されてくる問題をデータベースに登録する前に、 "仲間を" 巻き込むことです。ユーザーが問題を見つけたと思ったときは、メーリングリストかIRCで説明するように求めます。そうすることで、誰かが本当にバグかどうかを確認するのです。別の人の目に早めに晒すことで、たくさんの間違った報告を避けることができます。別の人がその振る舞いはバグではないとわかったり、最近のリリースで解決済みだとわかる場合があります。または、別の人が以前報告された問題から報告されるバグの兆候に精通しているので、古い問題であるとユーザーに指摘することで重複した報告を防ぐことができる場合もあります。 "既に報告された問題かどうかをバグ追跡システムで検索したかい?" とユーザーに聞くだけで十分なこともあります。多くの人はそんなことを考えてもいませんが、誰かがそうすることを 期待している とわかれば、喜んで検索するものです。

仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、欠点もいくつかあります。多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、軽視するかして、結局ひとりでバグ報告をしてしまうことです。よって、ボランティアにはやはりバグデータベースを見張ってもらう必要があります。さらに、ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らないので、ガイドラインを無視しているからといって厳しく注意するのはフェアではありません。よってボランティアは、誰にも見てもらっていないバグ報告を報告者にどう差し戻すのかについては、用心深く、なおかつ慎重でなければなりません。これは、問題をフィルタする仕組みを理解する人々を増やせるように、ゆくゆくは仲間を巻き込んでバグ報告をしてもらうことが目的です。誰にも見てもらっていないバグ報告を見つけたら、とるべき理想的な対処のステップは次のようなものです。

すぐにバグ報告に応答し、ユーザーがバグ報告をしてくれたことに丁寧にお礼を言います。しかし、バグかどうかを誰かに見てもらうガイドラインがあることを指摘します。（これはもちろん、ウェブサイトに目立つように投稿すべきです）
報告された問題が明らかに正しいもので重複していない場合は、とりあえずそれを受け入れて通常のライフサイクルを開始します。結局、報告した人はバグかどうかを誰かに見てもらうべきだと言われているので、正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。
そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークしましょう。しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、再度保留中にして欲しいと伝えます。この場合、報告した人は確認をとったスレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するはずです。

この方法はいずれバグ追跡システムの S/N比を改善してくれるでしょう。しかし、間違ったバグ報告は決してなくならないことを覚えておいてください。間違ったバグ報告を根絶する唯一の方法は、開発者以外の人にはバグ追跡システムを使わせないことです — しかし、この方法でよい結果が出ることはほとんどありません。間違ったバグ報告を取り除くことがプロジェクトのルーチンワークであることを受け入れ、できるだけ多くの人達の助けを得ようとした方がよいでしょう。

8章ボランティアの管理 の「バグマネージャー」も参照してください。

IRC / リアルタイムに行なわれるチャットシステム

多くのプロジェクトでは、Internet Relay Chat (IRC) を使ったリアルタイムのチャットルームを提供しています。そこではユーザーと開発者が質問を出し合い、すぐに返事を貰うことができます。自前のIRCサーバを動かすことも 可能です が、普通はそこまで頑張る必要はありません。むしろみんながやっていることを真似てみましょう。つまり、Freenode (http://freenode.net/) で自分のIRCチャンネルを開設するのです。 Freenodeは、IRCサーバを自分で管理する苦労からあなたを解放すると同時に、 ^[20] プロジェクトのIRCチャンネルを管理するために必要な規制を行っています。

まずやるべきことはチャンネルの名前を決めることです。もっともわかりやすいのはプロジェクトの名前です。 — Freenode で使える名前なら使ってください。もし使えないのなら、プロジェクトの名前に近い名前で、できるだけ覚えやすい名前を選ぶようにしてみてください。質問に素早く答えて欲しいユーザーがすぐにわかるように、プロジェクトのウェブサイトでIRCチャンネルが利用できることを知らせましょう。たとえばSubversion のホームページでは、ページ上部の目立つボックス部分に次のような情報を表示しています。

Subversionをお使いなら、メーリングリスト users@subversion.tigris.org を購読し、 Subversionによるバージョン管理と FAQ を読むことを勧めます。 IRCの irc.freenode.net 上のチャンネル #svn でも質問することができます。

プロジェクトによっては複数のチャンネルを持つものもあり、ひとつひとつが副次的なトピックを扱っています。たとえばあるチャンネルはインストール時の問題を扱い、別のチャンネルでは使い方の問題、開発に関するチャット、等です。 (6章コミュニケーション の「巨大化への対応」では、チャンネルを複数に分割する方法について議論しています。) プロジェクトが始まって間もないなら、皆が一緒にお喋りできるようにチャンネルの数はひとつにすべきでしょう。後に開発者ひとりに対するユーザーの数が増えるのに応じて、チャンネルの分割が必要になるかもしれません。

どのチャンネルで喋ればよいかは言うまでもなく、利用できる全てのチャンネルを知らせるにはどうしたらよいでしょうか? そしてチャットをするとき、プロジェクトに特有の決まりごとを知らせるにはどうすればよいでしょうか?

答えは チャンネルトピック ^[21] を設定して知らせることです。チャンネルトピックは、初めてチャンネルに入ったときにユーザーが見るメッセージです。これは新顔のユーザーに簡単な案内をすると同時に、さらに詳しい情報へのポインタを提供します。たとえば以下のようなものです。:

あなたは #svn で喋っています。

#svn のトピックは以下の通りです。Subversionユーザーの質問を受け付ける
フォーラムです。http://subversion.tigris.org も参照してください。 || 
開発に関する議論は、#svn-dev で行われています。 || 長い Subversion の
トランザクションを貼り付けないでください。http://pastebin.ca/ のような
貼り付け用のサイトを使ってください。 || ニュース: Subversion 1.1.0 が
リリースされました。詳しくは http://svn110.notlong.com/ を参照してくだ
さい。

これは簡単ですが、新顔のユーザーが知る必要がある情報を伝えています。チャンネルの目的を正確に伝え、プロジェクトのホームページを示し(ユーザーによっては、プロジェクトのウェブサイトを訪れたことがないとチャンネル内で迷子になってしまいます。) 関連するチャンネルに言及し、貼り付けに関する案内もあります。

貼り付け用のサイト

IRCチャンネルは共有スペースです。誰でも他人の発言を見ることができます。これは貢献したいと思うときに会話に割って入れますし、他のメンバーはやりとりを見て学ぶことができるので普段はよい状態です。しかしデバッグセッションのコピーのように、大量の情報を一度に流さなければならない場合は問題になります。なぜなら、チャンネルにあまりに多くの行を貼り付けると他の会話をぶち壊してしまうからです。

こうした問題の解決策は、 ペーストビン または ペーストボット サイトを使うことです。大量のデータを他人から見てほしいと頼まれる時は、チャンネルに貼り付けないで、 (たとえば) http://pastebin.ca/ に行き、フォームにデータを入力して生成されたURLをチャンネルに伝えるように頼みましょう。そうすれば、そのURLを誰でも訪れてデータを見ることができます。

今ではたくさんの貼り付けサイトが無料で利用できますし、まとめて示すには数が多すぎますが、私が使われているのを見たことがあるサイトをいくつか以下に示します: http://www.nomorepasting.com/, http://pastebin.ca/, http://nopaste.php.cd/, http://rafb.net/paste/, http://sourcepost.sytes.net/, http://extraball.sunsite.dk/notepad.php, http://www.pastebin.com/

ボット

多くの技術指向なIRCチャンネルには、いわゆる ボット と呼ばれる人間でないメンバーがいます。これは特定のコマンドに反応して情報を保存したり、表示したりできます。通常は、ボットはチャンネルにいる他のメンバーと同じように扱います。つまり、コマンドはボットに "話しかける" ことで伝えます。たとえば次のようなものです :

<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita>  Thanks!

これはボット(ayita としてチャンネルにログインしています)に "diff-cmd" という問い合わせの答えとしてあるURLを覚えておくように伝えています。では、ayita に話しかけて、他のユーザーに diff-cmd に関する情報を伝えるように頼んでみましょう :

<kfogel> ayita: tell jrandom about diff-cmd
<ayita>  jrandom: http://subversion.tigris.org/faq.html#diff-cmd

便利な短縮コマンドを使っても同じことが実現できます。

<kfogel> !a jrandom diff-cmd
<ayita>  jrandom: http://subversion.tigris.org/faq.html#diff-cmd

正確なコマンドとそれに対する振舞いはボットによって異なります。上の例は Freenode の #svn で通常動いている ayita(http://hix.nu/svn-public/alexis/trunk/) のものです。他にも Dancer(http://dancer.sourceforge.net/) や Supybot(http://supybot.com/) といったボットがいます。ボットを動かすのに特別なIRCサーバ上の権限は必要ないということを覚えておいてください。ボットはクライアントプログラムなので、誰でもセットアップして特定の IRCサーバ/チャンネル上で待機させることができます。

あなたのチャンネルで同じ質問が繰り返される傾向があるなら、ボットをセットアップすることを強くお勧めします。ボットの操作方法を身に付けるのはほんの一握りのメンバーですが、ボットが効率的に反応してくれるので、少ない人数で繰り返される質問に答えられるのです。

IRCの会話を保存する

IRCチャンネルで起こったことは全て保存できますが、必ずしもそれが期待されているわけではありません。 IRCでの会話は建前上は公なものかもしれませんが、非公式なもの、もしくは半ばプライベートな会話だと考える人も多くいます。 IRC上ではユーザーは文法に無頓着ですし、オンライン上で絶対に保存されたくない意見(たとえば、他のソフトウェアやプログラマーに関するもの)を言ったりするかもしれません。

もちろん、会話のまとめ を保存すべき時もあるでしょう。その場合はよいのです。ほとんどのIRCクライアントはユーザーの要求に応じて会話を保存することが出来ますし、それができなくても会話をフォーラム(ほとんどの場合はバグ追跡システム)に貼り付けるだけならいつでもできます。しかし、節操なく会話を保存すると不安になるユーザーもいるかもしれません。全ての会話を保存するのなら、必ずその旨をチャンネルトピックで明示的に宣言し、保存先のURLを示すようにしましょう。

RSS フィード

RSS (Really Simple Syndication) は、ニュースの概要を表すメタデータを "購読者" に配信するための仕組みです。 "購読者" とは、その概要を受信したいという意思を示した人たちのことです。 RSS ソースのことを通常は フィード と呼びます。また、ユーザーがフィードを購読するインターフェイスのことを フィードリーダー や フィードアグリゲータ などといいます。オープンソースの RSS リーダーとしては、たとえば RSS Bandit や、そのまんまの名前である Feedreader などがあります。

ここでは、RSS についての技術的な詳細を説明することは控えます ^[22]が、次のふたつはしっかり覚えておきましょう。まず、購読者がフィードリーダーを使用すると、購読しているフィードを 同じように 扱えるようになります。これが RSS のセールスポイントのひとつです。何かひとつのインターフェイスを選択すれば、すべてのフィードが同じインターフェイスで使用でき、配信される内容に集中することができるというわけです。次に、RSS は今やあらゆるところで利用されており、ほとんどの人は知らず知らずのうちにそれを使用しているということです。世間一般の人たちにとっては、RSS というのはウェブページ上の "このサイトを購読" とか "ニュースフィード" とか言うちっちゃなボタンのことです。そのボタンをクリックすれば、フィードリーダー (ホームページに埋め込まれているアプレットかもしれません) は自動的にそのサイトのニュースの更新情報を取得してくれます。

これらを踏まえると、あなたが運営するオープンソースプロジェクトでもおそらく RSS フィードを提供しなければならなくなるでしょう (あらかじめ用意されているホスティングサイト — 「ツールが一通り揃ったホスティングサイト」を参照ください — の多くは、この機能を持っています)。一日になんどもニュースを投稿してしまわないように注意しましょう。そんなことをしたら、購読者たちはどれが本当に大切なニュースなのかを判断できなくなってしまいます。あまりにも大量のニュースが投稿されると、そのフィードを無視されてしまったり、あるいは腹が立ってそのフィードの購読をやめてしまうかもしれません。理想を言えば、用途に応じて個別のフィードを提供するのがいいでしょう。大事な告知用のフィード、たとえばバグ追跡システム用のフィード、メーリングリストの投稿用のフィードなとといった具合です。とは言え、実際にこれをするのは大変です。プロジェクトのウェブサイトを訪れる人たちにとっても、プロジェクトの管理者にとっても、何をどうしたらいいのか混乱してしまうことでしょう。しかし、少なくともプロジェクトのトップページには RSS フィードを提供するようにしましょう。このフィードでは、リリース情報やセキュリティ警告といった重要な告知を配信します。 ^[23]

Wiki

wiki とは、訪れた人が誰でもコンテンツを編集し、拡張できるウェブサイトのことです。 "wiki" (ハワイ語で "素早い" とか "超高速の"という意味です）という用語は、ウェブサイトの編集ができるソフトウェアを指すものとしても使われています。 wiki は1995年に発明されましたが、 2000年か2001年に人気が出て、 wiki ベースな無料の百科事典である Wikipedia(http://www.wikipedia.org/) の成功がそれを後押ししました。 wiki は、IRCとウェブサイトの中間的なものと考えればよいでしょう。 wiki は即時性がないので、自分が更新する内容について推敲することができます。それでいて更新も非常に簡単なので、通常のウェブサイトを編集するのに比べて、 HTMLに悩む負担が小さくなっています。

wiki はまだオープンソースプロジェクトで標準的なツールになっているわけではありませんが、多分すぐにそうなるでしょう。 wikiは比較的新しい技術ですし、人々は wiki をいろいろなやり方でまだ試しているところです。よって—今の段階では、 2,3警告をするだけにしておいて、 wiki の成功を分析するよりは、 wiki の間違った使い方を分析する方がわかりやすいでしょう。

wiki を使おうと決めたら、見通しの良いサイト構成にすることと、魅力的な見た目になるように特に力を注ぎましょう。これは訪問者（i.e. 編集する可能性がある人でもあります）が無意識にどのように編集したらよいかがわかるようにするためです。同じく重要なのは、人々を誘導できるように、こうした見た目やサイト構成に関する基準を wiki に投稿しておくことです。よくあるのは、 wiki の管理者が、「多くの訪問者が高い品質のコンテンツを個別に追加してくれているんだから、こうした更新が集まったウェブサイト全体も高い品質であるに違いない」という幻想に堕ちてしまうことです。多く更新されているからといって、ウェブサイトがうまく機能するわけではありません。個々のページや段落は、それ自体素晴らしいものかもしれませんが、全体が混乱したり、まとまっていないウェブサイトに紛れ込んでしまうと、そうではなくなるでしょう。 wiki を使うと、次のような事態によく悩まされます。

読者を誘導するルールが欠けている うまく構成されたウェブサイトは、訪問者がいつでもサイト内のどこにいるかをわかるようにしています。例えば、ページがうまく設計されていると、訪問者は"目次"の部分と、"内容"の部分を直感的に区別できます。 wikiのページを更新する人も、はじめからそういった区別がされていれば、それを尊重することでしょう。
情報が重複している wikiでは、更新を行なう個々の人達が、情報が重複しているかを気にしないので、似たようなことを述べている異なったページが複数存在することがよくあります。これは、上で述べた読者を誘導するルールが欠けていることとも重なる部分がありますが、情報が重複していると、訪問者は自分が期待するコンテンツのありかを見つけられないかもしれません。
対象読者が決まっていない これは、更新を行なう人が多くいる場合にはある程度避けられない問題です。しかし、コンテンツを追加する方法の指針があれば、この問題で苦しむ可能性は少なくなるかもしれません。また、更新に関する指針が根付くように、はじめから例としてコンテンツをたくさん追加しておくのもよいでしょう。

こうした問題に対する共通の解は同じです。: 編集に関する指針を作り、その指針を wiki に投稿するだけではなく、それに従ってページを編集することです。一般に wiki は、更新する人が自分が見るページのあらゆる傾向を真似てしまうため、もともと存在するページのあらゆる不備が全体に伝染してしまいがちです。 wiki をただセットアップするだけで、全てうまくいくと期待しないでください。まずは、人々を誘導するテンプレートとなるように、よく練られたコンテンツを置いておかなければならないのです。

うまくいっている wiki の良い例は Wikipedia ですが、これは、（百科事典の項目という）内容が本来 wiki のフォーマットとよく合っているからというのが理由のひとつです。しかし、Wikipedia をよく調べてみると、管理者達がお互いが協力するためにとても周到に準備をしていることがわかるでしょう。新しい項目を追加する方法、適切な観点で編集する方法、どのような編集を行なうべきか、避けるべきか、編集合戦にまつわる論争を解決するプロセス（ある段階では、最終的な調停も含みます）、などにまつわる外部文書が存在します。管理者達は、繰り返し不適切に編集されたページがあった場合に、問題が解決されるまでそれをロックできるようアクセス制御も行なっています。言い換えれば、彼らはウェブサイトにページの雛形を書き込むだけで、うまくいくと思っていたわけではないということです。 Wikipedia は、創始者達が、どうしたら何千ものどこの馬の骨ともわからない人たちに、中立的な観点で記事を書かせることができるかを注意深く考えたからこそうまくいっているのです。フリーソフトウェアのプロジェクトで wiki を使うのに、これと同じくらい周到になる必要はないかもしれませんが、その精神は真似る価値があります。

wikiに関するさらに詳しい情報は、http://en.wikipedia.org/wiki/Wiki を参照してください。また、世界で最初のwikiはまだ健在で、wikiの運用に関する多くの議論が含まれています。 : 様々な観点から、http://www.c2.com/cgi/wiki?WelcomeVisitors, http://www.c2.com/cgi/wiki?WhyWikiWorks, そして http://www.c2.com/cgi/wiki?WhyWikiWorksNot を参照してみてください。

ウェブサイト

技術的な観点からプロジェクトのウェブサイトを立ち上げることについては、それほど語ることはありません。ウェブサーバを起動し、ウェブページを書くことはかなり単純な仕事ですし、ページの配置や設計に関して重要なことはほとんど以前の章で述べました。ウェブサイトの主な機能は、明快にプロジェクトの概要を提供し、 (バージョン管理システム, バグ追跡システムなどの)他のツールをウェブサイトと結びつけることです。たとえあなたにウェブサーバを設定して起動する技量がなくても、その作業を喜んでやってくれる人を探すことは普通難しくありません。とはいえ、時間と労力を節約するために、プロジェクトを運営するためのツールが一通り揃っているホスティングサイトがよく好んで使われます。

ツールが一通り揃ったホスティングサイト

一通りのものが揃ったホスティングサイトには、主に二つの利点があります。ひとつめは、サーバのディスク容量とネットワーク帯域の太さです。つまり、超高速なネットワーク上に、複数のサーバマシンが巨大なラックに収納されているのです。プロジェクトがどれだけ成功しても、ディスク容量を使い切ったり、ネットワーク接続が使い物にならなくなることはないでしょう。ふたつめは、サイトの維持が簡単なことです。ホスティングサイトは、バグ追跡システム、バージョン管理システム、メーリングリスト管理システム、アーカイバや、プロジェクトのウェブサイトを運営するのに必要ものを全て選んでくれています。また、それらは既に設定済みであり、蓄積される全てのデータのバックアップにも注意を払ってくれます。多くの決断をする必要はありません。フォームに入力し、ボタンを押しさえすればよいのです。そうすれば巨大なプロジェクト用ウェブサイトが突然手に入ることでしょう。

これらはとても重要な利点です。勿論、他のツールでよいものがあったとしても、 ホスティングサイトが 選択したツールや設定を受け入れなければならないという欠点があります。ホスティングサイトは、設定できるパラメータの範囲を普通狭くしているので柔軟性がありません。自前でウェブサイトを立ち上げてサーバへの完全な管理権限を持っていた場合にできる、きめの細かい制御は決してできないでしょう。

このことのよい例が、自動生成されるファイルの扱いです。あるプロジェクトのウェブページは、自動生成されたファイルかもしれません — たとえば、FAQのデータを編集しやすいマスターフォーマットに保存し、それからHTMLやPDF、その他表示用のフォーマットを生成するシステムがあるとします。この章の「すべてをバージョン管理する」で説明したとおり、あなたは自動生成されたフォーマットではなく、マスターファイルだけをバージョン管理したいと考えるでしょう。しかしウェブサイトが他人のサーバに置いてある場合は、マスターファイルが変更された場合にFAQのHTML版を再生成するカスタムフックを設定できないかもしれません。唯一の回避策は、ウェブサイトで表示できるように自動生成されたフォーマットもバージョン管理することです。

もっと大きな影響があるかもしれません。あなたが望むほどウェブサイトの見た目を変える権限がないかもしれません。ホスティングサイトの中には、ウェブページをカスタマイズすることを許可してはいますが、結局はデフォルトの配置がうんざりするようなやり方で表示されてしまうものもあります。たとえば、SourceForge がホスティングしているプロジェクトの中には、完全にカスタマイズしたホームページがあるけれども、詳しい情報を参照させるために "Sourceforge上のページ" に開発者を誘導しているものがあります。 SourceForge のページは、プロジェクトのホームページになるはずのものでしたが、ユーザーに自前のホームページを使わせないようにしています。 SourceForge のページには、バグ追跡システムやCVSリポジトリ、ダウンロードサイトへのリンクなどがあります。不幸なことに、SourceForge のページにはたくさんのプロジェクトとは無関係なリンクも含まれているのです。ページの一番上部にはバナー広告がありますが、アニメーション画像であることもよくあります。左側にはプロジェクトに興味がある人には殆ど関係がないリンクが垂直に配置されています。右側には別の広告がよく配置されています。ページの中央部分だけが本当にプロジェクトに特有の事項に専用の場所になっていますが、これらもわかりにくい方法で配置されているので、訪問者が次にどこをクリックしたらいいのかわからなくなってしまうことがよくあります。

SourceForge のページ設計の裏には、きっと — 広告のように、 SourceForge の立場からすれば尤もな理由があるのでしょう。しかし、プロジェクトの立場から見れば、その結果が理想のウェブページとはかけ離れたものになるかもしれません。私は SourceForge を非難するつもりで言っているのではありません。似たような懸念は多くのホスティングサイトにも当てはまります。重要なのは、トレードオフが存在するということです。プロジェクトのウェブサイトを維持するための技術的な重荷から解放されますが、他人のやり方を受け入れることとひきかえにはじめて恩恵を受けられるのです。

ホスティングサイトがプロジェクトに最適かどうかを決められるのはあなただけです。仮にホスティングサイトを選んだ場合、プロジェクトの"ホームとなるURL"に自前のドメインを使うことで、自前のサーバに移行する余地を残しておくようにしましょう。自前のURLをホスティングサイトに転送することもできますし、公開されているURLに完全に手を加えたホームページを置くことで、ユーザーを洗練された機能を持ったホスティングサイトに誘導することもできます。ウェブサイトのホスティングについて後に別の解を選んだとしても、プロジェクトのURLは変えないように確実に準備をしておくようにしましょう。

ホスティングサイトを選ぶ

2011年が始まった現時点で、自由につかえるホスティングサイトとして定評のあるのは次の三つです。これらはすべて、オープンソースライセンスで公開するプロジェクト用に無料で使うことができます。また、バージョン管理システムやバグ追跡システム、そして Wiki も用意されています (バイナリのダウンロード機能など、その他の機能を用意しているところもあります)。

GitHub 対応しているバージョン管理システムは Git だけですが、もし自分のプロジェクトで Git を使っているのならここを選ぶのが適切でしょう。GitHub は Git を使ったプロジェクトの世界の中心となっており、各種サービスも Git と統合されています。また GitHub には、プログラムからそのサービスを利用するための API も完備されています。メーリングリストはありませんが、メーリングリストのサービスは他にもいろいろあるのでたいした問題にはならないでしょう。
Google Code Hosting 対応しているバージョン管理システムは Subversion と Mercurial (少なくとも現時点では Git は未対応) で、 Wiki やダウンロードエリア、そしてよくできたバグ追跡システムも用意されています。また、API もあります。バージョン管理システムには当然ながらそれ自身の API があり、問題追跡システムにも専用の API があります。Wiki のコンテンツはバージョン管理システムと連動しているので、スクリプトから編集することができます。また、ダウンロードエリアにもスクリプトによるアップロードという名の API が用意されています。また、メーリングリストとして Google Groups が使えます。
SourceForge これは最も古くからあるホスティングサイトで、古くからあるだけあって今でも規模が最大です。他の二つのサイトが用意する機能をすべて備えており、インターフェイスも非常に使いやすいものです。しかし、プロジェクトのページに表示される広告ブロックが気になるという人もいます。現時点では、ホスティングサイトの三巨頭の中で唯一、主要なバージョン管理システム (Git、Subversion、Mercurial そして CVS) のすべてに対応しています。 SourceForge にはメーリングリストサービスも用意されていますが、もちろん他のメーリングリストサービスを使うこともできます。

Apache Software Foundation のように、自分達の任務と既にあるプロジェクトのコミュニティーにうまく合っているオープンソースプロジェクトを無料でホスティングしている組織もあります。

どれにすればいいかわからない場合は、これら三巨頭のいずれかを選ぶことを強くおすすめします。もう少し詳しく言うと、もしバージョン管理システムに Git を使っているのなら GitHub を、それ以外を使っているのなら Google Code Hosting を使うといいでしょう。 SourceForge も悪くありませんが、現時点で敢えて SourceForge を選ぶ特筆すべき理由はありません。また広告も気になります。

お気づきの人も多いでしょうが、フリーなホスティングサイトの多くは、そのサイト自身を構成するソフトウェアをフリーソフトウェアのライセンスで公開していません (公開しているサイトとしては Launchpad や Gitorious そして GNU Savannah があります)。個人的には、サイト自身を構成するソフトウェアのすべてのコードにもアクセスできるのが理想だと考えます。自分のデータをエクスポートしたり、自分のデータの操作を自動化させたりできるということが重要だからです。そのようなサイトであれば決してそこにロックインされることがなくなり、さらにプログラムを通じて拡張可能になります。ホスティングサイトを動かすためのすべてのコードをオープンソースで入手することにはそれなりの価値があります。とはいえ、実際にそのコードを運用するということはほとんどのユーザーにとって無理な話です。これらのサイトには何台ものサーバーやカスタマイズしたネットワーク、そして専任スタッフが必要になります。いずれにせよ、単にコードを持っているだけでは、サービスを複製したり「フォーク」したりするのは無理なのです。大事なのは、自分のデータがしばられてしまわないのを確実にするということです。

Wikipedia にホスティングサービスの比較 (日本語) の記事があります。オープンソースプロジェクトのホスティング環境の最新情報については、まずここを見るとよいでしょう。また、Haggen So は、博士論文 Construction of an Evaluation Model for Free/Open Source Project Hosting (FOSPHost) sites の研究の一環としてさまざまなホスティングサイトを評価しました。発表されたのは 2005 年ですが、2007 年に更新されています。この評価基準は今後も長く使えるでしょう。彼の調査結果は http://www.ibiblio.org/fosphost/ にあり、比較結果の表は http://www.ibiblio.org/fosphost/exhost.htm です。

possv2 24 March 2013: If you're reading this note, then you've encountered this chapter while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 todo: Note the possibility of mixing services from different canned hosting sites. Also, talk about the importance of APIs for an exit export. Mention the Google Groups conundrum. Maybe replace some of the above commentary with a reference to 付録A Canned Hosting Sites.

匿名性とプロジェクト参加

厳密にはホスティングサイトに限った問題ではないのですが、ホスティングサイトで最もよく見られるのが、ユーザーログインの機能に関する苦情です。ログイン機能自体は十分単純です。ウェブサイトでは、訪問者が自分のユーザー名とパスワードを登録することができるのです。登録するとユーザーのプロフィールが保存され、プロジェクトの管理者は、ユーザーにリポジトリへのコミット権限のような特定の権限を与えることができます。

この機能は非常に有用で、ホスティングサイトの主な利点のひとつです。問題は、未登録のユーザーにも許可されるべきタスク、特にバグ追跡システム内のファイルアップロードや、既存の問題にコメントをつけるときに、往々にしてログインが必要になってしまっている点にあります。こうしたタスクにログインを必要としてしまうと、本来迅速で便利であるべきタスクに参加する敷居が高くなってしまいます。勿論、バグ追跡システムにデータを登録した人に連絡を取りたい人もいますが、その場合は(本人が望んだ場合に)電子メールアドレスを入力できるフィールドを設けておけば十分です。新しいユーザーがバグを発見して報告したいと思ったとして、バグ追跡システムに入力する前にアカウント作成フォームを入力しないといけないとわかればうんざりするでしょう。そのユーザーは結局バグを登録しないかもしれません。

ユーザーを管理する利点は、通常は欠点に勝るものです。しかしユーザーを匿名で行動させる選択肢があるなら、 全ての 読み取り専用のアクションだけでなく、特にバグ追跡システムや、持っているならwikiページのデータ入力についても、ログインしていないユーザーに許可するようにしましょう。

Social Networking Services

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 tbd: subsections for Twitter, Facebook, any others. Twitter is useful; Facebook appears not to be so relevant to open source projects but check this with people who use it more. Identi.ca (if will persist). Others? Eventbrite (mention from "meeting-in-person" section), what else? Acknowledge that many of these services are not open source; times have changed, the train has left the barn or the horse has left the station or whatever.

^[15] 1975 年に出版された彼の著書 The Mythical Man Month (邦題:「人月の神話」) に登場した法則。 http://en.wikipedia.org/wiki/The_Mythical_Man-Month および http://en.wikipedia.org/wiki/Brooks_Law ( 日本語) を参照してください。

^[16] 本書の出版直後に Michael Bernstein が教えてくれました。"Mutt 以外にも、 reply-to-list 機能を実装しているメールソフトがあります。たとえば Evolution では、キーボードショートカット (Ctrl+L) でこの機能を使用できます。でもボタンはありません。"

^[17] その後、この機能をサポートするメーリングリスト管理ソフトがあることを知りました。 Siesta というものです。 http://www.perl.com/pub/a/2004/02/05/siesta.html の記事も参考になるでしょう。

^[18] その証拠としては http://cia.vc/stats/vcs や http://subversion.tigris.org/svn-dav-securityspace-survey.html があります。

^[19] configure ファイルをバージョン管理するか否かについては、別の見方もあります。Alexey Makhotkin の記事 "configure.in and version control" が、次の URL で見られます。 http://versioncontrolblog.com/2007/01/08/configurein-and-version-control/

^[20]Freenode への寄付を要求されたり、期待されたりすることはありませんが、あなた個人やプロジェクトに余裕があるなら寄付することを考えてみてください。アメリカ国内からだと税金が控除される寄付金として扱われますし、寄付されたお金を使って価値のあるサービスが提供されるのです。

^[21] チャンネルトピックを設定するには /topic コマンドを使います。 IRCコマンドは全て "/" で始まります。 IRCの使い方やチャンネルの管理に慣れていないのであれば、 http://www.irchelp.org/ を参照してください。: 特に http://www.irchelp.org/irchelp/irctutorial.html は優れたチュートリアルです。

^[22] 詳細は http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html をご覧ください。

^[23] このセクションは、書籍として出版された初版には存在しません。 Brian Aker のブログのエントリ "Release Criteria, Open Source, Thoughts On..." を読んで、オープンソースプロジェクトにおける RSS フィードの有用性に気づいたので追記しました。

第4章プロジェクトの政治構造と社会構造

優しい独裁者

誰がよき「優しい独裁者」になれるか？

合意に基づく民主主義

バージョン管理を行なうと堅くならずに済む
合意に至らなければ投票する
いつ投票を行なうべきか?
誰が投票するのか?
世論調査 v.s 投票
拒否権

全てを記録しておく

Joining or Creating a Non-Profit Organization

フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう仕組みで動くの？プロジェクトを維持しているものは何？誰に決定権があるの？" といったものです。私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、などについて当たり障りなく答えて、いつも釈然としない思いがします。実のところ、こうした質問に答えるのは簡単ではありません。実力主義、協力、そして動くコードは全て答えの一部ではありますが、日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。

この章では、成功しているオープンソースプロジェクトに共通している、基本的な仕組みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、プロジェクトが健全に運営されており、生き残る力が強いことを言います。新しいコードや開発者を受け入れたり、バグレポートに素早く反応することを継続できていれば、プロジェクトは健全に運営されているといえます。特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、生き残る力が強いといえます。 — プロジェクトを立ち上げたメンバー全員が他に移ったとしても、プロジェクトが生き残る可能性があるかを考えてみてください。 ^[24] 技術的に成功することは難しくありません。しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、プロジェクトが初期段階で成功して膨張したり、カリスマ的な人がいなくなったときに、対応できないかもしれません。

オープンソースプロジェクトを成功させる方法はたくさんあります。議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、新しい機能を企画するなどの、型にはまった統治の仕組みもあれば、形になって表れないものとして、メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、より意識的に自制することも含まれます。プロジェクトは、参加する人達がよく理解している習慣や手続きに支えられて存続するという意味で、どちらも行き着くところは同じです。これらの方法は、中央集権的なプロジェクトより、自発的に成長するプロジェクトで重要になります。自発的に成長するプロジェクトでは、少なくともしばらくは、よくないことが全体に影響することを参加する人が意識しているからです。

プロジェクトが分裂する可能性

開発者をフリーソフトウェアプロジェクトに繋ぎ止め、必要な時に妥協してもらうのに不可欠な要素は、コードが 派生する ことです。つまり、誰かがソースコードのコピーを使って、新しい競合プロジェクトを立ち上げることです。これは フォーク という用語でも知られています。逆説的なのは、プロジェクトが分裂する 可能性 の方が、まれながら実際に分裂することよりも、フリーソフトウェアプロジェクトにとって大きな力になるということです。プロジェクトが分裂することは万人にとってよくないことなので、 (詳細な理由は、8章ボランティアの管理 の「プロジェクトの分裂」で述べています。) その恐れが大きくなればなるほど、人々はそれを避けようとして妥協する可能性が大きくなります。

プロジェクトが分裂すること、いやむしろその可能性と言った方がよいでしょう。この可能性こそが、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由になっています。これはオープンソースプロジェクトで "独裁者" とか "暴君" と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。しかし、この手の "暴政" という言葉は特別なもので、伝統的に理解されている暴政の意味とは違うものです。いつでも自分の王国をコピーでき、いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？するはずがないですよね。

そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、重要な決定をする段になると民主主義の仕組みを使います。コードを複製できるということは、それを使って競合プロジェクトを立ち上げ、プロジェクトを分裂させられるということです。プロジェクトが分裂させられるということは、それを避けるために合意が形成されることを意味しています。全員がひとりのリーダーに従うこと（もっとも有名な例が、Linux kernel 開発の Linus Torvalds です）もあるかもしれませんが、これは完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを 選んでいる からです。独裁者がプロジェクトを魔法のように支配しているわけではないのです。全てのオープンソースライセンスに当てはまる、鍵となる性質は、コードの変更のしかたや、使用方法について、特定の集団を差別しないということです。仮に独裁者が突然よくない決断をしはじめたとしましょう。その場合不穏な空気が漂い、結局反乱が起きてプロジェクトが分裂してしまいます。もちろん、そこまでひどくなることは滅多にありません。そうなる前に独裁者のほうが譲歩するでしょうから。

しかし、プロジェクトが分裂することがプロジェクトで権力を行使することに歯止めをかけているからといって、プロジェクトを統率するやり方に重大な違いがあるわけではありません。決断をするたびに、競合プロジェクトを立ち上げようと思ってる人いる？と質問したくはないはずです。そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。次のふたつのセクションでは、ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。そこではふたつ例をあげていますが、いささか極度に理想的なものです。多くのプロジェクトは、ふたつの状態の間のどこかに位置しているのです。

優しい独裁者

優しい独裁者(Benevolent Dictator) モデルとは、正確には次のようなものです。つまり、最終的な決断を行う権限が、人格や経験が優れているという理由で、賢明に権限を行使できるひとりの人に委ねられていることです。

"優しい独裁者" （略して BD ともいいます）という言葉は、こうした役割に対して標準的に使われる用語ですが、むしろ "コミュニティーが認めた調停者" もしくは "審判" と考えた方がいいでしょう。一般的には、優しい独裁者が実際に全ての、もしくはほとんどの決定を行っているわけではありません。ある人がプロジェクトの全ての領域に渡って、優れた決断を一貫して行う十分な技能があることはまれです。そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、結局プロジェクトから去ってしまいます。よって、優しい独裁者は普通多く指示を出したりはしません。むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。優しい独裁者は議論そのものには参加しますが、普通の開発者として、自分より優れた技能を持つメンテナーの領域では、たびたび彼らに従います。結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に 望んでいる 場合だけ、彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。命令することで決定するのを我慢するのは、成功している優しい独裁者に事実上共通する特性です。これが、彼らが優しい独裁者という役割を維持している理由のひとつなのです。

誰がよき「優しい独裁者」になれるか？

優しい独裁者になるには複数の特性が必要です。まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、これは言い替えれば自制を働かせるということです。議論の最初の段階では、自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。だから、自分が悪い決断を下したときに、それを認識し、受け入れる能力も必要になるのです。— ですが、この資質は優れた開発者であれば、特にプロジェクトに長い間留まっている人であればなおさら 誰でも 持っているはずの資質にすぎません。しかし、優しい独裁者が違うのは、自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、たびたび間違いを犯す余裕があることです。年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。だからこそ優しい独裁者は、技術的な面でも精神的な面でも、自分の言葉が伝える重みに敏感になって、批判をしたり反対意見を述べるべきなのです。

優しい独裁者は、プロジェクトにいる誰よりも技術的なスキルが優れている必要は ありません。コードを書く能力に十分優れ、コードに加えられたあらゆる変更を理解し、思いやりをもってそれにコメントしなければいけませんが、それだけです。優しい独裁者の立場は、誰かから教わって得たものではありませんし、コードを書くスキルが恐ろしくあるという理由で得たものでもありません。 重要なのは 経験と総合的な設計センスです。— 必要に応じて優れた設計を生み出す能力ではなく、優れた設計をソースコードから認識する能力なのです。

優しい独裁者は、プロジェクトの創始者であることが普通です。しかし創始者であることは、優しい独裁者となる原因以上の相関関係はありません。正確にいうと、プロジェクトをうまく始められる資質 — 技術的なスキル、他の人をプロジェクトに参加するよう説得できること、などなど — が、優しい独裁者になるのに必要な資質です。そしてもちろん、創始者は自動的にプロジェクトの古株としてスタートするので、そのことで優しい独裁者への道が殆ど抵抗なしに開かれることは往々にしてあり得ます。

プロジェクトが分裂する可能性が二つあることを忘れないでください。優しい独裁者は他の人と同様、容易にプロジェクトを分裂させられますし、大多数の開発者が望んでいるプロジェクトの方向性が、自分が望むものと違っていると感じたときは、時折優しい独裁者以外の人もそうすることがあります。コードはコピーできるので、優しい独裁者がプロジェクトのメインサーバの root 権限（システム管理者の権限）を持っているかどうかは問題になりません。人によっては、サーバの管理権限を持っていることがプロジェクトの最終的な権限の源であるかのように話すひとがいますが、実際は無関係です。ある特定のサーバで開発者のコミットパスワードを追加したり、削除したりできる権限は、そのサーバにあるプロジェクトのコピーにのみ影響します。そうした権限に関する苦情が、優しい独裁者や他の開発者かどうかに関係なく長期間続くと、単に開発が他のサーバに移っていくだけです。

プロジェクトに優しい独裁者がいる方がうまくいくか、中央集権をいくらか緩めた仕組みの方がうまくいくかは、役割を果たす人達がどれだけいるかにかかっています。一般的なルールとして、優しい独裁者に誰がなってもいいことが明らかな場合は、そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、次のセクションで述べる分権的な決定プロセスを使うべきでしょう。

合意に基づく民主主義

プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、より開かれた民主主義的なプロセスに移行します。これは特定の優しい独裁者に必ずしも満足していないからではありません。単にグループ主体の統治の方が、生物学のメタファーを借りて言えば "進化的に安定している" からです。優しい独裁者が身を引いたり、決定する権限を多くの人に平等に与えようとするときはいつでも、グループが新しい、独裁的でない仕組みに移行する機会になります — これは言ってみれば組織化を行うということです。開発者のグループは最初の1、2回はこの機会を利用しませんが、結局は利用することになります。いったんそうしてしまえば、もとの仕組みに戻ることはありません。何故かは常識でわかることです。仮に N人からなるグループが、ある人に特別な権限を与えていると仮定すると、 N - 1 人が自分の影響力を弱めることに合意していることになります。独裁的でない仕組みでは、普通特別な権限を特定の人に与えたいとは思いません。たとえ望んだとしても、結果として行使できる権力は条件付きのものになります。優しい独裁者を任命しても、これは明らかなことですが、グループが後に辞めさせてしまうことができるからです。それゆえに、プロジェクトがいったんカリスマ的な人のリーダーシップをとる仕組みから、より型にはまったグループベースの仕組みに移行すれば、滅多に元に戻ることはないのです。

こうした仕組みがどう機能するかを詳細に見ていくと、中身は変化に富んでいますが、共通した要素が二つあります。ひとつは、グループはほとんどいつも合意に基づいて動くこと。ふたつめは、合意に達しないときに投票の仕組みを使うことです。

合意とは、皆が受け入れようと一致することです。これはあいまいな状態ではありません。誰かが合意に達したんじゃないかと提案し、それに対して誰も反対を表明しない場合、あるグループは合意に達したといえます。合意に達したんじゃないかと提案する人は、合意とは何かということと、仮に明らかでない場合は、合意の結果どのような行動をとるのかを具体的に述べるべきです。

プロジェクトで交わされるほとんどの会話は技術的な話題です。たとえば、正しくバグを直す方法とか、ある機能を追加するか、しないか、プログラムのインターフェイスをどの程度厳密に文書化するか、などです。合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。議論が終わるまでに、どの方向性をとるかについて合意がよく成立します。通常は議論を終了するという投稿をし、同時に何が決まるのかをまとめた上で、合意に達したよねと暗に提案します。これが "待った！俺は反対だ。もう少し徹底的に話し合う必要があるね。" と言える最後の機会を与えているのです。

規模が小さく、議論に値しない事柄を決めるときは、合意に達したという提案も暗黙に行われます。たとえば、開発者がバグ修正を自発的にコミットした場合、そのコミット自体が合意に達したことを提案することになります。つまり、"このバグは直す必要があり、この修正が正しいやり方だと皆が合意したと見做すよ" と言っているのです。もちろん、開発者は実際にそんなことを言っていません。彼はただ修正をコミットしただけですし、他の開発者はわざわざ同意すると口に出して言ったりしません。なぜなら黙っていることは合意することだからです。コミットされた修正が、合意を得られないと判明した場合、プロジェクトではそれがまだコミットされていないかのように議論されます。このやり方がうまく行く理由は次のセクションで述べていきます。

バージョン管理を行なうと堅くならずに済む

プロジェクトのソースコードがバージョン管理されているということは、ほとんどの決定が元に戻せるということを意味します。変更を元に戻す原因としてよくあるのが、皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、これは結局コミットした後に反対意見が出てくることになります。こうした反対意見は決まって、以前の議論を見逃したことを詫びることから始まりますが、反対する人がメーリングリストのアーカイブにこれにあたる議論を見つけられなかった場合は省略されます。どちらにせよ、変更がコミットされる前と後とで議論の口調を変える理由はありません。少なくとも、あるコミットに依存する変更が行われた時点（i.e. もともと加えられていた変更が突然削除され、新しい変更がそれを壊していた場合）まで、変更は取り消すことができます。バージョン管理システムは、プロジェクトにとってよくない、または性急な判断から生じた結果を元に戻す手段を与えているのです。これは言い替えれば、開発者が何かをする前にどのくらいのフィードバックが必要かということを、自分の直感を信頼して判断してよい、ということでもあります。

このことは、合意を得る手続きを型にはめる必要がないということでもあります。ほとんどのプロジェクトはこの手続きを感覚で扱っています。小さな変更は、議論をしないか、最小限の議論だけして、2、3の賛成があったあとに行われます。より重要な変更、特に多くのコードを不安定にさせる変更については、開発者達は合意に達した、つまり単にメールを頻繁にチェックしていなかっただけの理由で重要な議論をないがしろにしたヤツはいないはずだ、という合理的な根拠があるとみなす前に、１日か２日の間を置くべきです。

というわけで、自分がやるべきことを理解しているのなら、単に作業を進めてやり遂げるべきです。これはソフトウェアの修正だけでなく、ウェブサイトの更新、ドキュメントの変更、そして議論になりそうにない他のあらゆることに当てはまります。通常、とられたアクションを元に戻す必要がある事例は少ししかないでしょうし、そうした事例はケースバイケースで扱えます。もちろん、聞く耳を持たないことを奨励すべきではありません。議論中の事項と、既に実行されて効果が表れている決定事項の間には、いくら技術的に元に戻せるとはいっても精神的な差があります。開発者達は勢いが行動に繋がるといつも思っていますし、実際に行われた変更を元に戻すのは、はじめに変更するのをやめさせるほど、気が進まないものです。ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、他の開発者達は文句を言えますし、言うべきです。そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。

合意に至らなければ投票する

議論によっては、結論がでないことが必ずあります。行き詰まった状態を打開するあらゆる手段が失敗に終わった場合、投票が打開策になります。投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。ここで、普段やっている技術的な議論をしてみると、結論を出す手続きと意外によく合っていることが再びわかるでしょう。投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。こういう複雑な議論では、 仲裁人 の役割を果たす人が普通ひとりかふたりはいます。彼らは定期的にさまざまな主張をまとめたものをポストし、反対（賛成）意見の核がどこにあるのかを追いかけています。こうしたまとめは、議論がどの位進んでいるのかを知ったり、どういう問題に取り組んでいるのかを覚えておくのに役立ちます。また、実際に投票が必要になった場合に、投票用紙のひな型として役立つかもしれません。仲裁人が仕事をうまくこなせば、時が来れば皆に投票しましょうと呼びかけることもできるでしょうし、プロジェクトは彼らが作ったまとめをベースにした投票用紙を使うことができるでしょう。仲裁人自身は、議論に参加していても構いません。つまり、対立する人の意見を理解し、中立的に表現でき、自分の同志の気持ちが議論を中立的にまとめるのを妨げなければ、賛成、反対の立場を超越した立場にいる必要はないのです。

投票用紙の実際の内容は、議論の余地がないものになるのが普通です。投票が実際に行われるまでに、反対意見は２、３のキーとなる問題にまとめられ、理解できるラベルや簡単な説明が付けられます。開発者が投票用紙の形式そのものに反対する場合もあります。そういう人は、たとえば重要な選択肢が抜けていたり、選択肢に対する正確な説明がないといった、投票が正しいものかどうかを心配していることがありますが、投票によって出る結論が自分の望むものに絶対ならないことを多分知っていて、投票を避けようとしているだけの場合もあります。この手の妨害行為をどう扱うかは、 6章コミュニケーション の、「扱いにくい人たち」を参照してください。

投票システムを必ず決めるようにしましょう。なぜなら、投票システムにはたくさんの種類があり、どういった手続きがとられるのかについて参加者が間違った想定をしている可能性があるからです。ほとんどの場合に適しているのは 認定投票 です。このシステムでは投票者が自分が好む選択肢をできるだけ多く投票できます。認定投票は説明するのも、得票数を数えるのも簡単ですし、他の方法と異なり、一回の投票で済みます。認定投票と他の投票システムの詳細については、 http://en.wikipedia.org/wiki/Voting_system#List_of_systems を参照してください。しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。（当然、投票システムを決めるのにどの投票システムを使うかを議論することになるからです！）認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。 — つまり、投票システムはできるだけ公平であるべきということです。

最後に、投票は公開の場で行いましょう。どちらにせよ、公開の場で議論した問題について、秘密投票にしたり、匿名投票にしたりする必要はありません。オブザーバが投票を記録し、結果をチェックできるように、そしてすべてをアーカイブに記録するために、投票の参加者には、プロジェクトのメーリングリストに自分の投票をポストさせるようにしましょう。

いつ投票を行なうべきか?

投票で最も難しいのは、いつ投票を行うかです。一般的には、投票に実際に踏み切ることは滅多にすべきではありません— つまり、他のあらゆる手段が失敗したときの最後の手段にすべきです。投票が議論を解決する素晴らしい手段だと看做さないでください。実際、そうではないのです。投票は議論を終結させ、それによって問題について創造的に考えることもやめさせてしまうのです。議論が続いている限り、皆が好む新しい解決策を誰かが思い付く可能性があります。これは驚くほどたびたび起こります。活発な議論は、問題について新しい考え方を生み出しますし、結局皆を満足させる提案にも繋がります。たとえ新しい提案が生まれなくても、投票を行うよりは、妥協案を仲介してもらった方が通常はまだマシです。妥協したあとは、皆がちょっと悲しい思いをします。一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。政治的な観点からは、前者の方が好ましいといえます。なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。満足はしないかもしれませんが、それは他の誰もが同じなのです。

投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、頭数で問題を解決してしまいます。私は、オープンソースプロジェクトで経験を積めば積むほど、人々が問題を投票によって解決したがらなくなるのがわかってきました。むしろ、以前考えたこともない解決策を探ったり、もともとの計画よりも厳しい妥協をしようとします。早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、 "まだ投票を実施する段階ではないと思うよ。" といって、何故かを説明することです。別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。その反応が明らかに一方に偏っていたら、正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、新しい解決策や、以前の提案に基づいた新しい視点を示すことです。

まれなケースとして、示された全ての妥協案は、妥協していない全ての案よりも劣っていることで全員が一致することがあります。この場合、投票を実施することに反対しにくくなります。なぜなら、投票の方がより優れた解決に繋がる可能性がありますし、どのような結果になっても全員が過度に悲しい思いをすることはないからです。たとえそうであっても、投票を急ぐべきではありません。投票に至るまでの議論は有権者にいろいろなことを教えるので、議論を早い段階でやめてしまうと、投票の結果出てくるものの質が悪くなるかもしれません。

（投票をしたがるなというアドバイスは、 7章パッケージの作成、リリース、日々の開発 の「リリースを安定させるプロセス」で説明している、ソースコードに大幅な変更を加える投票には当てはまりません。そこでは、投票は対話のメカニズムとして働き、有権者を変更をレビューする手続きに参加させる手段となります。それによって、有権者は与えられた変更がどの程度のレビューを経ているのかを区別することができるのです。）

誰が投票するのか?

投票システムを使うとなると、有権者に関する疑問が出てきます。誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。なぜなら、どの人が熱心にプロジェクトに参加しているかとか、どの人がよりよい判断を下せるか、ということをプロジェクトに公式に認めさせることになるからです。

一番よいのは、既にある権限の区別、つまりコミット権限を単純に利用し、その権限に投票権限も付加することです。完全なコミット権限と、限定的なコミット権限を提供しているプロジェクトで、限定的なコミット権限を持つ人に投票権を与えるかどうかは、コミット権限を与える手続きがどのようなものかに大きく依存します。たくさんのサードパーティーのツールをリポジトリで管理させるようなやり方で、プロジェクトがコミット権限を気前よく配分している場合、限定的なコミット権限が単にリポジトリにコミットする権限だけで、投票権限はないことを明確にすべきです。逆に考えると、同じことが当然当てはまります。つまり、完全なコミット権限を持つ人には投票権限もあるのだから、彼らはプログラマーとしてではなく、投票権限のあるメンバーとして選ばれなければならない。ということになります。メーリングリスト上で破壊的な発言をしたり、プロジェクトを妨害する傾向がある人がいる場合は、プロジェクトはたとえその人が技術的に優れていたとしても、コミット権限を与える際に注意する必要があります。

完全なコミット権限にせよ、限定的なものにせよ、新しいコミッターを選ぶには投票システムを使うべきですが、この場合は秘密投票が適切になるまれな事例のひとつです。コミッターになる可能性がある人について、メーリングリストで投票を行うことはできません。なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。代わりに普通使われるのは、コミッターのみで構成されるプライベートなメーリングリストに、コミット権限を与える提案をし、それに対して既にいるコミッターが投票する方法です。他のコミッターはそこで行われる議論がプライベートなことを知っているので、自分の思うところを自由に述べていきます。そこで反対意見が出ないために、投票が必要ないこともあります。他のコミッターに反対意見を述べるチャンスを必ず与えるために２、３日待ったあと、提案者はコミッターになる候補者にメールしてコミット権限を与えます。反対意見があった場合は、他の問題と同じように議論が行われ、おそらく投票が行われるでしょう。このプロセスをオープンかつ率直なものにするにせよ、議論はとにかく非公開で行うべきです。コミット権限を与えようと考えている人が、何が起きているのかを知っていて、権限を貰えなかった場合、自分は投票権も失ったんだと決めつけてしまったり、傷ついてしまう可能性もあるでしょう。もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、受け入れるか拒むかの回答を明示的に行うしかありません。仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。たとえば "開発者チームは君のパッチを気に入っているけれども、量がまだ十分でない。" とか、 "開発チームは君のパッチを全て高く評価しているけど、適用する前にかなり調整が必要なんだ。だからコミット権限を与えるのが好ましいと思えない。このことは時間をかけて改善して欲しいと願っている。" という感じです。ただ、その人との信頼関係の度合によりますが、あなたの発言が相手にショックを与える可能性があることを忘れないように。メールを書くときは、相手の視点からメールを眺めるようにしましょう。

新しいコミッターを加えることは、他のほとんどの一度限りの決定よりもより重大なので、プロジェクトによっては投票に特別な要件を課すところもあります。たとえば、その提案には少なくとも n 票の賛成票が必須で、反対票があってはいけないとか、圧倒的多数の賛成票が必須、といったものです。正確な賛成票の数は重要ではありません。中心となる考え方は、開発チームが新しいコミッターを加えるのに慎重であるべき、というものです。コミット権限を奪う場合にも、投票には似たような、あるいはもっと厳格な要件が必要です。まぁしかし、こんなルールを必要としないのが望ましいのですが。コミット権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、 8章ボランティアの管理 の「コミッター」を参照してください。

世論調査 v.s 投票

ある種の投票では、有権者を広げた方がいいかもしれません。たとえば、与えられたユーザーインターフェイスがユーザーのソフトウェアの使い方と合うかどうかを、開発者が決められない場合、プロジェクトのメーリングリストを購読している人全員に尋ねてみるのがひとつの解になります。これは投票というよりむしろ 世論調査 ですが、開発者はその結果を拘束力のあるものとして扱っても構いません。どういった調査であっても、与えられている選択肢以外の回答を記入できることを必ず参加者に明示するようにしましょう。調査の質問として与えられた選択肢よりも優れた回答を考えている人がいる場合、調査の結果、その回答がもっとも重要だとわかる場合があるからです。

拒否権

プロジェクトによっては、 拒否権 として知られる特別な投票権を許しています。拒否権は性急に、または思いつきで行われた変更で、少なくとも皆でもっと議論する時間が必要な場合に、開発者がそれをやめさせる手段になります。拒否権は、とても強い反対と、議事の進行を妨害することの中間に位置すると考えるとよいでしょう。正確な意味はプロジェクトによって異なります。プロジェクトによっては拒否権を無効にするのがとても難しいところもありますし、おそらくは、もっと議論をするために強制的に時間を置いたあとで、通常の投票権で多数の得票を得れば、拒否権を無効にできるプロジェクトもあります。どんな拒否権であっても、説明が一通り行われてから行使すべきです。説明もされないのに行使された拒否権は無効なものと考えるべきでしょう。

拒否権を許すと、それが濫用されるという問題が起きます。開発者たちは、もっと議論が必要なときに拒否権を行使することで、リスクを増やしたくないと考えています。あなたは、自分自身が拒否権をとても慎重に行使し、そして拒否権を多く行使し続けている人がいる場合に、丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、拒否権に拘束力を持たせるよう求めることもできます — 結局は、明らかに大多数の開発者が X を望んでいる場合は、その X が将来何かにつけ発生するでしょうから。その場合は、拒否権を行使している開発者がそれを取り下げるか、グループが拒否権の力を弱くする決定をすることになるでしょう。

拒否権を行使するのに "-1" と書く人を見かけるかもしれません。この使い方は、高度に組織化された投票と拒否権システムを持つ Apache Software Foundation で生まれたものです。これについては http://www.apache.org/foundation/voting.html に説明があります。 Apache プロジェクトの基準は他のプロジェクトにも広まっているので、オープンソース界の多くの場所で、彼らの規約が形を変えて使われているのを見ることになるでしょう。技術的には、Apache プロジェクトの基準に照らしても、 "-1" という表現が正式に拒否権を行使していることを必ずしも表すわけではありません。しかし、非公式には拒否権を行使している、もしくは少なくとも強い反対の意志を示していると普通は受け取られます。

投票と同じく、拒否権の効果は遡って適用できます。疑問が持たれている変更が既にコミットされている、もしくはアクションが既に起こされているという理由で、（既にプレスリリースが出ている場合のように、取り返しが付かないものでなければ）拒否権に対して異を唱えるのはよくありません。言いかえれば、何週間、何ヶ月もたったあとに拒否権が行使されても、それが真面目に取り上げられる可能性は少ないですし、真面目に取り上げるべきでもありません。

全てを記録しておく

プロジェクトの規約や合意の数が多くなり過ぎるために、ある時点でどこかに記録しておく必要が生じます。記録を正統なものにするためには、メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。実際に記録するときは、メーリングリストのアーカイブにある関連したスレッドを参照するようにし、不明な点があるときにはもう一度尋ねるようにしましょう。記録した文書には人々を驚かせるようなことを書くべきではありません。なぜなら、その文書は合意の根拠ではなく、合意の中身を説明したものに過ぎないからです。もちろん、成功すればそれを権威あるものとして人々が引用しはじめるかもしれませんが、それはその文書がプロジェクトの総意を正確に反映しているだけに過ぎません。

これが 2章さあ始めましょう の「開発者向けのガイドライン」で述べた文書になります。当然、プロジェクトが若いうちは、長く続いているプロジェクトの歴史のような、ためになる話抜きでガイドラインを書かねばならないでしょう。しかしプロジェクトが成長するにつれ、明らかになってきた事柄を反映させた形で、文書を改訂することができます。

文書を包括的なものにするのはやめましょう。どんな文書でも、プロジェクトに参加するのに必要なことを全て網羅することはできません。プロジェクトで生まれる多くの規約は、ずっと暗黙のもので、決して明示的に言及されることがないにもかかわらず、メンバー全員がかたくなに守っているものなのです。単に当り前過ぎるので言及されないものもありますし、重要だけど曖昧なのでただ避けているだけのものもあります。たとえば、"メーリングリストでは礼儀正しくし、他人を尊重しましょう。また、フレームウォーを始めてはいけません。" とか、 "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。もちろん、これらは望ましいことではありますが、これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。メーリングリスト上で失礼な発言をしたり、バグだらけのコードを書いている人がいたとして、彼らはプロジェクトのガイドラインにやめろと書いてあるからといってやめはしないでしょう。こういう状況は包括的なガイドラインであらかじめ対処するものではなく、問題が起きたときに対処すべきものなのです。一方で、あるフォーマットですべてのAPIを文書化するルールのようなよいコードの書き方に関するガイドラインがプロジェクトにある場合は、できる限り完全なものを書いておくべきです。

ガイドラインに盛りこむ内容を決めるよい方法は、初心者がよく尋ねる質問や、経験豊富な開発者がよくこぼす不満に関する文書を基にすることです。これは必ずしも FAQ を基にすべきというわけではありません — ガイドラインは、FAQ よりわかりやすい物語風の構造が必要になるでしょうが、 FAQ と同様、将来起こりうる問題よりも、実際に起こった問題に取り組むという現実的な原則に従うべきです。

プロジェクトに優しい独裁者や、特別な才能に恵まれた幹部（社長とか議長とか、そういったものです）がいる場合は、引継ぎの手続きを明文化する良い機会になります。何らかの理由で優しい独裁者がプロジェクトから突然去る場合は、特定の人を後継者として単に指名すればいいだけの場合もあります。一般的には、優しい独裁者がいる場合、彼だけが後継者を指名することができます。投票で選ばれた幹部がいる場合は、彼らを選ぶのに候補者を選び、投票する手続きを踏む手続きがはじめに行われたことを文書に記録すべきです。そうした手続きがもともとなかった場合は、文書に手続きを明文化する前にメーリングリスト上で手続きに関する合意を得るようにします。階層的な支配構造に神経質な態度をとる人もいるので、こうした話題を扱うときは気を使う必要があります。

こうしたルールは見直すことができる、というのを明示しておくことが多分一番重要です。たとえ文書に記録された規約がプロジェクトを妨害しはじめたとしても、その文書が開発者グループの意図を強く反映したもので、プロジェクトへの不満や障害の源ではない、ということを周知しておきましょう。規約が自分の邪魔をするたびに見直しを求める人がいる場合は、その人と議論する必要は必ずしもありません。— 無視しておくことが最良の選択となることもあります。規約に不満があることで一致している人が他にいるなら、彼らが同調するでしょう。それは何かを見直すべきことをあらわしています。誰も同調しなければ、見直しを求める人に返答する人はいなくなるでしょう。そして規約は以前の状態のまま残るのです。

開発者向けガイドラインの良い例がふたつあります。ひとつは http://subversion.apache.org/docs/community-guide/ にある、Subversion Cummunity Guide です。もうひとつは、http://www.apache.org/foundation/how-it-works.html と http://www.apache.org/foundation/voting.html にある、Apache Software Foundation の統治に関する文書です。 Apache Software Foundation は実際はソフトウェアプロジェクトの集合体ですが、非営利組織として合法的に組織されています。よって彼らの文書には、開発する際の規約よりも、プロジェクトを統治する際の手続きについて多く記述されています。ですが、まだ読む価値は大いにあります。なぜなら、それはたくさんのオープンソースプロジェクトの経験を集積した文書だからです。

Joining or Creating a Non-Profit Organization

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 tbd

Mention Software Freedom Conservancy, SPI, ASF, GNOME, any others. Note "non-profit" vs "not-for-profit". Mention Kuali et al as models. Problems of consortiums. Don't assume the U.S. tax code benefit is familiar everywhere. Emphasize clear separation between the legal infrastructure and the day-to-day running of the project: the organization is there to take care of the things the developers don't want to deal with, not to interfere with the things the developers already know how to do. Explain fiscal sponsorship when talking about fundraising. Note trademark ownership as well as copyright ownership, and link to this section as appropriate from the licensing/copyrights chapter and from the money / corporate involvement chapter.

^[24]バス係数 という用語が知られています。これは、(たとえて言うと)どれくらいの人がバスに轢かれたらプロジェクトが破綻するかを示す数です。 https://en.wikipedia.org/wiki/Bus_factor も参照してください

第5章カネに関する問題

Crowdfunding: Kickstarter, etc

プロジェクトへの関わり方

開発者を長期に渡って雇用する

企業の人間としてではなく、個人として振る舞う

動機を隠し立てしない

カネで愛は買えない

契約する

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

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

プログラミング以外の活動を支援する

品質保証 (テストの専門家など)
法律上の助言、権利の保護
ドキュメントやユーザビリティの改善
ホスティングサイトや接続回線を提供する

マーケティング

見られていることを意識する
競合するオープンソースプロジェクトを攻撃しない

Hiring Open Source Developers

Bounties

この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきます。ここでは、フリーソフトウェアプロジェクトでお金を貰って雇われる開発者だけでなく、開発する環境が置かれる社会力学を理解する必要があるプロジェクト管理者も対象にします。以下のセクションでは、読者(あなたです！) はお金を貰って雇われる開発者か、開発者を管理する人であることを想定します。この章でのアドバイスは、両者に当てはまることもありますし、そうでないこともありますが、対象となる人は文脈の中で明らかにしていきます。

フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。多くの開発が、いつも非公式に奨励金の対象になってきました。システム管理者が業務の遂行を助けるためにネットワーク分析ツールを書き、オンラインにそれを投稿し、バグ修正や機能追加の貢献を他のシステム管理者から受けた場合、非公式に団体が設立されていきました。団体を維持するための資金は、システム管理者達の給料から出ており、オフィススペースやネットワークの帯域は寄付によって賄われました。こうした組織は、はじめのうちは制度的に認知されることはありませんでしたが、もちろん投資することで利益を得ていたのです。

当時と今の違いは、こうした努力の多くが公に認められるようになったということです。企業はオープンソースソフトウェアから得られる利益に関心を示すようになり、その開発に直接関わりはじめました。開発者達も、本当に重要なプロジェクトには少なくとも寄付や、可能であれば長期のスポンサーを期待するようになっています。お金があるからといって、フリーソフトウェアの基本的な開発力学が変わるものではありませんが、開発者の数や、開発者ひとり当たりの作業量の規模は劇的に変わりました。お金は、プロジェクトが組織化される方法や、関係者のプロジェクトでのやりとりの仕方にも影響を与えました。問題は、単にお金がどう使われるのかとか、投資に対する見返りをどのように測るか、ということにとどまらず、プロジェクトの管理やそのプロセスにも及びます。つまり、企業の階層的な命令系統と、緩やかに分散したフリーソフトウェアプロジェクトのコミュニティーが、お互いに生産的に動くにはどうしたらいいでしょう？そもそも "生産的に" という言葉がどういう意味なのか、について企業とコミュニティーは一致するのでしょうか？

金銭的な支援を受けることは、オープンソース開発コミュニティーでは一般的に歓迎されています。支援を受けることで、軌道に乗る前に多くのプロジェクトを潰してきたコミュニティーの弱点を無秩序の力に変えることができます。それゆえに、人々はソフトウェアを世に送り出したいと強く願うようになります。 — つまり、これから向こう6ヵ月間は自分の時間をそこらへんに転がっている何かに使おう、と人々は考えるのです。結局、何かを信じる心は、ある程度までは他の人に伝染しやすいものです。たとえば、IBM がオープンソースプロジェクトを支援したとき、このプロジェクトに失敗は許されないと人々は強く思いましたし、失敗しないようプロジェクトに注力しようと思う心が、プロジェクトが実際に失敗しない状況を作ったのです。

しかし、お金を出すことは、人を支配する感覚を生むものでもあります。注意深く扱わないと、お金はプロジェクトを、仲間内の開発者とそうでない開発者に分裂させてしまうかもしれません。ボランティアの開発者が、一番お金を出している人が機能追加や設計上の決定を行えるんだと思ってしまうと、実力志向が強く、それでいて他人の利益のために無給で働くことを好まないプロジェクトに移ってしまうでしょう。彼らは、決してメーリングリスト上で大声で不平を言ったりはしません。そのかわり、ボランティア達が真剣に取り組むことをやめてしまうため、外から口を出す人がどんどん少なくなっていくだけです。バグ報告や小規模な修正をたまに行う形で活動は続きますが、大規模なコードの貢献や、設計上の議論に外部から人が参加するといったことはなくなってしまいます。人々は自分に何が期待されているのかを感じ取り、期待に応えようと動いたり、それを裏切ったりするのです。

お金は注意深く扱う必要がありますが、そうしたからといってプロジェクトへの影響力を買えるわけではありません。ほとんどの場合は、買えるのですが、プロジェクトに直接影響力を行使できるわけではない、というのがミソです。単純な商取引では、欲しいものとお金を交換します。あなたが追加して欲しい機能があれば、契約にサインし、お金を払い、作業をしてもらいます。オープンソースプロジェクトでは、事はそう簡単ではありません。あなたは開発者達と契約することが出来ます。しかし、彼らがもし、お金を払うだけで開発コミュニティーにその有償の成果を取り込んでもらえると保証したのなら、彼らは — そしてあなたも — 勘違いをしています。コミュニティーは、成果物そのものの利点と、それがどの程度ソフトウェアのビジョンに合っているかに応じてそれを受け入れるのです。あなたはソフトウェアのビジョンについて口を出す権利はありますが、あなたの意見が唯一の声というわけではないのです。

よって、お金でプロジェクトへの影響力を買うことはできません。しかし、影響力に 繋がるもの を買うことはできます。もっとも明快な例はプログラマーを買うことです。優れたプログラマー達を雇えば、彼らはソフトウェアに関する経験を積み、コミュニティーで信頼を得るまでプロジェクトに張り付きます。そうすれば、他のメンバーと同じ手段でプロジェクトに影響を与えることができます。彼らはそれぞれが投票権を持つ場合もあれば、人数が多い場合にはブロック投票権を持つこともあります。彼らがプロジェクトで尊敬を得れば、投票権以上の影響力を持つことになるでしょう。雇われている開発者は自分の動機を偽る必要はありません。結局、ソフトウェアに変更を加えたい人は誰でも、それぞれに理由があるものです。企業がソフトウェアを変更したい理由が、他より正しくない、ということはありません。企業の目標がプロジェクトで重視されるかどうかは、企業規模や予算、もしくはビジネスプランによって決まるのではなく、企業を代表している人たちのプロジェクト内での地位によって決まるのです。

Crowdfunding: Kickstarter, etc

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 tbd

Kickstarter is the obvious place to start, but there are other funding systems too. Look at campaigns that have used indiegogo, snowdrift (if in production by then), ask around for others. Use Michael Bernstein's tips on how to do it right.

プロジェクトへの関わり方

オープンソースプロジェクトがお金を出してもらう理由は様々なものがあります。以下に示す理由は、相互に排他的なものではありません。つまり、支援を受ける理由は以下の複数、または全てが当てはまる場合があります。

コスト負担を共有する

関連があるソフトウェアを必要とする組織は、似たようなコードを社内で書いたり、商用ベンダから似たような商品を購入したりすることで、同じ目標に向かって重複した努力をしていることがよくあります。彼らはそれを知ると、自分たちの需要を調整するため、オープンソースプロジェクトを作る(または既存プロジェクトに参加する)かもしれません。その利点は明らかです。開発コストを分散しつつ、利益は参加したすべての組織が得ることができるからです。このシナリオは、非営利な組織の場合もっともわかりやすいのですが、競合関係にある営利組織であっても、戦略的には有意義なものです。

例: http://www.openadapter.org/, http://www.koha.org/

サービスを拡大する

企業が販売している複数のサービスが特定のオープンソースソフトウェアに依存していたり、それによってサービスの魅力を高めている場合、そのソフトウェアを活発に維持していくことがその企業の関心事になるのは自然の流れです。

例: CollabNet が http://subversion.tigris.org/ をサポートしていること(お断り: これは筆者のルーチンワークですが、これがこのモデルの最良の例です)

ハードウェアの営業をサポートする

コンピューターとその部品の価値は、それが利用できるソフトウェアの量に直接左右されます。ハードウェアベンダー — 完成したマシンのベンダーだけでなく、周辺機器デバイスやマイクロチップのベンダーも含みます — は、自分たちのハードウェアを動かせる高品質なフリーソフトウェアが存在していることが、顧客にとって重要であることに気付いているのです。

競争相手を弱体化させる

企業によっては、競合しているソフトウェアの力を弱めることを狙ってオープンソースプロジェクトをサポートするところもあります。競合するソフトは、オープンソースであってもそうでなくても構いません。競争相手の市場シェアを減らすことが、オープンソースプロジェクトに参加する唯一の理由ではないものの、そのひとつだったりすることはあり得ます。

例: http://www.openoffice.org/ (競争相手を弱体化させることが OpenOffice の唯一の存在理由ではありませんが、このソフトウェアは、少なくとも Microsoft Office に対する答えのひとつです)

マーケティング

人気のあるオープンソースソフトウェアに関わっている企業は、それだけでブランド管理をうまく行うことができます。

デュアルライセンス

デュアルライセンス とは、自分のソフトウェアに商用のソフトウェアを組み込んで売りたい顧客向けの伝統的な商用ライセンスと、ソースを公開して使いたい人向けのフリーなライセンスを同時に共存させてソフトウェアを提供するための手法です。 (10章ライセンス、著作権、特許 の「デュアルライセンスの仕組み」を参照してください) オープンソース開発者のコミュニティーが活発なら、デュアルライセンスされたソフトウェアは、広く多くの人から開発作業やデバッグをしてもらえるという利益を得られる上、企業はフルタイムで働くプログラマーを支援することで、ロイヤリティの収入を得ることができるのです。

このモデルの例として、よく知られているものがふたつあります。同じ名前のデータベースソフトウェアを作っている MySQL、そして Barkley DB を配布し、サポートしている Sleepycat です。これらの例が両方ともデータベースを扱う会社であることは、偶然の一致ではありません。データベースソフトウェアは市場でユーザーに直接売るというよりは、アプリケーションに統合される傾向があるため、デュアルライセンスのモデルによく合っているのです。

寄付を受ける

広く使われているオープンソースソフトウェアのプロジェクトでは、オンライン上で「寄付を行う」ボタンを押してもらったり、コーヒーのマグカップやTシャツ、マウスパッドなどのような、ブランド化した商品を売ることで、個人や組織から重要な貢献を受けることができます。ここで一言注意しておきます。もしあなたのプロジェクトで寄付を受けることにした場合、お金が入ってくる前に寄付されたお金をどう使うかを計画し、それをプロジェクトのウェブサイトに掲示するようにしましょう。どうお金を使うかの議論は、実際にお金が入ってくる前の方がうまくいきます。どちらにせよ、お金の使い方に同意が得られない場合は、寄付を受けることが非現実的であると判断した方がよいでしょう。

お金を出す側のビジネスモデルが、オープンソースコミュニティーに対する関わり方を決める唯一の要因ではありません。お金を出す側とコミュニティーとの歴史的な関係も影響しています。つまり、企業の方がプロジェクトを始めたのか、それともあとから既存のプロジェクトに参加したのか、という点です。どちらの場合も、お金を出す企業はコミュニティーから信頼を勝ち取る必要がありますが、あとから既存プロジェクトに参加した方が少し信頼されやすい、ということは驚くべきことではありません。必ずしもプロジェクトの方向性を支配するためではなく、導くためであったとしても、企業はコミュニティーでリーダー的な存在を維持したり、唯一の発言権を持とうとしているでしょうか。または、ある程度の人数コミッターを送り込み、顧客から報告されたバグを修正し、労せずして製品にそれを取り込みたいだけでしょうか？

このふたつの質問を、以降で説明するガイドラインを読むときによく覚えておいてください。これらはフリーソフトウェアプロジェクトに組織が参加するあらゆる場合に適用できますが、プロジェクトは人間が作るものですので、ひとつとして同じものはありません。ある程度、なりゆきに任せなければならないでしょうが、これから説明する原則を理解していけば、あなたが望むやり方と似たものが出てくるでしょう。

開発者を長期に渡って雇用する

オープンソースプロジェクトでプログラマーを管理している場合、技術的、政治的にうまくやっていくスキルを身につけるまで彼らをそこに留めるようにしましょう。 — それには最低でも2〜3年は必要です。もちろん、オープンソースプロジェクトであれ、クローズドなプロジェクトであれ、開発者を頻繁に入れ替えたりすると利益は得られません。初心者が仕事のコツを覚えるのに必要なのは、どんな環境であってもそこに留まることです。開発者を頻繁に入れ替えると、オープンソースプロジェクトではより不利になってしまいます。なぜなら、出て行くプログラマーはコードに関する知識だけでなく、そのコミュニティーで得た地位や人間関係も持って行ってしまうからです。

開発者がオープンソースプロジェクトで得た信頼は、人に伝えることができません。一番わかりやすい例をあげましょう。新たに参加する開発者は、プロジェクトから出て行く人からコミット権限を引き継ぐことは出来ません。 (この章の後の方にある「カネで愛は買えない」を参照してください) コミット権限がないので、新しい開発者はそれが得られるまでパッチを提出しなければいけません。しかし、コミット権限だけが失われた信頼を測る唯一の要素ではありません。長期に渡ってプロジェクトに関わった開発者は、メーリングリストでの雑多な古い議論に関する知識もあります。新しい開発者にはそうした知識がないので、古い議論を蒸し返そうとするかもしれません。それによってプロジェクトでの信頼がなくなってしまうかもしれないのです。つまり、「お前何も覚えてないのかよ？」と思われてしまうのです。新しい開発者は、プロジェクトにいる個人が持つ政治的な力に関する感覚もないので、長くプロジェクトにいた開発者ほど、開発の方向性について、円滑に影響力を発揮することははできないでしょう。

新しい開発者については、計画に基づいて訓練するようにします。彼には初日から開発コミュニティーと直接連絡をとらせ、バグ修正やコードを掃除するタスクを始めさせるべきです。それによってコードベースを学び、コミュニティーで信頼を得ることができます。しかし、長い時間がかかる、複雑な設計の議論の火付け役にはならないようにします。いつも新しい開発者の質問に答えてくれたり、経験を積んだ開発者が普通は気に留めないようなスレッドでも、彼のメーリングリストへの投稿を読んでくれている先輩の開発者がいるはずです。こうすることで、新しい人が活躍する前から開発グループを潜在的に刺激することができます。自分のコードを多くの人からピアレビューされることに開発者が慣れていない場合は、裏で励ましたり、ポインタを示してあげたりすることも大いに役立つでしょう。

CollabNet が Subversion プロジェクトで働いてもらうために開発者を雇うときは、一緒に話し合って保留中のバグをいくつか選んでもらい、経験を積んでもらいます。バグを解決するための技術的な概要を話し合い、新しい開発者が（公の場に）投稿する修正プログラムを（これも公の場で）レビューするために、経験を積んだ開発者を少なくともひとり割り当てます。メインの開発用メーリングリストで公になる前は、私たちは彼のパッチを見ることさえしません。理由があれば見ることもできるわけですが。重要なのは、新しい開発者が公の場で行われるレビューの過程を経験し、全く知らない人から批判を受けることに慣れると同時に、コードベースを学ぶことです。しかし私たちは、彼のパッチが投稿された後、自分たちのレビューがすぐに行われるようにタイミングを調整しようとします。こうして、メーリングリスト上での最初のレビューを自分たちが行うようにすると、他の人のレビューの口調を抑えるのに役立ちます。また、新しい人を真面目に扱おうという考え方を浸透させることができます。適切なメーリングリストのアーカイブを参照したり、説明をすることで、詳細なレビューに時間を割いているのを外部の人が見ると、新しい開発者の訓練が行われていて、彼に対して長期に渡って投資を行うことがわかるのです。こうすることで、開発者が少なくとも質問に答えたり、パッチをレビューするのに時間を割こうという気にさせることができるのです。

企業の人間としてではなく、個人として振る舞う

あなたが雇った開発者には、プロジェクトの公のフォーラムで一枚岩の企業の人間としてではなく、個人として振る舞ってもらうようにしましょう。これは企業が関わることでついてまわる否定的な意味合いがあるからではありません(まぁ多分あるのでしょうが、それはこの本では触れません)。むしろ個人こそが、オープンソースプロジェクトが構造的に扱える唯一の存在だからです。個人の貢献者は、議論に参加したり、パッチを提出したり、信頼を得たり、投票するなどができますが、企業にはそれができません。

それ以上に、分散した個人として振る舞うことで、反感が一ヶ所に集中するのを避けることができます。あなたが雇った開発者には、メーリングリスト上でお互いが反目させるようにしてみましょう。彼らにお互いのコードを頻繁に、公の場で、赤の他人としてレビューさせるようにしましょう。そして、いつも徒党を組んで投票させないようにしましょう。なぜならそうしてしまうと、他の人が「こいつらは徒党を組んでいる」と感じますし、道徳的な見地から、彼らをチェックし続けるために組織的な努力がなされるべきだからです。

実際に個人として振る舞うことと、そうしようと単に努力することは違います。状況によっては、雇った開発者達に一致した行動をとらせた方が便利なこともありますし、必要なときは裏で協力する準備をすべきでしょう。たとえば提案をするとき、合意が形成されつつあることを印象付けるために、何人かに早い段階から同意の意志を示してもらうようにします。他の人は、その提案に勢いがあると感じるでしょうし、仮に反対すれば、その勢いを削いでしまうとも思うでしょう。よって、理由がある場合だけ、人々は反対するようになります。反対意見を真摯に受け止めている限り、賛成意見を組織化することは間違っていません。賛成意見を公の場で明らかにすることは、たとえそれが事前に協力していたとしても真摯である点は変わりませんし、反対意見を封殺するのに使われない限り、害はありません。彼らの目的は、単に体裁を保つためだけに反対したがる類の人を抑えることなのです。そういう人については、6章コミュニケーション の「簡単な議題ほど長引く」を参照してください。

動機を隠し立てしない

あなたの組織がプロジェクトで目指していることを、できる限り隠さないようにしましょう。ただし、ビジネス上の秘密は漏らしてはいけませんが。たとえば、自分の顧客から強く要求されているという理由で、ある機能をプロジェクトに取り込んでもらいたいのであれば、メーリングリスト上で率直にそう言うようにしましょう。顧客から自分のことを秘密にしてほしいと頼まれることもありますが、その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。開発コミュニティーがあなたがやりたいことの動機を知れば知るほど、あなたが何を提案しても違和感が少なくなります。

これは、知識は力であり、他人が自分の目標を知れば知るほど多く干渉される、という直感に反するものです。 — 直感を受け入れるのは簡単ですが、取り除くのは難しいものです。しかし、ここではその直感は間違っています。新機能 (バグ修正でもなんでも) を公の場で主張することで、あなたは既にカードをテーブルに置いているのです。その時点で唯一問題になるのは、目標を共有できるようにコミュニティーを誘導できるかどうかです。仮に望むことだけを主張して、その理由となる具体例を述べなければ、その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。しかし、現実世界のシナリオを 2,3 述べ、提案している新機能がなぜ重要なのかを示すだけで、議論する上で劇的な効果があります。

別の視点から考えてみましょう。新機能やプロジェクトの新しい方向性に関する議論は長く、退屈なものです。人々の主張は「個人的には X が欲しいんだよね」とか、もっとよくあるのは「ソフトウェア設計を長い間やってきたんだけど、 X はユーザーにとってもの凄く重要だ / 誰も満足しない余計な飾りだよね」といったものになります。現実世界での使い方が示されていないと、議論の短縮や決着に繋がらないばかりか、実際のユーザー体験からは程遠い議論になってしまいます。そういった議論を止める力が働かない限り、結局はもっとも口が達者な人や、頑固な人、あるいは一番の古参によって結論が決まってしまうでしょう。

大量の顧客データを持つ組織として、あなたにはそういった議論を止めるチャンスがあります。他の人が開発コミュニティーに伝えることができない情報へのパイプ役になれるのです。あなたが望むことの根拠になる情報は恥ずかしいものでも何でもないのです。ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、広い見聞を持っているわけではありません。開発者はめいめいが、自分独自のやり方でソフトウェアを使っているのです。そして他の使い方については、直感や当て推量、そして本能に頼って作っていることを知っているのです。非常に多くのユーザーの信頼できるデータを提供することで、あなたは開発コミュニティーに酸素に似た何かを与えることになります。そうした情報を適切に示す限り、彼らは熱狂的にそれを受け入れるでしょうし、物事はあなたの望む方向に進むでしょう。

鍵となるのは、もちろん情報を適切に示すことです。あなたが大量のユーザーを抱えていたり、ユーザーがある機能を必要としている (またはそう思っている) からといって、自分の解決策を実装すべきだと主張してもうまくいかないでしょう。むしろ、ある特定の解決策についてではなく、問題となっていることがらをはじめに投稿するとよいでしょう。あなたの顧客が経験していることを詳細に記し、できるだけ多く分析しておきます。その上で、考えられうるだけの現実的な解決策を提示するのです。解決策がどれくらい有効かを人々が考え始めたら、あなたは彼らの発言を擁護したり、異議を唱えたりするのに自分のデータを示すことができます。あなたははじめからずっと特定の解決策が頭にあるかもしれませんが、はじめからその解決策を選んで特別な配慮をしてはいけません。これは相手を騙しているのではありません。単に普通の「公正な仲裁者」として振る舞うことです。結局、あなたの本当の目標は特定の問題を解決することです。特定の解決策は、そのための手段でしかないのです。仮にあなたが好む解決策が優れていれば、他の開発者達もそれを結局は認めてくれ、彼らの自由意志で応援してくれるようになるでしょう。彼らを威嚇して自分の解決策を実装させるより、この方があなたにとってよいでしょう。 (彼らが自分より優れた解決策を考えているかもしれません。)

これは、特定の解決策を好んでいることを言ってはいけないということではありません。しかし、あなたが既に内部で終えている分析が、開発用の公開メーリングリストで繰り返されるまで我慢しなければなりません。「すべての解決策をみてきたけれども、それは A, B, C という理由でうまくいかない。突き詰めて考えていくと、結局唯一の解決策は ...」などと発言してはいけません。問題なのは、こうした発言が尊大に聞こえるということよりも、むしろあなたがその問題を分析するためにある未知数の (多分大きいと人々は思うでしょう) リソースを既に裏で投入しているという印象を与えてしまうことです。これは既に物事が進行していて、多分決定もなされていて、公にはそれについて何も知らされていないように見えてしまいます。これは人々の怒りを買う原因になります。

当然、あなた はその問題について裏でどのくらい努力してきたかを知っています。その知識はある意味不利なものです。あなたが雇っている開発者は、メーリングリスト上にいる他の開発者とは違った精神状態に置かれてしまい、その問題について考えたことがない開発者の視点から物事を見る能力が欠けてしまいます。より早い段階で他の人にあなたと同じ言葉で考えさせれば、こうした溝は小さくなります。この論理は、個々の技術的な状況だけでなく、自分の目標をできるだけ隠さないという広義の要請にも適用できます。知らないことは知っていることよりも不安定なものです。あなたがやりたいことの動機を人々が知れば、彼らはたとえそれに反対であってもあなたと気軽に話してくれるでしょう。あなたの動機が分からなければ、彼らは物事を悪い方向に考えてしまうこともあります。

もちろんすべてを公にはできないでしょうし、人々もそんなことを期待していません。すべての組織には秘密があります。おそらく営利組織には多くの秘密があるでしょうし、非営利な組織でもあるでしょう。ある方向性を擁護する義務があるけれども、その理由を全く公にできない場合は、そういった制約の中で出来るもっとも優れた主張をするようにしましょう。そして、議論の中で自分が望むほど影響力を行使できない可能性がある、という事実を受け入れましょう。これは、開発コミュニティー全体に給料を払わないために行う妥協のひとつです。

カネで愛は買えない

あなたがカネを貰って雇われている開発者なら、カネで買えるものと買えないものに関する基準を早い段階から設定するようにしましょう。これは、あなたの気高くて侵し得ない性分について、 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章プロジェクトの政治構造と社会構造 の「優しい独裁者」を参照してください) がちょっと機能しにくいことを意味しています。優しい独裁者がプロジェクトに一番カネを出している場合は特にそうでしょう。独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、プロジェクトにカネを出している人がコミュニティーのルールを守っていると証明することは困難です。必ずしも不可能ではありませんが。それには、外部の開発者と同じ視点から物事を見ることができ、適切に行動できる人で、かつカネを出せる人がプロジェクトリーダーになる必要があります。その場合でも、コミュニティーで不満が広がる兆しが明るみに出てしまう場合に備えて、独裁的ではないやり方で提案をするのはよい考えです。

契約する

契約は、フリーソフトウェアの世界では注意深く扱う必要があります。理想を言えば、契約を結んで作業した人の成果物がコミュニティーに受け入れられ、公のリリースに取り込まれるのが望ましいです。理屈の上では、成果物の品質が良く、それがプロジェクトのガイドラインを満たしている限り、誰と契約しようが問題ありません。この理屈と実際は一致することもありますし、そうでないこともあります。つまり、品質が良い修正プログラムなら、それが全く知らない人が書いたものであっても、一般的にはソフトウェアに取り込むことが できる ということです。困るのは、重要な改良や新機能の追加を行う良質の修正プログラムを全く知らない人に作ってもらうのはとても難しいということです。作業を請け負う人には、プロジェクトでまず議論してもらわないといけません。議論にかかる時間は正確に予測できません。もしあなたが時給単位でお金を払っているのなら、予想以上のお金を支払うことになるかもしれません。逆に固定給であれば、その人は貰う金額に見合わない量の仕事をする羽目になるかもしれません。

この問題に対処する方法がふたつあります。望ましいのは、過去の経験に照らして議論にかかる時間を推測し、誤差を少し足しておきます。その値に基づいて契約するのです。これは、問題を独立した多くの小さな断片にできるだけ分割し、それぞれの断片の予測可能性を増やすのにも役立ちます。別のやり方として、修正プログラムだけを作ってもらう契約を交わし、それを公のプロジェクトに取り込んでもらうことを別の問題として扱う方法があります。こうすると契約書を書くのは楽になりますが、あなたがプロジェクトに依存する間、またはそれと同様の機能をプロジェクトの本流に取り込んでもらうまでの間、契約で作られた修正プログラムを維持するのに四苦八苦することになります。もちろん、前者の望ましい方法をとったとしても、修正プログラムが取り込まれることを契約の条件には出来ません。なぜなら、これは状況によっては売っていないものを売ってしまうことになるからです。 (もし、プロジェクトが対象となる機能をサポートしないと決めたらどうなるでしょう？) しかしながら、変更をコミュニティーに受け入れてもらい、彼らが承知すればそれをリポジトリにコミットしてもらえるよう、 誠意をもって 努力することを契約の条件にすることはできます。たとえば、プロジェクトがコード変更に関する基準を持っている場合は、契約でそうした基準を参照した上で、成果物はそれを満たすように取り決めることができます。実際、このやり方で契約の当事者全員が望む結果が普通は出てきます。

契約を成功させるために最も良い戦略は、プロジェクトの開発者を雇うことです — 契約の相手としてはコミッターが望ましいです。これは影響力を買っているように見えますし、実際そうですが、見た目ほど破綻しているわけではありません。プロジェクトの開発者は、主にコードの質が高いことと、他の開発者と交流しているからこそ、影響力を持っているのです。開発者があることを成し遂げる契約をしたからといって、彼のそうした地位を高めることにはなりませんし、傷つけることもありません。ただ、契約をすることで、周囲の人が彼のことをあれこれ詮索するようになるかもしれません。ほとんどの開発者は、不適切、または多くの人が嫌っている新機能の導入を支援することで、長い時間かけて築いてきたプロジェクト内での地位を危険に晒したりはしません。そういう目的で実際に開発者を雇うときは、どういう変更がコミュニティーに受け入れられやすいかについて、あなたはアドバイスを貰うはずです。また、プロジェクト内の優先順位をわずかながら変更させることになります。プロジェクト内の優先順位付けは、開発者が何に時間を掛けるかの問題にすぎないので、開発者の時間を契約で買うとすると、彼の仕事の優先度が少し変わることになるからです。これは経験を積んだオープンソースプロジェクトの開発者にとって避け難い現実ですし、雇い主が課す仕事を単にそれが 先に片付けられそう だという理由だけで、それだけに注意を向ける開発者も少なからずいます。彼らはその仕事を早く片付ける後押しをしてくれます。彼らは全くコードを書かず、設計について議論したり、コードをレビューしたりしているだけかもしれませんが、これらはとても役に立つものです。これまで述べてきたすべての理由から、契約相手になる開発者は、プロジェクトに既に参加している人をランク付けして選ぶのが一番よいのです。

プロジェクトの開発者を雇うとすると、疑問が二つ出てきます。契約を公にしない方がいいのでしょうか？また、仮に公にするとして、特定の開発者以外の人と契約しないことで、コミュニティーに緊張関係を作ってしまうことを気にかけるべきなのでしょうか。

可能であれば、契約することを公にするのがベストです。仮にできなければ、契約した開発者の振る舞いがコミュニティーのメンバーからは不自然に見えるかもしれません— おそらく、彼はどういうわけか今まで全く興味を示さなかった機能に、突然高い優先度を設定するようになるでしょう。彼がその機能を欲しがる理由を尋ねられたとき、契約をしている事実を話せないのだとしたら、どうやってその理由をもっともらしく説明したらいいのでしょう？

また、あなたが関わっている作業がさも重要なことのように振る舞ってはいけません。開発者を雇っているからというだけの理由で、自分の投稿を重く扱うべきという厚かましい態度をメーリングリスト上でとる人がいました。こうした態度は、開発者を雇う人が — 契約することで生み出される コードではなく、契約している事実を重視していることを示していますが、他の開発者からすれば、コードだけが重要なのです。どんなときでも、誰が誰にお金を払っているのかではなく、技術的な問題に注意を払うべきです。契約にまつわる問題をうまくコミュニティーで処理している、 Subversion の開発者を例に挙げましょう。彼が自分のコード変更についてIRCで議論しているとき、彼は小声で (IRC の privmsg というプライベートな会話を使って) 今書いている機能や修正プログラムを書くのに、お金をもらっていることを他のコミッターに伝えます。彼はその変更をずっと望んでいたし、その作業をしてお金を貰えるのが幸せであるかのように一貫して振る舞います。彼は契約相手の身元を明かすかもしれませんし、明かさないかもしれませんが、いずれにせよ契約の詳細に立ち入ったりはしません。契約の話は、どうやって作業を成し遂げるかについての技術的な議論をするときに、補足的にするだけです。

この例は、契約を公にした方がいいもうひとつの理由を示しています。契約にお金を出している組織が複数あった場合、一方が何をしようとしているのかがわかれば、リソースを共同で出資できるからです。上の場合、プロジェクト最大の出資者 (CollabNet) はこうした出来高払いの契約に関わっていませんが、誰か他の組織があるバグ修正にお金を出していれば、 CollabNet はリソースを他のバグに振り向けることができ、プロジェクト全体の効率が上がるのです。

他の開発者は、プロジェクトで契約している人がいることを嫌がるでしょうか？一般的には NO です。特に、お金をもらっている人がコミュニティー内で地位を確立し、尊敬されているメンバーであるときは特にそうです。契約がすべてのコミッターに平等に行き渡ると思っている人なんて誰もいません。コミュニティーのメンバーは、スポンサーと長期に渡って関係を築くことが重要だとわかっていますが、不安なのは、一度あなたが信頼できる人を見つけてしまったら、公平さを保つために他の人に仕事を振りたがらないことでしょう。これについては次のように考えましょう: はじめに誰かを雇うとき、必ず 誰かを 選ばなければならないのだから、反対はでないでしょう — 仮に誰も雇わなくてもあなたの落ち度はありません。後に、2度目になって同じ人を雇ったとしても、それは常識から外れていません。あなたは彼を知っていて、直近の仕事は成功しているのです。どうしてリスクをとる必要があるでしょうか？こうした理由から、仕事を皆に平等に振るのではなくて、コミュニティー内に突出した人がひとりやふたり出てきたっておかしくありません。

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

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

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

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

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

Jim と私は契約を結び、新しい認証機構を設計する作業に腰を据えて取り組みました。私たちが思いついたのはとても単純なもの (アメリカ合衆国は、当時暗号化に関するプログラムに輸出規制をかけていました。よって、暗号化の強度が高い認証機構を実装できなかったのですが、このことは顧客も理解してくれていました) でしたが、この手のプロトコルは設計したことがなかったので、専門家から見れば明らかな間違いが残っていました。この手の間違いは、設計を提案する文書を書いて、他の開発者にレビューして貰えば容易に発見できるものでした。しかし、当時の私たちには開発用のメーリングリストをリソースとして使うという考えがなかったため、そうしませんでした。コミュニティーの人たちは私たちが何をコミットしても受け入れることがわかっていましたし、それに — 自分たちが無知であることがわからなかったので — 自分たちがやっていることを他人が見える形にはしなかったのです。たとえば、修正プログラムを頻繁に投稿したり、小さな理解しやすい単位で特別なブランチにコミットしたりするなど、です。結果としてできた認証プロトコルは、あまり出来がよくありませんでしたし、一度作ってしまったら、互換性の問題を考えると改良も難しいものだったのです。

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

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

プログラミング以外の活動を支援する

プログラミングはオープンソースプロジェクトで行われる活動の一部に過ぎません。プロジェクトのボランティアから見ると、プログラミングはもっとも目立つ、華やかな部分です。このことは、ドキュメントやテストなどのプログラミング以外の活動が、少なくとも独占的なソフトウェアと比較すると残念ながら無視されることがある、ということを意味しています。企業は、自らが持つソフトウェア開発の内部インフラをオープンソースプロジェクトに与えることで、こうした無視されがちな活動を埋め合わせることができます。

内部インフラをオープンソースプロジェクトにうまく与えるための鍵は、企業の内部プロセスをオープンソースプロジェクトのそれに変換することです。この変換にはそれなりの努力が必要です。企業の内部プロセスとオープンソースプロジェクトのそれは一致しないことが多いですし、そうした違いは人間が介入しないと埋められないものだからです。たとえば、企業とオープンソースプロジェクトは異なるバグ追跡システムを使っているかもしれません。たとえ同じものを使っていたとしても、蓄積したデータが全く違うかもしれません。なぜなら、企業のバグ追跡の対象がオープンソースプロジェクトのそれとは全く違うからです。一方のシステムにある情報の断片は、もう片方のシステムに反映させるべきかもしれませんし、企業秘密に関わるものだから削除すべきかもしれませんし、一方にないものをもう片方に追加しなければいけないかもしれません。

ここでは、企業とオープンソースプロジェクトをそうした点で橋渡しする方法を説明します。うまく橋渡しすれば、オープンソースプロジェクトがより順調に動き、コミュニティーは与えられたリソースを理解するはずです。また、企業が自分のエゴのために物事を不適切に進めているのではないかと疑わなくなるはずです。

品質保証 (テストの専門家など)

独占的なソフトウェアの開発では、バグ探しやパフォーマンス、スケーラビリティのテスト、インターフェイスやドキュメントの確認、などの品質保証専門チームを置くことが普通です。フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、品質保証に関する活動は積極的に行われないのが一般的です。これはテストのような地味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、ユーザー数が多いプロジェクトのコミュニティーでは、テストの網羅率が高くなると人々が考えるということもあります。また、パフォーマンスやスケーラビリティのテストの場合は、ボランティアは必要なハードウェアリソースを得られないから、ということもあります。

多くのユーザーを抱えているプロダクトには多くのテスターがいる、という考えは全く根拠がないものではありません。一般的な環境で、基礎的な機能にテスターを割り当てるのはあまり意味がないのは確かです。なぜなら、そういう状況ではバグがすぐに見つかるのが自然の流れだからです。しかし、ユーザーはただ仕事をこなそうとするだけなので、プログラムの動作の限界を意図的に探そうとはしません。よってある程度のバグが残る可能性があります。さらに、容易に回避する方法があるバグの場合、ユーザーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。もっとも油断ならないのは、あなたの顧客 (あなたが 関心がある人たちです) のソフトウェアの使い方が、そこら辺にいる平均的なユーザーの使い方と違う場合があることです。

テスト専門のチームは、こうした手合いのバグをフリーソフトウェアでも発見してくれます。難しいのは、テストチームが行った作業の結果を、わかりやすい方法で皆に伝えることです。組織内のテスト専門部署は、テスト結果を報告する独自のやり方をそれぞれ持っています。たとえば企業独自の方言や、特定の顧客や彼ら向けのデータに関する特定の知識などです。こういった独自の情報は、書式や秘密保持の観点から、公開されているバグ追跡システムに載せるのは不適切です。たとえあなたの企業で使っているバグ追跡システムが、フリーソフトウェアプロジェクトのそれと同じだったとしても、特定の企業向けのコメントやバグに関するメタデータ (たとえば、バグに対する内部的な優先度や、特定の顧客向けに解決するスケジュール) を作る必要があるでしょう。こうした情報は外部には漏らさないのが普通です— 場合によっては、顧客にすらみせてはいけないものです。しかし、たとえ秘密でなくても、それらはフリーソフトウェアプロジェクトにとっては関心がないものです。よって、そうした情報に気を取られてはいけません。

しかしながら、バグ報告そのもの はフリーソフトウェアプロジェクトにとって重要なものです。実際、テスト専門のチームからあがってきたバグ報告は、多くのユーザーから受け取るそれよりもある意味価値があるものです。なぜなら、彼らはユーザーが調べてくれないことを調べてくれるからです。テストチームからしかあがってこないバグ報告がある場合、確実に保存してフリーソフトウェアプロジェクトが利用できるようにしておきます。

確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、彼らとの仲介役 (通常は開発者のひとり) が、内部向けのバグ報告を新しいものに「翻訳」してバグ追跡システムに登録するようにします。ここでいう「翻訳」とは、単に顧客特有のデータ (バグの再現手順には、勿論顧客の同意を得た上で顧客のデータを使う場合があります) を参照せずにバグについて説明することです。

テストチームが直接問題を登録する方がどちらかといえば望ましいです。こうすることで、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。役に立つバグ報告をすると、技術的な貢献をすることと同じくらいあなたの組織への信頼は高まります。これは開発者にとっては、テストチームと直接話をする機会に繋がります。たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、開発者はスケーラビリティに関するバグ (これをテストするリソースを彼らは持たない場合があります) を修正する作業に注力でき、その修正が望ましい結果を出しているか検証するよう、バグ追跡システム上にコメントすることでテストチームに頼むことができます。開発者から多少の抵抗があることは覚悟しておいてください。プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。テストチームが重要なバグを発見し、理解しやすいバグ報告を行えば、こうした抵抗を振り払うのは簡単です。一方、彼らのバグ報告の質がユーザーからあがってくるそれと大差ない場合は、開発者と彼らが直接話をする意味はありません。

どちらにせよ、組織内部のバグ報告が、外部のバグ追跡システムにいったん登録されたら、組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。組織の管理者や雇われている開発者は、必要に応じて顧客に特有の情報について注釈を付けても構いませんが、みんなが使えるようにするために、外部の情報を利用するようにしましょう。

こうした作業の過程で、あなたには余計な負担が掛かるはずです。ひとつしかバグがないのに二重にバグ報告を管理するのは、ひとつを管理するのに比べて仕事が多くなるのは当然です。ただ、こうすることで多くのプログラマーがバグ報告の情報を利用でき、問題の解決に貢献できるようになるのです。

法律上の助言、権利の保護

営利企業であれ、非営利な組織であれ、法人はフリーソフトウェアに潜む複雑な法律問題に注意を払う機会があるほぼ唯一の組織です。開発者個人は、オープンソースライセンスの微妙な違いを理解している人もいますが、著作権、商標、そして特許に関する法律の詳細を理解するためのリソースも時間もないのが普通です。あなたの組織に法務部がある場合、プログラムについている著作権の状態を調査したり、実際に起こりうる特許や商標の問題について開発者に具体的に助言することができます。こうした点で開発者を助ける正しいやり方は、 10章ライセンス、著作権、特許 で議論しています。もっとも重要なのは、法務部と開発者コミュニティーがコミュニケーションを取る必要がある場合、それぞれが全く違う世界にいることを認識した上で話をすることです。お互いが過去に話したことがある場合もあれば、一方が全く知らない専門領域に関する知識を持っているものとめいめいが思い込んでいる場合もあります。一番よいのは、仲介役となる人 (開発者か、技術的な専門知識をもった弁護士) を必要な限り間に置くことです。

ドキュメントやユーザビリティの改善

ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として有名ですが、私は少なくともドキュメントについては、独占的なソフトウェアとの違いが誇張されていると思っています。とは言っても経験上は、素晴らしいドキュメントやユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。

あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、プロジェクトの開発者ではなく、彼らと建設的に話ができる人を雇うとよいでしょう。プロジェクトの開発者を雇わない方がよい理由はふたつあります。ひとつは、プロジェクトから離れてしまうと開発する時間がとれなくなること。もうひとつは、対象となるソフトウェアにあまりにも距離が近い人は、第3者の視点からそれを眺めるのが難しいために、ドキュメントを書いたりユーザビリティを調べるのに普通向いていないからです。

しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておらず、普通のユーザーに感情移入できる人を探しましょう。

中級者レベルのユーザーが、ドキュメントを書くのに多分向いているでしょう。実際、この本の第1版が世に出たあと、私は Dirk Reiner というオープンソースソフトウェアの開発者から次のようなメールを受け取っています。

    「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。
    もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの
    チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー
    ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか
    を覚えていましたし、問題を乗り越えてきていたので、どう人に説明すればいいかを
    分かっていました。このため、彼が書いたドキュメントは、彼自身が理解できなかっ
    た部分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」
    ものとして見逃していた部分も網羅できていたのです。
 
    もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は
    自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま
    うまくできたこと、をうまく組み合わせることができました。
    よって、彼が書いたドキュメントはさらに素晴らしいものになっていたのです。

ホスティングサイトや接続回線を提供する

一通りのツールが揃ったホスティングサイト ( 3章技術的な問題 の「ツールが一通り揃ったホスティングサイト」を参照してください) を使っていないプロジェクトに対して、サーバやネットワーク接続を提供— もっとも重要なのはシステム管理を手助けすることですが—すると、プロジェクトが大いに助かる可能性があります。たとえそれがあなたの組織ができる全てであったとしても、世間的に良い評価を得るためにそれなりの手段になることでしょう。但し、プロジェクト全体の方向性に影響を与えることはできません。

ホスティングサイトを提供していることに感謝の意を表すために、プロジェクトのホームページにお礼の言葉を載せてもらったり、バナー広告を貼らせてもらえることが期待できます。ホスティングの設定にあたって、プロジェクトのURLをあなたの企業のドメイン内に設定した場合、 URLだけでプロジェクトとあなたの企業が関係があることを理解してもらえるでしょう。これによって、あなたの企業が開発に全く貢献していなくても、ほとんどのユーザーが 何かしらの 関係があると看做すようになります。問題は、ユーザーがそう考えることに開発者も気づくため、ホスティングサイトやネットワーク回線以外の開発リソースを提供しなければ、あなたのドメイン内にプロジェクトを置くことにあまりいい感情を持たない可能性があることです。何だかんだ言っても、最近はたくさんのホスティングサイトがあります。コミュニティーは結局、実態に見合わないクレジットを与えるのは、ホスティングを提供してもらう利点に見合わないと感じて、プロジェクトを他に移してしまうでしょう。よって、あなたがホスティングサイトを提供したいなら、そうすると良いでしょう— 但し、すぐにもっと積極的にプロジェクトに関わるプランを示すか、自分の主張がどれくらいプロジェクトに影響を与えられるかについて、よく考える必要があります。

マーケティング

ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、マーケティングは役に立つものです。マーケティング活動をうまくやれば、頭の固いプログラマーが理由もよくわからないのに、そのソフトウェアに対して良い印象を持つくらいにまで、オープンソース界隈の評判を作り出すことができます。ここでは、マーケティングにおける競争力学を一般的に分析するわけではありません。フリーソフトウェアの世界に関わっている企業は結局、企業自体や、ソフトウェア、そしてソフトウェアと企業の関係をどうやって売り込んでいくか、を考えるようになります。以下では、こうした努力をするにあたって陥りがちな一般的な落とし穴について解説します。 6章コミュニケーション の「宣伝・広報」も参照してください。

見られていることを意識する

ボランティアの開発者コミュニティーをあなたの味方に付けるには、はっきりしていない事柄は喋らないことが とても 重要です。すべての主張を公にする前に注意深く調べ、その主張自体をチェックする手段も公にしておきます。独自に事実を検証できるのは、オープンソースの重要な部分です。それはコード以外の部分にも当てはまります。

当然のことながら、検証できない主張をするなと企業にアドバイスする人などいません。しかし、ことオープンソースの活動においては、主張を検証する経験に長けた人が非常に多くいます— なぜなら、広い帯域のインターネット接続回線を持ち、物事を中傷するために社会的接触を持つ可能性がある人が大勢いるからです。化学工業の巨大企業が川を汚染している場合、それは検証可能ですが、検証できるのは訓練を受けた科学者のみです。彼らは巨大企業の科学者から反論され、頭をかきむしってどう考えたらよいのか困惑するかもしれません。一方で、オープンソースの世界であなたがすることは、目に見える形で記録されるだけではありません。多くの人が独立してチェックし、独自の結論を下し、それらを口コミで広めていくのです。この口コミのネットワークは既に定着しているものです。つまり、オープンソースがどのように影響するかを決める要素であり、あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにしても、特に人々が言っていることが事実である場合は、普通難しいものです。

たとえば、"プロジェクトXを作った" とあなたの組織が言うのは、実際にそうしたのであれば問題ありません。しかし、実際にコードを書いたのが外部の人間である場合、 "Xというソフトウェアを作った" と言ってはいけません。逆に、誰かがリポジトリの中身を覗いてみて、あなたの組織以外の人が変更を加えた跡が殆どまたは全くない場合は、ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。

それほど昔のことではありませんが、とてもよく知られているコンピューター会社が、重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、というアナウンスを見ました。はじめのアナウンスが出た後、私は公開されているバージョン管理システムのリポジトリを見てみましたが、そこには3つのリビジョンしか存在していませんでした。言い換えれば、彼らはソースコードのインポートを終えたこと以外は何もしていなかったのです。それ自体は変な事ではありませんでした。— だって結局彼らはアナウンスしただけですから。しかし、すぐに活発な開発が行われると期待する理由は何もなかったのです。

しばらくたってから、別のアナウンスがありました。以下にそれを示しますが、リリースナンバーとソフトウェアの名前は別のものに置き換えてあります。

Singer コミュニティーによって厳密にテストされた後、 Singer 5の Linux 版と Windows 版が、製品としての使用に耐える品質になったことを発表します。

"厳密なテスト" によってコミュニティーが明らかにしたことを知りたいと思い、私はリポジトリを再度見に行って最近の変更履歴を覗いてみました。プロジェクト自体のリビジョンは3のままでした。明らかに、コミュニティーはリリース前に修正すべきバグを ひとつも 見つけていなかったのです！コミュニティーによるテスト結果がどこかに記録されているはずだと考えて、私は次にバグ追跡システムを調べてみました。そこには確かに6つの問題が記録されていましたが、そのうちの4つは数ヶ月の間保留状態のままだったのです。

これは勿論信じがたいことです。テスターが巨大かつ複雑なソフトウェアをそれなりの時間使えば、彼らはバグを見つけるものです。たとえそうしたバグが次回のリリースに取り込まれなかったとしても、テストの結果としてバージョン管理システム上での活動か、新しい問題がバグ追跡システムに登録されていると期待されるはずです。しかしながら、どこを見ても、はじめのアナウンスと、その次のアナウンスとの間に活動の跡はみられなかったのです。

問題は、コミュニティーがテストしたことについて、企業が嘘をついたことではありません。コミュニティーがテストしたかどうかは私には分からないからです。しかし、彼らが言っていることがどれくらい嘘っぽいかは明らかでした。バージョン管理システムだけでなく、バグ追跡システムにも、厳密なテストが行われたことを示す痕跡はなかったので、企業はコミュニティーがテストしたという主張をしないか、目に見える形のテスト結果へのリンク ("278個のバグが発見されました。詳細はここをクリックしてください") を提供すべきでした。後者は誰でもコミュニティーの活動レベルを素早く把握できるようにするものです。実際は、コミュニティーがテストしたことを探すのに2、3分しかかかりませんでしたし、普通なら記録される場所に、テストの痕跡が全く残っていなかったのです。検証するのに大した手間はかかりませんでしたが、手間をかけたのは私だけではないはずです。

透明性と検証可能性は、正確なクレジットを与えるときも勿論重要です。詳しくは、8章ボランティアの管理 の「クレジット」を参照してください。

競合するオープンソースプロジェクトを攻撃しない

競合するオープンソースプロジェクトについて、否定的な意見を述べるのはやめましょう。否定的な事実については一向に構いません。 — 容易に裏が取れる主張は、比較の要素としてよく見られるものだからです。しかし、あいまいな事柄に対して否定的な評価を行うことは避けた方が良いでしょう。理由はふたつあります。まず、それがきっかけで建設的でないフレームウォーが起こりがちだからです。ふたつめは、もっと重要なことですが、 あなたの プロジェクトにいるボランティアの開発者の中からも、競合プロジェクトで働く人が出る可能性があるからです。前者より、後者の方が多く発生する可能性が高いです。なぜなら、それぞれのプロジェクトは既に同じ専門領域に属していて(それゆえに競合関係にあります)、その領域で専門知識を持っている開発者は、それを生かせる場所であればどのプロジェクトでも貢献してよいからです。直接的には開発者が重複していない状況でも、あなたのプロジェクトにいる開発者が、関連するプロジェクトの開発者を知っている可能性があります。彼らの建設的な人間関係を維持する能力が、否定的なマーケティングのメッセージによって全て壊れてしまう可能性だってあるのです。

ソースコードが公開されていない競合プロジェクトを攻撃することは、特にその製品がマイクロソフト製である場合は、オープンソースの世界では広く受け入れられています。個人的には、この傾向は (単刀直入に事実を比較するのであれば一向に構わないのですが) 残念に思っています。なぜなら、これは相手に失礼であるからというだけでなく、プロジェクトが自ら作っているものの誇大広告を信じ、それゆえに競合相手が実際に優れている点を無視し始めるのが危険でもあるからです。一般的には、マーケティングのメッセージが、自分たちの開発コミュニティーにも影響を与えるものかどうかを注意しておくとよいでしょう。マーケティングにお金が使われると、開発者は自分達のソフトウェアが持っている本当の強みや弱点を、客観的な眼で見なくなってしまいます。このため、企業の開発者はマーケティング上のメッセージに対して、公のフォーラム上でさえある種無関心な態度を示すのが普通ですし、むしろそれが期待されています。はっきりしているのは、企業の開発者はマーケティングによるメッセージに対して、公の場で矛盾した態度を直接示してはいけない (但し、それが実際に間違っているというのなら別ですが、その手の事実は早い段階からわかることでしょう) ということです。企業の開発者はそうしたメッセージをネタとして扱い、コミュニティーをマーケティングのメッセージから現実に引き戻す手段にしているのです。

Hiring Open Source Developers

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 todo: Not sure this is necessary as a separate section, but consider it. Ref Fitz's article, obviously. Move material from above into here. Look at gun.io.

Bounties

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 todo: Theory: bounties usually don't work in practice. Ask around, look for counterexamples. What about gun.io?

第6章コミュニケーション

明瞭に、わかりやすく書くという技術は、オープンソース界で暮らす上で最も重要なもののひとつといえるでしょう。ある意味ではプログラミング技術よりも重要かもしれません。プログラミングの技術は優れているがコミュニケーションスキルに欠ける人は、一度にひとつずつのことしかこなせません。また、周りの人の気を引くことにも苦労するかもしれません。逆に、プログラマーとしては二流だがコミュニケーションスキルが優れている人は、周りの人をうまく巻き込んでさまざまな作業をこなすことができます。そして、結果としてプロジェクトをよい方向に引っ張っていってくれるのです。

コードを書く能力のある人が、必ずしも他人とうまくやっていくためのコミュニケーション能力があるとは限りません。よいプログラムを書く能力と技術的な問題をうまく説明する能力とにはそれなりの相関関係はあるかもしれませんが、「技術的な問題を説明する」ということはプロジェクト内でのコミュニケーションにおけるほんの一部のことに過ぎません。それよりもずっと大事なことは、次の３つ。まず聞き手の気持ちになって考えること、自分の投稿やコメントを客観的に見るようにすること、そして他人にも自分自身の投稿やコメントを客観的に見させるようにすることです。

……といったことを口で言うのは簡単ですが、実際にやってみるとこれは非常に難しいことです。というのも、フリーソフトウェアの開発にはさまざまな人たちが参加しており、彼らのコミュニケーション方法もそれぞれ異なるからです。何か意見を述べたいときはどうすればいいのでしょう？メーリングリストへ投稿する？バグ追跡システムに登録する？それともコードのコメントとして記述する？掲示板での質問に回答するとき、相手がどれくらいの知識を持っていると想定したらいいのでしょう？当然、ここでいう「相手」とは、質問の当事者だけでなく後であなたの回答を読むであろう第三者も含まれます。開発者と利用者の関係を良好な状態に保つにはどうしたらいいのでしょう？利用者からの機能追加要求や勘違いのバグ報告、その他の雑談などに開発者たちが悩まされないようにするには？コミュニケーションの手段が尽きたら相手にどう伝えたらいいでしょうか？また、どう対処したらいいのでしょうか？

これらの問題に対する解決策は、通常は一時的なものとなります。というのも、どんな解決策であっても、プロジェクトの規模が大きくなったりプロジェクトの体制が変わったりすれば意味がなくなってしまうからです。また、これらの解決策はたいていその場しのぎのものになります。刻々と変化する状況にあわせて即興で対応しなければならないからです。すべてのメンバーは、コミュニケーション不全に陥っていないかどうかを常に気にかけ、それに対応する必要があります。このような行動を支援することも、オープンソースプロジェクトの運営の大事な一部です。以下のセクションでは、あなた自身がうまくコミュニケーションを行う方法を扱います。また、プロジェクト内での円滑なコミュニケーションを維持するための方法についても説明します。 ^[25]

書いたことがすべて

考えてもみてください。インターネット上では、あなたが何者であるかを判断する基準は「あなたが何を書いたか」「他人があなたのことをどのように書いたか」しかありません。たとえあなたが頭脳明晰で洞察力に優れ、カリスマ性のある人物だったとしても、あなたの書いたメールが中身のない乱雑なものだったら他の人たちはあなたのことを「中身のない乱雑な人」とみなすことでしょう。逆に、実際のあなたが中身のない乱雑な人だったとしても、あなたの投稿する内容が明快で有益なものなら、他の人たちは実際のあなたがどうであるかなんて気にしません。

自分が何かを書くときには十分注意を払うようにしましょう。決して損はしません。フリーソフトウェアのハッカーとして長年の経験を持つ Jim Blandy は、次のような話をしてくれました。

あれは 1993 年のこと。当時私は Free Software Foundation で働いており、 GNU Emacs のバージョン 19 のベータテストをしていました。私たちはだいたい週に一度のペースでベータ版をリリースし、それを試したユーザーからバグ報告をもらうようになっていました。直接会ったことはないのですが、いつもすばらしい仕事をしてくれるユーザーが一人いたのです。彼のバグ報告は常に明快でわかりやすく、問題を解決する大きな助けになりました。時には彼自身がバグを修正してくれることもありましたが、それもまた的確なものがほとんどでした。まさに最高の奴だったんです。
FSF では、誰かが書いたコードを取り込む前には、そのコードの著作権を FSF に渡すための法的手続きをしてもらうことになっています。見知らぬ誰かさんからもらったコードをそのまま取り込むことは、破滅への第一歩だからです。
そこで私は、彼にメールで書類を送りました。「ちょっとした事務手続きが必要なんだ。内容はここに説明してあるので、まず君がここに署名してほしい。そしてもうひとつの書類に君の雇用主の署名をもらってほしい。そうしたら君のバグフィックスを取り込めるだろう。いつもありがとう。感謝してるよ。」こんな内容でした。
彼から返ってきた返事は「私には雇用主はいません」というものでした。
で、私は言いました。「ああ、そうかい。それなら、代わりに君の通う大学に署名をもらって送り返してくれないかな？」
しばらくして、彼から再び返事が返ってきました。「あ、あの……。僕、実はまだ 13 才で、親と同居しているんですけど……」

彼の文面がとても 13 才のガキが書いたのようなものには見えなかったので、誰もそんなことは想像していなかったのです。皆に気に入られるようなものの書き方について、これからみていきましょう。

構成や体裁

ケータイのメールじゃないんだから、何も考えずにただだらだら書き連ねるといったことはやめましょう。ちゃんとした文を書き、単語の先頭はちゃんと大文字にして、適切に段落分けをするようにしなければなりません。これは、メールだけでなくその他のちゃんとした文書においても最も重要なことです。 IRC のようなその場限りのやりとりの場合は、あまりそんなことを気にする必要はありません。略語を使いまくったりしても大丈夫です。しかし、正式な掲示板上などにはそんな習慣を持ち込まないでください。メールやマニュアル、バグ報告などのように後に残ることが前提の文書については、標準的な文法やスペルで書く必要があります。また、きちんと構成されていなければなりません。これは決して「とりあえず長いものには巻かれておけ」とかいう類の話ではありません。ここで挙げた規則は、単なるしきたりといったものではないのです。文書を読みやすくするために進めてきた結果がこれなので、できるだけそれを尊重するようにしましょう。読みやすく書くようにする理由は、他人が理解しやすくなるからというだけではありません。そうすることで、あなたが「他人としっかりコミュニケートするつもりのある人だ」と認められるようになるからという面もあります。

メールを書く際には、オープンソース開発者の間で暗黙の了解となっている決まりごとがいくつかあります。

メールではプレーンテキストのみを使用し、 HTML やリッチテキストといった形式は避けましょう。テキストにのみ対応したメールソフトでは、他の形式のメールがうまく見えないことがあります。また、半角 72 文字程度で改行を入れるようにしましょう。 1 行が 80 文字を超えてはいけません。これ (80 文字) は、端末の画面上で 1 行に表示できる桁数の標準値です。これより広い幅の端末を使っている人もいるでしょうが、これより狭いものを使っている人はいません。 80 文字ぎりぎりではなくもう少し余裕を持って改行しておくことで、返信時に引用符を追加しても改行位置を気にする必要がなくなります。

実際に改行すること。 メーラーによっては、メールの作成時にはいかにも改行しているように見せていても、実際のメールでは改行されていないといったものもあります。そのまま送信すると、あなたの意図したところに改行が入っていない状態のメールが送信されることになります。受け取った側の画面によっては、改行の位置がおかしくなってしまうことでしょう。もしあなたがそのようなメーラーを使っているのなら、メール作成時に実際の改行を見せるような設定項目がないか探してみましょう。

画面の出力やコードの一部、その他フォーマット済みのテキストを記述する場合は、はっきりとわかるように位置をずらしておきましょう。どこからどこまでが地の文でどこからどこまでが引用なのかを明確にしておくことが大切です (本書を執筆しはじめた当初は、こんなことを説明するつもりはありませんでした。しかしさまざまなオープンソース関連のメーリングリストを見ていくうちに、さまざまな種類のテキストを区別せずごちゃごちゃにしている人があまりにも多いことに気づきました。それはそれは非常に読みづらいものでした。そのおかげで彼らの投稿の内容をつかみにくくなるだけでなく、率直に言って彼らはちょっとだらしない人たちだなと感じました)。

他人のメールを引用して返信する際は、適切な場所に返信内容を書くようにしましょう。必要なら、いくつかの場所に分けて書くことになってもかまいません。また、不要な部分は引用しないようにしましょう。もしその投稿全体に対して一言コメントしたいのなら、投稿の先頭 (つまり、あなたの返信を書いた後にメールの引用が続く形式) にそれを記述します。それ以外の場合は、まず関連する箇所を引用したうえで、その後に返信を書きます。

メールの件名はよく考えてつけるようにしましょう。これは、メールの中でもっとも重要なものとなります。というのも、プロジェクトの他のメンバーはそのメールを読むかどうかを件名で判断することになるからです。いまどきのメールソフトは、関連するメッセージをスレッドにまとめる機能を持っています。スレッドにまとめるための基準は、件名が同じというだけではなくその他のヘッダの内容も使用します (このヘッダの内容は、表示されないこともあります)。もしひとつのスレッド内で話題が変わるときは、返信の際に件名を適切に変更することもできます (変更すべきです)。その他のヘッダの内容によってスレッドの構成はそのまま保持されますが、件名を変えておくと、そこで話題が変わったことがわかりやすくなります。また、本当に新しい話題を始めたい場合は、新しいメールとして送信するようにします。既存のメールに「返信」して件名だけを変えるというのではいけません。さもないと、あなたの出したメールがスレッドに紛れ込んでしまいます。これによる損失は、単に時間を浪費してしまうことだけではありません。「コミュニケーションツールをうまく使いこなせる人」というあなたの評判も落ちてしまいます。

中身

きれいに体裁を整えたメールは読者の気を引くことでしょう。しかし、実際に読んでもらうには中身が大切です。「これさえ守れば中身のある内容を書ける」というようなルールはもちろんありません。しかし、それに近づくための原則ならいくつかあげることができます。

読む人のことを考えて書くようにしましょう。活発に活動しているオープンソースプロジェクトには、さまざまな情報が付きまとっています。メールの読み手が、それらの情報をすべて知っているものと期待してはいけません。実際のところ、彼らはそんな情報など知ろうともしないこともあるものです。可能な限り、読み手にとって便利な情報を提供するようにしましょう。たとえば、ほんの数分時間を使うだけで、メーリングリストのアーカイブで特定のスレッドを表す URL を調べることができます。それを示すことで、読み手が同じことをする手間を省くことができるでしょう。さらに 5 分から 10 分ほど余計に時間を割けば、複雑になったスレッドの簡単なまとめを作成することもできるでしょう。これは、あなたの投稿の背景にある話の流れを伝えるのに役立ちます。こんな風に考えてみましょう。プロジェクトがうまくいけばいくほど、メーリングリストや掲示板の書き手に対する読み手の比率が高くなります。あなたの投稿する内容が n 人に読まれているとすると、あなたがちょっと時間を使って作業をするだけで n 人ぶんの同じ時間を節約できるようになるわけです。n が大きくなればなるほど、この価値は向上します。そしてあなたがそうしているのを見れば、他の人たちも同じようにしてくれるようになるでしょう。その結果、プロジェクト全体の効率が向上することになります。n 人が苦労するのと一人が苦労するのとどちらがいいかといえば、後者でしょう。

物事を誇張しないようにしましょう。オンラインの投稿では、話が大げさになりがちです。たとえばバグを報告する人は、開発者たちの気を引くようにわざと大げさに話すこともあります。ちょっと気になる点が見つかったときに「この深刻な問題のおかげで、私 (そして友人や同僚や親戚一同) はまともにこのソフトウェアを使うことができない」といった具合に報告するわけです。しかし、この問題はユーザーからの報告に限ったことではありません。プログラマーたちだって、技術的な議論をしているときに同じようなことをしています。特に、どちらが正しいかという問題より各自の好みにかかわるような問題を扱う際にその傾向があります。

"そのやりかただと、コードが読みにくくなっちゃうよ。保守する人はたまったもんじゃないだろうな。それに引き換え J. Random の提案した方法は..."

もう少し控えめな言いかたにしたほうが、実際の気持ちは伝わりやすくなります。

"たしかにそれでも動くよ。でも、可読性や保守性を考えると、それは理想的なやりかたではないと思うんだ。J. Random の提案する方法だとそんな問題は発生しない。なぜなら..."

誇大表現を完全になくすことは不可能でしょうし、また一般にそうする必要もありません。他の誤解に比べると、誇大表現が及ぼす被害はそれほどでもありません。主に書き手側が損をするだけのことです。読み手側はそれを補正して読めるので、単に書き手が少し信頼性を失うというだけだからです。プロジェクトにおけるあなたの影響力を考えると、不要な誇大表現は避けるようにしておくべきです。そうすると、あえてキツめに表現する必要が生じた場合に周りの人たちにそれを受け入れてもらいやすくなります。

よく見直すようにしましょう。ある程度以上の量の文章を書いた場合は、完成した文章を実際に送信する前にもう一度頭から読み直すようにします。作文の授業でも同じことを教わったかと思いますが、これはオンラインの議論でも特に重要です。オンラインの議論は断続的なものになる傾向があるので (メッセージを書いている途中で過去のメールを読み直したり、何かのウェブページを確認したり、何らかのコマンドを実行してデバッグ出力を取り込んだり、……)、ついつい論旨を見失いがちです。断続的に書き上げたあとで一切チェックせずに送信したメッセージは、読み手にもそのように受け取られてしまいがちです。これは書き手にとってもうれしいことではありません。きちんと時間をとって、書いた内容を見直すようにしましょう。投稿内容がきちんとまとまっていればいるほど、あなたのメッセージを読んでもらいやすくなるでしょう。

口調

繰り返しメッセージを作成しているうちに、おそらく自分の文面がかなり素っ気ないものになっていくことに気づくことでしょう。これはほとんどの技術系フォーラムでありがちな話ですし、それ自体には特に問題はありません。一般社会でのコミュニケーションではありえないような素っ気無いやり取りが、フリーソフトウェアのハッカーたちの間ではごく普通なのです。以下に引用するのは、とあるコンテンツ管理ソフトのメーリングリストにかつて私が投稿したときに受け取った返信です。

どんな問題が発生したのか、もうちょっと詳しく正確に説明してくれませんか？

それから。

お使いの Slash のバージョンは何ですか？
元の投稿からはそれを読み取ることができませんでした。

apache/mod_perl のソースをビルドした手順を正確に教えてください。

slashcode.com に投稿された Apache 2.0 のパッチを試してみましたか？

  Shane

まさに簡潔そのものです！挨拶もなければ署名は自分の名前だけ。そしてメッセージの本文はと言えば一連の質問事項を可能な限り簡潔に並べただけ。唯一あった質問以外の文はといえば、私の元の投稿に対する間接的な批判でした。しかし、私は Shane のメールを見て気を悪くすることはありませんでした。彼の素っ気ない返答を見ても「ああ、忙しい人なんだろうな」というくらいのことしか思わなかったのです。彼は私の投稿を無視することもできたのに、あえて質問を返してきたのです。つまりこれは、彼が私の問題を解決するために時間を割いてくれているということを意味します。

すべての読み手がこのように好意的に受け取ることができるでしょうか？必ずしもそうではないでしょう。それはその人や状況によります。たとえば、ある人が自分の犯した間違い (おそらく彼女はバグを書いてしまったのでしょう) について説明する投稿をしたとしましょう。これまでの経験から、あなたは彼女が気の小さい人であることを知っています。こんな場合は、もちろん簡潔な返信を書くこともできますが少しは彼女の気持ちを気にかけるようにしたほうがいいでしょう。あなたの返信の大部分は、簡潔に技術者の視点で見た分析になるかもしれません。かなり素っ気ないものになることもあるでしょう。そんな場合でも「簡潔に書いているのは決して君を冷ややかな目で見ているからではないんだよ」とわかるようなことを最後に何か示しておきましょう。たとえば、バグを修正するためのアドバイスをひととおり忠告した後の締めの言葉として「じゃ、がんばってね。<あなたの名前>より」といったことを書いておけば、決してあなたに悪気があるわけじゃないことが伝わります。あるいは、意図的に絵文字を使ってみたりして相手に安心感を与えるという作戦も効果的です。

参加者がどう感じるかについていちいち気にするのを変に感じるかもしれません。でも、ぶっちゃけた話、人の感情というものは生産性に大きな影響を及ぼします。感情は他の意味でも重要ですが、あえて実益の範囲に的を絞ったとしても、不満を感じている人はよいソフトウェアを書くことができないといえるでしょう。しかし、電子メディアには多くの制約があるので、人が何を感じているのかを知る手がかりを常に得られるとは限りません。そこで、a) こんな場合に普通の人はどんなふうに感じるだろうか？ b) 過去のやりとりから、この人はどんな人物だと考えられるだろうか？といった内容をもとに経験から推測する必要がでてきます。中にはもっと突き放した態度で、単純に額面通りの対応をすることを好む人もいます。つまり、彼女が自分で「私、こう思うんです」と言わない限りは決してそれに対する対応をしないというものです。個人的にはこの方法はおすすめできません。それにはいくつかの理由があります。まず、現実の世界ではみんなそんなことはしないでしょう？何でオンラインだとそうなるんですか？もうひとつ。たいていのやりとりは公開の場所で行われるので、たいていの人はプライベートな場所に比べて自分の感情を抑えがちになります。もう少し正確に言うと、他人に対する感情 (感謝や怒りなど) は表現してもかまわないと考えているようですが、内心 (不安やプライドなど) は知られたくないようです。しかし、大半の人たちは周囲の人が自分のことをよくわかってくれていると感じていればよい仕事をしてくれます。ちょっとしたことを気にかけるだけで、状況をうまく判断できるようになります。そして、今以上に人をやる気にさせることができるようになるのです。

もちろん、「プロジェクトのカウンセラーになれ」「皆がうまくやっていけるよう常に手助けしてやれ」と言いたいわけではありません。しかし、皆がどのように振舞っているかを注意深く気にしていれば、実際に面と向かって会ったことのない人でもどんな人なのかがなんとなくわかるようになるでしょう。そして、自分が何か書くときの口調に気を使うようにすれば、あなたに対する周りの印象は驚くほどよくなります。これは、プロジェクト全体にとってもよいことです。

何が失礼にあたるのか

オープンソース文化の特性のひとつに、何が失礼で何が失礼でないかということに関する独特の基準があります。以下で説明する内容は、ソフトウェア開発やソフトウェア全般に特有のものではありません (数学や自然科学、工学にかかわっている人たちならおなじみのものでしょう)。しかし、フリーソフトウェアの世界は人材の出入りが頻繁に行われ、新しい人たちが常に流入してきます。こういう考え方になじみのない人たちが流入してくることも大いにありえるでしょう。

まずは、失礼ではないことについて説明します。

技術的な批評については、たとえそれが直接的で歯に衣着せぬものであっても失礼にはあたりません。実際のところ、逆にそれはほめ言葉ともとれるかもしれません。批評するということは、それが時間をかけて真剣に議論する価値があるものだと暗に認めているわけです。そして、それがうまく成長すると、批判よりも賞賛のほうが多くなってくるわけです (もちろん、その批評が個人攻撃に成り下がってしまったりその他の明らかに失礼な内容になってしまうこともありえます)。

ぶっきらぼうで素っ気ない質問、たとえば先ほど引用した Shane のメールのような質問は失礼にはあたりません。状況によってはちょっと非情に見えたり馬鹿にしているように感じられるような質問であっても、それは真剣になされたものであり、必要な情報をできるだけ手早く引き出したいという以外に隠された意図はありません。サポートセンターの有名な質問である「コンピュータのコンセントはちゃんとささっていますか？」というのは典型的な例です。サポート係の人は、ただ単にコンセントがささっているかどうかを知りたいだけです。仕事を始めたばかりのころはこの質問の前にいちいち丁寧な前置き ("すみませんが、いくつかの可能性を排除するために少々質問させていただいてよろしいでしょうか？中には基本的すぎるものもありますが、我慢してくださいね……") をしていたのでしょうが、それにも疲れてきたのでしょう。今や、彼女は単刀直入に「ささっているのかいないのか」を聞くだけになっています。フリーソフトウェアのメーリングリストでも、同様の質問が散々行われています。これは決して相手を侮辱しているのではありません。最も明らかな (そしておそらく最もありがちな) 可能性をできるだけ早い段階で排除しておきたいというだけのものなのです。それをよくわかっている人は、文句も言わずにその質問に従い、よりよい結果を得ることになります。しかし、もし文句を言う人がいてもそれをけなしてはいけません。これは、単なる文化の相違であり、どちらが悪いとかいうものではありません。あなたの質問 (あるいは批評) には隠れた意味はまったくないということを説明してあげましょう。単に情報を効率的に取得したかった (あるいは伝えたかった) だけであり、それ以上でも以下でもないと言えばいいのです。

では、何が失礼にあたるのでしょう？

先ほど、技術的な批評をすることは一種のほめ言葉にあたると言いました。その観点から言うと、真剣な批評をしないということは一種の侮辱になるかもしれません。これは、誰かの作業 (何らかの提案やコードの変更、バグの報告など) を単に無視することを言っているのではありません。あとできちんと返事をすると約束したのでない限り、何も反応しなくても一向に問題はありません。周りの人も、単に何か言うだけの時間がなかったんだとみなしてくれるでしょう。しかし、もし何か反応を返すのなら、決して手抜きをしてはいけません。時間をかけてしっかり分析し、必要なら適切なサンプルを用意し、過去ログのアーカイブから関連する議論を探すといった作業を欠かさないようにしましょう。そんなことをしている時間はないが、でも一言だけいっておきたいという場合は、メッセージの中に釈明をいれておきましょう ("これ、たしかバグとして報告されていたはずなんだけど、今ちょっと探しているヒマがないんだ。ごめんね" といった具合に)。大事なのは、文化的な基準があることを認識することです。その基準は守ること。そしてもし守れない事情があるときは、守れないことを認識していると知らせること。いずれにせよ、基準が大切です。この基準を守れなかった上にその理由も説明していないとなると、その話題 (そして関係者たち) に対して十分に時間をかけるだけの価値がないと考えているように思われてしまいます。怠け者であると思われるよりも、単に時間がないだけなんだということを率直に説明しておくほうがいいでしょう。

もちろんこれ以外にも失礼にあたることは多々あるでしょう。しかしその多くはフリーソフトウェア開発に限ったものではありません。一般常識の範囲で判断できるはずです。もしまだご覧になっていないのなら、 2章さあ始めましょう の「炎上を阻止する」も参照してください。

顔

人間の脳には、表情を認知するための領域があります。通称は "fusiform face area" です。その機能の大半は先天的なものであり、後から身につけるものではありません。個々の人物を見分けるという技能は生き延びるためにきわめて重要なものなので、専用の特別なハードウェアが発達してきたということだったのです。

インターネットを使用した共同作業は、心理学的にはちょっと奇妙なものといえるでしょう。だって、緊密な連携をとっている相手のことを、自然で直感的な方法では決して認識できないのですから。たとえばどんな顔なのかもわからなければどんな声なのかもわからない、そしてどんな背格好なのかもわからないといった具合です。これを補うには、特定の スクリーンネーム を決めてあらゆる場所でそれを使用するように心がけましょう。メールアドレスの先頭 (@ 記号より前) の部分や IRC のユーザー名、リポジトリのコミッター名、バグ追跡システムのユーザー名などなど、すべての場所でこのスクリーンネームを使用するようにします。この名前が、オンラインでのあなたの "顔" となります。短い文字列で、実際の顔と同じ働きをさせるわけです。残念ながら私たちの脳にはこれに直接反応するハードウェアは内蔵されていないわけですが。

スクリーンネームは、あなたの実名から直感的に得られるものにしましょう (たとえば私は "kfogel" にしています)。メールヘッダなど、場合によっては実名を実際に表記することもあるでしょう。

From: "Karl Fogel" <kfogel@whateverdomain.com>

実際のところ、この例には 2 つの内容が存在します。先ほど説明したように、スクリーンネームは実名と直感的に対応します。しかし、実名は 実際の名前です。つまり、これは次のような何らかの作り上げた名称とは異なります。

From: "Wonder Hacker" <wonderhacker@whateverdomain.com>

The New Yorker の 1993 年 7 月 5 日号に掲載された Paul Steiner の有名な漫画で、ある犬がコンピュータ端末にログインするというものがあります。影の声がこう言います。"インターネット上では、誰も君が犬だなんて思わないだろう" この手のことを考える人たちの頭の中にはきっと「オンライン上での立場をよりよくしたい」「オンライン上で有名になりたい」といった気持ちがあるのでしょう。 "Wonder Hacker" と名乗っておけば周りの人たちに 本当に 凄腕のハッカー (wonderful hacker) だと信じてもらえると思っているようです。だけど事実は事実。たとえ誰も気づかなかったとしても、君が犬であることには変わりありません。オンラインで仮想人格を作り上げたところで、読者を感動させることはできません。周りの人たちは、あなたのことを単なる夢想家かあるいは臆病者とみなすでしょう。周囲とのやりとりには実名を使うようにしましょう。もし何らかの理由で匿名でいたい場合は、いかにも本名っぽいハンドルを作成してそれを使用するようにしましょう。

オンラインで一貫した "顔" を使用し続けることに加えて、あなたをより認識してもらいやすくする方法がいくつかあります。もしあなたが何らかの肩書き ("医師"、"教授"、"監督" など) を持っているのなら、あまりそれを見せびらかさないようにしましょう。また、直接それに関する話題になったときは別にして、肩書きについて言及することも避けましょう。ハッカー界、そして特にフリーソフトウェア文化においては、肩書きに頼る人は排他的な臆病者とみなされます。たとえばメールの最後に書く署名の一部として肩書きが登場するくらいなら問題ありません。ただ、議論の際に自分の立場をよくするためにその肩書きを使うのは避けましょう。間違いなくそれは裏目に出ます。あなただって、肩書きなんかじゃなくあなた自身を認めてもらいたいでしょう？

メールの署名欄について補足します。できるだけ小さくて上品なものにしておきましょう。何なら署名なんてなくってもかまいません。あらゆるメールの末尾に法的な注意書きをでかでかと掲載するようなことは避けましょう。特に、フリーソフトウェアプロジェクトへの参加と両立しない意見を述べるようなときに、これは致命的です。たとえば、私が参加しているある公開メーリングリストの参加者の中には、すべての投稿の末尾にこんな様式の文書をつけてくる人がいます。

重要な通知:

あなたが誤ってこのメールを受け取ってしまったり、我々のメールに関する
免責条項の声明や監視ポリシーを読みたい場合は、以下の声明文を読むか、
このメールの送信者と連絡を取って下さい。

このメールでのやりとりは Deloitte & Touche LLP から発信されたもの
です。Deloitte & Touche LLP は 登録番号 OC303675 でイングランドと
ウェールズ地方に登録された有限事業組合です。組合のメンバーの名前は以下
の住所で閲覧可能です。Stonecutter Court,1 Stonecutter Street, London
 EC4A 4TR, United Kingdom. ここは組合の主たる営業所であり、登録済みの
事務所です。Deloitte & Touche LLP は、金融サービス機構(FSA) が認証
し、管轄しています。

このメールと添付された内容は秘密のものであり、閲覧に特別な許可が必要な
場合があります。これは送信者が意図した受信者のみが利用できます。仮にあ
なたがそうした人でない場合、このメールに含まれているやりとりや情報を開
示したり、コピーしたり、利用したりすることは強く禁じられており、違法行
為です。あなたが仮にこのメールを誤って受け取ったのであれば、"間違って受
けとりました" というタイトルをつけて IT.SECURITY.UK@deloitte.co.uk に返
送するとともに、このメールとそのコピーを破棄してください。

電子メールによるやりとりは、盗聴されたり、破損したり、改竄されたり、配
送の途中で失われたり、配送が遅延したり、中身が不完全な場合があったり、
コンピューターウイルスが含まれることがあるので、エラーがなく安全である
という保証がありません。私たちはこのような事態やそれが引き起こした結果
生じる不利益を受け入れることは出来ません。電子メールで私たちと連絡をと
りあう方々は、全員がこのリスクを受け入れているとみなされます。

私たちの顧客と連絡を取る場合、このメールと添付される内容に含まれるいか
なる意見やアドバイスも、Deloitte & Touche LLP 顧客契約書で示されて
いる諸条件によって制約を受けます。

私たちのビジネスに関係ない意見やアドバイス、その他の情報がこのメールに
記されている場合、それは私たちが発信したものでも、認めたものでもありま
せん。

たまに出てきてちょっと質問するだけという人がこんなことをするのだったら、馬鹿らしいとは感じるかもしれませんがそれほどの害はないでしょう。しかし、もしこの人物が本格的にプロジェクトに参加したいと言い出したらどうしましょう？この法的文書がきっと問題になってくるでしょうね。ここには、少なくともふたつの危険信号があります。まず、この人物は自分のツールを完全にコントロールできるわけではないということ。もしかしたら、社内のメールサーバが強制的にこのメッセージをメールに付加しており、それを迂回する手段がないのかもしれません。そしてもうひとつは、彼の所属する組織はフリーソフトウェア活動に関する理解がほとんど (あるいはまったく) ないということ。もちろんこの組織はメーリングリストへの投稿を明確に禁止しているわけではありませんが、彼の投稿は明らかに歓迎されざるものでしょう。まるで、機密情報が外部にもれるリスクの回避が最優先されているようです。

「外向けのメールには必ずこういった文書をつけておけ」というような決まりのある会社で働いている方は、無料のメールアカウントを取得してそのアドレスでプロジェクトに参加することを検討しましょう。無料のメールアカウントは、たとえば gmail.google.com や www.hotmail.com、そして www.yahoo.com などで取得できます。

陥りがちな罠

目的のない投稿をしない

オンラインのプロジェクトに参加するひとたちが陥りがちな罠のひとつに「すべてのメッセージに返信しなければ！」というものがあります。そんなことはありません。第一、数ヶ月を経てある程度の規模になったプロジェクトについて、すべてのスレッドの議論を追いかけるなんて不可能です。また、自分が注目しているスレッドについても、その投稿の多くは別に返信を要求しているものではないでしょう。開発系のフォーラムでは特に、次のようなメッセージが多くなる傾向があります。

見過ごせない問題についての意見
誰かが言ったことに関する賛成意見あるいは反対意見
これまでの議論のまとめ

これらのいずれについても、本質的には 返信は不要です。注意深くスレッドを観察していれば、あなたが言いたいことはきっと他のだれかが言ってくれるでしょう (みんなが同じように考えていたら、結局だれも発言しなくなってしまうんじゃないの？と思われるかもしれませんが、そんなことはありません。たいていの場合、何か言わずにはいられない人が 誰かしら 存在するものです)。明確な目的がある場合にのみ返信を行うようにしましょう。まずは自分に問いかけることです。「その返信で何を達成したいのか、きちんとわかっているのか？」「その目的は、自分が返信しない限り達成できないものなのか？」

あなたがスレッドに口出しをするのに適切な場面は次のふたつです。 a) 提案内容の不備に気づいたが、おそらく他の誰もそれに気づいていないと思われるとき、そして b) 誰かと誰かの間の意思疎通がうまくいっていないときに、投稿内容を整理して二人の関係を修復してあげられそうなとき。あとは、誰かが何かをしてくれたことに対する感謝のメッセージやただ単に "私もそう思います！" というだけのメッセージなどを送信してもよいでしょう。というのも、そういった投稿をすればそのメールに対する返信が不要であることがはっきりするからです。そして、そのスレッドで最後にメールを投稿した人に対して「スレッドがきれいにまとまった」という安心感を与えることもできます。しかし、そんな投稿の際にも、投稿の前によく考えるようにしましょう。「ちょっと投稿しすぎじゃない？」と思われるより「もうちょっと発言してほしいな」と思われるほうがずっとマシです (活発なメーリングリスト上でどのように振舞えばいいのかについての意見は、付録D なんで自転車置場の色まで気にしなきゃならないの？ の後半をご覧ください)。

生産的なスレッドとそうでないスレッド

活発なメーリングリストで欠かせないのは、次の 2 点です。まず明らかなのは、注目すべきものとどうでもいいものを見分けること、もうひとつは、できるだけノイズの原因となることを避けることです。自分自身の投稿の S/N 比を高く保つだけでなく、他の参加者のメッセージの S/N 比も同様に高くしたい。それができないならいっそのこと投稿しないでほしい。

どうすればいいのかを考えるために、まずは状況を考えてみましょう。この中で、生産的でないスレッドといえるのはどれでしょうか？

すでに行われている議論をもう一度繰り返す。まるで、最初に投稿した内容を誰も読んでいないのではないかと思われるような状態。
話がどんどん誇張されていき、その議論にかかわる人がどんどん減っていく状態。
実際には何もしない人たちばかりが大騒ぎし、実際に動くことになる人が黙り込んだままの状態。
はっきりとした提案を出さないまま、多くのアイデアが議論されている状態 (もちろん、どんな興味深いアイデアだって最初はぼんやりとした想像から始まるものです。ここで大事なのは、そこからどう膨らませるかです。そのスレッドは、ぼんやりとした空想レベルのアイデアを具体的にまとめあげる流れになっていますか？それとも、別の想像や関係のない想像などのどうでもいいことに振り回されていますか？)

うまく機能していないスレッドがすべて無駄なものであるとは限りません。中には重要な話題が含まれているかもしれません。そんな場合は、そのスレッドが盛り上がっていないということ自体が問題です。

あまり押し付けがましくならないようにスレッドの流れをよい方向に持っていくのは、ある種の芸術といえます。単に「無駄な話をするのはやめよう」とか「もっと前向きなことを投稿するようにしようよ」とか言うだけではうまくいきません。もちろんこれらを個人的に行うことはできるでしょうが、ちょっと強く言ってしまうと攻撃的になってしまいます。そうではなく、前に進むためには次に何をすべきなのかを提案しなければなりません。あなたが望む結果が得られるような道筋を (無理やり指示しているような流れになるのを避けつつ) 示してあげるのです。提案のよしあしを区別するのは、主に口調の問題となります。たとえば、こんなやり方はよくありません。

これ以上議論しても、収束しないでしょう。とりあえず、だれかがこの提案を実現するパッチを書くまでこの話題はやめることにしませんか？同じ議論を何度も繰り返すなんて無意味です。ごちゃごちゃ言うより、結局はコードでしょ？

それよりは、こちらのほうがいいでしょう。

いくつかの提案はありましたが、結局どれもうまく膨らませることができず、多数決をとる段階まではいきませんでした。また、今や新しい意見も出てこなくなっています。単にこれまでの議論を繰り返しているだけです。今私たちに必要なのは、この提案に関する完全な仕様かあるいはパッチを含む投稿でしょうね。そうすれば、少なくともなんらかのアクション (その仕様について合意をとったりパッチをテストしたり) ができるでしょう。

後者のアプローチを最初のものと比べてみましょう。最初のほうは「私」と「その他のメンバー」の間に一線が引かれていましたが、後のほうは違います。みんなをうまく議論に巻き込んでいます。あなたがそのスレッドの議論に最初からかかわっていたかどうかに関係なく、主語を「私たち」とすることが重要です。これによって、それまでスレッドをみているだけで何も発言しなかった人たちに対しても「みんなにかかわる話なんだ」ということを確認させることができるからです。スレッドが煮詰まってしまった原因については説明していますが、誰かをののしったり自分の意見を押し付けたりはしていません。淡々と事実を述べているだけです。最も重要なのは、前向きに進めるために次に行うべきことを示している点です。これにより、ただ単に議論を打ち切らせる (そんな制限をしても、だれも守ってくれないでしょう) のではなくより建設的な方向に会話を持っていこうとしているのです。

そのスレッドをもっと膨らませたいといった状況ばかりであるとは限りません。時には、こんなスレッドはさっさと打ち切ってしまいたいと思うこともあるでしょう。この場合には、スレッドを終了させるための投稿をします。もしそのスレッドが既にみんなに忘れ去られてしまっているものなら、あなたが投稿するだけでそのスレッドは事実上終了するでしょう。もちろん、スレッドを打ち切るための完璧な方法なんてありません。もしそんなのがあったとしても、使いたいとは思わないでしょう。しかし「何か目に見える成果を出してください。でなければこのスレッドを終了します」とお願いすると、うまくいくことでしょう。ただ、スレッドを終了させるのは十分に考えた後にしてください。話題によっては、雑談の中から生産的な内容に発展することがあるかもしれません。あまりに拙速に打ち切ってしまうと、あなたはせっかちな人と思われてしまいます。

どんなスレッドであっても、すぐに終了するとは期待しないでください。あなたが投稿した後にも、おそらくいくつかの投稿があるでしょう。あなたのメールがまだ届いていなかったり、あるいはいわゆる「最後にひとこと」が言いたかったりといった人たちによるものです。心配することはないですし、先ほどの投稿を繰り返す必要もありません。スレッドが収束する (あるいはさらに膨らんでいく) のを黙って見守っていればいいのです。完全にスレッドをコントロールすることなんてできません。ただ、あなたは多くのスレッドに何らかの効果を及ぼせるはずです。

簡単な議題ほど長引く

どんな議題であっても議論は紆余曲折するものですが、技術的な難度が低い話題になればなるほど議論が発散する可能性があがります。結局のところ、技術的な難度が高い話題になればなるほどその話題についていける人の数が少なくなるということです。そんな話題についていける人というのは、たいていは長年経験を積んだ開発者です。彼らはこれまでに何度となくそのような議論に参加しており、全員が納得のいく合意を得るにはどうしたらいいのかを知っているのです。

というわけで、合意を得ることが最も難しいのは、誰にでもわかる (誰でも意見が言える) レベルの技術的な問題となります。また同様に、組織論や広報活動、資金調達などの "やわらかめ" な話題も合意を得にくいものです。これらの話題については、人はいつでも気の済むまで議論に参加することができます。議論に参加するための前提条件もなければ何が正しくて何が間違っているのかを (後になっても) 決めることもできない、そして、他人の意見を聞いてから「後出し」で議論に参加することもできるからです。

議論の量と話題の複雑さが反比例するという原則はよく知られており、俗に Bikeshed Effect (自転車置場効果) と呼ばれています。ここで、Poul-Henning Kamp による説明を見てみましょう。もともとは BSD 開発者向けに投稿されたものですが、今や超有名になっています。

話せば長くなる昔話だけど、実際のところは単純な話だ。C・ノースコート・パーキンソンが 1960 年代初期に書いた「パーキンソンの法則」という本があって、そこにはものごとの管理に関するさまざまな洞察が書かれていたんだ。
[...]
自転車置場の例にでてくるもう一方の役者が、原子炉だ。なんだか、いかにも時代を感じさせるなぁ。
パーキンソンは、委員会に乗り込んで数百万から数億ドルもの原子炉建設計画を承認させる方法を説明している。しかし、原子炉ではなく自転車置場を作りたいと思ったら終わりのない議論に巻き込まれることになるだろうとも言っている。
パーキンソンによると、原子炉はあまりに巨大で高価そして複雑であるためにみんながその内容を把握できなくなるということだ。考えようともせずに思考停止してしまい、「まぁここまで来る前に誰か他の人が一部始終をチェックしただろう」ということになってしまう。リチャート・P・ファインマンの著書には、これに関連するロス・アラモスでの興味深い事例がいくつか紹介されている。
さぁ一方自転車置場だ。週末をつぶせばだれでも作ることができ、余った時間にテレビで試合を見て楽しむことさえできるだろう。どんなに用意周到であったとしても、どんなに妥当な提案だったとしても、だれかが機会をとらえては、自分もなにかやっていることを示したり、自分もそれに注目してることを示したり、「俺を忘れるな」と言ったりするだろう。
デンマークでは、こういったことを「指紋をつける」って言うんだ。個人的なプライドや見栄のために何かをして、あとからその証拠を見せられるようにする。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものよくやりそうなことでもあるが、一般人だって機会があればやりそうだよ。ほら、よく生乾きのセメントに足跡がついてたりするだろう？

(彼の投稿の完全版はかなり長くなりますが、一読の価値はあります。付録D なんで自転車置場の色まで気にしなきゃならないの？ でご確認ください。また http://bikeshed.com も参照ください)

これまでにグループでの議論に参加したことがある人なら誰でも Kamp の言っていることがよくわかるでしょう。しかし、自転車置場に色を塗るようなことを避けるよう全員を説得するのは不可能です。できることといえば、そんな状況を見つけたときに「こういう状態になっているんじゃない？」と指摘するくらいです。そして、影響力の強い開発者たちに対して「早めに筆をおろしてくれませんか？」とお願いするのです。そうすれば、少なくとも彼らはノイズの原因とはならなくなります。自転車置場の塗装大会を完全にやめさせることはできないでしょうが、プロジェクトの文化をうまく育てていけばそんな羽目になる頻度を下げる (そして発生したときも早く収束できるようにする) ことができます。

宗教論争を回避する

宗教論争 (holy war: 聖戦) とはある種の論争のことです。ただ、時には話し合いで解決できないほど大きな問題になることもあります。お互い、相手側を打ちのめすまで議論を続けようとします。これは、先ほどのいわゆる「自転車置場問題」とは多少異なるものです。自転車置場の議論に加わっている人たちは、先を競って自分の意見を表明します (だって簡単に意見を言えるから)。でも、彼らは必ずしもそれを強く主張するわけではありません。時には相手の意見に理解を示すこともあります。しかし「宗教論争」においては、相手の意見に耳を傾けた時点で負けです。みんな「正解はたったひとつである」という点では合意しているのですが、ただ「正解がどれか」という点で争っているのです。

いったん宗教論争が始まってしまったら、みんなが満足するようなかたちでそれを収束させることは不可能です。炎上している真っ只中で「これって宗教論争じゃない？」と指摘したところで無意味です。そんなこと、みんなとっくに知っているわけなんだから。残念なことに、宗教論争の多くは「この問題は話し合いを続ければ解決できるのか」という点に対しても意見の対立が発生するものなのです。第三者からみれば、どちら側も相手を説得できそうにないのは明らかです。当事者たちは「相手側は何もわかっちゃいない。うまく説得すればきっと私たちの考えをわかってくれるだろう」とお互い考えています。私は「こんな争いには正解なんてない」とは 言いません。時には正解があることもあるのです。私も過去に何度か宗教論争に巻き込まれましたが、そのときはいつも私たちのほうが正論でした。とはいえ、そんなのはどうでもいいことです。どちらが正しいのかを納得いくように説明する方法なんてないのですから。

宗教論争を解決しようとしてやりがちなことは「こんなことをいつまでも続けていても時間のムダじゃないか！もういい加減やめてしまわない？」と言うことですが、これでは不十分です。このやりかたには 2 つの問題があります。まず、これまで議論に費やしてきた時間や気力は取り戻せないということです。いま大事なのは「あとどれだけ議論しなければならないのか？」です。もし「もうちょっと話をすれば解決できそうだ」と感じている人が何人かいるのなら、 (少なくとも彼らの視点からは) 議論を続けるのは理にかなっています。

もうひとつの問題は、そこで議論をやめてしまう (現状維持とする) ことが、どちらか一方に事実上の勝利宣言をするのに等しいことがあるということです。また時には「とにかく現状をどうにかしなければならない」という点では合意しているが「どのように変えるのか」で争っているということもあります。こんな場合は、議論を打ち切ってしまったら誰の得にもなりません。そのことはみんなわかっているので、この場合は議論を続けることも可能でしょう。

じゃあ、いったいどのように処理したらいいのでしょう？

まず言えることは、そんな議論が起こりえないようにするということです。これは、皆さんが思っているほど難しいことではありません。

宗教論争になりがちなネタは、だいたい予想がつきます。プログラミング言語についてだったりライセンスについてだったり (10章ライセンス、著作権、特許 の「GPL とライセンスの互換性」をご覧ください)、あるいは reply-to の処理についてだったり ( in 3章技術的な問題 の「Reply-to はどうすべきか」をご覧ください) などです。たいていのプロジェクトは一度や二度はこういう経験をしており、それによって開発者たちの結束が急速に深まったりします。このような争いをやめさせたり、あるいは被害をできるだけ抑えたりするための方法は、どこに行っても同じです。たとえ自分側の意見が正しいと確信しているのだとしても、 とりあえずは 相手側の意見にも耳を傾け、理解を示すようにしましょう。この手の争いでよくある問題は、それぞれの側が可能な限り敷居を高くしてしまって自分たち以外の考えはみんなまったくばかげていると言い切ってしまうことです。このような場合、相手側を説得したり意見を変えさせるようにしたりするのも難しくなってしまいます。つまり、単に相手に「まちがっていました」と認めさせるだけではなく「心から まちがっていました！」と認めさせなければならなくなるのです。相手側に説得を受け入れてもらいやすくするには、まずあなた自身の確信を押し付けないようにすることです。つまり、現在行われている議論の内容をきちんと理解していること、そして説得力があるかどうかはともかく、少なくとも分別はあるということを示すことです。相手が返事を返す余地があるような意思表示をするようにしましょう。そうすれば、状況は改善するでしょう。結果としてあなたが望んでいたそのものは得られないかもしれませんが、少なくとも、プロジェクトの士気に影響を及ぼすような巻き添え被害は防ぐくとができます。

宗教論争が避けられない状況になったら、あなたがどの程度それにかかわるのかを早めに決断しましょう。なんだったら、その手の議論を正式に放棄してしまってもかまいません。そうすれば、皮肉を言ったり反対意見に対して捨てゼリフを残したりせずにきれいに宗教論争から身を引くことができます。議論を放棄する場合は、潔く行うことが大切です。

プログラミング言語に関する宗教論争は、少し事情が異なります。というのも、彼らは技術的に高いレベルにある人であることが多く、また多くの人が何らかの意見を持っており、利害関係が非常に高くなるからです。その争いの結果、プロジェクトで使用する主要なプログラミング言語が決まってしまうかもしれません。一番いい方法は、プロジェクトの初期段階のうちに開発者間で言語を選択してしまうことです。そしていったん決めた開発言語については、「それが他の言語より優れているから」という理由 ではなく、「それがいちばん書き慣れているから」という理由で守っていくようにします。決して「プログラミング言語を学術的に比較する」といった方向に陥らないようにしましょう (なぜだかよくわかりませんが、誰かが Perl を持ち出したとたんにこの方向に話が進むことが多いようです)。この手の話題はまったく無駄なものであり、避けるべきです。

この手の議論に関する歴史的な背景については http://catb.org/~esr/jargon/html/H/holy-wars.html をご覧ください。また、Danny Cohen によるより簡単な解説が http://www.ietf.org/rfc/ien/ien137.txt にあります。

"口やかましい少数派" について

メーリングリストでの議論においては、少数派の意見がいかにも大きな異議であるように見せることは簡単です。長々としたメールをメーリングリストに大量に投稿すればいいのです。これは議事進行妨害と似ていますが、反対意見が大きくなっていると思い込ませることにはより強力な意味があります。というのも、あまりにたくさんの意見が行きかうと「誰がいつ何を言ったのか」を追いかけるのが面倒になってしまうからです。「よくわからないけど、何だか重要なことを議論しているんだな」と本能的に感じ、騒ぎがおさまるまでしばらくおとなしくしている人が多くなるのです。

このような効果をうち消す最もよい方法は、何らかの証拠をもって「異議を申し立てている人がどれだけ少数であるかということ」「他の大半の人たちが合意しているということ」を明確に指摘することです。より状況を明確にするために、明確に意見は表明していないがおそらく多数派に合意するであろうと思われる人たちに個別に意見を聞いてみてもいいでしょう。反対している人たちが自分の意見を故意に膨らませようとしているといったことを指摘するのはやめましょう。多分彼らはそんな気持ちはないでしょう。たとえ意図的にしているのだとしても、それを指摘したところで戦略上なんの利点もありません。あなたがすべきことは、単に実数を比較して示すこと。そうすれば、他の人たちは自分の実感とずれていることをわかってくれるでしょう。

この手法は、賛成か反対かがはっきりするような議論に関しては適用できません。この方法がうまくいくのは、誰かが大騒ぎしているものの大半の人にとってはそれが議論すべき問題なのかどうか判断できないといった場合です。議論をしばらく見ていて、それが (メールの数のわりには) あまり人々の気を引いていないものであってどうでもいい議論であると判断したら、それをはっきりと示してあげましょう。いわゆる "口うるさい少数派" が目立っているときには、あなたの投稿が一服の清涼剤となるでしょう。こんな場合、たいていの人はちょっと落ち込んでいます。「なんてこった。大量の投稿があるので多分重要なことを話しているんだろうけど、いったい何がどうなっているのかちっともわかりゃしない」といった気分です。実際の議論が必要以上に大げさになりすぎていたことを説明すれば、彼らはそれまでの流れを見直して何が起こっていたのかを理解してくれるでしょう。

扱いにくい人たち

扱いにくい人たちに対して電子会議室上で対応するのは、面と向かって対応することに比べて多少難しくなります。ここで言う "扱いにくい" とは "失礼な" という意味ではありません。確かに失礼な人たちは不快なものですが、彼らが必ずしも扱いにくいというわけではありません。本書では、すでに失礼な人たちへの対処法は説明済みです。とりあえず一言指摘したあとは、そのまま無視してしまうか、何事もなかったかのように他の人たちと同じよう接すればいいのです。それでも彼らが失礼な振る舞いを続けるようなら、彼らはきっとそのプロジェクトの誰にも見向きもされなくなるでしょう。自業自得です。

本当にやっかいなのは、あからさまに失礼な態度であるとはいえないがプロジェクトの進み具合に悪影響を与えている人たちです。彼らは他の人たちの時間や労力を余計に費やさせるだけでプロジェクトに何の利益ももたらしません ^[26]。

そういった人たちは、プロジェクトを進めるにあたって要となる箇所を探してはそこで自分の影響力を誇示しようとします。このような行いは、単に失礼であるだけの人よりよっぽど油断なりません。なぜなら、その振る舞いだけでなくそれによる被害も明白だからです。このような行いの典型的な例は、いわゆる議事進行妨害です。進行中の議題について、誰かが (いかにももっともらしく聞こえるように) 「まだ結論は見えていない。もっと別の解決策も検討してみるべきだ。違う視点から見直してみるのもいい」といった意見を述べるが、実際のところは既にほぼ合意がとれているかあるいは採決をとる準備ができているといった状況です。別の例を考えてみましょう。なかなか合意が得られない議論において、「まずはお互いの意見の不一致を確認してこれまでの議論のまとめを作成しよう」という流れになることがあります。そのまとめを作成した結果、自分が気に入らない方向に進むかもしれないと考えている人は、まとめの作成作業さえも邪魔しようとするかも知れません。妥当な提案に対していちいち反対したり、誰も喜ばないような新たな話題を持ち出したりなどといった手段で粘着してくるわけです。

扱いにくい人たちへの対応

こんな振る舞いに対抗するには、何が彼らをそうさせるのかを理解することが助けになります。たいていの人は、意識してそのように振舞っているわけではありません。毎朝起きたときに「さあ、今日も斜に構えて議論をかき乱し、みんなをいらいらさせてやろう」と考える人なんていませんよね。そんな行動に彼らを導くのは、たいていの場合は「自分はこのグループでの議論や意思決定の際に仲間はずれにされているのではないか」という被害妄想です。彼らは自分がないがしろにされていると感じています。あるいは (もっと深刻な場合は) 自分だけをのけものにして他のメンバーだけで何かをしようとたくらんでいると感じることもあります。そう感じている彼にとって、プロジェクトの進行に口をはさんで 何とか 自分のほうに目を向けてもらえるようにすることは完全に正当な振る舞いです。極端な場合は、彼は「自分が戦わなきゃこのプロジェクトはダメになってしまう」と思い込んでいるかもしれません。

こういった攻撃は、その性質上みんなが一斉に気づくものではありません。人によっては、明白な証拠があらわれるまでそれを認めないかもしれません。つまり、このような攻撃を何とか収めるのはそれなりの作業になるということです。何かが起こっていると自分が気づくだけでは不十分で、他のメンバーを納得させるだけの証拠を用意する必要があるのです。その証拠を示す際には十分な注意が必要です。

戦うだけの余力がない場合、とりあえずはしばらく見過ごしておくのが得策です。ちょっとした感染性の病気と同じようにとらえらばいいのです。プロジェクトが極端に衰弱していない限り、病気に感染してもなんとかなります。下手に薬に頼ると、何らかの副作用があるかもしれません。しかし、無視できない程度の被害が出始めたら、それが動き出すときです。まず、目にしている状況をしっかり書き留めてください。公開しているアーカイブを参照するようにしましょう。このような場合のためにも、プロジェクトの活動をアーカイブしておくことが大切になります。よい手がかりが見つかったら、次にプロジェクトの他のメンバーと個人的な話し合いをします。このときに「こんな風に感じるんだけど……」と話すのではなく、まず「最近何か感じることはない？」というように問いかけるようにします。トラブルメーカーの行いについて他人がどう思っているのかについて聞けるのは、これが最後のチャンスになるかもしれません。あなたがいったんトラブルのことについて話し始めるとどうしても相手の意見は変化してしまい、もともとどう考えていたのかを思い出せなくなってしまうでしょう。

個人的な話し合いの結果、同じような問題を感じている人が少なからずいるとわかったとしましょう。そろそろ何か行動をおこすときです。このときは ほんとうに 用心深くならなければなりません。この手のトラブルメーカーは、しばしば「自分が不当にいじめられている」と思い込んでしまいがちだからです。何をするにしても、「プロジェクトの動きを故意に妨害している」「被害妄想に陥っている」あるいはその他あなたが疑っていることが事実であると決め付けて責めたりしてはいけません。あなたの最終的な目標は、もっと妥当なものでかつプロジェクト全体の利益のためになるものでなければなりません。彼らの振る舞いを改めさせるか、あるいは追い出してしまうか。最終的にはどちらかになるでしょう。あなたと他の開発者たちとの関係によっては、事前に個別に手を組んで共同で責めていくことも有効かもしれません。ただ、それが裏目に出ることもあります。裏でこそこそと何かをして中傷しているようにとられたら、あまりよく思われないかもしれません。

たとえまずい行動をしたのが手を組んだ相手のほうだったとしても、言い出したのがあなたである以上、周りから見ればまずい行動をしたのは あなた だということになります。自分のいいたいことを示す例をできるだけ多く集めるようにしましょう。そして、できるだけやさしく紳士的に説得するようにするのです。もしかしたら問題の当事者を説得しきれないかもしれません。しかし、その他大勢の人たちを説得できればそれで十分です。

実例

私がフリーソフトウェアにかかわりだしてから 10 年以上たちますが、私が覚えている限り、これまでにこのようなことが起こったのは一度だけです。そのときは、実際に投稿をやめてもらうよう働きかけるはめになりました。このような場合によくありがちなことですが、実際のところ彼はまったく悪気はなく、良かれと思ってやっていただけでした。彼は単に、投稿すべきときと控えるべきときの区別ができなかったのです。私たちのメーリングリストは一般に公開されており、彼は非常に頻繁にそこに投稿していました。さまざまな内容について質問を繰り返すこともあり、コミュニティーの間で徐々に目障りに感じられるようになってきました。質問を投稿する前に少しは自分で調べるようにやさしくお願いしてはみたのですが、彼には何の効果もありませんでした。

最終的に有効だったのは、完全に中立で定量的なデータを示すことでした。開発者のひとりがアーカイブを調べ、以下のようなメッセージを何人かの開発者に個別に送ったのです。問題の人 (以下の一覧における 3 番目の人。ここでは仮に "J. Random" とします) がプロジェクトにかかわり始めてから日がまだ浅いこと、そしてコードやドキュメントに一切貢献していないこと。なのにメーリングリストの投稿ランキングでは 3 番目になっていることがわかります。

From: "Brian W. Fitzpatrick" <fitz@collab.net>
To: [... 匿名性を確保するため、送信先は省略します ...]
Subject: The Subversion Energy Sink
Date: Wed, 12 Nov 2003 23:37:47 -0600

過去25日間の svn [dev|users] リストの投稿数トップ6は以下のとおりです。

    294  kfogel@collab.net
    236  "C. Michael Pilato" <cmpilato@collab.net>
    220  "J. Random" <jrandom@problematic-poster.com>
    176  Branko Čibej <brane@xbc.nu>
    130  Philip Martin <philip@codematters.co.uk>
    126  Ben Collins-Sussman <sussman@collab.net>

この中の5人は、近々発表予定の Subversion 1.0 に貢献してくれている人たち
です。

また、この中の1人は、他の5人の足を引っ張って時間と気力を浪費させているだ
けの人です。彼のおかげでメーリングリストが停滞するだけでなく、無意識のう
ちにSubversionの開発自体も速度が低下してしまっています。詳細な解析をした
わけではありません。ただ、Subversionメーリングリストのスプールをざっと
grepしてみたところ、この人物がメールを投稿するたびに、他の5人の中の少な
くとも2人が返信をするはめになってしまっているようです。

そろそろ何らかの行動を起こすべきときじゃないでしょうか？ たとえそれで当
該人物がここから去ってしまうことになってもやむを得ません。控えめにやさし
く説得するだけでは何の効果もないことはすでに証明されています。

dev@subversion はバージョン管理システムの開発を手助けするためのメーリン
グリストであり、グループセラピーを行う場所ではありません。

- 3日もの間、大量のメールと格闘し続けた Fitz より

最初のうちは気づかなかったのですが、J. Random (仮名) の振る舞いはプロジェクトの進行を妨げる典型的なものでした。彼は、議事の進行を妨害しようとするなどの具体的な行動をとったわけではありません。ただ「各メンバーに節度を持った対応を期待する」というメーリングリストの方針をうまく利用していたということです。私たちは「どんなネタをどんなときに投稿すべきか」といった判断は完全に各個人に任せていたのです。したがって、誰かが不適切な投稿をしたりそれを改善するそぶりを見せなかったりしても、私たちはどうすることもできなかったのです。彼が頻繁に投稿を繰り返すことを他のメンバーはみんな気にしていたのですが、「それは○○という規則に違反している」と指摘する根拠はなかったのです。

当時の Fitz のやり方は、巧妙なものでした。彼はまず定量的な証拠を集めました。そして、それを慎重に広めたのです。まずは、仲間になってくれると心強いと思われるごく一部の人たちにだけそれを伝えるようにしました。何らかの対応が必要だと合意した彼らは、J. Random に電話をかけて問題点を直接指摘し、投稿を控えてくれるよう頼みました。彼は、なぜそんなことを言われなければならないのかをわかっていないようでした。まあ、もしわかってくれるだけの人であれば、最初からこんな問題は起こらなかったでしょうけどね。結局、彼は投稿をやめることに同意してくれました。そしてメーリングリストは通常どおりに戻ったのです。最終的にこの作戦がうまくいった理由のひとつは「彼の投稿をスパム対策用のソフトウェア (3章技術的な問題 の「スパム対策」をご覧ください) で拒否することもできるんだよ」という圧力を遠まわしに与えたことにもありました。しかし、このような圧力を与えることができたのも、 Fitz が最初に主要人物に根回しをしておいたからこそです。

巨大化への対応

オープンソース界では、成功の代償は重いものです。あなたの書いたソフトウェアが有名になればなるほど、その情報を知りたがる人の数も劇的に増加します。一方、みんながほしがっている情報を提供できる人の数は、それほど急激に増えることはありません。さらに、たとえ情報をほしがる人と情報を提供する人の増加率がうまい具合にバランスがとれていたとしても、オープンソースプロジェクトのメンバー間でのコミュニケーションは人数が増えれば増えるほど面倒になります。たとえばメーリングリストを考えてみましょう。たいていのプロジェクトには、一般的なユーザー向けのメーリングリストがあります。いわゆる "users" とか "discuss" とか "help" などといった名前のメーリングリストです。名前が何であるかにかかわらず、これらのメーリングリストの目的は同じです。疑問がある人が質問をすれば何らかの答えが得られるということ、そして、それらのやり取りをただ眺めていることでそれなりの知識を得られるということです。

この手のメーリングリストのメンバーは数千人になることも珍しくありません。また、一日あたりの投稿数が数百になることもよくあります。しかし、このくらいの規模になってくると、システムは徐々に破綻しはじめます。個々のメンバーが一日にさばききれない量のメッセージを受け取るようになると、メーリングリストのメッセージがその人にとって重荷になってしまうでしょう。考えてもみましょう。たとえば、Microsoft が Windows XP 用にこの手のメーリングリストを開設したとします。 Windows XP を使っている人は、世界中に何億人といます。そのうちのほんの 0.1% の人が 24 時間のうちにひとつの質問を投稿したとすると、この仮想メーリングリストの一日の投稿数は10万通にもなってしまいます! もちろん、実際にはそんなメーリングリストは存在しません。もしあったとしても、だれもそんなメーリングリストのメンバーでい続けることはできないでしょう。これはメーリングリストに限った問題ではありません。 IRC チャンネルやオンラインの掲示板、その他個人からの質問を受け付けるあらゆるシステムには同じ論理があてはまります。この論理が示唆するところはあまり思わしくありません。オープンソースモデルでしっかりとしたサポートを続けようとすると、世界征服できるほどにまでプロジェクトの規模を拡大するのは不可能だということです。

メーリングリストや掲示板の規模が臨界点に達しても、大爆発が発生するといったことはありません。負の反応は、静かに出てくることになります。たとえばメーリングリストから脱退する人や IRC チャンネルから去る人が出てきたり、ノイズが目障りだという理由で質問を控える人が出てきたりといった具合です。人がみなこのように合理的な選択をすれば、掲示板の規模はある程度管理可能な範囲で落ち着くのでは? と考える人がいるかもしれません。しかし、このような場合にまずメーリングリストから去っていくのは、たいていの場合は経験を積んだメンバーです。一方、参加して日が浅い人たちはそのままそこに残ったままでいるでしょう。つまり、プロジェクトの規模が大きくなりすぎてもまだ同じコミュニケーションモデルを使用していると、その場における質問や回答のレベルが徐々に低下していくということになります。まるで、(実際にはそうではないかもしれないのに) 新参者のほうが古参メンバーより劣っているというように見えてしまうかもしれません。このような状況になると、古株のメンバーはそこに参加するメリットをあまり感じられなくなり、どこか他の場所を探すようになるでしょう。プロジェクトの規模が拡大したときにコミュニケーションの仕組みをどうするか。これには、次のふたつの戦略がかかわってきます。

全体としては巨大化の悪影響が出てきつつあるようだが、特定の分野の話題についてはまだその影響を受けていない というところを見つけたら、その分野の話題だけに特化した会議室を新たに作成する (つまり、被害が及ばないうちに他の場所に避難させる)。
情報を自動的に取得できる場所を多く確保し、それをきちんと系統立てて管理する。また、常に最新の情報を反映させ、人が見つけやすいようにする。

作戦 (1) は、通常はそんなに難しくありません。たいていのプロジェクトは、最初はメーリングリストがひとつだけで始まります。そこでは、一般的な議論のほかに、機能追加の要望や設計に関する疑問、コーディングに関する問題などさまざまな内容をごちゃ混ぜにして扱います。そしてプロジェクトにかかわるすべての人たちがそのメーリングリストに参加しています。しばらくすると、扱う内容によっていくつかのメーリングリストに分割したほうがよいということがわかってきます。たとえば、あるスレッドでは開発に関連する話題が盛り上がっており、別のスレッドでは、いわゆる「○○をするにはどうすればいいの？」的な質問が行われ、また別のスレッドではバグレポートや機能追加要求が行われていたりといった具合です。中にはこれらのスレッドの複数に参加する人もいるかもしれませんが、ここで重要なのは、これら異なるタイプのスレッドには共通点がほとんどないということです。ということで、これらの話題をそれぞれ個別のメーリングリストに分割しても、特に弊害は出ないでしょう。

この分割は、二段階の手順を踏んで行います。まず新しいメーリングリスト (あるいは IRC チャンネルなど) を作成し、次にそのメーリングリストを適切に使用するよう、他の人たちを誘導することになります。後半の作業は数週間程度の時間をかけて行うことになりますが、それくらいあれば人はみなその考えを理解してくれるでしょう。あなたがすべきことは、間違った場所に投稿してきた人に対して他人にも見える場所でそれを指摘してあげることです。そうすれば、他の人たちはいちいち指摘されなくても新しい場所を利用することになるでしょう。すべてのメーリングリストの一覧をまとめたウェブページを作成するのも有用です。他の人に新しい場所を指定する代わりに、そのページを参照させるだけでよくなります。うまくいけば、他のメンバーも投稿の前にそのページを参照してくれるようになるかもしれません。

作戦 (2) は、そのプロジェクトが存続する限りずっと続けることになる作業です。もちろんこれは、ドキュメントを常に最新の状態に保って (2章さあ始めましょう の「ドキュメント」をご覧ください) みんなをそこに誘導するという作業の一環でもあります。しかし、それ以外にも考慮すべき点があります。次のセクションでは、こちらの作戦について詳しく見ていきます。

アーカイブを目に付きやすくする方法

通常は、オープンソースプロジェクトにおけるあらゆるやり取りの内容は (IRC での会話は例外として) 保存されます。そのアーカイブは、一般に公開された検索可能な場所に配置され、常に参照できるようになります。すなわち、なんらかの情報が特定の場所に保存されたら、それは常に同じ場所に存在する必要があるということです。

できるだけこれらのアーカイブを活用し、その存在を広めるようにしましょう。たとえわかりきった内容の質問に答える場合であっても、その答えを含むアーカイブがありそうならそれを探して場所を示したほうがいいでしょう。あなた自身が常にそのようにするよう心がけていると、「アーカイブがそこにある」「アーカイブを検索すれば答えが得られる」ということに気づいてくれる人もあらわれるでしょう。また、同じ内容を改めて書き直すのではなくアーカイブを参照させるようにすることで、「同じ情報を重複させない」という指針を守ることができます。同じ回答をわざわざいろんな場所に分散させる必要なんてありますか? このような重複をできるだけ減らすように心がければ、ある回答に以前にたどり着いた人が、それを再び見つけ出すことも簡単になるでしょう。参照をうまく利用することは、検索結果全般にもよい影響を与えます。というのも、インターネットのサーチエンジンは他の場所から多く参照されているリソースを重視するからです。

しかし、場合によっては情報を多重化してもいいこともあります。たとえば、あなた以外の人が投稿した次のようなメッセージがアーカイブ内にすでにあるとしましょう。

おそらく Scanley のインデックスが狂い始めているのでしょう。
復旧させるには次の手順を実行してください。

1. Scanley サーバを停止する
2. Scanley に同梱されているプログラム 'defrobnicate' を実行する
3. サーバを立ち上げる

数ヵ月後に、また別の人が「インデックスがおかしいみたいなんです」という投稿をしてきたとしましょう。アーカイブを検索したあなたは先ほどのメッセージを見つけました。でも、そのメッセージの手順にはすこし不備があるようです (単なる間違いなのか、あるいはその当時とは仕様が変わったのかといったところでしょう)。こんなときのイケてるやりかたは、作業手順をきちんとまとめなおしたメッセージを新たに投稿し、そこで「以前の投稿は内容が古くなっている」と明記しておくことです。

おそらく Scanley のインデックスが狂い始めているのでしょう。
7 月にも同じような投稿があり、J. Random がそれに対して回答しています。
その回答は http://blahblahblah/blah にあります。以下に示す手順は、
J. Random が示した手順をもう少しきちんと補足したものです。

1. Scanley サーバを停止する
2. Scanley サーバを実行しているユーザーになる
3. そのユーザーで、'defrobnicate' プログラムを実行する
4. Scanley を手動で起動し、インデックスが正常になったことを確認する
5. サーバを再起動する

(理想を言えば、古いほうの投稿にメモをつけて「この内容は古くなっています。新しい情報はこちらです」といったことが指定できればいいのでしょう。しかし、私の知る限り、このような「新しい情報はこちら」機能を持ったアーカイブソフトウェアは存在しないようです。おそらく、アーカイブの内容の整合性を失わずにこの機能を実装するのは少し手間のかかることなのでしょう。こういうこともあるので、よくある質問とその回答については専用のウェブページを作成しておくことをお勧めするのです)

アーカイブの使用法として最もよくあるのは、技術的な質問に対する答えを探すというものでしょう。しかし、プロジェクトにとってのアーカイブの重要性は、それをはるかに上回るものです。そのプロジェクトの公式なガイドラインがいわば「制定法」であるとするなら、アーカイブはそのプロジェクトの「慣習法」といえます。すなわち、これまでに行われたあらゆる議論の流れとその結論がアーカイブから得られるのです。以前と同じような議論を繰り返す際には、まずアーカイブを検索してみるのが義務といえるでしょう。そうすれば、現在の状況や予想される反論を知ることができ、それに対する反証の準備をすることができます。おそらく自分では思いつかなかった角度からの意見も見つけることができるでしょう。また、他のメンバーもあなたがすでにアーカイブを検索しているものとして話を進めるでしょう。たとえ以前の議論で何の結論も出ていなかったとしても、その議論を再開する際には以前の議論へのポインタを示すべきです。そうすることで、他のメンバーは「その議論の結論がまだ出ていない」そして「あなたがやるべきことをやっている」つまり、あなたの意見はこれまでの議論の繰り返しではないのだろうということをわかってくれます。

全リソースをアーカイブと同様に扱う

これまでのアドバイスは、単なるメーリングリストのアーカイブだけにあてはまるものではありません。特定の情報は常に同じ場所で得られるようにする、見つけやすい場所に置くなどといった原則は、プロジェクトのすべての情報に対して同様にあてはまるものです。プロジェクトの FAQ を例にして考えてみましょう。

人は FAQ をどのように使うのでしょう?

適当な単語やフレーズを入力して検索できればいいですね。
単に特定の質問に対する答えを探すというだけでなく、全体をざっと眺めたいこともあるでしょう。
Google のようなサーチエンジンでも FAQ の内容を見つけられるようにしてほしいと思うことでしょう。
FAQ の特定の項目を直接指し示せるようにもしたいものです。
FAQ に新たな内容を追加できるようにもしたいでしょう。しかし、注意すべきなのは、FAQ への新たな内容の追加は FAQ の検索よりもはるかに頻度の低いものであるということです。 FAQ は、書き込むよりも読まれるほうが圧倒的に多いものです。

1. は、つまり FAQ が何らかのテキスト形式でなければならないということです。 2. と 3. が言わんとしていることは、FAQ が HTML ページとして存在しなければならないということです。 2. はさらに、HTML が読みやすい形式であること (つまり、その見栄えを変更できること) や目次を持っていることも要求しています。 4. を満たすには、FAQ の各項目に HTML の 名前付きアンカー を指定しておく必要があります。それによって、ページ内の特定の場所に直接到達できるようになります。 5. が意味するところは、FAQ のソースファイルの取得が容易であり (3章技術的な問題 の「すべてをバージョン管理する」をご覧ください)、また編集しやすいものでなければならないということです。

名前付きアンカーと ID 属性

ウェブページ内の特定の場所に直接移動させるには、名前付きアンカーを使う方法と id 属性を使う方法の二通りがあります。

名前付きアンカー は単なる HTML のアンカー要素 (<a>...</a>) と同じで、そこに "name" 属性を追加したものです。

<a name="mylabel">...</a>

最近のバージョンの HTML では、より汎用的な id 属性 をサポートしており、<a> だけでなく任意の HTML 要素で使用することができます。たとえば次のように使用します。

<p id="mylabel">...</p>

名前付きアンカーと id 属性の使用法は、どちらも同じです。 URL の最後にハッシュマーク (#) に続けてラベルを指定すると、ブラウザはページ内のその場所に直接移動するようになります。

http://myproject.example.com/faq.html#mylabel

名前付きアンカーは事実上すべてのブラウザがサポートしており、最近のブラウザのほとんどは id 属性にも対応しています。万全を期すなら、名前付きアンカーだけを用いるか名前付きアンカーと id 属性を併用する (もちろん、そのときは両者に同じラベルを指定する) ことをおすすめします。名前付きアンカーについては、開始要素と終了要素をひとつにまとめることはできません。たとえ要素内のテキストが存在しない場合でも、以下のように開始要素と終了要素を別々に書かなければなりません。

<a name="mylabel"></a>

……とはいえ、普通はここには (セクションのタイトルなど) 何らかのテキストが入るものです。

名前付きアンカーを使うにしても id 属性を使うにしても、ラベルを指定してアクセスしない限りはブラウザ上でそのラベルは見えないことに注意しましょう。しかし、たとえば FAQ の特定の回答をメールで示したい場合など、その場所のラベルが何なのかを知りたいこともあるでしょう。このような場合のために、"name" や "id" 属性を指定した場合は title 属性 も同じ要素に指定しておくとよいでしょう。たとえば次のようにします。

<a name="mylabel" title="#mylabel">...</a>

title 属性を指定した要素内のテキストの上をマウスポインタが通過すると、たいていのブラウザでは title 属性の内容をポップアップ表示します。私は、この title 属性の内容にハッシュマークも含めるよう心がけています。それを見たユーザーが、URL の最後にそれをつなげれば直接この場所に到達できるということに気づきやすくするためです。

ここでは FAQ についてのみ取り上げましたが、これは、リソースの体裁を整えるほんの一例にすぎません。ここで取り上げた内容 (直接検索できること、主要なサーチエンジンから検索できること、閲覧しやすいこと、特定の場所を参照しやすいこと、適切に編集しやすいこと) は、ウェブページ全般やソースツリー、バグ追跡システムなどでも当てはまるものばかりです。メーリングリストのアーカイブ用ソフトウェアの多くは、これらの項目の重要性に大昔から気づいていました。そのため、メーリングリストのアーカイブ用ソフトウェアの多くはこれらの機能を自前で搭載しています。その他の形式の文書については、担当者がそれなりに手間をかける必要があるかもしれません (このような作業をボランティアに任せていくための方法については 8章ボランティアの管理 で説明します)。

しきたりの成文化

プロジェクトが歴史を積み重ねて複雑さを増していくにつれて、新規参入する人たちが覚えなければならないデータの量も増加します。長年そのプロジェクトにかかわっている人たちは、プロジェクトの成長とともにそのしきたりを作り上げたり学んだりすることができました。彼らは往々にして、今まで築き上げてきた伝統がどれほど巨大なものかに気づいていません。そして、新たに参加してくる人たちがその伝統を守らないのをみて驚くのです。もちろんこれは、最近の人たちが古株よりも劣っているということではありません。プロジェクトの初期に比べ、新規参入のハードルが高くなっていることが問題なのです。

プロジェクトが積み上げていく伝統には、コミュニケーションの方法や、コーディング規約および他の技術情報を蓄積する方法もあります。これらについては、それぞれ 2章さあ始めましょう の「開発者向けドキュメント」および 4章プロジェクトの政治構造と社会構造 の「全てを記録しておく」で例を挙げて説明しました。このセクションでは、プロジェクトの成長に伴ってこれらのガイドラインをいかに最新の状態に保つかを説明します。特にコミュニケーションに関するガイドラインは重要です。というのも、これはプロジェクトの規模や複雑さが大きくなるにつれて変わっていくものだからです。

まずは、みんなが何に困っているのかを調べましょう。同じような状況で (特に新入りのメンバーが) 困っていることに気づいたら、それは「ガイドラインをきちんと設定すべきなのに、まだできていない」という証拠です。次に、同じことを何度も何度も繰り返して言うのをいやがらないようにしましょう。いやいや言っているように思われてはいけません。新入りさんがどんどん入ってくる以上、あなたや他のベテランメンバーが同じことを繰り返すはめになるのは避けられません。

すべてのウェブページ、メーリングリストへのすべての投稿、そしてすべての IRC チャンネルには告知用のスペースを設けるようにしましょう。これは商業的な広告を行うものではなく、そのプロジェクト自身のリソースについて告知するための場所となります。そこに何を載せるのかは、それをどのような人たちが読むのかにあわせて決めます。たとえばユーザーからの質問を受け付ける IRC チャンネルの場合、それを利用する人の多くはこれまでにそのプロジェクトにかかわったことがない人となるでしょう。単にインストールしてみただけであることも多いでしょうし、たいていは「今すぐに」回答を欲していることでしょう (ちょっとでも待てるのなら、普通はメーリングリストに質問するでしょうから。答えが返ってくるのに多少時間がかかることさえ我慢できれば、こっちのほうが手間がかかりません)。普通の人は IRC チャンネルに常駐することはありません。ふらっと登場して質問を行い、そして去っていくだけです。

したがって、このチャンネルで扱う話題の対象は、ソフトウェアについての技術的な質問の回答を 今すぐに ほしい人たちということになります。今後ずっとプロジェクトのコミュニティーに参加するであろう人たちにくらべ、この手の人たちにとってはコミュニティーのガイドラインはそれほど重要ではありません。活発なチャンネルがどのようにしているのかの例を見てみましょう (3章技術的な問題 の「IRC / リアルタイムに行なわれるチャットシステム」で示した例と見比べてみるといいでしょう)。

あなたはチャンネル #linuxhelp で話しています。

#linuxhelp のトピックは以下の通りです。
質問する前に、以下の二つは必ず読んでください。
http://www.catb.org/~esr/faqs/smart-questions.html &&
http://www.tldp.org/docs.html#howto | チャンネルに関するルールは
http://www.nerdfest.org/lh_rules.html にあります | kernel 2.6.x へのアップグレードについて質問する前に
http://kerneltrap.org/node/view/799 を調べてください | kernel のメモリ空間が参照可能になる脆弱性:
http://tinyurl.com/4s6mc -> 2.6.8.1 か 2.4.27 にアップデートすること |
衝突するハッシュアルゴリズム: http://tinyurl.com/6w8rf | reiser4 ファイルシステムリリース)

メーリングリストの場合、この「告知スペース」にあたるのは全メッセージの最後に付加されるちょっとしたフッターとなります。たいていのプロジェクトでは、この部分にメーリングリストへの参加方法や脱退方法を載せています。また、そのプロジェクトのホームページや FAQ ページの場所を載せていることもあるでしょう。そんなことなんて、メーリングリストのメンバーならみんな知っているはずだと思われるかもしれません。おそらくそれは正しいでしょう。しかし、メーリングリストへの投稿を見るのは、何もメーリングリストの参加者だけであるとは限りません。メーリングリストのアーカイブは、さまざまな場所からリンクされることになります。投稿の内容によっては、メーリングリストの参加者よりもずっと多くの人たちに読まれることになるものもあるでしょう。

書式を整えることには絶大な効果があります。たとえば Subversion プロジェクトでは、 3章技術的な問題 の「バグ追跡システムをあらかじめフィルタする」で説明したバグフィルタリング技術である程度うまくいっていました。ただ、それでもバグとは言えないような内容がたびたび登録されてしまっていました。そんなことがあるたびに、担当者がいちいち彼らに教えてやる必要があったのです。そう、これまで 500 人もの人に言ってきたのと同じことを。ある日のこと。そんな状況に業を煮やしたある開発者が、バグ追跡システムのガイドラインを読まずに投稿するユーザーに対してキレはじめたのです。それを見た他の開発者たちは、この方式ではもはややっていけないことに気づきました。彼は提案しました。バグ追跡システムのトップページの目立つところに「メーリングリストや IRC で十分に議論してからバグを登録するように」と書いてやろうと。そう、黄色い背景に赤の太字で。すべてのページの先頭にでかでかと。私たちはそれを実行しました (その結果は http://subversion.tigris.org/project_issues.html でご覧いただけます)。その結果。本来のバグ以外が登録されてしまうことが激減したのです。もちろん、(期待通り) 現在もそれは続いています。しかも、ユーザー数が増えているにもかかわらず、ゴミの量は目に見えて減っています。その結果、バグデータベースの中に含まれるゴミの量が減っただけではなく、バグに対応する人たちの空気もよくなってきたのです。今でもたまにバグ以外のゴミが登録されることもありますが、そんな場合の反応も暖かいものとなっています。これは、そのプロジェクトのイメージとメンバーの精神衛生の両方によい影響を及ぼします。

このことから得られた教訓は、単にガイドラインを作成するだけではダメだということでした。作成したガイドラインは、それを最も必要としている人たちの目に付きやすいところに掲げる必要があったのです。そのプロジェクトにあまりなじみのない人でも明確にわかるようにしなければならなかったのです。

そのプロジェクトのしきたりを説明する場所は、何も静的なウェブページだけではありません。ある程度は対話的な取り締まりも必要です (ここで言う「取り締まり」とは、手錠だの牢屋だのといったものではありません。単に好意的な注意をする程度のものです)。 2章さあ始めましょう の「きちんとしたコードレビューの習慣」で説明したコミットレビューを含むすべてのピアレビューでは、特にそのプロジェクトの決まりに反していないかどうかも注意してレビューするようにしましょう。

Subversion プロジェクトで利用している規約をもうひとつご紹介しましょう。私たちは、"r12908" と書けばそれは "バージョン管理リポジトリのリビジョン 12908" という意味であるとしています。小文字の "r" は非常にタイプしやすい文字だし、数字の半分の高さしかないので数字と組み合わせても識別しやすいのです。もちろん、こんな決まりを作ったからといってみんながすぐそれに従うとは限りません。たとえば、こんなログメッセージを含むコミットメールが届くこともあるでしょう。

------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines

J. Random からのパッチを採用した <jrcontrib@gmail.com>

* trunk/contrib/client-side/psvn/psvn.el:
  revision 12828 に存在していたtypoをいくつか修正
------------------------------------------------------------------------

...こんなコミットに対するレビューの返事は、次のようになるでしょう。 "ところで、過去の変更内容を指す場合は 'revision 12828' じゃなくて 'r12828' 形式にしてくれないかな?" これは、単に格好だけの問題ではありません。そうすることで、人間が読みやすくなるだけでなく機械で自動解析することも簡単になるのです。

このような標準にしたがって共通の方式を使用するようにし、それをどこでも一貫して使うようにすると、そのプロジェクトの事実上の決まりとして認められるようになります。このような決まりを作っておくと、プロジェクト内のコミュニケーションをより円滑にするためのツールを作りやすくなります。たとえば "r12828" 形式で書かれたリビジョンをリポジトリ閲覧システムへの直リンクに変換したりといったことがやりやすくなるのです。もし "revision 12828" のような形式でリビジョンを表すようにすると、ツールを作るのは難しくなるでしょう。たとえば途中に改行がはいったりすることもあるでしょうし、文章の中から抜き出すのも難しくなります ("revision" という単語は他の場面でもよく使われるでしょうし、 "12828" のような単なる数字もさまざまな場所で用いられます。一方、リビジョン番号以外の意味で "r12828" 形式を用いることはまずないでしょう)。同様のことが、バグ番号や FAQ の項目番号 (ヒント: 名前付きアンカーと ID 属性で説明したように、URL で名前付きアンカーを用いることを考えてみましょう) などにも当てはまります。

短めの決まった形式が存在しない情報であっても、できるだけ一貫して重要な情報を提供するようにしなければなりません。たとえばメーリングリストへの投稿を指すときに、単に送信者と件名だけで済ませてはいけません。それだけでなく、アーカイブへの URL と Message-ID ヘッダも含めるようにしましょう。 Message-ID ヘッダを含めておけば、メーリングリストへの投稿をローカルに保存している人たち (旅行中でも過去のメールを読めるように、オフラインのコピーをラップトップに残している人もいます) にとって便利です。アーカイブにアクセスしなくても、Message-ID ヘッダからメッセージが特定できるからです。この場合、送信者と件名だけでは不十分です。だって、同じスレッド内で同じ人が同じ件名のメッセージを一日に何度も送信することって、そんなに珍しいことではないでしょう？

プロジェクトの規模が大きくなればなるほど、この手の一貫性はより重要となります。一貫性とは、プロジェクトのメンバーがどこでも同じ規則に従うこと。そして規則に従わなければならないと認知していることを指します。こうしておけば、無駄な質問が繰り返されることも減ります。メンバーが 100 万人だろうがひとりだろうが、その負荷はそれほど変わりません。本当につらくなるのは、質問してくる人の数が増え始めてきたときです。したがって、プロジェクトの規模が大きくなってきたら、質問の量を減らす方向に進めることを心がけましょう。そのためには、質の高い情報を提供し、さらにその情報を見つけやすいようにしておくことです。そうすれば、わざわざ質問するまでもなく必要な情報をすぐに見つけられるようになります。

バグ追跡システムでは議論しない

バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになるという危険が常にあります。議論を行うための場所としてはメーリングリストのほうが適しているのにもかかわらずです。きっかけはちょっとしたことです。誰かが問題点を投稿する際に、何らかの提案やパッチを付け加えたとしましょう。それを見た他の人が、その解決策には何らかの問題があると考え、指摘します。それを見た元の投稿者がさらに反論をします。 ……このような具合です。

問題なのは、まずバグ追跡システムは議論をするには適していない場所だということです。そしてもうひとつ。他人の目が届かないということもあります。開発に関する議論は開発者向けメーリングリストで行うものと考えられているので、議論に参加したい人は開発者向けメーリングリストのほうをチェックしているのです。彼らは、バグ追跡システムの状況を扱うメーリングリストには参加していないかもしれません。仮に参加していたとしても、その中身はそれほど真剣にチェックしていない可能性があります。

いったいどこがマズかったというのでしょう？最初にバグを報告した人が自分なりの解決策を示したのがそもそもの問題？はじめからメーリングリストに投稿すべきだった？それとも、最初の報告に対して反応した人のほうに問題がある？

この問いに対する正解はありませんが、一般的な原則はあります。問題の報告に単なるデータを追加したい場合は、バグ報告システムを使用するようにし、何らかの会話を始めるつもりならメーリングリストを使用するということです。どちらが適切かがはっきりしない場合もあるでしょうが、自己判断でできるだけ適切なほうを選ぶようにしてください。たとえば、何らかの議論を呼びそうなパッチを添付する際には、おそらくそれについて何らかの質問が返されるであろうと予測できます。通常は問題を報告する際にパッチも添付するのでしょうが (自分で直接コミットする気がない、あるいはコミット権がない場合を仮定しています)、議論を呼びそうなパッチの場合はメーリングリストを使用したほうがいいでしょう。いずれにせよ、単なるデータの追加から実際の対話に移行しはじめる段階は誰かが気づくことでしょう。このセクションの最初であげた例の場合、パッチに問題があることに気づいた２番目の投稿者がそれにあたります。パッチに問題があることに気づいたということは、その後何らかの議論が始まることも予測できるでしょうし、その後の会話は適切な場所で続けるべきだということもわかるでしょう。

数学にたとえてみましょう。もしその情報がすぐに収束していきそうなら、バグ追跡システムに直接投稿するようにします。一方その情報が発散しそうなら、メーリングリストや IRC チャンネルを使ったほうがいいでしょう。

これは決して、バグ追跡システムでは一切の意見交換を禁じるということではありません。たとえば、元の報告者に対しての詳細な再現手順の問い合わせなどは、たいていすぐに収束するものです。その問いに対する答えが新たな問題を発生させることなどまずないでしょう。単にこれまでにまとめられている情報を補足するものとなるだけです。その程度の内容のやりとりで、わざわざメーリングリストをにぎわせることはありません。必ず、一連のやりとりはバグ追跡システムの中で済ませるようにしてください。同様に、そのバグ報告が間違い (バグではない) ことが明らかだというのなら、そのバグ報告に対して直接そのように言うといいでしょう。また、提案内容にちょっとした問題 (問題の解決を妨げるほどには重大でない問題) があったときに、それを指摘するくらいならかまいません。

一方「バグか仕様か」や「そのソフトウェアのあるべき振る舞い」といった思想的な話題を扱う場合は、きっと他のメンバーも議論に参加したくなることでしょう。その手の話題は、一点に収束するのではなくあちこちに寄り道しがちです。ということで、これはメーリングリストのほうに振るようにしましょう。

バグ追跡システムへの報告に関する議論をメーリングリストに移した場合は、メーリングリストのスレッドへのリンクをバグ報告に追加しておきましょう。たとえそのバグ報告でその後議論が展開することがないとしても、後日そのバグ報告を参照した人が議論に参加したい場合などにそのリンクが重要となります。最初にスレッドを立ち上げる人の負担が少し増えることになりますが、オープンソースの世界には「言いだしっぺの法則」という文化があります。後からそのバグを参照するであろう何千何万の人たちが利益を受けることを思えば、議論に参加している数人の手間が増えることも我慢できるでしょう。

メーリングリストでの議論の結果得られた結論や議論のまとめは、もとのバグ報告にもコピーしておくようにしましょう。後でそれを読む人たちにとって役立ちます。議論をメーリングリストへ移行させるときの手順は、次のようになります。まずそのスレッドへのリンクをバグ報告に追加し、メーリングリストでの議論が収束したらその結論をバグ報告にコピーする (そして、メーリングリスト上での結論のメッセージへのリンクを付加する)。そうすれば、後でそのバグ報告を見た人は、あちこちたどらなくてもそのバグがすでに収束していることを把握できます。結論をコピーしても、よくある「どちらが正しい情報かわからない」という情報重複の問題を引き起こすことはありません。メーリングリストのアーカイブやバグ追跡システムのコメントは通常は静的なものであり、後で変化することがないからです。

宣伝・広報

フリーソフトウェアの世界では、内部での議論と一般向けのアナウンスの間に明確な違いはありません。その一因としては、想定する読み手がはっきり定義できないことがあります。ほぼすべての投稿が一般向けに公開されているとすれば、プロジェクトの外部の人たちがその投稿をどう受け取るかなどコントロールできません。プロジェクトの外部に公開するつもりなどまったくなかった投稿であっても、たとえば slashdot.org へのタレコミなどの影響で何百万もの人に読まれることになるかもしれません。オープンソースプロジェクトを運営していくにあたってこれは避けられないことです。ただ、通常そのリスクはあまり大きくありません。一般に、正しい方法で情報の報道価値を示しておきさえすればプロジェクトの外部に伝えるべき情報はきちんと伝わるようになります。

重要なアナウンスの場合、その公開方法は 4 通りか 5 通りくらいになることもあります。そして各方面へのアナウンスはほぼ同時に行わなければなりません。

プロジェクトのトップページは、おそらく最も多くの人たちが目にする場所でしょう。重大なアナウンスに関しては、トップページにも掲載するようにしましょう。ここに掲載するのは概要だけとし、詳細な情報を知りたい人のためにはプレスリリース (以下で説明します) へのリンクを用意しておきます。
また、ウェブサイト上には「ニュース」や「プレスリリース」と題した場所を設け、アナウンスの詳細はそこに書くようにします。プレスリリースの目的のひとつは、他のサイトからのリンクの際に使用する、正規の「アナウンスオブジェクト」を用意することにあります。したがって、プレスリリースは適切な構造にしておく必要があります。プレスリリースごとに個別のウェブページを用意するにしても、ひとつのblogの個別のエントリとするにしても、あるいはその他の形式にするとしても、他のサイトからリンクする際に別のプレスリリースと区別できるようにしておかなければなりません。
そのプロジェクトが RSS フィードを提供しているのなら (「RSS フィード」をご覧ください)、そこにもアナウンスを含めなければなりません。サイトの構築方法によっては、プレスリリースを作成したら自動的にフィードも更新されるようになっているかもしれません。
新たなリリースが公開されたというアナウンスの場合は、 http://freecode.com/ 上のそのプロジェクトについてのエントリも更新しましょう (Freshmeat のエントリを作成する方法については「広報」をご覧ください)。 Freecode のエントリを更新すると、 Freecode の変更履歴を扱うメーリングリストにそのエントリの内容が投稿されます。このメーリングリストに投稿されるのは Freecode の更新情報だけではありません。それ以外にも、多数の人が注目しているポータルサイト (http://slashdot.org など) の更新情報も投稿されます。 Freecode は、これらのデータを RSS フィードでも提供しています。つまり、あなたのプロジェクトの RSS フィードを購読していない人たちにも Freecode 経由で情報を伝えることができるのです。
あなたのプロジェクトのアナウンス用メーリングリストにメールを送信します。アナウンス用メーリングリストの名前は "announce" とします。つまり announce@yourprojectdomain.org のようになるというわけです。これは事実上の標準として使われている名前であり、この名前のメーリングリストに流されるメールは重要なアナウンスのみに限定しなければなりません。流れるメールのほとんどはそのソフトウェアの新たなリリースに関するものとなるでしょうが、それ以外にも資金集めのお知らせやセキュリティ上の脆弱性の発見 (本章で後ほどとりあげる「セキュリティ脆弱性の告知」をご覧ください) に関するメールも送信されます。あるいは、プロジェクトが大きく方向転換する際のお知らせなども投稿されるでしょう。 announce メーリングリストの流量はあまり多くなく、また重要な内容のみに使用するものです。そのプロジェクトの各種メーリングリストの中でも購読者の管理に最も力を入れる必要があります (あまり乱用するのではなく、熟考してから投稿するようにしましょう)。誰もが好き勝手にアナウンスを作成したりスパムだらけになってしまうことを避けるため、 announce メーリングリストは必ずモデレートしなければなりません。

これらの各所に出すアナウンスは、できるだけ同時になるようにしましょう。メーリングリストに流されたアナウンスがプロジェクトのホームページやプレスリリースに反映されていなければ、それを見た人は混乱してしまいます。さまざまな変更 (メールの送信、ウェブページの編集など) を事前に準備しておいて同時に実行すると、情報の一貫性が失われることが少なくなります。

それほど重要でもない出来事の場合は、上であげた手法のうちいくつか (あるいはすべて) を省略してもかまいません。出来事の重要性に応じて、それでもプロジェクトの外部には自然に伝わっていくでしょう。たとえば「新しいリリースが公開されました」というのは重要な出来事ですが、ただ単に「次のリリースの公開予定日が決まりました」というのは、実際のリリースに比べてそれほど重要ではありません。リリース予定日が決まったという程度の情報なら (アナウンス専用ではなく) 通常のメーリングリストに投稿し、あとはウェブページ上のタイムラインを更新しておくくらいで十分でしょう。

しかし、あなたのプロジェクトに関心を持っている人たちは、リリース予定日が決まったという話題をインターネット上の他の場所で持ち出すかもしれません。メーリングリストに参加しているけれどもただ話を聞いているだけで自分は一切発言しないという人たちが、必ずしも他の場所でも同じように黙っているとは限りません。口コミの影響は侮れません。ちょっとしたアナウンスであっても、それが正しい内容で周りに広まるよう心がける必要があります。具体的に言うと、他の人に引用されることを想定した投稿では、どの部分を引用してもらいたいのかを明確にし、その部分は公式のプレスリリースと変わらないレベルで書くようにするということです。たとえば次のようにします。

開発の最新状況をお知らせします。Scanley のバージョン 2.0 を、 2005 年 8 月中旬にリリース予定です。詳細な情報は http://www.scanley.org/status.html でもご覧いただけます。このバージョンで追加される主要な機能は、正規表現による検索です。
その他の新機能は、 ... また、次のようなバグの修正も含まれます ...

最初のパラグラフでは、ふたつの重要な情報 (リリース予定日と新機能) を簡潔に説明し、さらに詳細な情報を知るための URL を示しています。この部分だけしか読まなかったとしても、内容が伝わるようにしておきましょう。メールの残りの部分は、他に伝わる際には無視される可能性があります。もちろん、中にはメール全体へリンクする人もいるかもしれません。しかし、ほとんどの人はメールの一部を引用するのみとなります。そうである以上、一部を引用する人が引用しやすいようにすることを心がけましょう。うまく引用してもらえば、情報を広く伝えることができます。

セキュリティ脆弱性の告知

セキュリティ脆弱性の処理のしかたは、他のバグ報告の場合とは異なります。通常、フリーソフトウェアの世界では、物事をオープンにして誰にでも見えるようにすることが当たり前のことです。一般的なバグ報告の対応状況は、興味のある人なら誰にでも見えるようになっています。いつバグが報告されたのか、どのような議論がなされたのか、そして最終的にどのように修正されたのか。これらはすべて、知りたければ誰でも知ることができるわけです。

セキュリティに関するバグの場合は、これとは異なります。セキュリティに関するバグが原因でユーザーのデータが漏洩してしまう可能性もありますし、場合によってはコンピュータを破壊してしまうことになるかもしれません。このような問題をオープンな場で議論してしまうと、問題があることを全世界に知らしめてしまうことになります。当然その中には、そのバグを悪用しようという人たちもいることでしょう。単に淡々とバグを修正してコミットしただけでも、バグの存在を世にさらしてしまうことになります (攻撃者の中には、公開されているプロジェクトのコミットログをチェックしている人もいます。変更内容を調べれば、変更前のコードにセキュリティ上の問題があることがわかるでしょう)。ほとんどのオープンソースプロジェクトでは、この開放性と秘密主義の対立に折り合いをつけるために同じような方針をとっています。その方針は、以下のようなものとなります。

修正が完了するまではバグのことを口外しない。そして、バグがあったことをアナウンスすると同時に修正プログラムを公開する。
修正プログラムは、可能な限り迅速に提供する。そのバグが外部からの報告で発覚したものである場合は特に急ぐ必要があります。というのも、プロジェクトの外部の人間の中に少なくとも 1 人はその脆弱性を突く攻撃ができる人がいるということがはっきりしているからです。

実際のところ、この規則は標準化した手順としてまとめることができます。これらの手順について、以下のセクションで解説します。

バグ報告を受ける

当然のことながら、各プロジェクトにはセキュリティバグの報告を一般から受け付けるための窓口が必要です。しかし、これは通常のバグ報告を受け付けるアドレスと一緒にはできません。というのも、通常のバグは誰にでも見えるようになっているからです。そこで、セキュリティ関連のバグ報告を受け取るためのメーリングリストを別途用意します。このメーリングリストのアーカイブは一般に公開してはいけません。また、参加資格は厳しく制限するべきです。そのプロジェクトに長くかかわっていて信頼できる開発者たちのみをメンバーに加えるようにしましょう。もし "信頼できる" の具体的な定義が必要な場合は、たとえば "コミット権を得てから 2 年以上経過している" などといった条件を使用するといいでしょう。そうすれば、参加資格に関して "えこひいきしているのでは?" といった批判を避けることができます。このメーリングリストに参加しているメンバーが、セキュリティバグに対応するメンバーとなります。

セキュリティ関連のメーリングリストについては、スパム対策やモデレートは行わないのが理想です。というのも、重要な報告がスパム扱いされてしまうと困りますし、たまたまその週末にすべてのモデレータがメールをチェックしなかったなどという理由で重要な報告に気づくのが遅れるというのも困ります。何らかのスパム対策ソフトウェアを使用するのなら、可能な限り緩やか目の設定にしておきましょう。重要な報告をフィルタリングしてしまうくらいなら、多少のスパムが混ざってしまうほうがずっとましです。作成したメーリングリストをうまく活用するためには、そのアドレスを周知させる必要があります。しかし、このメーリングリストはモデレートされておらず、またスパム対策も甘いものです。したがって、そのアドレスを宣伝するときには、アドレスを隠すために何らかの細工が必須となります。詳細は 3章技術的な問題 の「アーカイブでのメールアドレスの処理」で説明します。幸いにも、アドレスを読みにくいものになどしなくてもアドレスを隠すことは可能です。 http://subversion.tigris.org/security.html をご覧になったうえで、そのページの HTML ソースを確認してみてください。

大至急それを修正する

セキュリティメーリングリストに報告が来たら、次は何をすればいいのでしょう? まず最初にすべきことは、その問題の重大度 (severity) と緊急性 (urgency) を評価することです。

その脆弱性はどれくらい深刻なものでしょう? 悪意のある攻撃者が、そのソフトウェアを使用しているコンピュータを乗っ取ってしまえるほどのものですか? それとも、ただ単に何らかのファイルのサイズが漏洩してしまうというだけのものですか?
その脆弱性を突く攻撃の難易度はどの程度ですか? スクリプトを使って誰でも攻撃できる程度のもの? あるいはその場の状況を熟知している人が高度に頭を働かせても、ごくまれにしか成功しないもの?
誰がその問題を報告してきたのですか? この問いへの答えによって脆弱性そのものの性質が変わるわけではありませんが、他にどれくらいの人がその問題に気づいている可能性があるかを推測することができます。もしそのプロジェクトの開発者自身から報告されたのなら、ちょっとだけ (本当にちょっとだけ) 安心できます。おそらく、その報告者は他人にその問題を漏らしていないでしょうから。一方、もし anonymous14@globalhackerz.net とかいうアドレスからのメールで報告を受けたのなら、一刻も早く対応すべきでしょう。あなたにその問題を報告してくれた人は、あなた以外の人にもその情報を漏らしているかもしれません。あるいは報告を受けたときには既にその脆弱性を突いた攻撃を始めているかもしれません。

ここで考えているのは、あくまでも 緊急 (urgent) と 超緊急 (extremely urgent) のどちらかというレベルの話であることに注意しましょう。たとえ今回の報告が既知の信頼できるところからのものであったとしても、それよりずっと前に他の人が同じ問題を発見しているがただ報告していないだけなのかもしれません。緊急性が低いといえるのは、そのバグが本質的に深刻なセキュリティ問題を引き起こさないといえる場合のみです。

ところで、さきほどの "anonymous14@globalhackerz.net" の例は、決して冗談で言ったわけではありません。実際、このようにどこの誰だかわからないような相手からバグの報告を受けることもあり得ます。彼らは自分の身元を明かすこともないでしょうし、あなたの味方なのか敵なのかさえはっきりさせないでしょう。でもそんなの関係ありません。あなたにセキュリティホールを教えてくれたということは、向こうはあなたに対してひとつ貸しを作ったと考えているはずです。それに対して、誠意を持って対応する必要があります。まず報告してくれたことに対して感謝し、修正版を公式リリースする予定日を彼らに伝えるようにします。時には 報告者側から 日時を指定されることもあります。つまり、「バグが修正されているかどうかにかかわらず、 ○月○日になればこの問題を公表する」などどして暗黙の脅しをかけてくるようなものです。これは単なる弱い物いじめに感じられるかもしれませんが、おそらくその報告者が過去に経験したいやな思い出 (せっかくセキュリティ問題を報告してやったのに、ソフトウェアの作者にまともに取り合ってもらえなかったなど) に基づく先制攻撃と考えたほうが適切でしょう。いずれにせよ、報告者をいちいち怒らせている余裕などありません。結局のところ、もしそのバグが深刻なものなのだとしたら、その報告者はユーザーに問題を引き起こさせる方法を知っているということになります。彼の機嫌を損ねないよう丁重に扱いましょう。そうすればきっと相手もこちらを尊重してくれることでしょう。

セキュリティバグの報告者としてほかによくあるのは、セキュリティの専門家です。彼らはソフトウェアのコードを監査するのを仕事にしており、ソフトウェアの脆弱性についての最新情報を追いかけています。この手の人たちは、バグを報告する側だけでなくバグ報告を受け取る側としての経験も豊富です。おそらくあなたのプロジェクト内のどのメンバーよりも経験を積んでいることでしょう。また、彼らの特徴としては、期日を指定してその日までの対応を迫り、期日がくればバグを一般に公表するというやり方があります。交渉次第で期日を引き延ばすこともできるかもしれませんが、それは相手によります。セキュリティの専門家たちにとっては、報告先にまともに取り合ってもらうための唯一効果的な方法が期日を設定することなのです。彼らが期日を指定してきたとしても、それを失礼だとは思わないようにしましょう。それなりの理由があって続いている伝統なのですから。

重大度と緊急性を判定し終えたら、実際の作業に取り掛かり始めます。修正をエレガントに行うか、それともとにかくすばやく修正するのかのトレードオフになることもあります。このようなときのために、まず最初に緊急性を判定しておいたのです。セキュリティに関する修正についての議論は、当然セキュリティメーリングリスト内でのみ行います。また、問題の報告者がもし議論への参加を希望するなら、報告者もその議論に参加させましょう。そして、技術的な理由でそれ以外の開発者が参加することもあるかもしれません。

修正内容をリポジトリにコミットしてはいけません。一般に公開するまではパッチ形式で管理しておくようにします。もし仮にそれをコミットしてしまったら、たとえログメッセージを適当に取り繕っていたとしても見る人が見ればその変更の意味するところを感づかれてしまいます。どこの誰がどういう目的であなたのリポジトリをチェックしているかなんてわかりません。コミットメールの送信をやめたとしても無意味です。まず、コミットメールの送信が突然止まったという時点で「なにか怪しい」と思われてしまうでしょう。そしてコミットメールの有無にかかわらず、その内容はリポジトリのデータとして残されているわけです。修正の開発はすべてパッチ形式で行い、パッチは隔離された場所で管理します。そのバグの対応をしている人たちだけが知っている個別のリポジトリなどがいいでしょう (Arch や SVK といった中央管理型ではないバージョン管理システムを使用しているなら、完全にバージョン管理された環境で作業を進めることができます。バグへの対応中は、外部からはリポジトリにアクセスできないようにしておけばいいのです)。

CAN/CVE 番号

これまでに、セキュリティの問題の中で CAN 番号 や CVE 番号 といったものをみたことがある人がいるかもしれません。たとえば "CAN-2004-0397" あるいは "CVE-2002-0092" といった形式のものです。

これらの番号は、どちらも同じ型の内容を表しています。これは http://cve.mitre.org/ で管理されている "Common Vulnerabilities and Exposures" リストのエントリを表します。このリストの目的は、既知のセキュリティ問題についての共通の呼び名を提供することにあります。そうすることで、個々の問題をはっきり区別できるようになります。また、詳細な情報を探すための中央広場としての働きもあります。 "CAN" 番号と "CVE" 番号の唯一の違いは、前者はまだ正式に認定される前の状態であるということです。 CVE Editorial Board によって認定されて公式リストに登場したものが後者となります。しかし、どちらの情報も一般に公開されており、認定の前後で番号自体は変わりません。単に、番号の前の "CAN" が "CVE" に置き換わるだけのことです。

CAN/CVE のエントリ自体には、バグの詳細な説明や対処方法などは含まれていません。その代わりに、そのバグの概要説明と外部リソース (メーリングリストのアーカイブなど) へのリンクを用意し、詳細な情報が知りたい人はそちらを参照すればいいようになっています。 http://cve.mitre.org/ の真の目的は、きちんと整理整頓された場所を用意してすべての脆弱性に名前をつけ、詳細なデータを得るための道筋を示すことです。たとえば、エントリの例として http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 を見てみましょう。その記述内容は非常に簡潔なものであり、なにやら怪しげな略語をつけたリンクがあるだけです。これらの略語の意味については http://cve.mitre.org/data/refs/refkey.html でご確認ください。

あなたが対応した脆弱性が CVE の条件を満たすようなら、CAN 番号の取得を検討するといいでしょう。取得方法は、意図的に難しくしてあります。基本的に、まずあなたが誰かの知り合いであるか、誰かの知り合いの知り合いである必要があります。なんだかよくわからない言い方ですが、要はこういうことです。脆弱性でもない内容や中身のないような報告に対応するのを避けるため、 CVE Editorial Board は既知の信頼できる情報源からの報告しか受け取らないのです。したがって、脆弱性をリストに載せてもらうには、あなたのプロジェクトと CVE Editorial Board の橋渡しをする仲介役が必要になるということです。周囲の開発者に聞いてみましょう。その中に一人くらいは、「以前に一度 CAN を取得したことがある」とか「知り合いが CAN を取得していた」とかいう人がいるでしょう。この方式の利点は、知り合いのつてをたどっていくうちに a) それは MITRE の言うところの脆弱性に該当しないから投稿する必要はないとか b) その脆弱性にはすでに CAN あるいは CVE 番号が割り当てられているといったことを教えてくれるかもしれないということです。後者の可能性としては、そのバグが既に別のセキュリティメーリングリストで報告されているといったことがあります。たとえば http://www.cert.org/、あるいは http://www.securityfocus.com/ の BugTraq メーリングリストなどがこれにあたります (もしあなたのプロジェクトに対して何も連絡がないまま後者の状態になっているのだとしたら、自分たちのうかがい知れないところで何かが起こっているということを心配しなければなりません)。

どうせ CAN/CVE 番号を得るのなら、普通はバグの調査段階のできるだけ早いうちに番号を取得したいものです。そうすれば、その後のやりとりはその番号を使用して進めることができます。 CAN エントリは、一般に公開される日まで使用できません。それまでは空のエントリが存在するだけ (場所を確保するだけ) であり、あなたがバグの存在と修正を公表するまで、そこには何の情報も掲載されません。

CAN/CVE のプロセスについてのより詳細な情報は http://cve.mitre.org/cve/identifiers/candidates_explained.html で得られます。また CAN/CVE 番号を非常にうまく使っているオープンソースプロジェクトの例としては http://www.debian.org/security/cve-compatibility があります。

事前通知

セキュリティ対策チーム (セキュリティメーリングリストのメンバー、あるいはそのセキュリティ問題の対応担当者) が修正を完了したら、次はそれをどのように公表するのかを判断する必要があります。

単に修正をリポジトリにコミットするとか全世界に公表するとかだと、そのソフトウェアを使用している人たちは事実上即時のアップグレードを迫られることになってしまいます。さもないと、攻撃を受ける危険性が生じるわけですから。したがって、ある種の重要なユーザー向けには 事前通知 をしておくほうが適切なこともあります。いわゆるクライアント/サーバ型のソフトウェアなどでは特にこれが重要です。有名なサーバが、一時的にでも攻撃の対象となってしまう可能性があるからです。これらのサーバの管理者にとっては、アップグレードを行うためには 1 日から 2 日の時間が必要となるでしょう。脆弱性が一般に公開される前にそのくらいの猶予があれば、サーバの管理者はありがたいと思うことでしょう。

事前通知とは、単に一般公開前にそれらの管理者向けにメールを送信することを指します。通知メールでは、脆弱性の内容とその対処方法を説明しておくようにします。事前通知の送信先は、その情報を適切に扱ってくれると信頼できる相手に限定しなければなりません。つまり、事前通知を受け取る資格があるのは、次のふたつの条件を満たす相手だけだということです。まず、攻撃を受けると深刻な問題となるような巨大で重要なサーバを運営しているということ。 さらに、一般公開の前にその問題をペラペラしゃべってしまうような口の軽い人ではないということ。

事前通知のメールは、それぞれの相手に個別に (一度に一通ずつ) 送信するようにします。全員に一括送信などしては いけません。そんなことをすれば、それを受け取った人たちに「私のほかにどんな相手に送っているのか」を知られてしまいます。これが何を意味するのか。それを受け取った人は「(私以外の) 他のメンバーのサーバにも同じセキュリティホールがある」ということを知ってしまうことになります。全員をブラインドカーボンコピー (BCC) で指定すればいいという問題でもありません。受け取り先が使用しているスパムフィルタの設定によっては、BCC で送信されたメールをブロックしたり優先度を下げたりするようになっていることもあるからです (最近のスパムには、BCC を使用して送られてくるものが多いのです)。

事前通知メールの例を、ここに示します。

From: あなたの名前
To: admin@large-famous-server.com
Reply-to: あなたの名前 (セキュリティメーリングリストのアドレスではありません)
Subject: [機密] セキュリティ脆弱性の通知


このメールは、Scanley サーバにおけるセキュリティ警告に関する極秘の事前
通知です。

このメールの内容は、決して他人に転送しないでください。一般向けには 5 月
19 日に公表する予定です。それまではこの情報を口外しないようお願いいたし
ます。

あなたにこのお知らせを送信した理由は、(おそらく) あなたが Scanley サー
バをご利用いただいており、5 月 19 日にセキュリティホールを公表する前に
パッチを適用したいであろうと考えられるからです。

参照:
=====

   CAN-2004-1771: Scanley stack overflow in queries

脆弱性:
=======

   サーバのロケールの設定が正しくない場合に、クライアントから不正な
   クエリを送信するとサーバ上で任意のコマンドを実行できるようになります。

重大度:
=======

   非常に深刻。サーバ上で任意のコードの実行を許してしまいます。

回避方法:
=========

   scanley.conf で 'natural-language-processing' オプションを 'off'
   に設定することで、この脆弱性を回避可能です。

パッチ:
=======

   以下のパッチは Scanley 3.0、3.1 および 3.2 に適用可能です。

   新しい公開リリース (Scanley 3.2.1) が 5 月 19 日の直前に公開されます。
   つまり、この脆弱性を公表するのと同時に公開するということです。以下の
   パッチを適用するか、あるいは新しいリリースが発表されるのをお待ちくだ
   さい。3.2 と 3.2.1 の違いは、以下のパッチのみです。

[...ここにパッチを示します...]

CAN 番号を取得している場合は、それを事前通知に含めるようにしましょう (先ほどの例で示したようにします)。まだ情報は公開されておらず MITRE のページには何も掲載されていませんが、それでも含める価値があります。 CAN 番号を示すことで、それを受け取った相手は「この通知で知ったバグと後日正式に公開されるバグが確かに同じものである」ということを確認できます。正式にバグが公開されたときに、余計な心配をせずにすむというわけです。まさにこれこそが、CAN/CVE 番号の重要なところです。

修正を一般に公開する

セキュリティバグへの対応で最後に行うのが、修正内容を一般に公開することです。ひとつの包括的なアナウンスで、以下の内容を説明しなければなりません。まずその問題の内容、そして CAN/CVE 番号を取得していればその番号、当面の回避策と本質的な修正方法などを示します。 "修正" は、通常はそのソフトウェアの最新バージョンへのアップデートとなります。しかし、ソースコード形式で実行されるソフトウェアなどでは、パッチの適用をもって "修正" とすることもあります。新しいリリースを作成した場合は、それが通常のリリースとは異なりセキュリティパッチの適用によるものであることを明示しておく必要があります。そうしておけば、保守的な管理者であっても副作用を気にせずにアップグレードできるようになります。当然、今回のセキュリティ修正は将来のリリースにも含まれているでしょうから、将来のアップグレードの際にも心配せずにすみます (リリース手続きの詳細については、 7章パッケージの作成、リリース、日々の開発 の「セキュリティリリース」で説明します)。

セキュリティ対応の修正で新バージョンをリリースするか否かにかかわらず、通常の新バージョンのリリースと同程度の優先度でアナウンスを行うようにします。つまり、そのプロジェクトの announce メーリングリストにメールを送ったりプレスリリースを作成したり Freecode のエントリを更新したりといったことです。そのプロジェクトの評判を気にしてセキュリティバグの存在を甘く見るなんてことは論外ですが、セキュリティに関するアナウンスの影響と実際の問題の重大度との兼ね合いには注意しましょう。そのセキュリティホールが単に些細な情報が漏洩するというだけのものであってコンピュータ全体がのっとられてしまうほどのものではないという場合は、あまり大騒ぎしないほうがいいこともあります。場合によっては announce メーリングリストへの投稿も控えるということもありえます。ささいなことで毎回大騒ぎしていると、ユーザーはどう思うでしょう? 実際にはそれほどではないのに「このソフトウェアはあまり安全ではない」と思われてしまうかもしれません。また、本当に深刻な問題が発生したときにそれをアナウンスしても、「またいつものやつだろう」と無視されてしまう可能性もあります。重要度の判断方法については、 http://cve.mitre.org/about/terminology.html にすばらしい入門文書があるので、ぜひご覧ください。

セキュリティ問題の対処方法がよくわからない場合は、経験がありそうな人を探して相談するようにしましょう。脆弱性の評価やその処理の技術は、経験を積まないとなかなか得られないもので、最初のうちは失敗することが多いものです。

セキュリティ脆弱性の扱いに関する Apache Software Foundation のガイドラインが http://www.apache.org/security/committers.html にあります。こちらも参照ください。この素晴らしいチェックリストを見れば、自分がすべてを注意深く行っているかどうかを判断できます。

^[25] これらの問題については、いくつか興味深い研究があります。たとえば Gutwin、Penner および Schneider による Group Awareness in Distributed Software Development もそのひとつです。この論文はオンラインで公開されていましたが、一時しばらく見えなくなっていました。その後、改めて http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf で公開されました。もしこの URL で見つからない場合は、また別の場所に移動した可能性があります。サーチエンジンを使って探してみてください。

^[26] 扱いにくい人たちの一例について、Amy Hoy が愉快な記事 Help Vampires: A Spotter's Guide で的確に指摘しています。Hoy 曰く、「それはきっと、時計の時刻合わせをするのと同じくらいに普通のこと。コミュニティの衰退は、放射性同位体の減衰と同じくらいに予測可能なこと。オープンソースのプロジェクトなり言語なりがそれなりの知名度を得るようになると — 半減期を迎えると、と言ってもいい — 奴らはやってくる。そしてコミュニティの気力をそぐようになる。奴らは Help Vampire。そして、それを阻止するために私はここにいる...」

第7章パッケージの作成、リリース、日々の開発

リリースに番号を付ける

リリース番号の構成要素
単純なやり方
奇数/偶数に意味を持たせるやり方

リリースブランチ

リリースブランチの使い方

リリースを安定させるプロセス

リリースオーナーによる独裁

リリースに含める変更を投票で決める

リリースを安定させるプロセスを管理する
リリースマネージャー

パッケージング

パッケージのフォーマット

パッケージ名とレイアウト

大文字にするか、小文字のままにするか
プレリリース版

コンパイルとインストール

バイナリパッケージ

テストとリリース

リリース候補
リリースを告知する

複数のリリースラインを管理する

セキュリティリリース

リリースと日々の開発

リリースの計画を立てる

この章では、フリーソフトウェアのプロジェクトが、ソフトウェアをパッケージングしてリリースする方法と、開発パターン全体がこうした目標にどう繋がっているのかについて述べていきます。

オープンソースプロジェクトと独占的なソフトウェアのプロジェクトとの主な違いは、開発チームに対して中央集権的な管理が行なわれているかどうかにあります。新しいリリースを準備しているとき、この違いは特にはっきりします。独占的なソフトウェアのプロジェクトでは、企業は今度のリリースにかかわる作業に集中し、新機能の開発や重大でないバグフィックスは、リリースが終わるまで脇に置いてくれと開発チーム全体に求めることができます。ボランティアの集団はそんな一枚岩ではありません。オープンソースプロジェクトの人々は様々な理由で働いています。よってリリース作業を手伝うことに興味がない人たちは、たとえリリース作業が進行中でも日々の開発作業を続けたいと考えます。開発が止まることはないので、オープンソースソフトウェアのリリース作業は、独占的なソフトウェアのそれに比べて時間がかかりがちですが、混沌としたものではありません。これは高速道路の修復にちょっと似ています。道路を直すには二つやり方があります。ひとつは、道路全体に作業員が群がって問題が解決するまで全力で働けるように、道路を完全に閉鎖することです。もうひとつは、一度にひとつの車線でだけ作業を行い、もう一方は通行できるようにしておくことです。はじめのやり方は 修理を行なう作業員にとっては 効率がいいやり方ですが、それ以外の人にはよくありません — 作業が終わるまで道路全体が閉鎖されるからです。ふたつめのやり方は時間がかかり、修理する作業員は大変です（少ない人数、少ない機械、窮屈な環境での作業を強いられる上、通行する車を徐行させて交通整理をする旗振り役も置かなければいけない、など）が、作業員が全力を出さなくても少なくとも道路は使いやすい状態のままです。

オープンソースプロジェクトはよくふたつめのやり方で動いています。実際、複数の異なったリリースラインがある状態で、成熟したソフトウェアのモジュールを管理するために、プロジェクトはずっと小規模な道路修理を続けているような状態です。いつも二つの車線が閉鎖して作業をしています。つまり、リリースを定期的なスケジュールに従って行なえるように、開発チームは裏で起こるささいな不都合にはいつも目をつぶっているのです。

この作業モデルはリリース作業以外にも一般化できます。互いに依存していないタスクは平行して処理をするという原則です。— これはオープンソースソフトウェアの開発に限ったものではありませんが、オープンソースプロジェクトは、独自のやり方でこの原則を実践しています。プロジェクトで作業をしているボランティア達は、道路工事の作業員や通行する車を気にする余裕はそんなにありませんし、カラーコーンの傍に待機して車に旗を振らせることに作業員を専念させる余裕もないのです。つまり、彼らはプロジェクト管理の負荷の変化が激しい管理プロセスよりは、負荷が一定か、変化が少なくなるようなプロセスを好みます。ボランティアたちは、ちょっと不便だなと思う状態が続いても嫌がりません。自分にかかる負荷が予想できるからこそ、彼らはプロジェクトで起こっていることがスケジュールと衝突しているかどうかを気にせずに作業できるのです。プロジェクトが別の作業をやめてある作業に専念させるようなマスタースケジュールに縛られていると、多くの開発者が長い間何もしない状態が発生します — これは非効率であるばかりか、退屈なので危険です。退屈した開発者は、すぐに辞めてしまうでしょう。

リリース作業は、平行して行なわれる作業のなかでも開発とは関係ないもっとも目立つタスクです。よって次のセクションで説明するやり方で、リリース作業を行なうタイミングを調整しています。しかし、リリース作業と平行して行なえる作業、たとえば翻訳や国際化、コードベース全体に徐々に浸透するようにAPIを大規模に変更する、などが同時に行なわれていることに注意してください。

リリースに番号を付ける

リリースを行なう方法を議論する前に、リリースに対する名前の付け方をみておきましょう。これは、リリースがユーザーにとって何を意味するのかを知らせるのに必要なものです。リリースとは、次のようなものです。

古いバグが直っています。これは全てのリリースに当てはまると多分ユーザーが期待していいことでしょう。
新しいバグが入り込んでいます。これは時々行なわれるセキュリティリリース(この章の後半の「セキュリティリリース」を参照してください)や他の単発リリースを除いて、普通は十分過ぎるほどあり得ることです。
新機能が追加されているかもしれません。
新しい設定オプションが追加され、古いオプションの意味が微妙に変わっているかもしれません。あって欲しくないことですが、直前のリリースと比べてインストール手順も変わっている可能性があります。
互換性のない変更が入っているかもしれません。たとえば、古いバージョンで使われていたデータフォーマットはある種の変換を（多分手動で）しないともはや使えなくなっているといったものです。

見てわかる通り、全てが良いことばかりではありません。よって経験豊富なユーザーは、新しいリリースを少し恐る恐る扱います。特にそのソフトウェアが成熟しており、既にユーザーが求めた（または欲しいと思った）動きをほとんどしてくれていた場合はなおさらです。たとえ新機能が追加されても、それによってソフトウェアが意図しない振舞いをするかもしれないという点で、ありがた迷惑なものなのです。

よって、リリースに番号を付ける目的はふたつあります。当然、リリース番号はリリースの順番を明確に伝える（i.e. ふたつのリリース番号を見れば、どちらが新しいものかがわかる）べきものですが、それだけではなくて、変更の性質や程度をできるだけ簡潔に示すものでなければなりません。

そんなことを全部数字で表現するのかって？まあ、程度の差はありますが答えはYESです。リリース番号の付け方は、些細な話題なのに最も古くからあちこちで議論されてきた（6章コミュニケーション の「簡単な議題ほど長引く」を参照してください）もののひとつですが、近い将来、唯一の完全な標準に落ち着く気配はありません。しかし、一貫していること という普遍的に受け入れられた原則に基づいて、優れた戦略がいくつか出てきています。番号の付け方を選び、それを文書化し、守るようにしましょう。番号の付け方をはっきりさせれば、ユーザーはあなたに感謝することでしょう。

リリース番号の構成要素

このセクションではリリース番号を付ける規約を説明しますが、読者に前提となる知識が殆どないことを想定しています。主に参考資料として読まれることを意図していますが、あなたが既にこうした規約に馴染んでいるのなら、飛ばして読んでも構いません。

リリース番号はドットで区切られた数字の集まりです。

Scanley 2.3
Singer 5.11.4

... などです。ドットは小数点ではなく、単なる区切りです。"5.3.9" の次は "5.3.10" となります。プロジェクトによっては、ドットを小数点ととしてあらわすところもあります。もっとも有名な Linux Kernel では、Linux 1.0 に至るまでに、 "0.95", "0.96" ... "0.99" と番号が続きますが、ドットが小数点ではないという規約は今や確固としたものとして確立され、標準となっているはずです。バージョン番号の構成要素（ドットを除いた数字の部分）の数に制限はありませんが、殆どのプロジェクトでは3つか4つにとどめています。その理由は後に明らかにしていきます。

数字の部分に加えて、 "Alpha" とか "Beta"（アルファ版/ベータ版を参照してください）といった、バージョンの状態を説明するラベルを付加するプロジェクトもあります。たとえば次のようなものです。

Scanley 2.3.0 (Alpha)
Singer 5.11.4 (Beta)

Alpha や Beta といった識別子は、同じバージョン番号ながら、こうした識別子がつかないものが将来リリースされることを示しています。よって、"2.3.0 (Alpha)" は結局 "2.3.0" になります。このように、複数の最終リリースの候補となるものを一行であらわすために、識別子そのものがメタ識別子を持つことができます。例として、一般の人が利用できるようになるまでの順番で、一連のリリースを以下に示します。

Scanley 2.3.0 (Alpha 1)
Scanley 2.3.0 (Alpha 2)
Scanley 2.3.0 (Beta 1)
Scanley 2.3.0 (Beta 2)
Scanley 2.3.0 (Beta 3)
Scanley 2.3.0

"Alpha" という識別子がついているときに、 Scanley "2.3" は "2.3.0" と記されていることに注意してください。 "2.3" と "2.3.0" は等しいものです。 — つまり、番号にくっついているゼロの部分は簡潔にするためにいつでも省略できます。— しかし、識別子があるときは、簡潔さはもはや問題ではありません。よって、"2.3" という簡潔な記述ではなく、"2.3.0" と完全な形で表記する方がよいでしょう。

比較的よく使われる他の識別子には "Stable", "Unstable", "Development", そして "RC"（リリース候補という意味）があります。もっとも広く使われているのは未だ "Alpha" と "Beta" で、 "RC" が3番目あたりの位置にきますが、 "RC" の後には常に数字のメタ修飾子が付くことに注意してください。つまり、"Scanley 2.3.0 (RC)" をリリースするのではなく、 "Scanley 2.3.0 (RC 1)" をリリースしてから RC2 を、という具合です。

"Alpha", "Beta", "RC" という3つのラベルは今や広く知られているので、たとえ他のラベルが、内輪の用語ではなく、普通の用語だからという理由で一見よい選択のように見えても、他のラベルを使うのはお薦めしません。ソフトウェアをインストールする人々はこの3つのラベルに既に馴染んでいますし、根拠無しに他のプロジェクトがやっていることと違ったことをする理由はありません。

リリース番号にあるドットは小数点ではありませんが、数字の位置には重要な意味があります。バージョン "1.0"（これはもちろん、"1.0.0" と等しいです）より前のリリースは全て "0.X.Y" というリリースです。 "3.14.158" のすぐ後は、"3.14.159" であって、 "3.14.160" や、"3.15.XXXXXX" などではないのです。

リリース番号を付ける一貫した決まりがあれば、ユーザーは同じソフトウェアのふたつのリリース番号を見て、数字だけでふたつの重要な違いを区別できるようになります。 3つの数字からなる典型的なリリース番号では、はじめの数字は メジャー番号、ふたつめは マイナー番号、そして三つめは マイクロ番号 になります。たとえば、バージョン "2.10.17" は 2番目のメジャーリリースシリーズのうち、 10番目のマイナーリリースラインであり、そのライン上での17番目のリリースということになります。 "ライン" と "シリーズ" という言葉は、ここではくだけた使い方をしていますが、文字通りの意味です。メジャーシリーズというのは、単に同じメジャー番号を共有するリリース全てを指し、マイナーシリーズ（またはマイナーライン）は、同じメジャー番号とマイナー番号を共有する全てのリリースを指します。つまり、"2.4.0" と "3.4.1" は "4" というマイナー番号は同じですが、同じマイナーシリーズではありません。一方、"2.4.0" と "2.4.2" は、 "2.4.1" がそれらの間にリリースされる場合には隣り合うリリースにはなりませんが、同じマイナーシリーズに属しています。

これらの数字の意味は、あなたが期待する通りの意味になります。つまり、メジャー番号をひとつ増やすことは、大きな変更が行われたことを示しています。マイナー番号をひとつ増やすことは、小さな変更が行われたことを意味しています。そしてマイクロ番号をひとつ増やすことは、本当につまらない変更が行われたということになります。プロジェクトによっては、特にリリース間の違いをきめ細かく管理するために、 パッチ番号 と通常呼ばれる4番目の番号を追加しているところもあります。（混乱しやすいのですが、"パッチ番号" を、 3番目のマイクロ番号と同じ意味で用いているプロジェクトもあります。）最後の数字を ビルド番号 として用いるプロジェクトもあります。ビルド番号はソフトウェアがビルドされるたびにひとつ増えていき、ビルド以外の変更がないことをあらわしています。ビルド番号はバグレポートを特定のビルド番号に結びつけるのに役立ちますし、バイナリパッケージを通常配布しているプロジェクトで、恐らくもっとも役に立つでしょう。

いくつ数字を使うのか、それぞれの数字が何を意味するのかについては、多くの異なる規約がありますが、その違いの多くはマイナー番号に関するものです。 — マイナー番号については裁量の余地がありますが、そう多くはありません。次の2つのセクションでは、もっとも広く使われている規約のうち、いくつかを議論します。

単純なやり方

ほとんどのプロジェクトには、たとえマイクロ番号をひとつ増やすだけの場合であっても、どんな修正をリリースに取り込むかについてのルールがあります。マイナー番号を増やす場合にはまた違ったルールがありますし、メジャー番号を増やす場合はさらにルールが違います。こうしたルールに決まった基準はありませんが、複数のプロジェクトでうまく使われてきたルールをここで説明します。あなたのプロジェクトでこのルールを単純に採用してもよいのですが、たとえそうしなくても、これはリリース番号が伝える情報をうまく表現する見本になります。このルールは、APRプロジェクトで使われているものです。 http://apr.apache.org/versioning.html を参照してください。

マイクロ番号だけに影響する（つまり、同じマイナーライン上で行う）変更は、前方互換性と後方互換性の両方がなければなりません。つまり、変更はバグ修正のみか、既にある機能に対するわずかな改善にとどめるべきです。新機能は、マイクロ番号を変更するリリースに取り込んではいけません。
マイナー番号に影響する（つまり、同じメジャーラインで行う）変更には、後方互換性がなければなりませんが、前方互換性は必ずしも必要ありません。マイナー番号を変更するリリースでは、新機能を取り込むのが普通ですが、一度にたくさん取り込んだりはしません。
互換性を維持するには限度があります。メジャー番号に影響する変更がその境目となります。新しいメジャーリリースには前方互換性も後方互換性もありません。メジャーリリースには新機能が含まれているはずですが、全ての機能が新しくなっている場合さえあります。

後方互換性 と 前方互換性 の正確な意味は、ソフトウェアが実現することに依存しますが、解釈の余地がないのが普通です。たとえば、あなたのプロジェクトがクライアント/サーバアプリケーションを作っているとすると、 "後方互換性" とは、サーバを 2.6.0 にアップグレードしても既にあるバージョン 2.5.4 のクライアントが以前と異なる振舞い（もちろんバグを直した場合は別です）をしたり、動かなくなる機能があってはいけないということです。一方、サーバを 2.6.0 にアップグレードすると同時に、クライアントも2.6.0にすると、 新しい 機能がクライアントで使えるようになるかもしれませんが、 2.5.4で使えていたクライアントの機能は 2.6.0 でどう扱われるかわかりません。こういうことが起こると、このクライアントのアップグレードには前方互換性がないことになります。つまり、クライアントを 2.5.4 にダウングレードしても、 2.6.0 で使えていた全ての機能は使えないということになります。なぜなら、2.6.0 の機能には新機能が含まれているからです。

こういうわけで、マイクロリリースは本来バグフィックスのためだけに存在します。マイクロリリースでは前方、後方互換性の両方を維持しなければなりません。つまり、2.5.3 から 2.5.4 にアップグレードしたあとで気が変わって 2.5.3 に戻したとしても、特定の機能が失われてはいけません。もちろん、2.5.4 で直したバグはダウングレードするとまた再現するでしょうが、そのバグがあっても既に動いている機能が使えていれば、機能が失われたことにはならないのです。

クライアント/サーバ間のプロトコルは、互換性の問題が起きる可能性がある分野のひとつです。別の分野として、データフォーマットがあります。ソフトウェアがデータを永続的なストレージに保存するでしょうか？もしそうなら、読み書きを行うフォーマットはリリース番号のルールで決まっている互換性のガイドラインに従う必要があります。バージョン 2.6.0 は 2.5.4 が保存したファイルを読み込める必要がありますが、 2.5.4 が読めないフォーマットに黙ってアップグレードしているかもしれません。なぜなら、マイナー番号をまたがるとダウングレードできる必要はないからです。あなたのプロジェクトが他のプログラムで使われているライブラリを配布しているとすると、その API も互換性の問題が起こる領域に入ります。新しいバージョンに古いバージョンを置き換える形でアップグレードしても安全かどうか、詳しいユーザーがわかるように、ソース、バイナリレベルでの互換性に関するルールを詳しく説明しておかなければいけません。詳しいユーザーは、バージョン番号をみれば互換性があるかどうかがすぐにわかるでしょう。

このしくみでは、メジャー番号を増やすまで過去のしがらみなしに再出発する機会はありません。このため不便な状況になることもたびたびあります。自分が本当に追加したいと思っている新機能があったり、プロトコルを再設計したいと思ったとしても、互換性を維持している間はそう簡単にできません。最初から拡張可能な方法で設計すること（このトピックに関しては一冊本を書く価値がありますし、この本の範囲外でしょう）以外に、この問題に対する魔法の解は存在しません。しかし、リリース間の互換性に関するルールを示し、それを守ることはソフトウェアを配布するにあたって不可欠です。不愉快な思いを一度させてしまうと、多くのユーザーが離れていってしまいます。ここまで説明してきた互換性に関するルールは、広く知られているだけでなく、まだそういったルールに馴染みがない人にも説明しやすく、覚えてもらいやすいという点で優れています。

互換性に関するルールは、バージョン 1.0 以前には適用されないことが一般に知られています。（しかし、はっきりさせておくために、リリースポリシーではこのことを明示的に宣言しておくべきです）開発の初期段階にあるプロジェクトは、バージョン 0.1, 0.2, 0.3 といった順で、 1.0 の準備ができるまでリリースを行うことができますし、リリース間の違いを適宜大きくすることができます。バージョン 1.0 以前は、マイクロ番号を使うかどうかは任意です。プロジェクトの性質とリリース間の差異によっては、 0.1.0, 0.1.1 といった番号があれば便利かもしれませんし、そうでないかもしれません。バージョン 1.0 以前のリリース番号のルールはかなりルーズです。これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることと、早くから使っている人はどちらにせよ寛大な傾向にあることが主な理由です。

こうした制約は、３つの数字を使った番号の付け方にだけ当てはまります。あなたのプロジェクトでは、３つの数字を使って、これとは違った番号の付け方を簡単に思い付くでしょう。もしくは、細かい粒度は必要ないので、代わりに２つの番号を使おうと決めることもできるでしょう。重要なのは、こういうことは早めに決めておいて、それぞれの数字が意味するところを正確に皆に知らせ、それを守ることです。

奇数/偶数に意味を持たせるやり方

プロジェクトによっては、マイナー番号の偶数/奇数をソフトウェアの安定度を示すために使うことがあります。つまり、偶数は安定版で、奇数は不安定版ということです。これはマイナー番号にのみ当てはまることで、メジャー番号とマイクロ番号には当てはまりません。マイクロ番号をひとつ増やすことは、バグフィックスが行われた（新機能はない）ことを示しますし、メジャー番号をひとつ増やすことは、大きな変更が行われたか、新機能が揃っていることをあらわしています。

数あるプロジェクトの中でも、特に Linux Kernel プロジェクトで使われてきたこの仕組みの利点は、製品版を使うユーザーが潜在的に不安定なコードの影響を受けることなく、新しい機能をテスト用にリリースできることです。ユーザーは、リリース番号から、 "2.4.21" は現在動いているWebサーバのマシンにインストールしていいが、 "2.5.1" は多分家のワークステーションの実験用に限るべきだろう、ということがわかります。開発チームは不安定版（マイナー番号が奇数のもの）に関するバグレポートを扱い、不安定版でいくつかのマイクロ番号のリリースを重ねて安定してきたら、マイナー番号をひとつ増やし（つまり、マイナー番号を偶数にします）、マイクロ番号を "0" にリセットします。そして恐らくは、安定版のパッケージをリリースしていくことになるでしょう。

この仕組みは少なくとも、以前説明した互換性のガイドラインと衝突しないことを保証します。これはマイナー番号にいくらか追加情報を付加したものです。これによって、他の仕組みよりマイナー番号がひとつ増える回数が２倍多くなりますが、大きな害はありません。奇数/偶数に意味を持たせる仕組みは、リリースサイクルがとても長いプロジェクトでもっとも有効でしょうし、プロジェクトの性質上、新機能よりも安定性に重きを置く保守的なユーザーの割合が高いところでも有効です。この仕組みが、新機能を大胆にテストする唯一の方法ではありません。この章の後半の「リリースを安定させるプロセス」でも説明していますが、潜在的に不安定なコードをリリースするもっと一般的な方法は、ユーザーがリスクと利益のトレードオフをリリース名からすぐに把握できるように、リリースにマークを付けることです。

リリースブランチ

開発者の視点から見ると、フリーソフトウェアプロジェクトは継続してソフトウェアをリリースしている状態です。開発者は通常、最新の利用可能なコードをいつも実行しています。なぜならバグを発見したいですし、最新だが機能として不安定な領域を避けつつ、間近なところでプロジェクトの状態を追いかけているからです。彼らは毎日ソフトウェアのコピーを更新していますが、一日に一回以上更新することもあります。よって変更をコミットするときは、他の開発者も２４時間以内にコミットした変更のコピーを入手すると期待できるのです。

では、プロジェクトはソフトウェアをどうやって正式にリリースすべきなのでしょうか。ある時点のソースツリーのスナップショットを取得してパッケージにまとめ、たとえばバージョン "3.5.0" として世界中に配布すべきなのでしょうか。常識からいって答えはNOです。第一、開発ツリー全体が綺麗になっていて、リリースの準備ができている瞬間なんて多分ありません。開発を始めた新機能のコードが、様々な完成度でそこらじゅうに転がっているでしょう。バグを直すために大きな変更をコミットする人もいますが、その変更には議論の余地があり、スナップショットをとったときには議論中の場合もあります。この場合、議論が終わるまでスナップショットの取得を遅らせるだけではうまくいきません。なぜなら、別の関係ない議論がその間に始まってしまう可能性がありますし、そうなると その議論も 終わるまで待たねばならなくなります。このプロセスはいつ終わるのか保証できません。

とにかく、ソースツリーの完全なスナップショットを使ってしまうと、たとえツリーをリリースできる状態にもっていけたとしても、そのとき進行している開発を妨げてしまいがちです。たとえば、現在のスナップショットを仮に "3.5.0" とし、次のスナップショットが "3.5.1" になるとして、 "3.5.1" にはリリース 3.5.0 で見つかったバグの修正が殆ど含まれているとしましょう。しかし、この両方のスナップショットが同じツリーにあると、開発者はこのふたつがリリースされている間何をすべきでしょうか？互換性に関するガイドラインがあるため、新機能を追加することはできません。しかし、開発者全員が 3.5.0 のコードに入っているバグを熱心に修正するとは限りません。新機能を完成させようとしている開発者もいます。リリース作業がソースツリーを不自然な休止状態にする必要があるという理由だけで、自分が興味がないことに取り組むか、ぼけっとしているかを選ばねばならなくなったら、開発者は怒ってしまうでしょう。

こうした問題に対する解は、いつも リリースブランチ を使うことです。リリースブランチは、バージョン管理システムの単なるブランチ（ブランチ を参照してください）です。そこでは、リリースされることになっているコードが開発の本線から隔離されます。リリースブランチの概念は、フリーソフトウェアプロジェクトで生まれたものではありません。たくさんの商用ソフトウェアの開発チームもリリースブランチを使っています。しかし、商用ソフトウェアの開発では、リリースブランチは贅沢なものだと考えられることがあります — つまり、開発チームがメインツリーを安定させる作業を急いでいる間は、大きな締切に追われて省略されてしまう一種の "ベストプラクティス" になってしまう可能性があるのです。

しかし、リリースブランチはオープンソースプロジェクトに不可欠なものです。私はリリースブランチ無しでリリースを行っているプロジェクトを見たことがありますが、いつもぼけっとしている開発者がいる一方で — 通常は少数の — 開発者がリリースを世に出すために働いていたのです。これは複数の点で悪い結果をもたらしてしまいます。まず第一に、開発全体の勢いが衰えてしまいます。ふたつめに、リリースの質が必要以上に下がってしまいます。なぜなら、開発者は２, ３人しか働いていませんし、他の開発者が早く開発に復帰できるように急いで作業を終えようとしてしまうからです。３つめは、異なった仕事が開発者同士を不必要に衝突させてしまうため、開発者チームが精神的に分裂してしまうことです。ぼーっとしている開発者は、自分達のスケジュールや興味に沿って行動を選べるのであれば、リリースブランチに少し注意を向けるだけで多分幸せなのです。しかしブランチがなければ、彼らが選べるのは "俺は今日リリース作業をやろうか、それとも本線で開発している新機能の作業をしようか？" という二択ではなく、 "俺は今日プロジェクトに参加しようか、それともやめちゃおうか？" となってしまいます。

リリースブランチの使い方

リリースブランチを作る正確な手順は、利用しているバージョン管理システムに依存しますが、ほとんどのシステムでは、一般的な概念は勿論同じです。ブランチは通常別のブランチか、trunk（幹）から派生します。伝統的に、trunk では本線の開発が進んでおり、リリースの制限を受けません。リリース "1.0" 用のはじめてのリリースブランチは trunk から派生します。 CVS では、ブランチを作成するコマンドは次のようになります。

$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_0_X

Subversionでは、次のようにします。

$ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x

（これらの例はすべて、３つの数でリリース番号を付けるやり方を想定したものです。それぞれのバージョン管理システムで使われる正確なコマンドを示すことはできませんが、 CVS と Subversion の例を示すことで、他のシステムで対応するコマンドが予測できればいいなと思っています。）

"1.0.0" ではなく、 (文字通り "x" という文字を使って）"1.0.x" ブランチを作成したことに注意してください。これは同じマイナーライン — つまり、同じブランチということです — が全てのマイクロリリースで使われるということです。リリースのためにブランチを安定させる実際のプロセスについては、この章の後半の「リリースを安定させるプロセス」で説明しています。ここでは、バージョン管理システムとリリースプロセスの関係にだけ注意を払うことにします。ブランチが安定し、リリースの準備ができたら、ブランチのスナップショットにタグを打つときです。 CVS では、次のようにします。

$ cd RELEASE_1_0_X-working-copy
$ cvs tag RELEASE_1_0_0

Subversion では、次のようにします。

$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0

このタグは 1.0.0 がリリースされた時点の、プロジェクトのソースツリーの正確な状態を表しています。（これはパッケージ化された配布物やバイナリが削除された後で、古いバージョンを取得したい場合に役立ちます。）同じリリースラインでの次のマイクロリリースは、同じく 1.0.x ブランチ上で準備され、リリースの準備が出来次第、 1.0.1 のタグが打たれます。 1.0.2 に向けて繰り返しブランチを綺麗にしていきましょう。 1.1.x リリースラインについて考え始める時期が来たら、新しいブランチを trunk から作ります。 CVS では、次のようにします。

$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_1_X

Subversion では、次のようにします。

$ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x

メンテナンスは 1.0.x と 1.1.x ラインに対して並行して続けられ、リリースは両方のラインから独立して行えます。実際、ふたつの異なったラインからほとんど同時にリリースが行われることも珍しくありません。古いラインからのリリースは、一気に（たとえば）1.1 へバージョンアップしたいときは、必ず周到な準備をしたいと望む保守的なサイト管理者にお薦めです。一方で大胆なユーザーは通常、不安定なバージョンであるというリスクを負ってでも、必ず最新の機能を使うために、より新しいラインの最新のリリースを採用します。

ここで説明したことが、リリースブランチの唯一の使い方ではありません。自分が参加していたプロジェクトではとてもうまくいっていたのに、ある状況下ではうまくいかないことがあるかもしれません。うまくいきそうなやり方を使ってください。しかし、以下の点は重要なので覚えておきましょう。つまり、リリースブランチの目的は、日々の開発作業によって生まれる変化からリリース作業を分離することと、リリース作業を組織的に行うために、物理的な作業スペースをプロジェクトに与えることです。このプロセスは次のセクションで説明します。

リリースを安定させるプロセス

リリースを安定させるプロセス とは、リリースブランチをリリースできる状態に持っていく作業です。つまり、どの変更をリリースに含めるか、含めないかを決定し、その方針に従ってブランチを整備することです。

この "決定" という言葉には、厄介なことがたくさん含まれています。リリース直前に新機能がたくさん出てくるのは、協調的なソフトウェアプロジェクトでは日常茶飯事です。開発者はリリースが近いことを知ると、それに乗り遅れまいとして大急ぎで変更作業を終えようとします。これは勿論、リリースするときにはまさに起こって欲しくないことです。開発者は自分の好きなペースで新機能を実装していればいいのであって、自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方がいいのです。ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、コードは不安定になり、（普通）多くのバグが発生してしまうのです。

ほとんどのソフトウェアエンジニアは、リリースを安定化する過程でどの変更をリリースに取り込むべきかについて、おおまかな点で一致しています。深刻なバグ、特に回避しようがないバグの修正は含めていいでしょう。ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正（但し、それがインターフェイスの一部と考えられていて、安定していなければいけない場合は別です）も同様です。多くのプロジェクトでは、リスクが低いか、コアに影響しない変更も受け入れますし、リスクを測るための正式なガイドラインもあるでしょう。しかし、どんな基準があったとしても人間の判断は必ず必要です。変更をリリースに取り込むか否かをプロジェクトが決めなければいけないのは日常茶飯事でしょう。危険なのは、開発者それぞれが自分の変更をリリースに含めたいと思っているので、変更を受け入れることを望む人は多いのに、それに対して NO という人が少ないことです。

そういうわけで、リリースを安定化させるプロセスは、ほとんどが "NO" と言う仕組みを作ることと同じです。オープンソースプロジェクトに特有なのは、開発者を傷つけたり、がっかりさせることなく "NO" といいつつ、価値がある変更はリリースに取り込むようにする方法に知恵を絞っていることです。たくさんの方法がありますが、いったん開発チームがそれらを重要な基準として注目すれば、基準を満たす仕組みを作るのは簡単です。ここではもっとも人気のある、両極端なやり方をふたつ簡単に説明しますが、二つだけにすることで、プロジェクトが創造性をなくしてはいけません。他のやり方はたくさんあるでしょうから、私が実際に使われているのを見たことがあるふたつだけに留めておきます。

リリースオーナーによる独裁

開発者グループは特定の人物がリリースオーナーになることに同意します。リリースオーナーはどの変更をリリースに取り込むかを決める最終的な権限を持ちます。勿論、それについては通常議論が行われますし、期待されていますが、開発者グループは結局、リリースオーナーに最終的な決断を行うための十分な権限を与えなければなりません。この仕組みがうまく機能するには、加えられた全ての変更を理解できる卓越した技術力を持ち、社会的にうまくやっており、多くの人を傷つけずにリリースにもっていけるよう議論を導くコミュニケーション能力がある人を選ばなければいけません。

よくあるのは、"この変更は間違ってないけど、テストをする十分な時間がとれていない。だから、今回のリリースに含めるべきではない。" というものです。これは、リリースオーナーがプロジェクトに関連した技術の知識を広く持っている場合に大いに役立ちますし、その変更が潜在的にコードを不安定にする（たとえば、ソフトウェアの他の部分に与える影響や、移植性に関することなど）理由を得ることができます。場合によっては、リリースオーナーの決定が正しいことを証明せよという人や、見た目ほどその変更はリスキーでないと主張する人も現れます。リリースーオーナーは、こうした主張のすべてが自分の決定に反対しているか、反対に固執しているわけではないと判断できれば、こうした主張に真正面からぶつかる必要はありません。

プロジェクトリーダーがリリースオーナーになる必要はないことに注意してください。 (そもそもプロジェクトリーダーがいる場合は、4章プロジェクトの政治構造と社会構造 の「優しい独裁者」を参照してください) 実際、プロジェクトリーダーとリリースオーナーは兼任 しない ほうがよいことがあります。優れたプロジェクトリーダーになるのに必要なスキルは、リリースオーナーになるのに必要なそれと同じではありません。リリースプロセスと同じくらい重要な局面では、誰かがプロジェクトリーダーの判断を相殺するくらいの方が賢いかもしれません。

この章の後半にある「リリースマネージャー」で説明するリリースマネージャーは、リリースオーナーとは対照的に独裁的ではありません。

リリースに含める変更を投票で決める

リリースオーナーの独裁と正反対のやり方ですが、開発者はどの変更をリリースに取り込むかを投票することができます。しかし、リリースの安定化するプロセスで一番重要なのは変更を除外することなので、複数の開発者が積極的に賛成した変更をリリースに取り込めるように投票システムを設計することが重要になります。変更をリリースに取り込むには、過半数以上の賛成が必要とすべきです(4章プロジェクトの政治構造と社会構造 の「誰が投票するのか?」) を参照してください)。別のやり方として、一人が賛成し、他の人が反対しなければ十分という考え方もあるでしょうが、不幸な政治力学によって、各々の開発者は自分が加えた変更に賛成票を投じるが、報復を恐れて他の開発者の変更には反対票を投じたがらなくなるという状況が生まれます。これを避けるには、開発者達にあらゆる変更をリリースに取り込めるよう協力して行動させるように、システムを変えるべきです。これは多くの開発者が個々の変更をレビューするだけでなく、それぞれの開発者が変更に対して反対票をためらわずに投じることも意味します。なぜなら、自分の意見とは反対の票を投じる人が、自分を侮辱していると思う人はいないからです。参加する人が多くなればなるほど、個人に関する議論ではなく、変更に関する議論が多く行われるようになります。

Subversion プロジェクトで使われているシステムは、うまくバランスがとれているようなので、私はここでそれをお勧めします。ある変更をリリースブランチに適用するには、少なくとも３人の開発者が賛成しなければならず、反対する人がひとりもいてはいけません。 "反対" の票がひとつでもあれば、リリースに含めるのを止めるのに十分です。つまり、リリースにおける "反対" 票は拒否権と同じになります(「拒否権」を参照してください)。当然のことですが、この手の反対票を投じるには正当な理由がなければなりませんし、理屈の上では十分多くの人が不当だと感じれば覆すことができますし、特別な投票があっても同様です。実際、こんなことは決して起こりませんし、起こって欲しくもありません。どちらにせよ人々はリリースに対しては保守的ですし、誰かがある変更をリリースに含めることに拒否権を投じたいと強く感じるときは、普通は十分な理由があるときです。

リリースの手続きはわざと保守主義に偏っているので、正当な理由が付けられた反対票は、技術的というより手続き的に扱われることがあります。たとえば、ある変更はよく書かれていて、バグは起こさないだろうけど、マイクロリリースに含めるには変更の規模が大きいからという理由で反対票を投じる人がいるかもしれません。 — 多分その変更は新機能を加えるものか、微妙な点で互換性のガイドラインに完全に準拠していないのでしょう。ある変更にもっとテストが必要だと直感で思ったという理由で反対票を投じる開発者を見たことがありますが、綿密に調べても何のバグも見付けられなかったのです。開発者たちはちょっと不平をいいましたが、反対票は有効なまま、その変更はリリースに含められなかったのです。（ですが、後のテストでバグが見付かったかどうかを私は覚えていません）

リリースを安定させるプロセスを管理する

プロジェクトで投票システムを変える選択をした場合、投票用紙や決選投票を行う物理的な仕組みをできるだけ便利にすることが求められます。たくさんの電子投票システムがオープンソースで公開されていますが、実際もっとも簡単なのは、リリースブランチに STATUS または VOTES といったテキストファイルを用意することです。このファイルは提案されている変更を一覧にしています。— 開発者であれば誰でも変更をリリースに取り込むよう提案することができます。 — このファイルには、全ての投票と、それに対する賛成、反対意見、それに加えてあらゆるメモ、そしてコメントが書き込まれています。（ところで、変更を提案することは、必ずしもその変更に賛成票を投じているというわけではありません。しかし、そのふたつは同時に行われることがよくあります。）こうしたファイルのエントリは、次のようになるでしょう。

* r2401 (問題 #49)
  クライアント/サーバのハンドシェイクが２度行われるのを避ける。
  変更する理由:
    余計なネットワークのターンアラウンド時間を減らす。変更の規模は小さく、レビューしやすい。
  メモ:
    これについては http://.../mailing-lists/message-7777.html
    及びこのスレッドにある他のメッセージで議論された。
  投票:
    +1: jsmith, kimf
    -1: tmartin (バージョン 1.0以前のサーバとの互換性が壊れてしまう。
                 確かに、1.0以前のサーバはバグが多いが、だからといって
                 何故必要もないのに互換性を壊すのか？)

この場合、提案された変更は賛成票を2つ得ていますが、 tmartin によって拒否権を行使されています。 tmartin は括弧つきのメモで拒否権を行使した理由を述べています。正確なフォーマットは問題ではありません。つまり、プロジェクトでどのように決めてもよいのです — 多分、 tmartin が拒否権を行使した理由は "メモ:" のセクションに移すか、変更の理由は他のセクションに合わせて "説明:" ヘッダをつけるべきでしょう。重要なのは、変更を評価するのに必要な全ての情報を到達可能にしておくことと、決選投票をする仕組みをできるだけ簡単にしておくことです。提案されている変更はリポジトリのリビジョン番号で参照します。（今回の場合は、単一のリビジョン r2401 ですが、複数のリビジョンでも簡単にできます）リビジョン番号は、trunk に加えられた変更を参照することが想定されています。既にリリースブランチに変更が加えられている場合は、投票する必要はないでしょう。もしバージョン管理システムが個々の変更を参照する明示的な文法を持ってない場合は、プロジェクトが作るべきです。投票を実効性のあるものにするためには、対象となる各々の変更は曖昧でない状態で識別できなければならないのです。

こうした変更の提案、もしくは投票の対象になる変更は、必ずリリースブランチに綺麗に適用できなければなりません。つまり、衝突せずに適用できるということです（コンフリクト を参照してください）もし衝突がある場合は、綺麗に適用するよう調整したパッチか、変更を調整したバージョンを格納した一時ブランチを投票のエントリに記述すべきです。たとえば次のようなものです。

* r13222, r13223, r13232
  libsvn_fs_fs の自動マージアルゴリズムを書き直した
  変更する理由:
    30万リビジョンが格納されたリポジトリのパフォーマンスが許容できない
    (小さなコミットをしても50分以上かかる)
  変更を加えたブランチ:
    1.1.x-r13222@13517
  投票:
    +1: epg, ghudson

この例は実在のプロジェクト、つまり Subversion 1.1.4 のリリースプロセスで作られた STATUS ファイルから引用したものです。変更が起こした衝突を調整したブランチがあるにもかかわらず、オリジナルのリビジョンを、どうやって変更を表現する規則的な名前にしているかに注意してください。（そのブランチも、変更をリリースにマージするのを容易にするために３つのtrunkリビジョンを r13517 というリビジョンにまとめていますが、これは許されるはずです）この例にはオリジナルのリビジョンが記述されています。なぜなら、ログメッセージが残っているので、もっともレビューしやすいからです。一時的なブランチにはそうしたログメッセージはないでしょう。情報の重複を避けるため（3章技術的な問題 の「情報の一元管理」を参照してください）、ブランチのログメッセージは"r13222, r13223, r13232 を 1.1.x ブランチ用に調整した" と簡単にすべきでしょう。変更に関する情報は全てオリジナルのリビジョンから追いかけることができます。

リリースマネージャー

リリースに取り込む変更を実際にリリースブランチにマージする(マージ (あるいはポート) を参照してください)プロセスは、開発者であれば誰でもできます。変更をマージする専門の人を置く必要はありません。もし変更がたくさんあれば、マージする負担を分散させた方がよいかもしれません。

投票することと変更をマージすることは別々に行われますが、実際にはリリースプロセスを指揮する人がひとりかふたりはいます。この役割を正式に リリースマネージャー と呼ぶことがありますが、どの変更を取り込むかに関する最終的な決定権があるリリースオーナー（この章のはじめの方の「リリースオーナーによる独裁」を参照してください）とは全く別物です。リリースマネージャーは、リリースに取り込む候補になる変更の数や、実際に取り込まれた変更の数、そして取り込まれる可能性が高い変更の数などを追いかけています。重要な変更に対して開発者が十分に注意を払わず、投票もされずに放置されるかもしれないとリリースマネージャーが感じた場合、彼らは他の開発者に小言を言ってレビューや投票をするよう促します。リリースに取り込む変更がたまってきたら、リリースマネージャーが引き取ってまとめてリリースブランチにマージすることもあります。変更を明示的にコミットする以外の仕事を全て彼らにやらせる必要はないと理解しているのなら、他の開発者がそうした仕事をリリースマネージャーに任せられるのはよい状態です。リリースを世に出す時がきたら(この章の後半の「テストとリリース」を参照してください)、リリースマネージャーは最終的なリリースパッケージを作成したり、デジタル署名を集めたり、パッケージをアップロードしたり、公式にアナウンスを出す作業に注意を払います。

パッケージング

フリーソフトウェアを配布する標準的なやり方は、ソースコードを配布することです。これはソフトウェアがソースコードをそのまま実行できる(i.e. Perl, Python, PHP などのように、インタプリタによって解釈できるもの)か、はじめに(C, C++, Javaなどによって）コンパイルする必要があるかどうかに関わらず当てはまります。コンパイルする必要があるソフトウェアの場合、ほとんどのユーザーが多分自分でソースをコンパイルせず、あらかじめビルドされたバイナリパッケージをインストールするでしょう。 (この章の後半にある「バイナリパッケージ」を参照してください) しかしながら、バイナリパッケージはオリジナルのソースコードを元にして作られています。ソースパッケージで重要なのは、曖昧でない形でリリースを定義していることです。プロジェクトが "Scanley 2.5.0" を配布する場合、それが特に意味するところは "コンパイルして（必要であれば）インストールすると、Scanley 2.5.0 を生成するソースファイルのツリーである" ということです。

どういう形でソースファイルをリリースすべきかについては、かなり厳格な基準があります。基準から外れた部分も時折見つかるでしょうが、それはルールではなく例外です。やむを得ない理由がなければ、あなたのプロジェクトでもこの基準に従うべきです。

パッケージのフォーマット

ソースコードはディレクトリツリーを保存してくれる標準的なフォーマットでリリースすべきです。 Unix または Unixライクなオペレーティングシステムでは、 compress コマンドや、gzip、 bzip または bzip2 コマンドを使って圧縮した TAR フォーマットを使うという決まりがあります。Microsoft Windows では、ディレクトリツリーを保存した状態で配布する標準的なやり方として zip フォーマットを使う方法があります。これはたまたま圧縮もしてくれるので、アーカイブを作った後に圧縮を行う必要がありません。

TAR ファイル

TAR とは、"Tape ARchive" を略したものです。なぜなら、tar フォーマットはディレクトリツリーを磁気テープに保存するのに理想的な直列のデータストリームとして表現するからです。また、この性質ゆえにディレクトリツリーを単一のファイルとして配布することが標準となっています。圧縮された tar ファイル(またはtarボール)を提供するのは非常に簡単です。システムによっては、tarコマンド自体が圧縮済みのtarボールを生成するものもありますし、圧縮するのにtarコマンドとは別のコマンドを使うシステムもあります。

パッケージ名とレイアウト

パッケージの名前は、ソフトウェアの名前とリリース番号の後で、アーカイブのやり方に合った適切なフォーマットの拡張子を最後につけるようにしましょう。たとえば、Scanley 2.5.0 を Unix向けにパッケージングし、 GNU Zip(gzip) フォーマットで圧縮したときの名前は次のようになるでしょう。

scanley-2.5.0.tar.gz

また、Windows 向けに zip フォーマットで圧縮した場合の名前は次のようになるでしょう。

scanley-2.5.0.zip

どちらのアーカイブを展開しても、カレントディレクトリに scanley-2.5.0 という名前の単一のディレクトリツリーが生成されるはずです。このディレクトリには、ソースコードを(必要なら)コンパイルし、インストールできる状態でソースコードを配置すべきでしょう。ディレクトリツリーの最上部には、このソフトウェアが何をするもので、今回のリリース内容がどういうものか、そしてプロジェクトのWebサイトやその他面白いファイルなどのリソースについて説明した README ファイルをプレーンテキストで配置します。他の面白いファイルとしては、README ファイルの兄弟分にあたり、サポートする全てのオペレーティングシステム上でソフトウェアをビルドし、インストールする方法を説明した INSTALL ファイルがあげられます。 2章さあ始めましょう の「ライセンスを適用する方法」でも説明していますが、ソフトウェアの配付条件を示した COPYING や LICENSEファイルもツリーの最上部に配置します。

今回のリリースで新しくなったことを説明する CHANGES (NEWS と呼ばれることもあります) ファイルもツリーの最上部に配置します。この CHANGES ファイルは、これまで行われたリリース全ての変更点を集めたもので、今回のリリースの変更点の一覧が一番最初になるように、リリースされた順番とは逆順に記されています。この変更点一覧を完成させるのは、リリースブランチをリリースできる状態にする作業の最後に行うのが普通です。開発している間に少しずつ変更点を書き足していくプロジェクトもあれば、バージョン管理システムのログを組み合わせることで情報を集め、最後にひとりの人間がまとめるまで作業を保留するのを好むプロジェクトもあります。変更点の一覧は、次のようになるでしょう。

Version 2.5.0
(2004年12月20日に /branches/2.5.x からリリース)
http://svn.scanley.org/repos/svn/tags/2.5.0/

 新機能、改良点:
    * 正規表現による問い合わせを追加 (問題 #53)
    * UTF-8 と UTF-16 で書かれたドキュメントのサポートを追加
    * ドキュメントが ポーランド語、ロシア語、マダガスカル語に翻訳された。
    * ...

 バグ修正:
    * 再インデックス時のバグを修正 (問題 #945)
    * 問い合わせに関するバグをいくつか修正 (問題 #815, #1007, #1008)
    * ...

変更点の一覧は、必要であればどれだけ長くても構いませんが、小さなバグ修正や機能追加を全て含めてしまうことで、内容が退屈にならないようにしましょう。このファイルの目的は、新しいリリースにアップグレードすることで得られるものの概要をユーザーに示すだけです。実際、変更点の一覧はリリースアナウンスの電子メールに書くことが普通なので、それを見る人のことを考えて書くようにしましょう。

CHANGES ファイルと ChangeLog ファイル

伝統的に ChangeLog ファイルは、プロジェクトでこれまで行われたあらゆる変更を一覧にします。 — つまり、バージョン管理システムにコミットされた全てのリビジョンです。 ChangeLog ファイルには様々なフォーマットがあります。どんなフォーマットでも同じ情報が含まれているので、フォーマットの詳細はここでは重要ではありません。その情報とは、変更日、変更した人、変更に関する簡単な要約(または単にその変更のログメッセージ）です。

CHANGES ファイルは違います。このファイルは変更点を一覧にするだけでなく、ある人達が見て重要だと思われるものも一覧に加えます。そして正確な変更日や変更した人のようなメタデータはよく省略されます。混乱を避けるため、CHANGES と ChangeLog ファイルを同じ意味で使わないでください。プロジェクトによっては、"CHANGELOG" ではなく、 "NEWS" というファイル名を使うところもあります。こうすることで "ChangeLog" との混同は避けられますが、この名前はぴったり来る名前ではありません。なぜなら、 CHANGES ファイルは全てのリリースの変更点を保持しているので、先頭に書いてある最新のニュースに加えて、たくさんの古いニュースも掲載することになるからです。

ChangeLog ファイルは、どちらにせよ徐々に消えつつあるものかもしれません。このファイルはCVSがバージョン管理システムの唯一の選択肢だった時代には役に立つものでした。なぜなら、CVSでは変更点の情報が展開しにくかったからです。しかし、最近のバージョン管理システムを使うと、 ChangeLogで保存されていたデータは、バージョン管理システムのリポジトリに要求することでいつでも引き出すことができます。これによって、プロジェクトが変更点を静的なファイルに保存する意味がなくなります。 — 実際には、リポジトリに保存されたログメッセージは、 ChangeLog ファイルの内容と重複するだけなので、もっと無意味なことが起こります。

ツリーにあるソースコードのレイアウトは、バージョン管理システムのリポジトリから直接プロジェクトをチェックアウトしたときに得られるものと同じか、できるだけ似たものにすべきです。これらの間には少し違いがあるのが普通です。たとえば、リリースされるパッケージには設定やコンパイルに必要な自動生成されたファイル(この章の後半の「コンパイルとインストール」を参照してください) が含まれていたり、プロジェクトが管理していないが、必須のものであったり、ユーザーがまだインストールしていないかもしれないサードパーティーのソフトウェアが含まれているからです。しかしながら、たとえ配布されたディレクトリツリーが、バージョン管理システムのリポジトリにある開発ツリーと全く同じだったとしても、その配布物は作業コピーと同じであってはいけません(作業コピー を参照してください)。あるリリースは、開発ツリーへの静的な参照ポイントです。 — これは特に、ある時点の固定されたソースファイルの設定を表したものです。もし配布物が作業コピーと同じだと、ユーザーがそれを変更するかもしれません。また、実際に変更した後でリリースがあることを考えると危険です。

パッケージの中身は、パッケージングのやり方に関わらず同じであることを忘れないでください。リリース—つまり、"Scanley 2.5.0" と呼ぶ場合に参照する正確なものは、 zipやtarボールを展開したときに生成されるディレクトリツリーと同じです。よって、プロジェクトはこれら全てのフォーマットをダウンロード用に提供しても構いません。

scanley-2.5.0.tar.bz2
scanley-2.5.0.tar.gz
scanley-2.5.0.zip

しかし、パッケージを展開して生成されるソースツリーは全て同じでなければなりません。このソースツリーは配布物です。つまり、ダウンロードするパッケージのフォーマットは、ユーザーの便宜のためだけに存在します。ソースパッケージにちょっとした違いがあっても許される場合があります。たとえば、Windows用のパッケージでは、テキストファイルの行はCRLF(キャリッジリターンとラインフィード)コードで終わるべきです。一方でUnix用のパッケージでは、LFで終了します。仮に異なったオペレーティングシステム間で違うコンパイル用のレイアウトが必要なら、異なったオペレーティングシステム用のソースパッケージでは、ソースツリーが少し異なっていても構いません。しかし、こうした違いは基本的にちょっとした変換で済ませるものです。基本的なソースファイルは、同じリリースのパッケージの範囲では同じにしておくべきです。

大文字にするか、小文字のままにするか

プロジェクトの名前を引用する場合、普通は適当な名詞を大文字にし、もし頭文字だけを大文字にする単語があれば、そのようにします。たとえば "MySQL 5.0", "Scanley 2.5.0" などです。大文字の表現をパッケージ名でも使うかどうかは、プロジェクトによって異なります。たとえば、Scanley-2.5.0.tar.gz と scanley-2.5.0.tar.gz のどちらがよいか、ということです。(私は後者が好きです。なぜなら、シフトキーを人に打たせるのが嫌だからではなく、大文字を使うパッケージをたくさんのプロジェクトに出荷させることになるからです) 重要なのは、tarボールを展開したときに作られるディレクトリが同じ名前を使っているかどうかです。ユーザーを驚かせないようにすべきです。つまり、配布物を展開して生成されるディレクトリ名は、ユーザーが正確に予測できるようにしておかなければなりません。

プレリリース版

プレリリース版またはリリース候補のパッケージをリリースする場合は、その識別子はリリース番号の一部になります。よって、パッケージ名にその識別子を含めるようにしましょう。たとえば、「リリース番号の構成要素」で説明したアルファ版やベータ版のリリースの順番は、パッケージ名では以下のように表現します。

scanley-2.3.0-alpha1.tar.gz
scanley-2.3.0-alpha2.tar.gz
scanley-2.3.0-beta1.tar.gz
scanley-2.3.0-beta2.tar.gz
scanley-2.3.0-beta3.tar.gz
scanley-2.3.0.tar.gz

はじめのパッケージは、scanley-2.3.0-alpha1というディレクトリに展開され、ふたつめは scanley-2.3.0-alpha2 に展開される ... などです。

コンパイルとインストール

ソースコードをコンパイルし、インストールを行う必要があるソフトウェアは、経験豊富なユーザーが従う標準的な手順があります。たとえば、C, C++, その他のコンパイル言語で書かれたプログラムでは、 Unixライクなシステムでユーザーがタイプする標準的な手順は次のようなものです。

   $ ./configure
   $ make
   # make install

はじめのコマンドは、自動的に実行環境をできるだけ把握し、ビルドの準備を行います。ふたつめのコマンドはソフトウェアをビルドします。（しかしインストールは行いません）最後のコマンドはシステムにソフトウェアをインストールします。最初のふたつのコマンドは通常のユーザーで実行し、最後はrootユーザーで実行します。このシステムをセットアップする作業の詳細は、Vaughan, Elliston, Tromey, Taylor が書いた GNU Autoconf, Automake, and Libtool という優れた本があるので、それを参照してください。この本は出版社 New Riders によってツリーウェア^[27]として公開されており、 http://sources.redhat.com/autobook/ でもオンラインで利用可能です。

この手順が唯一の標準というわけではありませんが、もっとも普及しているもののひとつです。 Ant (http://ant.apache.org/) ビルドシステムが特にJavaで書かれたプロジェクトで人気を得つつありますが、Antもビルドとインストールの標準的な手順を持っています。同様に、PerlやPythonのようなプログラミング言語では、その言語で書かれた殆どのプログラムで同じ手順を使うことを勧めています(たとえば、Perlモジュールは次のようなコマンドを使います。 perl Makefile.PL) 自分のプロジェクトにどの標準を使うかがわからない場合は、経験豊富な開発者に尋ねてみましょう^[28]。たとえどの標準を使うかがはじめわからなくても、適用できる標準が 存在する と思っても大丈夫です。

自分のプロジェクトに適した標準が何であれ、やむを得ない場合以外はそれを破ってはいけません。標準的なインストール手順は、たくさんのシステム管理者が反射的に実践しているものです。プロジェクトの INSTALLファイルに自分が馴染んだ手順が書かれているのがわかれば、このプロジェクトは標準的な規約を守っているという信頼をすぐに得られます。標準的な手順をドキュメントに記すことで、他のことも理解しやすくなるでしょう。また、2章さあ始めましょうの「ダウンロード」でも議論していますが、標準的なビルド手順があると、開発者になる可能性がある人も喜んでくれます。

Windows では、ビルドとインストールの標準的な手順がUnixライクなシステムほど決まっているわけではありません。コンパイルする必要があるプロジェクトでは、 Microsoft の標準的な開発環境(Developer Studio, Visual Studio, VS.NET, MSVC++, など)のワークスペース/プロジェクトモデルに合った形でソースツリーをリリースすることが標準的な規約のようです。ソフトウェアの性質にもよりますが、Cygwin環境(http://www.cygwin.com/)経由でUnixライクなビルドオプションを提供することもできるでしょう。もちろん、自前のビルドとインストール手順があるプログラミング言語やフレームワーク—e.g Perl や Python のような— があるときは、環境が Windows, Unix, Mac OS X, あるいは他のオペレーティングシステム上であっても、それが提供している標準的な手順を採用すべきです。

標準的なビルド、インストール手順にプロジェクトを合わせる努力を惜しまないようにしましょう。ビルドとインストールはソフトウェアを使う入口となる作業です。それを終えたら、やむを得ないならソフトウェアが扱いにくくてもよいのです。しかし、ユーザーや開発者がソフトウェアに触れる最初の段階で、予想外の手順を踏む必要があるなら、それは恥ずかしいことなのです。

バイナリパッケージ

ソースコードをパッケージングしてリリースするのが正式なやり方ですが、ほとんどのユーザーは、オペレーティングシステムのソフトウェア配布システムや、プロジェクト自体や、サードパーティーから取得したバイナリパッケージをインストールします。ここでいう "バイナリ" というのは必ずしも "コンパイルして生成したもの" という意味ではありません。ここでは単に、ソースコードをビルドしてインストールする手順を経ずに、コンピューターにインストールすることができる設定済みのパッケージのことをいいます。 RedHat GNU/Linux では、その仕組みはRPMシステムと呼ばれ、Debian GNU/Linux では、 APT (.deb) システムといいます。Microsoft Windows では、 .MSI ファイルや、実行すればインストールを行ってくれる .exe ファイルであることが普通です。

バイナリパッケージを作る人がプロジェクトに深く関わっている人であれ、サードパーティーであれ、ユーザーはそれらをプロジェクトの公式なリリースとして扱い、バイナリパッケージの振る舞いをベースにしてバグ報告システムに問題を登録してきます。よって、パッケージャーに明確なガイドラインを提供し、彼らが提供するパッケージが、プロジェクトのソフトウェアを適切に表現してくれるように、彼らと緊密に連携することがプロジェクトの関心事になります。

パッケージャーが主に知っておくべきことは、生成するバイナリパッケージは、プロジェクトからリリースされたオフィシャルなソースコードを元にすべきだということです。ユーザーにバグ修正や機能追加を提供するために、パッケージャーはソースコードリポジトリのコピーや、リリース後にコミットされた修正を選んでバイナリパッケージに取り込むことがあります。しかしこうした習慣は、実際には多くの混乱を引きおこします。プロジェクトはリリース済みのバージョンで見つかったバグ報告や、最近の trunk や主要なブランチのソースコードのバグ報告（つまり、注意深く最先端のコードを実行している人が見つけたバグ）を受け付ける準備をしています。バグ報告があがってくると、応答する人はそのバグがある時点のスナップショットで発生したということや、修正済みであること、そしてユーザーがアップグレードすべきか、次のリリースを待つべきかを確認することができます。仮にまだ報告されていないバグの場合は、リリースの時点が明確であれば、それの再現やバグ報告システム上でのバグの分類もやりやすくなります。

しかしながら、ユーザーが改造を加えたものや、バージョンが決まっていない中間的なコードに対するバグ報告は、プロジェクトは受け付ける準備ができていません。こうした報告は再現させるのが難しく、後の開発で加えられる別の変更に予想外の影響を与える可能性もあります。このため、開発者が責任を取る必要がない不正な振舞いをソフトウェアが起こしてしまうのです。過去に発生していたはずのバグが 発生しなくなってしまった ために、多くの時間を浪費してしまってげんなりしたことがあります。これはユーザーが公式のリリース(全く同じではない)にちょっと改造を加えたバージョンを使っていたためです。バグが発生しなかったのが予想外だったので、開発者全員がその理由を調べるために詳細な調査をしなければなりませんでした。

さらに、リリースされたソースコードには変更が必要だとパッケージャーが主張することもあります。パッケージャーは、プロジェクトの開発者にこうした変更を報告し、変更の計画を説明すべきです。パッケージャーが加えた変更は、開発者が受け入れてくれるかもしれませんが、受け入れてもらえなくても、自分がソースコードに変更を加える理由をプロジェクトに知らせておくべきです。これは、プロジェクトが予想外のバグ報告を見張ることができるようにするためです。開発者はプロジェクトのウェブサイトに免責事項を記載することで、こうしたバグ報告に対応してもよいでしょう。また、バイナリパッケージのユーザーに、自分たちが使っているパッケージがプロジェクトが公式にリリースしたものとは正確に同じものではないことを知らせるために、適切な場所で作業をするようにパッケージャーに求めることもできます。こういう状況で、パッケージャーと開発者がいがみ合う必要はありませんが、残念なことに対立してしまうこともあります。パッケージャーは、目指すものが開発者と少し違うだけなのです。パッケージャーはユーザーがインストールすればすぐに使えるものを主に求めています。開発者ももちろんそれを追求してはいますが、彼らは一貫したバグ報告を受付け、互換性を保証するためにパッケージャーが使っているバージョンを知らなればいけません。このふたつの目標はたびたび対立します。対立が起きたときには、プロジェクトはパッケージャーを拘束していないし、パッケージャーと開発者は、持ちつ持たれつの関係にあることを思い出すとよいでしょう。プロジェクトは、ソフトウェアを作るだけであっても、パッケージャーにとって良いことをしているのは事実です。しかし、パッケージャーもユーザーにソフトウェアを広めるために地道な作業のほとんどをこなすことで、開発者にとってよいことをしているのです。この作業は、とてつもない数のユーザーを対象にすることもあります。パッケージャーに反対の意思を示すのはよいことですが、喧嘩をしてはいけません。開発者は自分が出せる最良のソフトウェアを世に送り出すことのみに注力すればよいのです。

テストとリリース

安定版のリリースブランチから、ソースコードのtarボールがいったん作成されると、正式なリリースの手続きが始まります。しかし、tarボールを世界中で利用できるようにする前にはテストを行い、最低限の、通常は3人以上の開発者からリリースしてよいとの同意をもらっておくべきです。この手続きは、明らかな欠陥を探すために単にリリースを調べることではありません。理想を言えば、開発者がtarボールをダウンロードし、インストールしたばかりのシステム上でそれをビルドし、インストールして自動回帰テスト(8章ボランティアの管理 の「自動テスト」を参照してください) を実行し、さらに手動でテストをいくらかしておくべきでしょう。これらのチェックや、プロジェクトが持っているリリース時のチェックリストの項目をすべてクリアすれば、開発者は GnuPG(http://www.gnupg.org/) や PGP(http://www.pgpi.org/)、または PGP と互換性のある他のプログラムを使ってtarボールに電子署名を行います。

ほとんどのプロジェクトでは、開発者はプロジェクトが共有している鍵を使わず、自分の鍵を使って電子署名をします。そしてできるだけ多くの (すなわち、最低限の人数が必要という意味であって、署名する開発者の数を限ればいいという意味ではありません) 開発者が同じtarボールに署名します。署名する開発者が多くなればなるほど、多くテストされているということになり、セキュリティに関心があるユーザーが、そのtarボールから自分が信頼するルートを見つけられる可能性が高くなります。

開発者達からリリースしてよいとの同意をもらったら、リリース(つまり、すべてのtarボール、zipファイル、そして配布される他のあらゆるフォーマットのファイル) は、電子署名と MD5/SHA1のチェックサム(http://en.wikipedia.org/wiki/Cryptographic_hash_function を参照してください) と一緒にプロジェクトのダウンロードエリアに置きましょう。これには標準的なやり方がいくつかあります。ひとつは、それぞれのリリースするパッケージを、対応する電子署名を記したファイルと、チェックサムが書かれたファイルと一緒に置くことです。たとえば、リリースするパッケージのひとつが、scanley-2.5.0.tar.gz だとすると、同じディレクトリにそのtarボールに行った電子署名が含まれている scanley-2.5.0.tar.gz.asc と、MD5 チェックサムを記した scanley-2.5.0.tar.gz.md5 や、 SHA1チェックサムを記した scanley-2.5.0.tar.gz.sha1 を置いておきます。別の方法として、リリースするパッケージに対する全ての電子署名を scanley-2.5.0.sigs のようなひとつのファイルに集めておくことがあります。同じやり方がチェックサムにも使えます。

どの方法を使っても構いません。単純な手続きに留めるようにし、それを明確に文書化するようにしましょう。そして、以後のリリースに対してもそれを一貫して適用するようにします。このように、電子署名とチェックサムをつける目的は、自分が受け取ったコピーが悪意がある人間によって改竄されていないことを確認する手段をユーザーに与えることです。ユーザーはダウンロードしたコードをすぐに自分のマシンで実行してしまいます — つまり、コードが改竄されていれば、攻撃者がそのデータにバックドアを仕掛けることができてしまいます。セキュリティに関して偏執的なユーザーについては、この章の後の方にある「セキュリティリリース」を参照してください。

リリース候補

多くの変更が加えられた重要なリリースでは、多くのプロジェクトは好んで リリース候補 をはじめにリリースします。たとえば、scanley-2.5.0 をリリースする前に scanley-2.5.0-beta1 をリリースするといった具合です。リリース候補を出す目的は、正式なリリースを行う前に、コードを広くテストしてもらうことです。問題が見つかれば、それはリリースブランチで修正され、新しいリリース候補が(scanley-2.5.0-beta2のような形で)リリースされます。このサイクルは、見過ごせないバグが残っていない状態になるまで続けられ、その時点で最後のリリース候補が正式なリリースとなります — つまり、最後のリリース候補と正式なリリースの唯一の違いは、バージョン番号の識別子を除いた点だけ、ということになります。

ほとんどの点で、リリース候補は実際の正式リリースと同じように扱うようにします。 alpha、beta、そして rc といった識別子は、保守的なユーザーに対して正式リリースまで待つように警告するものであればそれで十分です。そしてもちろん、リリース候補をアナウンスする電子メールは、リリース候補を出す目的がフィードバックを求めるためのものであることを記しておきましょう。それ以外は、リリース候補に対して正式なリリースと同じだけの注意を払うようにします。結局は、衆目の眼に晒すことはバグを発見する最高の方法ですし、リリース候補が最終的に正式リリースになるかどうかわからないからこそ、開発者はリリース候補を人々に使ってもらいたいと願うのです。

リリースを告知する

リリースを告知するのは、オープンソースソフトウェアを開発するときに起こる他のイベントと似ていますし、その手続きも 6章コミュニケーション の「宣伝・広報」で説明している方法に従うとよいでしょう。ただ、リリースを告知する場合には特別な点がいくつかあります。

リリースしたtarボールのダウンロード先URLを示す場合は、必ず MD5/SHA1 チェックサムと、電子署名ファイルの場所も同時に示すようにしましょう。リリースの告知は複数の場所 (メーリングリストやニュースページなど) で行われるため、こうすることでユーザーがチェックサムの情報を複数の情報源から得ることができ、最も強くセキュリティに関心を持つユーザーが、チェックサムが改竄されていなかったことを確信できるようになります。電子署名ファイルへのリンクを複数回張ったとしても、その電子署名ファイルがより安全になるわけではありませんが、プロジェクトがセキュリティに真面目に取り組んでいることを人々 (特にプロジェクトを間近で追いかけていない人) が再び確認できます。

電子メールとニュースページで告知をするときは、リリースを宣伝する文章以上の情報も含めるようにし、ユーザーがなぜアップグレードすべきかがわかるように、関連する CHANGES ファイルの部分を必ず含めるようにしましょう。この重要性は、正式なリリースのときも、リリース候補の場合でも同様に当てはまります。バグ修正と新機能の内容を示すことは、ユーザーにリリース候補を試すように誘う意味で重要です。

最後に、開発チームとテスター、そして優れたバグ報告に時間を割いてくれた全てのユーザーに対して感謝の言葉を忘れないようにしましょう。しかし、個人で巨大な仕事をする責任があった人がいない限り、特定の人を名指ししてはいけません。その仕事の価値はプロジェクトのメンバー全員がよーく知っていることですから。クレジットの洪水に脚をとられないように注意しましょう。(8章ボランティアの管理 の「クレジット」を参照してください)

複数のリリースラインを管理する

ほとんどの成熟したプロジェクトは、複数のリリースラインを平行して管理しています。たとえばバージョン 1.0.0 がリリースされた後は、プロジェクトが明示的にリリースラインの維持をやめるまで、マイクロ(バグ修正)リリースを 1.0.1, 1.0.2 などの形でリリースするようにします。ただ (マイナー番号が上がった) 1.1.0 をリリースすることが、 1.0.x ラインの維持をやめる十分な理由にはならないことに注意してください。たとえば、新しいマイナー(メジャー)シリーズのはじめのリリースは絶対にアップグレードの対象にしないことをポリシーにしているユーザーもいます — つまり、彼らはたとえば 1.1.0 の間は他のユーザーにバグを探させ、 1.1.1 のリリースを待っているのです。これは必ずしも自分勝手な行動とは言えません。 (彼らは、新機能や、バグ修正の恩恵を受けることを控えていることも覚えておきましょう) ただ、理由が何であれ、彼らはアップグレードをとても慎重に行うと決めただけなのです。よって、プロジェクトが 1.1.0 のリリースを目前にして 1.0.3 で重大なバグを発見した場合は、ちょっと厳しいですが 1.1.0 でその修正を行い、すべての 1.0.x 系を使っているユーザーにアップグレードを推奨することになるでしょう。この場合、1.1.0 と 1.0.4 を両方リリースしたとして、開発者とユーザーの双方がハッピーでしょうか？そうではないですよね。

1.1.x ラインの維持がうまくいくと、プロジェクトは 1.0.x ラインの 維持をやめる と宣言することができます。この宣言は公式なものとして行いましょう。その告知は単独で行うこともできますし、 1.1.x ラインのリリース告知と一緒に行うこともできます。どの方法をとるにしても、ユーザーは古いリリースラインが維持されなくなることを知らなければいけません。なぜなら、その告知に従って、ユーザーはアップグレードをする決断ができるからです。

プロジェクトによっては、以前のリリースラインのサポートを保証する期間を設定するところもあります。オープンソースの文脈でいえば、"サポート" とはそのリリースラインに対するバグ報告を受け付け、バグが十分出尽くすまでメンテナンスリリースを行うということです。一方で、明示的にサポート期間は設定しないものの、古いリリースラインを使っているユーザーの数を把握するため、バグ報告の数を見張るプロジェクトもあります。古いリリースラインを使うユーザーの率がある値より下がった時点で、プロジェクトはそのラインの維持をやめると宣言し、サポートをやめるのです。

リリースを行うごとに、必ず ターゲットバージョン または ターゲットとなるマイルストーン をバグ報告システムに設定するようにしましょう。これは、ユーザーが適切なリリースに対してバグを報告できるようにするためです。開発中の最新のソースコードに対しては、 "development" や "latest" と呼ばれるターゲット名を設定することも忘れないでください。なぜなら、ユーザーによっては、 — 活発な開発者だけではありません — 公式なリリースより新しいコードを実行しているからです。

セキュリティリリース

セキュリティに関わるバグを扱う方法の詳細は6章コミュニケーション の「セキュリティ脆弱性の告知」で扱っていますが、セキュリティリリースを行うにあたっては、特に議論すべきことがいくつかあります。

セキュリティリリース とは、セキュリティ脆弱性を修正するためだけに行われるリリースです。脆弱性を修正したコードはリリースが公になるまで明らかにできません。これは修正がリリースの日までリポジトリにコミットできないだけでなく、リリースされるまで公の場でテストできないことも意味しています。開発者は、当然のことながら自分たちで修正箇所を調べ、内部でテストすることができますが、広くユーザーにテストしてもらうことはできないのです。

このようにテストが不足することから、セキュリティリリースは常に既に存在するリリースに対して修正を行い、それ以外には 何も変更しない ようにすべきです。これは、テストなしに多くの変更をリリースすればするほど、新しいバグが発生する可能性が高くなるうえ、新しいセキュリティ上の脆弱性が発生する可能性すらあるからです！この保守的なやり方は、セキュリティ上の修正を展開する必要があるシステム管理者だけでなく、セキュリティ上の修正とそれ以外の修正を同時にマシンに展開しないというアップグレードポリシーを持つ管理者にも馴染みやすいものです。

セキュリティリリースを行うために、ユーザーをちょっと騙す場合もあります。たとえば、プロジェクトが 1.1.3 のリリースに向けて動いていて、 1.1.2 に対するバグ修正を行うと公に宣言しているときに、セキュリティに関わるバグ報告が行われた場合です。当然、開発者達はその修正がリリースされるまでセキュリティ問題について話すことはできません。つまり、そのときまで 1.1.3 は計画通り 1.1.2 のバグ修正が含まれたものになると言い続けなければならないのです。しかし、実際に 1.1.3 が出てみると、1.1.2 にセキュリティバグの修正が加わったことだけが変更点で、他の修正は 1.1.4 に先送りされてしまっていました。(これはもちろん、セキュリティバグの修正に加え、 他の修正も 1.1.4 には含まれることになるということです)

セキュリティの修正だけが含まれたリリースであることを示すために、リリース番号に追加の構成要素を加えることもできます。たとえば、 1.1.2.1 というリリース番号は、 1.1.2 に対してセキュリティ修正だけが加わったリリースだと区別できます。そしてそれより "大きい" リリース番号 (e.g. 1.1.3, 1.2.0 など) は、同じセキュリティ修正が加えられたリリースであるとわかります。一方、プロジェクトを間近で追いかけていない人にとっては、ほとんどの場合は3つの数字でリリース番号が構成されているのに、ランダムに、ときどき4つの番号を見ると少し混乱する可能性があります。私が見てきたほとんどのプロジェクトは、リリース番号を一貫させる方針を採用し、セキュリティの修正が含まれたリリースの場合も、たとえそれが他のリリース計画を番号ひとつ分ずらすことを意味するとしても、最新リリースの次の番号を使っています。

リリースと日々の開発

平行して行われるリリースを同時に管理するということから、日々の開発のやり方を推測することができます。特に、次のことはどんなときでも推奨される強制的な規律になります。つまり、コミットのひとつひとつは、論理的な変更単位であること、そして関連のない変更をごっちゃにして一度にコミットしてはいけない、ということです。変更する量がとても多い、または一度にコミットするのが破壊的である場合は、それをN回のコミットに分割し、それぞれのコミットが変更全体をうまく分割したサブセットであるようにします。そして変更全体に関係のないものは一切含まれないようにします。

次に示すのは、まとまりのない悪いコミットの例です。:

------------------------------------------------------------------------
r6228 | jrandom | 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 lines

問題 #1729 を修正 : インデックス作成を上品に行うようにした。これに伴い、
ファイルにインデックスを作成している最中にユーザーがファイルを変更していたら警告するようにした。

* ui/repl.py
  (ChangingFile): 新しい例外クラス
  (DoIndex): 新しい例外を処理するようにした

* indexer/index.py
  (FollowStream): インデックスを作成中にファイルが変更されたら、例外を生成するようにした
  (BuildDir): 上記とは関係ないが、いくつかの古いコメントを削除し、
  コードのフォーマットをいくつか修正した。また、ディレクトリ作成時のエラーチェックを修正した。

その他関連のないクリーンアップ:

* www/index.html: typoを修正し、次のリリース日を設定。
------------------------------------------------------------------------

問題点が浮き彫りになるのは、来るべきメンテナンスリリースに備えて、 BuildDir 関数のエラーチェックをリリースブランチに移植する必要が出てきたときです。移植する人は、それ以外の変更点はいらないのです。たとえば、問題 #1729 の修正自体をメンテナンスブランチに取り込むことは認められず、 index.html の調整もここでは関係ありません。しかし、BuildDir の変更を、バージョン管理システムのマージ機能を使って容易に取り出すことはできません。なぜなら、バージョン管理システムは、この変更を他の関係のないものとグループ化するように指示されているからです。実際には、マージする前でさえ問題が出てくるでしょう。投票を行うために変更点を羅列する場合です。: 投票を提案する人は、該当する変更のリビジョン番号を与える代わりに、提案されているコミットの一部分を分離するためだけに、特別なパッチを作ったり、変更用のブランチを切らなければならなくなります。このため、他の人がうんざりする量の仕事をすることになります。それというのもすべて、変更点を論理的なグループに分割するのを面倒臭がったコミッターのせいなのです。

実際には、このコミットは 4つに分割すべきでした。ひとつは問題 #1729 の修正、もうひとつは古いコメントの削除と BuildDir 関数のコードフォーマットの修正、そして BuildDir 関数のエラーチェックの修正、最後に index.html の微調整です。 3番目のコミットこそが、メンテナンスリリースのブランチに含めるよう提案されているものなのです。

それぞれのコミットを論理的な変更単位に分割するのが望ましいのは、もちろんリリースブランチを安定させるためだけではありません。心理的にも、意味がまとまっているコミットはレビューしやすく、必要な時に元に戻しやすい (バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります) ということもあります。前もって皆が規律をちょっと守っておけば、プロジェクトが後に頭痛の種を多く抱えずに済むのです。

リリースの計画を立てる

オープンソースプロジェクトが、歴史的に独占的なソフトウェアのプロジェクトと異なる点は、リリースの計画に関するものです。独占的なソフトウェアのプロジェクトでは、確固とした〆切があるのが普通です。その理由は、顧客にある時点でアップグレードを提供すると約束している場合もあれば、新しいリリースをマーケティング上の理由から他の仕事と連携させる必要があったりとか、プロジェクトにお金を出しているベンチャーキャピタルの人が、さらに投資をする前に成果を見る必要がある場合もあります。一方、フリーソフトウェアプロジェクトでは、ほとんど文字通りの意味での「道楽」が最近までほとんどの動機付けとなってきました。: つまり、好きだからコードを書いてきたのです。全ての機能が揃う前にリリースする必要性を感じる人はいませんし、そもそもなぜそうすべきなのでしょう？フリーソフトウェアプロジェクトでは、皆の仕事がひとつの生産ラインに乗っているわけではないのです。

最近では、多くのオープンソースプロジェクトが企業からお金を出してもらうようになり、それに伴って企業の〆切文化の影響をより多く受けるようになってきています。これは多くの点では良いことなのですが、お金を貰って雇われている開発者とボランティアの開発者の間で、優先順位の衝突が起きる可能性があります。こうした衝突はリリーススケジュールをいつ、どのようにするかという問題でよく発生します。プレッシャーが強い雇われ開発者は、当然リリースする日程を決めたがりますが、ボランティアの開発者は他の問題意識の方が強いかもしれません — それは自分たちが求める機能や、仕上げておきたいテストであったりします — よって、ボランティアの開発者達はリリースを待つべきだと感じることになります。

もちろんこの問題については、議論し、妥協する以外に一般的な解決策はありません。しかし、提案されているリリースの存在から、日付を切り離すことで、衝突の頻度や度合いを最小限にすることができます。つまり、はじめはざっくりとした見積り^[29] 以外は日付について触れず、直近から中期的な段階で、プロジェクトはどういった形のリリースができるか、そしてそのリリースにどんな機能を含めるのか、という方向に議論を誘導してみるのです。機能について早期に確定しておくことで、個々のリリースに関する議論が複雑になる度合いを減らすことができ、予測可能性を高めることができます。また、新機能や他の複雑なことをリリースに追加することで、リリースの定義を拡大解釈する提案に反対させるある種の先入観を植え付けることができます。たとえリリースの日取りが決まっていなくても、その内容がうまく決まっていれば、リリースの内容を拡大するのを正当化するのはそれを提案する人の責任になります。

トマス・ジェファーソンの伝記 Jefferson and His Time では、 Dumas Malone が、バージニア大学の組織を決めるための初ミーティングを彼がどのように進めたかについて語っています。大学を設立するというアイディアはもともとジェファーソンのアイディアでしたが、 (オープンソースプロジェクトに限らず、どこででもあることですが) 他の多くの関係者が、自分たちの興味があることや議題を持って会議に乗り込んできたのです。彼らがミーティングに集まってそれらを徹底的に議論していると、ジェファーソンは周到に準備した建築図面や、その予算や実作業、提案されているカリキュラム、そして自分がヨーロッパから輸入したいと考えていた特別な学部の名前を示して見せたのです。会議室にいた人の中に、彼以外でそうした議題についてほんのわずかでも準備にした人はいませんでした。つまり、彼らはそうした議題についてはジェファーソンのビジョンに従わざるを得ません。結局、バージニア大学設立は多かれ少なかれ彼の計画通りに進んだのです。建築費が予算をオーバーしていたり、彼のアイディアの多くは様々な理由で実現しなかったりしましたが、ジェファーソンはそれらすべてが起こることをあらかじめ完全に予想していたのでしょう。彼の狙いは戦略的でした。ミーティングで他の人が修正を提案せざるをえないような現実的な路線を提示するようにしたのです。その結果、全体の枠組み、そしてプロジェクトのスケジュールも、だいたい彼が望むものになったのです。

フリーソフトウェアプロジェクトの場合、"ミーティング" はありませんが、小さな提案の積み重ねは、そのほとんどがバグ追跡システムで行われます。プロジェクトであなたがちょっと信頼されていて、いろいろな新機能や改善やバグ修正をターゲットとなるリリースに割り当てはじめれば、アナウンスした全体のプランに従って、人々はあなたについてくるでしょう。いったんそれらが多かれ少なかれあなたの思い通りに進めば、実際のリリース時期に関する議論もより進みやすくなるでしょう。

もちろん、個々の決定をまるで文書で確定したかのように示さないのが重要です。特定のリリースで問題の解決をすると決めるときには、コメントで議論に参加してもらい、反対意見を述べてもらったりし、可能な時はいつでも、真摯に説得に応じましょう。単に権力を行使するために、力を振りかざしてはいけません。リリース計画を立てる過程で他の人が議論に参加すればするほど (8章ボランティアの管理 の「技術的な作業だけでなく管理作業もみんなで」を参照してください) 、自分が本当に重視している問題の優先度を高めることに賛同するよう説得することも容易になるのです。

リリース計画を立てるときに緊張を緩める別の方法として、リリースを頻繁に行うことがあります。リリースする間隔が長期間空くと、それぞれのリリースの重要性がメンバーの中で増してしまいます。つまり、自分たちのコードが取り込まれなかったときのショックが大きくなってしまうのです。なぜなら、次に取り込まれるチャンスまでどれくらい時間がかかるかがわかってしまうからです。リリースプロセスの複雑さと、プロジェクトの性質にもよりますが、 3ヶ月から6ヶ月の間くらいが、普通は適切なリリース間隔です。しかし、安定版のリリースラインは、もうすこし早い間隔でマイクロリリースを出した方がよいかもしれません。

^[27]ドキュメントやその他の印刷物を指すハッカー用語

^[28] Python では python setup.py install という、Distutils を使った標準的なコマンドがあります。Ruby の場合は Rubygems 経由で gem install [パッケージ名] というコマンドを使います。

^[29]別のアプローチとして、 Martin Michlmayr の Ph.D論文 Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management (http://www.cyrius.com/publications/michlmayr-phd.html) を読むとよいかもしれません。これは巨大なソフトウェアプロジェクトにおいて、機能ベースのリリースプロセスとは正反対の、時間軸をベースとしたリリースプロセスを採用することに関する論文です。 Michlmayr は、Google でこれを題材にした講演も行っています。Google Video で視聴可能です。http://video.google.com/videoplay?docid=-5503858974016723264

第8章ボランティアの管理

ボランティアを最大限に活用する

委任

作業依頼と担当者の決定を明確に区別する
委任したあとのフォロー
みんなの好みを知る

賞賛と批判

縄張り意識の回避

自動化の割合

自動テスト

すべてのユーザーの協力を得るために

Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats)

技術的な作業だけでなく管理作業もみんなで

パッチマネージャー
翻訳マネージャー
ドキュメントマネージャー
バグマネージャー
FAQ マネージャー

引き継ぎ

コミッター

コミッターの選びかた
コミット権の剥奪
部分的なコミット権
休眠状態のコミッター
秘密主義を避ける

クレジット

プロジェクトの分裂

分裂の動きをうまく処理する
新しいプロジェクトを立ち上げる

そのプロジェクトが目指すゴールに向かってみんなで協力してがんばっていくには、ただ単に「メンバーがみんな仲良くやっており、決定的な機能不全は起こしていない」というだけでは不十分です。プロジェクトのメンバーを管理する役割の人が必要となります。ボランティアを管理するという技術は、コンピュータプログラミングの「技術」とは少々異なるかもしれません。でも、学習と実践を通してうまく行えるようになるという点では、ボランティアの管理も一種の「技術」であるといえるでしょう。

本章では、ボランティアの管理に関する手法を取り上げます。これまでの章に比べて、より Subversion プロジェクトでの実例を引き合いに出すことが多くなるでしょう。というのも本書の執筆時には私はこのプロジェクトで作業しており、 Subversion プロジェクトの過去の資産については熟知しているからです。また、ちょっと微妙な話題などでは身内のネタのほうが扱いやすいという面もあります。もちろん、その他のプロジェクトについても調査をしました。本章で扱う内容に従った (あるいは従わなかった) 結果、そのプロジェクトはどうなったのか。政治的な問題をクリアしたものについては、他のプロジェクトの例も本章で取り上げます。

政治という言葉が出てきたついでに、みなさんがあまりよく思っていないであろうこの言葉についてよく考えてみましょう。技術者の多くは「政治的な話なんかうんざりだ。どこか別のところでしてくれよ」と考えがちです。「僕ははただ、このプロジェクトのために一番いいのはどの方法なのかを考えて意見を言っているだけなんだ。なのに彼女はといえばいつも政治的な理由であれこれ文句をつけてくる。」私が思うに、技術者という人種は政治 (あるいは彼らが政治であると思っているもの) を嫌う傾向が特に強いようです。というのも技術者は、「あるソリューションが他のものより優れているかどうかは客観的に判断できるはずだ」という考えを持っているからです。プロジェクトのメンバーが、あまり本質的でない問題に気をとられている (たとえば自分の評価だけを気にする、他人の評判を落とそうとする、あからさまな駆け引きを行う、他人に嫌われないことばかり考えるなど) ようだと、他のメンバーはあまりいい気がしないでしょう。もちろんほとんどの場合は、他のメンバーも重大な関心事については同じように本質的でない振る舞いをしてしまいます。

もしあなたが「政治」という言葉を何か汚らしいものだと感じ、自分のプロジェクトでは政治的な話を避けるようにしたいと思っておられるのなら、そんな考えは即刻捨ててしまいましょう。複数の人間が資源を共有して作業を進めていく以上、政治的な話は避けることができないものです。何かのアクションを起こしたときに、そのプロジェクトにおける各メンバーの影響力がどのように変化するかを考慮する。これはまったくもって合理的なことです。結局のところ、もしあなたが多くのプログラマーと同様に自分の判断とスキルに自信を持っているのなら、何らかのアクションによって影響力が落ちたとしても、それは単なる技術的な問題だと考えなければなりません。同じことが、その他のいかにも「政治的」な振る舞いにだっていえるでしょう。実際のところ、純粋に「政治」といえるようなものはありません。人の行動というのは現実社会のさまざまな因果関係の中で行われるので、人はまず最初に政治的なことを意識するようになります。政治というのは、一言で言ってしまえば「すべての因果関係を考慮すること」という合意にすぎません。とある決定がメンバーの多くを技術的に満足させるものだったとしましょう。ただ、それによってメンバー間の力関係に変化が生じ、主要なメンバーが仲間はずれにされたと感じるようなことがあったとします。この場合、主要なメンバーが感じる気持ちはかなり重要なものとなります。それを無視してしまうのは、気高いというよりはむしろ目先のことしか考えていないといえるでしょう。

さて、これ以降のアドバイスを読む際には、そしてプロジェクトで活動をする際には、政治のことだけを考えている人なんて どこにもいない ということを心にとどめておきましょう。政治をしているように見えるのは単なる戦略に過ぎず、時には有効でしょうが決して現実の政治ではありません。政治というのは、単に意見の相違が生じたときに起こるもので、成功しているプロジェクトはそういう状況を建設的に解決するような政治の仕組みを確立させています。

ボランティアを最大限に活用する

フリーソフトウェアプロジェクトでボランティアとして働くのは、なぜでしょう? ^[30]

「なぜ?」と聞かれたら、たいていの人は「よりよいソフトウェアを作りたいから」とか「個人的にバグの修正にかかわりたいから」などと答えることでしょう。ただ、これだけがすべてだというわけではありません。もし彼らに感謝の言葉を一言もかけなかったとしたら、もし彼らの言うことに一切耳を傾けなかったとしたら、それでも彼らはボランティアとして関わり続けてくれると思いますか? もちろんそんなわけはありませんね。人がわざわざ時間を割いてフリーソフトウェアに関わるのは、よりよいコードを書きたいなんていう抽象的な重いだけからではありません。彼らの真の動機を理解しておけば、ボランティアの人たちとうまくやっていくのに役立つでしょう。「優れたソフトウェアを作り上げたい」とか「難しい問題に挑戦してみたい」などという思いもその動機のひとつかもしれません。しかし、人にはもともと「他の人たちと共同作業をしたい」「他の人に尊敬されたい」といった願望もあります。共同作業を進めていくにあたっては、何らかの行動基準を定めた上で目標に向かってともに進んでいけるようにしなければなりません。

そんな行動基準は、いつも自然に立ち上がるというわけではありません。たとえば、プロジェクトによっては「頻繁に繰り返し発言する人がよりよい立場を得る」ように見えるものもあります (オープンソース界で長年すごしてきた人なら、おそらく「ああ、あれのことね」と頭に思い浮かぶものがあることでしょう)。決して偶然そうなっているわけではありません。複雑な議論を長々と続けていることに対する敬意のあらわれとして、立場が上がってきているのです (実際にその議論がプロジェクトにとって有用かどうかは関係ありません)。名声を得るための行動が、同時に建設的な行為となるような空気を作り出す。そのための方法を以下で説明していきます。

委任

「委任」は、単に負荷を分散させる方法というだけでなく政治的・社会的な道具にもなります。人に何か作業をたのむことにはどんな効果があるか、考えてみましょう。いちばんわかりやすいのは、「お願いを聞き入れてもらえたら、実際の作業は彼が行うことになってあなたは行わない」ということです。しかし、それ以外の効果もあります。お願いをすることによって「私はあの人に頼られているんだ」と彼に気づかせることができます。さらに、もしそのお願いを公開の場でしたのなら、「『私はあの人に頼られている』ということを、みんなも知っているんだ」ということにも彼は気づくでしょう。彼は「あの人の言うことだから、聞かなきゃ」というプレッシャーを感じるかもしれません。したがって、人に何か頼みごとをするときには、もし嫌なら気兼ねなく断れるように気配りしなければなりません。彼に依頼する作業が、プロジェクト内の別の人との調整を要するようなものであった場合、それは彼に「あなたは他の人とは違う。もう一段階すすんだ協力を頼みたい」と言うのに等しいといえるでしょう。そのプロジェクトのひとつのサブドメインを管理させるくらいのことになるかもしれません。あまりやりすぎると威圧的に受け取られかねず、彼はその責任の重大さから逃げ出してしまうかもしれません。

これらの効果を考慮すると、人に何か作業をお願いするのは理にかなったことでしょう。たとえそれを自分でやったほうが手際よくできることがわかりきっていたとしても。もちろん、何らかの事情で人にお願いをせざるをえないということもあります。あなたが自分でそれを行うのがコストに見合わない (他にもっと重要な作業がある) 場合などです。しかし、そんな差し迫った事情がない場合であっても、人に作業をお願いすることがあるかもしれません。将来的にその人にもっと深くプロジェクトに関わってほしいと考えている場合、最初のうちは少々余分な時間を使ってしまってもかまわないでしょう。また、逆も成り立ちます。誰か他の人の作業を手伝ってあげれば、あなたに対する相手の印象はよくなるでしょうし、相手から尊敬されるようになるでしょう。委任したり代理をお願いしたりすることは、何も個々の作業だけのことではありません。プロジェクトへのより深い関わりを持たせることにも関係します。

作業依頼と担当者の決定を明確に区別する

誰かがその作業を引き受けてくれるであろうことが、ほぼ見当がつくこともあります。たとえば、誰かがコードにバグを仕込んでしまったとか、誰かがコミットした内容がプロジェクトのガイドラインに明らかに反しているといった場合です。そんな場合は、問題点を指摘した上でその当人に対応をお願いするだけで十分です。彼はきっとその作業を引き受けてくれるでしょう。しかし、時には相手がそのお願いを聞き入れてくれるかどうかが判断できないこともあります。お願いを聞いてくれるかもしれないし、拒否されるかもしれない。「○○をやってくれて当然でしょ」といった態度で頼まれると、誰もあまりいい気はしません。人に作業をお願いするときには、状況に応じた適切な方法を考えましょう。

相手がもっともいらつくであろうパターンは、本人にはその気がないのに「これはあなたがやるのが当然でしょ」といったことを匂わせてお願いすることです。たとえば、バグ対応の担当者を決めるときにこのパターンがしばしば発生します。プロジェクトのメンバー間では、誰がどの分野に詳しいかはだいたいわかっています。何かバグ報告を受け取ったときに、「これは彼にやってもらえばすぐに修正できるだろう」と見当がつくこともよくあるでしょう。しかし、だからといって、何の前置きもなしにいきなりその人に対応をお願いしたりすると、相手は気を悪くするかもしれません。「私は期待されているんだ」と喜んでもらえるかもしれませんが、それと同時に「私にこの技術があるばっかりに、こんな作業を押し付けられるんだ」と感じることもあるかもしれません。バグ対応というのは技術を身につけるためのよい作業でもあります。こんな場合は、あえて誰か他の人に対応を任せるのもいいでしょう! (バグ追跡システムの中には、バグ報告の内容に応じて自動的に担当者を決める機能を持つものもあります。このようなシステムを使用すれば、「押し付けられる」という感覚はあまりなくなるでしょう。というのも、これはあくまで機械的に割り当てられるものであり、私情が挟まれていないことがわかっているからです)。

特定の人に負荷がかからないよう、できるだけみんなに均等に作業を割り当てることは大切です。ただ、時には、いちばんわかっている人に一刻も早く対応してもらいたいこともあるでしょう。そんなときに毎回根回しをする (「このバグ、ちょっと見てくれないかな?」「いいよ」「わかった。じゃあ担当者を君に設定するよ」「オーケー」) 時間が割けないのなら、できるだけ圧力を感じさせないように淡々とお願いするようにしましょう。ほぼすべてのバグ追跡システムには、担当者を決めるときにコメントをつける機能が備わっています。そのコメントで、次のように言うといいでしょう。

君にお願いするよ、jrandom。たぶん君がいちばんこのコードに詳しいだろうから。もしその時間がなかったら、気兼ねせずにつき返してくれてもいいよ。 (で、もし今後こんな依頼を受けるのがいやだっていうのなら、そう言ってほしいんだ)。

こうすれば、誰かに作業を依頼することと相手がそれを受諾するかどうかということを明確に区別することができます。ここで、このやり取りは当事者間だけでなく全員が見ていることに注意しましょう。その人に技術があるとみなされていること、そしてその人に依頼を受諾するかどうかの決定権があることが全員に伝わるのです。

委任したあとのフォロー

誰かに何かの作業を依頼したら、その後のフォローも忘れないようにしましょう。これは通常、公開のフォーラムで行います。次のような形式になるでしょう。 "ところで、X についてはどうなっていますか? 教えてください。別に無理ならそれでも気にしません。ただ単に気になっただけなので。" 返事があるかもしれませんし、あるいはないかもしれません。あまり状況が芳しくないという返事があったら、 X について何か別の対応策を考える必要があります。順調だよという返事があったら、しばらくはその作業の進捗を気にしないようにしましょう。進捗状況について、簡単にコメントだけしておきます (人はみな、自分の作業が他人に認められていることを知るとうれしいものです)。数日待っても返事がなかった場合は、もう一度聞いてみるか、あるいは「返事がなかったんだけど、誰か他に X についての状況を知っている人はいますか?」という投稿をすることになります。あるいは自分で調べることになるかもしれませんが、その場合でも「最初の問いかけに対して返答がなかったので」という投稿をしておくようにしましょう。

返事がなかったことをわざわざ投稿するのは、 決して その相手を非難するものではありません。また、周りにそのように受け取られないように言い回しには注意しましょう。目的は、単に「この前たずねたことをまだ気にかけていますよ。何か反応があったらすぐ気づきますよ」という姿勢を示すことです。そうしておけば、次に同じようなことがあったときに反応を得られやすくなります。周りの人たちから、あなたはどんなちょっとしたことでも見逃さない人だということを認識してもらえるからです。

みんなの好みを知る

自分が何に興味を持っているのかをわかってもらえていると、人はうれしいものです。一般論として、周りの人たちの性格をしっかり把握しておけば彼らはいい気分になるでしょう。そして、あなたと一緒により多くの作業をしたいと思うようになることでしょう。

たとえば Subversion プロジェクトにおいては、「まずは何とかしてバージョン 1.0 のリリースにこぎつけたい (現在はリリースされています)」という人たちと「新機能を追加したり興味深い問題を解決したりといったほうが先決だ。バージョン 1.0 がいつリリースされるかなんて、そんなの関係ないよ」という人たちとに明確に区別することができました。どちらがいいとか悪いとかいうことではありません。世の中には二種類の開発者がいるというだけのことです。そしてどちらのタイプの開発者もプロジェクトに多大な貢献をしてくれています。私たちにはすぐにわかりました。「1.0 のリリースに向けてがんばろう!」といった動機付けでみんなを一丸にできるなんて思わないほうがいいということを。電子メディアは非常にあてにならないものです。この気持ちはみんなで共有できていると感じていたとしても、実際にそう思っているのは当事者だけで、周りの人たちはまったく別の方向を見ていることもあるのです。

みんながそのプロジェクトに何を求めているのかに注意すればするほど、周りに効率よく作業を依頼できるようになります。実際に作業を依頼しなくても、「あなたが何を求めているのかはわかっているよ」ということを示すだけでも大事です。そうすれば、自分がその他大勢のひとりではないということをみんなに気づかせることができます。

賞賛と批判

賞賛と批判は決して相反するものではありません。多くの場合において、両者は非常に似通っています。両者はともに、相手の気を引くことが主目的であり、全体的なことを言うよりも特定のことに絞った方が効果的です。また、どちらも具体的な目標を定めた上で行わなければなりません。やり過ぎると、どちらの効果も薄れます。必要以上にほめすぎたり、あまりにも頻繁にほめまくっていたりすると、あなたのほめ言葉の価値が下がってしまうことでしょう。批判だって同じです。ただ実際は、批判のほうについては価値が下がる速度は多少遅くなるでしょう。

技術者の文化の中で重要なのは、詳細かつ冷静 (個人的な感情に左右されていない) 批判は、一種の賞賛とも受け取られるということです (6章コミュニケーション の「何が失礼にあたるのか」で説明しました)。なぜなら、その作業はきちんと精査するだけの価値があるものだということが暗示されているからです。しかし、あくまでも詳細かつ冷静というふたつの条件を満たしている場合のみであることに注意しましょう。たとえば、誰かがコードにいい加減な変更を加えたとしましょう。そんなときに単に「そんないい加減な変更はするな」とだけ言うのは無意味です (というか、有害でさえあります)。いい加減なのは、結局はその人の性格の問題であり、その作業成果とは関係ありません。実際の作業成果に対してのみ反応するようにしましょう。変更内容の中でまずいところを、淡々と指摘していくほうがずっと効果的です。同じ人が何度も何度も同じようなケアレスミスを繰り返すようなら、批判の最後に「同じことが繰り返されている」と指摘するのもいいでしょう。ただし、その場合も、怒りを抑えることを忘れないようにしましょう。

批判を受けても相手が何も変わらなければ、もう少しきつめな対応をすることになります。この場合の対応としては、できるだけ相手を傷つけないように彼の地位を奪うといったことがあります。本章の後半の「引き継ぎ」で、この実例をご覧いただきます。しかし、これは滅多に起こることではありません。たいていの人は、具体的で詳細な批判を受け取れば (口には出さずとも) 何らかの改善の姿勢を見せるものです。

ほめ言葉は誰も傷つけることはありません。ただ、だからといって何も考えずにほめまくればいいというものでもありません。賞賛は、一種の道具であるともいえます。使う前には、なぜそうするのかを検討するようにしましょう。一般論として、人がふだんからごく普通に行っていることをほめるのはあまりいい考えではありません。あるいは、そのグループに参加する上で当然のこととして期待されている作業に対しても、特にほめることはないでしょう。それをやり始めると、いつやめるかの判断が難しくなってしまいます。当然のことをやっている人たち全員を個別に賞賛してまわりますか? どこかで線を引いてしまうと、ほめられなかった人は「なぜ?」と思うでしょうね。それよりも、いつもとは異なる働きをした人や予期せぬ活躍をした人に対して控えめに賞賛の言葉を贈るほうがずっと効果的です。そして、「これからももっとがんばってね」と励ますわけです。メンバー全体の生産性が一段階向上したと見なせるようになったら、賞賛の言葉を贈る基準もそれにあわせて少し厳しめに変えましょう。通常の行いに対して賞賛を繰り返すと、そのうちにそれは無意味になってしまいます。みんなが高い生産性を発揮してくれているのはもはや予想以上の働きでもなんでもなく期待通りのものであるわけで、それをさらに上回る働きをした時点で改めて賞賛の対象となるわけです。

もちろんこれは、みんなの貢献を受け入れてはいけないという意味ではありません。でも、知っておいてほしいのです。プロジェクトがうまく機能していれば、みんなが何をやっているのかはすでにわかるようになっているわけです。そして、誰かがやった作業はメンバーみんなが知っている (ということを、それをやった本人も気づいている) わけです。直接賞賛の言葉を贈る以外にも、人の作業に対して何らかの意志を表明する方法はあります。たとえば、何らかの議論をしているときに「このへんについては彼女が多くの作業をしてくれているし、彼女が詳しいだろう」と言ってみる。あるいは、みんなに見える場所でコードの内容について彼女に尋ねてみる。または、もっとも効率的な方法としては、彼女の作業成果に基づいてさらなる作業を行うといったものもあります。そうすれば、自分の作業が他人に認められているということを彼女も感じてくれるでしょう。これらの行為は、別に計算の上で行わなければならないというものではありません。プロジェクトに多大な貢献をし続けている人は、何もしなくても自然にプロジェクト内での影響力を高めていくものです。正当な評価を受けていないとあなたが感じた場合を除き、それを後押しするために何らかの作業をする必要はありません。

縄張り意識の回避

プロジェクトの特定の分野において、だれかが作業を独占しようとし始めたら要注意です。誰かが始めようとした作業を積極的に引き継いだりといったことなどがそれにあたります。そのような振る舞いは、最初のうちは健全なものに見えるかもしれません。表面的には、その人がより多くの作業を引き受けてくれることでその分野の作業を活発にさせてくれるように見えるかもしれません。しかし、長い目で見た場合、これはあまりよい兆候ではありません。周りの人が "あそこに立ち入っちゃいけない" と感じるようになると、みんなそこにはかかわらなくなります。その結果、どうなるか。その分野のレビューが機能しなくなり、もろいものとなってしまいます。一人の開発者がすべての責任を負ってしまい、その人が欠ければそれでおしまいになってしまうからです。さらに悪いことに、それはプロジェクトの平等主義や協力体制を壊してしまうことになります。理論上は、すべての開発者が好きなときに好きな作業に参加できるようにしておくべきです。もちろん、実際には多少異なることはあるでしょう。その人によって得意な分野やそうでない分野があるでしょうし、素人は達人の言うことに従うしかないという分野もあるでしょう。しかし、重要なのは、これらはすべて自発的に参加する作業であるということです。能力や実績にもとづいて非公式に権限を与えることもありますが、決してそれを積極的に受け入れることがあってはなりません。権力を欲している人が仮に有能な人であるとしても、あくまでもその権威は非公式なものとすべきです。つまりメンバー間の合意によるものということです。また、その権威によって他のメンバーの介入を妨げることがあってはなりません。

誰かの作業内容を、技術的な理由で取り消したり編集したりするのは、もちろん全然違う話です。この場合、決定的な要素は作業の中身であり、誰がその作業の責任を負っているかではありません。たまたま特定の分野のレビューを行うのが特定の人に集中してしまうかもしれませんが、その人が他人の介入を拒否しない限りは特に問題はありません。

縄張り主義が登場するのを防ぐために、多くのプロジェクトではソースファイルから作者名や保守担当者名を取り除くようになっています。私は心からこの習慣に賛同します。 Subversion プロジェクトでもこの方式を採用しており、 Apache Software Foundation でもそれは事実上の公式方針となっています。 ASF のメンバーである Sander Striker は次のように述べています。

Apache Software foundation では、ソースコードに author タグを使用しないことを推奨しています。これには、法的な問題以外にさまざまな理由があります。共同開発とは、みんなで一丸となって作業に取り組み、みんなで一丸となってプロジェクトにかかわるということです。クレジットを与えるのもいいでしょう。というか、むしろすべきでしょう。でも、間違った情報を与えることになってしまってはいけません。どんなときに author タグを追加するのか。あるいはどんなときに削除するのか。明確な基準などありません。コメントを書き換えただけのときにあなたの名前を追加しますか? たった 1 行だけ修正したときは? コードをリファクタリングして、元のコードとは 95% ほど違うものになったとしましょう。こんな時に、元の作者の author タグを削除しますか? すべてのファイルをちょっとずつ修正して、自分の名前がすべてのファイルに登場するようにする人がいたとしましょう。あなたはそれを見てどう思いますか?
クレジットを与えるよりもいい方法があります。私たちとしてもそちらをおすすめします。技術的な側面から見て、author タグは不要です。特定のコードを誰が書いたのかを知りたければ、バージョン管理システムを使用すればすぐにわかることです。また、author タグは更新が遅れて現状を反映しなくなりがちです。 5 年前に書いたっきりで忘却の彼方にあったコードについて個人的に問い合わせられたとして、あなたはどう思いますか?

ソフトウェアプロジェクトにおいて、ソースコードファイルこそがその存在の証となります。開発者コミュニティー全体でソースコードに責任を持つべきであり、小さなグループに分けてしまってはいけません。

ソースコードで author タグや maintainer タグを使用したいと文句を言う人もいるでしょう。そうすれば、誰がもっともがんばっているかが一目瞭然になるからというわけです。しかし、この意見にはふたつの問題があります。まず、「どの程度の作業をしたら名前を追加してもいいのか」といったどうでもいい問題が必ず立ち上がってきます。次に、クレジットを得ることがまるで権威を得ることであるかのような勘違いを起こしてしまいます。過去にその部分の作業をしたからといって、コードのその部分が作業をした人のものになるわけではありません。しかし、ソースファイルの先頭に個人の名前が並べられていたら、そんな風に勘違いしてしまうことが避けられません。いずれにせよ、クレジットは既に得られているわけです。たとえばバージョン管理システムのログやメーリングリストのアーカイブなどでそれがわかります。したがって、ソースファイルからクレジットを削除したところで何も失われる情報はありません。 ^[31]

あなたのプロジェクトで「ソースファイルには作者の名前を記載しない」ことに決めたとしても、決してやり過ぎないようにしましょう。たとえば、多くのプロジェクトには contrib/ という領域があって、細々したツールやヘルパースクリプト類をここで管理しています。これらの中には、特定の人が作成したものであってプロジェクトとは関連のないものもあります。そんな場合には作者の名前を含めてもかまわないでしょう。だって実際のところ、そのファイルはプロジェクト全体で管理しているわけではないのですから。一方、そのようなツールをプロジェクトの他のメンバーがハックするようになり、本格的にプロジェクトに含めたくなることもあるかもしれません。そのような場合は、原作者の承認を得た上で作者のクレジットを削除し、プロジェクトで管理している他のリソースとあわせるようにします。原作者がそれをいやがった場合、妥協案としては次のようなものが考えられます。

# indexclean.py: 古いデータを Scanley インデックスから削除する
#
# 原作者: K. Maru <kobayashi@yetanotheremailservice.com>
# 現在の保守担当者: The Scanley Project <http://www.scanley.org/>
#                   そして K. Maru.
# 
# ...

しかし、できればこうした妥協は避けたいものです。また、ほとんどの人は、言うことを聞いてくれることでしょう。自分の作ったものがそのプロジェクトにより深く組み込まれていくというのはうれしいものです。

大事なのは、どんなプロジェクトであってもその中心部と周囲はきっちりつながっているということです。本体のソースコードファイルは明らかにプロジェクトの中心となるものであり、コミュニティー全体で管理しなければなりません。一方、周辺のツールやドキュメントの中には特定の個人が保守しているものもあるかもしれません。たとえそれがプロジェクトに関連するものであったりプロジェクトとともに配布されている場合であっても、本質的にひとりで保守を担当していることになります。すべてのファイルに対して画一的な規則で縛る必要はありません。ただし、コミュニティー全体で管理しているリソースは決して個人で囲い込んでしまってはいけないということを覚えておきましょう。

自動化の割合

機械にできることは、わざわざ人間にさせずに機械に任せてしまいましょう。おおざっぱに言って、定型作業を自動化すれば少なくとも効率が 10 倍にはなるでしょう。頻繁に行う作業であったり複雑な作業であったりした場合は、 20 倍以上になることも珍しくありません。

ここでは、あなたが単なる一人の開発者ではなく "プロジェクトの管理者" になったつもりで考えてみましょう。各開発者は、各個人がやっている枝葉の作業に精一杯でプロジェクト全体の様子 (自動化できる作業をわざわざ手作業でやってしまっているなど) が見えていないかもしれません。それに気づいている人であっても、わざわざ時間を割いて問題を解決しようとは思わないでしょう。実際のところ、各個人の作業自体は重荷となるほどのものではなく、「何とかしなきゃ」と思うほどには困っていないのです。たとえ個々の作業にかかる時間はわずかなものであったとしても、各開発者がそれを行う回数だけ掛けるとどうなるでしょう。さらにその結果を開発者の人数分だけ掛けたら? ……ということを考えだすと、自動化は無視できなくなります。

ここでいう "自動化" とは、広い意味の自動化を指しています。いくつかのパラメータを指定して同じ動作を繰り返すというものだけでなく、人間の作業を支援する技術的な仕組み一般を指して "自動化" といっています。いまどきのプロジェクトの運営における最低限必要な自動化については 3章技術的な問題 で説明しました。しかし、これら以外にも各プロジェクトに固有の問題もあることでしょう。たとえば、ドキュメント担当チームの場合は、常に最新版のドキュメントが公開されているウェブサイトが必要かもしれません。たいていの場合、ドキュメントは XML などのマークアップ言語で作成されるので、コンパイルが必要となるかもしれません。表示用とダウンロード用のドキュメントを作成するなど、このコンパイル処理は複雑なものになることもあります。コミットがあるたびに最新版をコンパイルしてウェブサイトに反映させるというのは、複雑で時間のかかる処理です。しかし、何日かかけてでもその仕組みを作成する価値はあります。最新の状態を確認できるようにする仕組みがないとしても、それで困るのはほんの一握りの人たちだけかもしれません。それでも、その仕組みを作ることによる利益は計り知れないものがあります。

このように自動化すると、時間の浪費が解消されるだけでなく人間が手動で作業したときの作業ミス (ミスは必ず発生します) でいらいらすることもなくなります。何段階にも及ぶ複雑な定型作業なんて、まさにコンピュータにやらせるべきものです。そもそもコンピュータが発明されたのはそういう作業をやらせるためだったのですから。そんな作業はコンピュータに任せ、人間はもっと創造的な作業に時間を割くようにしましょう。

自動テスト

テストの自動化はどんなソフトウェアプロジェクトにとっても有用ですが、オープンソースプロジェクトでは特に有用となります。自動テスト (特に回帰テスト) を行うことで、不慣れな分野のコードでも安心して変更できるようになります。これは、開発の効率を大きく向上させます。問題の原因を人間の目で検出するのは大変 (まず「このあたりに問題があるのではないか」と見当をつけ、その部分に問題がないかどうかあらゆる手段で調べることになります) なので、それを自動化すれば 大きな 時間の節約になります。

回帰テスト

回帰テスト (リグレッションテスト、Regression testing) とは、修正済みのバグが再発していないかどうかを調べるテストのことです。回帰テストを行う理由は、コードを変更したことで予期せぬところでソフトウェアを破壊していないことを確認するためです。ソフトウェアが大規模、複雑になっていくにつれて、予期せぬ副作用があらわれる可能性も大きくなります。きちんと設計していればその可能性を低くすることはできるでしょうが、完全に問題を解消するのは不可能です。

ということもあり、多くのプロジェクトでは テストスイート を用意しています。これは、プロジェクトとは別に用意されたプログラムで、過去に存在したバグが再現するような処理を実行します。テストスイートを実行してこれらのバグが再現した状態を リグレッション といいます。これは、誰かの修正が過去に修正済みのバグを再発させてしまったことを意味します。

http://en.wikipedia.org/wiki/Regression_testing もご覧ください。

回帰テストは決して万能というわけではありません。バッチ処理的なプログラムではうまく動作するでしょうが、たとえばグラフィカルなインターフェイスで操作するプログラムに適用するのは難しいものです。もうひとつの問題として、回帰テスト用のフレームワークが非常に複雑なものであるということが挙げられます。まともに使いこなせるようになるまでにはかなりの時間がかかることでしょう。この複雑さをなんとか軽減させることが大切です。たとえ時間がかかったとしても、その努力は必ず報われます。新しいテストをテストスイートに追加しやすくすればするほど、多くの開発者がテストを作成してくれるようになります。その結果として、リリース後に見つかるバグも少なくなるでしょう。テストを書きやすくするために費やした努力は、将来にわたってそのプロジェクトに大きな効果を及ぼします。

多くのプロジェクトでは "Don't break the build!" という決まりがあります。これは、コンパイルできなくなったり実行できなくなったりするような変更はコミットするなという意味です。そんなコミットをしてしまった人は、かなり気まずい思いをすることになるでしょう。回帰テストを採用しているプロジェクトの場合、この決まりはもっと明確になります。つまり「テストが失敗するような変更はコミットするな」ということになるのです。テストスイート全体を毎晩自動実行するようにしておけば、このようなコミットを検出することは容易です。そして、テストの実行結果は開発者向けメーリングリスト (あるいはテスト結果専用のメーリングリスト) に送るようにすればいいのです。ほら、ここにもまた自動化の例がひとつ登場しました。

わかりやすくて作業しやすいテストシステムがあれば、たいていの開発者は喜んで回帰テストを作成してくれるでしょう。変更をするときはテストも作成するというのは共通認識となっています。この作業は、複数で協力して行うこともあります。バグ修正作業を二人で分担し、一人が実際の修正を行ってもう一人がテストを書くといったようにです。テストを書く側の担当者のほうが、作業量は多くなりがちです。もともと実際のバグ修正にくらべてテストを書く作業はつまらないものなので、テストを書くのが苦にならないようにする必要があります。

プロジェクトによっては、さらに厳しい規則を設けていることもあります。バグ修正や機能追加を行う際は、必ず新しいテストを追加しなければならないといったものです。このような規則を設けることのよしあしは、多くの要素に依存します。「そのソフトウェアがどんな類のものなのか」「開発チームの構成はどのようなものなのか」「新しいテストを書く難易度はどれくらいか」などが考慮の対象になります。 CVS (http://www.cvshome.org/) プロジェクトでは、長年この厳しめの規則を採用しています。理屈の上では、これはよい方針でしょう。 CVS はバージョン管理用のソフトウェアであり、ユーザーのデータを壊して復旧できなくしてしまうようなことがあってはならないからです。ただ、実際に運用していく上では問題がありました。 CVS の回帰テストスイートは、ひとつの巨大なシェルスクリプトでできています (sanity.sh という変な名前がついています)。これは非常に読みづらく、また修正したり拡張したりするのも大変なのです。新しいテストを追加するのが大変であること、そしてパッチが受け入れられるためには新しいテストが必須であること。これらによって、CVS は事実上パッチの受け入れを拒否しているようなものだと言えます。かつて私が CVS プロジェクトで作業をしていたころ、「CVS のパッチを作成したんだけど、sanity.sh にテストを追加しなきゃならないっていう話を聞いて結局あきらめた」という人を散々見てきました。

バグの修正そのものより新たな回帰テストを書くほうが時間のかかるというのはごく普通のことです。ただ、CVS の場合はそれがちょっと極端すぎます。数時間かけて自分用のテストを作ったとしても、まだそれが間違っているかもしれません。 35,000 行にもおよぶシェルスクリプトの中には、思いもよらぬような込み入った仕組みが潜んでいるからです。長年 CVS にかかわっている開発者でさえも、新たなテストを追加するときには不満をもらすことがあります。

このようになってしまった原因は、私たちが自動化の割合について考えていなかったことです。自前で作るなり既存のものを使うなりして、本物のテストフレームワークに移行しようという試みはありました。 ^[32] しかし、長年それを怠ってきたツケが今まわってきているというわけです。この使いづらいテストスイートのせいで現在の CVS に取り込まれて いない バグ修正や新機能って、いったいどれくらいになるんでしょう? 実際のところは知りようがありません。ただ、新しいテストシステムを開発 (あるいは既存のシステムを採用) する時間を確保するために減ってしまうバグ修正・機能追加の数よりはるかに多いことは確かです。テストシステムを移行するのにかかる時間は有限のものですが、何もせず現状のテストスイートを使い続けることによる被害は永遠に続くわけですから。

ここで言っているのは、「テストを書くよう厳しく要求するのはダメ」ということではありません。また、テストシステムをシェルスクリプトで書くのが必ずしも悪いというわけでもありません。きちんと設計した上であれば、それが有用な場合もあるでしょう。言いたかったのは、「もしテストシステムが開発の障害になっているのなら、何か手を打たなければいけない」という単純なことです。その他の定型作業も一緒です。もしそれが障害やボトルネックになっているのなら、何らかの対処が必要です。

すべてのユーザーの協力を得るために

ユーザーとのやり取りは、そのプロジェクトに新たなメンバーを迎え入れるためのチャンスでもあります。わざわざ時間を割いてプロジェクトのメーリングリストに投稿してくれたりバグ報告をしてくれたりといった時点で、その人はその他大勢 (の、そもそもそのプロジェクトのことなんか知らない人たち) よりもより深くプロジェクトに興味を持ってくれていることがわかります。そんな人たちをうまく釣り上げてしまいましょう。バグ報告を受け取ったら、その人に感謝したうえで「ところで、それを自分で修正してみる気はない?」と聞いてみるといいでしょう。 FAQ に載せるべき質問が欠けているだとかプログラムのドキュメントが不十分だとかいう指摘を受け取った場合は (実際にそんな問題があったと仮定します)、指摘をしっかり受け入れた上で「ところで、それを自分で書いてみる気はない?」と聞いてみましょう。当然、たいていの場合は「いえ、そこまでは……」と断られるでしょう。でも、聞いてみること自体にはそんなに手間はかかりません。それに、毎回そのように返事をしていれば、その他の参加者も「何か自分ができることでプロジェクトに参加できるんだな」と気づくはずです。

目標は、単に新たな開発者やドキュメント作者を確保することだけではありません。みんなによりよいバグ報告をしてもらえるように仕向けることは、長い目でみれば十分に採算の取れることです。ほんの少しの手間で彼らが将来多くのバグ報告をしてくれるようになればすばらしいと思いませんか? そのためには、初めてバグを報告してくれた人に対して建設的な反応を返すことが大切です。建設的な反応とは、単にバグを修正するということだけではありません (もちろんそれが理想ではあります)。たとえば、より詳細な情報を提供するよう相手に求めたり、あるいはただそれがバグであるということを認めるだけでも建設的な反応といえます。人は誰でも、自分の意見に耳を傾けてほしいものです。また、バグを報告した人はそのバグが修正されることを望んでいます。後者の望みはすぐにはかなえられないこともあるかもしれません。しかし、あなた (というか、あなたのプロジェクト) が前者の望みをかなえてあげることはできるはずです。

当然のことですが、「何か言いたいのはわかるけれども具体的なことがさっぱりわからない」ようなバグ報告にたいしても腹をたてたりしてはいけません。個人的に、私はこのような態度は気に入りません。さまざまなオープンソースのメーリングリスト上で、このような開発者が見られます。そして、その害は明白です。かわいそうな新入りさんが、次のような無意味な報告を送ってきたとしましょう。

Scanley が動かないんだけど。起動しようとするとエラーが出るんだ。他のみんなは大丈夫なのかな?

過去にこの類の報告を数限りなく見てきた開発者のなかには、こんな答えを返す人がいます。

ちっ。そんな情報だけでいったいどうしろって言うんだよ。もっと詳しい情報を教えてくれないと。せめて Scanley のバージョンとか OS の種類、あとエラーメッセージくらいは必要だ。

こんな答えを返す人は、ユーザーの目線で考えることができていないのでしょう。そして、そんな反応が その他の 人たちにどんなふうに思われるかにも考えが及んでいないのでしょう。プログラミングの経験がない人やバグ報告の経験のない人などは、正しいバグ報告の方法なんて知らないかもしれません。そんな人への対応はどうしたらいいのでしょう? 教育しちゃえばいいんです! どうせするなら、よりよい返事をもらえるようにしてみましょう。

ご迷惑をおかけして申し訳ありません。何が起こったのかを調べるためにはもう少し詳細な情報が必要です。 Scanley のバージョンと使用している OS、そしてエラーの正確な内容を教えてくれませんか? あと、実行したコマンドとその出力結果を正確に教えてもらえると助かります。詳細は http://www.scanley.org/how_to_report_a_bug.html をご覧ください。

必要な情報をユーザーから引き出すには、こういった感じの返答のほうがずっと効果的です。なぜなら、この返答はユーザーの視点に立って書かれているからです。まず 1 点目。この返答では「問題があったんですね。お察しします。さぞ大変だったことでしょう」と同情の意を表しています (バグ報告に対して毎回このようにする必要はありません。バグの深刻度、そしてユーザーがどの程度困っているのかに応じて使いわけます)。次に 2 点目。バグ報告のお作法を知らないことをバカにするのではなく「どうしたらいいのか、どんな情報がほしいのか」といったことを説明しています。ごく一般的なユーザーは、「エラーの内容を教えて」と言われても、それが「エラーメッセージを正確に教えてください。途中までで切ったり変に省略したりしないこと」という意味であるとはわかりません。そんなユーザーに対応する場合は、とくに事細かに説明しなければなりません。最後に 3 点目。より詳しい、きちんとしたバグ報告をするための方法がわかるよう、ポインタを示しています。うまく対応すれば、きっとこの報告者はリンク先のドキュメントを読んでその内容を理解してくれるでしょう。もちろん、事前にそのためのドキュメントを用意しておかなければなりません。そのドキュメントでは、開発チームがバグ報告の際にどんな情報を欲しているのかを明確に説明しておくようにします。理想を言えば、プロジェクトにおけるユーザーのバグ報告の内容にあわせてそのドキュメントを日々改良していくことが大切です。

Subversion プロジェクトにおけるバグ報告の説明は、まさにこの形式のよい例といえます (付録E バグ報告のやり方を説明した例 をご覧ください)。最後のほうに、バグを修正するためのパッチの提供を促している箇所があることに注目しましょう。そうしたからといって、バグ報告におけるパッチの添付率が上がるわけではありません (バグを修正できるくらいのレベルの人なら、いちいち言われなくてもパッチが有用であることを知っているはずですから)。真の目的は、すべての読者 (特にそのプロジェクトに初めて参加する人たち、あるいはフリーソフトウェアの世界に初めて足を踏み入れる人たち) に対して「このプロジェクトは多くのボランティアの貢献によって成り立っている」ということを示すことです。プロジェクトの開発メンバーだからといって、バグ修正に対する責任がバグの報告者より重いということはありません。新入りさんにはあまりなじめない考え方でしょうが、これは重要です。それをみんなに理解してもらえれば、バグ修正のための手助けをより多く得られるようになるでしょう。コードが書けない人であっても、バグの再現手順を詳細に説明したりだれかのバグ修正の内容を検証したりといった支援は可能です。最終的な目標は、みんなに「自分とプロジェクトのコアメンバーの間には 本質的な 違いはない」ということを理解してもらうことです。

失礼なユーザーに対しては、多少きつく対応しても許されるでしょう。たまに、バグ報告や苦情を書く際に状況を考えずにプロジェクトをバカにした態度をとる人がいます。このような人は、バカにしたかと思えば急にこびへつらってきたり、態度をコロコロ変えることがよくあります。かつて Subversion のメーリングリストにこんな投稿をした人がいました。

6 日もたったのに、いまだに Windows 版のバイナリがないってどういうこと?!? 毎回こんなことが続くんで、もういらいらしっぱなしだよ。そんなの自動化しちゃえばいいだけのことでしょ?? "RC" 版を出したってことはそれをみんなに使ってほしいんでしょ? なのにこんな状態だと使うこともできないじゃないか。試しようがないのなら、テスト期間なんて無駄じゃない??

この煽り気味の投稿に対する返信は、どれも驚くほど落ち着いたものでした。このプロジェクトではバイナリ版をリリースしない方針になっていることを指摘し、そんなにバイナリが大事なのなら自分でそれを作って提供するべきだと返信したのです。驚くなかれ、彼の次の投稿はこんな一文から始まっていました。

まず最初に一言。Subversion は最高のツールだし、プロジェクトのすべての参加者には本当に感謝してるんだよ。[...]

...といった舌の根も乾かぬうちに、またバイナリを提供しないことに対するプロジェクトへの批判を続けたのです。彼は自分では何もしようとしませんでした。それに対して、 50 人ほどが彼を批判する返信をしました。私はそれを見ても、とくに気に病むことはありませんでした。 2章さあ始めましょう の「炎上を阻止する」で説明した、失礼な人に対する「ゼロトレランス (情け容赦なく)」という考え方は、そのプロジェクトに対して継続的にかかわり続ける人たちに対するものです。しかし、相手がただ単に不満をぶちまけているだけなんだということがわかってしまえば、彼に対して気配りをしても無意味です。

幸いなことに、こんな状況になることはほとんどありません。初心者に対してもより建設的な対応を心がけているプロジェクトでは、まずこのようなことはありえないでしょう。

Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats)

24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.

poss2 tbd

Some examples to use: Ubuntu community sprints, Adam Hyde's flossmanuals doc sprints, and the Danese/Noel-style public hackathons. Distinguish between purely dev events and dev+user+funder+enterprise events — all are useful, but don't confuse audiences.

技術的な作業だけでなく管理作業もみんなで

プロジェクトを運営していくにあたっては、技術的な作業だけでなく管理作業も大切です。プロジェクトが複雑になればなるほど、メンバーや情報の流れの管理作業が多くなります。管理作業だってみんなで協力してやるようにしましょう。別にトップダウンの階層がなくたってそれは可能です。実際のところ、行う作業というのは軍隊式の命令系統ではなくピアツーピアのネットワークトポロジーに近いものだからです。

「○○管理者」を正式に任命することもあれば、その場のノリで決めてしまうこともあります。 Subversion プロジェクトには、「パッチマネージャー」「翻訳マネージャー」「ドキュメントマネージャー」「バグマネージャー (非公式ですが)」そして「リリースマネージャー」がいます。これらの中には意識して任命したものもあれば、勝手に立候補してくれたものもあります。プロジェクトが成長するにつれて、さらにいろいろな役割が追加されることになるでしょう。以下で、これらの役割 (に加えてさらにいくつかのもの) についての詳細を説明します (リリースマネージャーについては省略します。すでに本章の前半の「リリースマネージャー」や「リリースオーナーによる独裁」で取り上げているからです)。

以下の説明を読むにあたっては、これらの役割の担当範囲がが決してお互いに排他的なものではないことに注意しましょう。たとえば問題マネージャーでなくても問題データベースを変更することがあるでしょうし、 FAQ の編集権を FAQ マネージャーに独占させてしまうこともありません。これらの役割というのはあくまでも責任の範囲に関するものであり、独占させるためのものではありません。各マネージャーの仕事で重要なのは、「誰かが自分の担当分野の作業をしていることに気づいたら、その人がうまくやっていけるように自分の方針を伝える。そして、みんなの作業が競合しないようにする」ということです。マネージャーは、自分の担当分野の作業手順書を作成しなければなりません。そうすれば、何らかの理由でマネージャーが作業をできなくなったとしても誰かがすぐに後を引き継ぐことができます。

特定の役割を希望する人が複数あらわれることもあります。このような場合にそれをうまく処理する方法には「これが正解!」というものはありません。たとえば、希望者に所信表明を出してもらい、それをもとにコミッターによる投票を行うという手もあります。しかしこれは面倒ですし、後に尾を引いてしまう可能性があります。それよりは、希望者たちがお互いに話し合って決めてもらうほうがいいでしょう。そうすれば、結果がどうであれ、他人に決められてしまうよりは満足のいくものになるはずです。

パッチマネージャー

パッチがたくさん送られてくるフリーソフトウェアプロジェクトでは、「どんなパッチが投稿されたのか」「そのパッチをどう処理することにしたのか」といった情報を追いかけるのは大変です。中央管理体制でない場合などは特にそうでしょう。大半のパッチはそのプロジェクトの開発者向けメーリングリストに投稿されます (中にはバグ追跡システムに投稿したり外部のウェブサイトで公開したりといったものもあります)。そしてそのパッチをどのように処理するかについては何通りものパターンがあります。

時には、パッチをレビューした結果何か問題が見つかり、元の投稿者に差し戻しとなることもあります。このようなやり取りは、通常は何度か (メーリングリスト上で) 繰り返されることになります。元の投稿者がパッチを何度か書き直し、レビューする側が何も文句のつけようがなくなるまでこれが続きます。この繰り返しがいつ完了するのかがはっきりわかるとは限りません。もしレビューした人がパッチをコミットすれば「これで完了」とはっきりわかるのですが、そうでない場合はいろいろな理由が考えられます。「コミットする時間がないだけ」「そもそもその人にコミット権がなく、他の開発者にコミットを依頼できていない」などの理由があるでしょう。

パッチに対する反応としてよくあるもうひとつのパターンは、そのパッチをネタにして議論が紛糾することです。議論の内容はパッチそのものである必要はなく、そのパッチの背景にある考え方のよしあしについてが話題になることもあります。たとえば、ある特定のバグを修正するパッチが投稿されたとしましょう。しかし、開発者側ではもっと別の修正方法のほうがよいと考えている (問題をより一般化して、もっと広い範囲を修正することを考えているなど) ということがあります。開発者側の考える修正方法は、何も以前から頭にあったものであるとは限りません。投稿されたパッチを見ることで、別の修正方法をひらめくということもあります。

たまに、投稿したパッチが完全にスルーされてしまうことがあります。これは、たまたま そのときにパッチをレビューする暇のある開発者がいなかっただけ (みんな、誰か他の人がみてくれるだろうと思っていただけ) ということが多いようです。「誰かが相手をするのを待つ」のに時間の制限はありませんし、それ以外にも重要な作業はいくらでもあります。かくしてそのパッチは誰の目にとまることもなくやみに葬り去られていきます。せっかくの有用なパッチがこんなことで見過ごされてしまう可能性があるわけです。それだけでなく、さらに悪い副作用もあります。せっかく時間を割いてくれたパッチ作者のやる気をそいでしまうということです。さらに「パッチのひとつでも書いてやろうか」と考えているその他の人たちにとっても、そのプロジェクトが魅力あるものには見えなくなるでしょう。

パッチマネージャーの役割は、この手の「闇に葬り去られてしまう」パッチをなくすことです。そのために、次のような手順ですべてのパッチを安定した状態にします。パッチマネージャーはすべてのメーリングリストのスレッドを監視し、パッチを含む投稿を拾い出します。最終的にそのパッチがコミットされているのなら特に何もすることはありません。レビューと修正を繰り返した結果、最終版のパッチがまだコミットされていないという場合は、最終版のパッチ (とメーリングリストでの議論) を問題追跡システムに投稿します。そうすれば、開発者が後でその記録を追うのが容易になります。もしそのパッチが特定の問題を修正するためのものなら、問題追跡システム上に登録されているその問題のコメントとしてパッチの情報を加えます。この場合は、新たな問題として投稿することはありません。

パッチに対する反応が何もないまま数日が経過した場合は、パッチマネージャーが「誰かレビューする人はいませんか?」とフォローします。そうすれば、普通は何らかの反応があります。「そのパッチは適用する価値があるとは思えない。なぜなら……」とか「じゃあ私がレビューしましょうか?」などです。反応があった場合は、先ほど説明したような手順で処理していきます。それでも誰も反応しなかった場合は、そのパッチを問題追跡システムに登録するかどうかはパッチマネージャーの判断で決めます。しかし、少なくともパッチの投稿者に対しては 何らかの 反応を返すようにしましょう。

パッチマネージャーを任命したおかげで、 Subversion の開発チームは時間と気力を大幅に節約することができました。専任の担当者がいなければ、開発者みんなが「今すぐには返事できそうにないけれど、誰か他の人が反応してくれるのかなあ? それとも私が後で対応したほうがいいのかな? でも、もし誰か他の人も同じように考えているのなら時間の無駄だなあ」と常に心配するはめになっていたでしょう。パッチマネージャーのおかげで、このような裏読みをすることはなくなりました。各開発者は、パッチを見たときの状況に応じてどう処理するかを決めることができます。もしそれをレビューしたいのならそうします。マッチマネージャーが適切にフォローしてくれるでしょう。もしそのパッチを完全に無視したいのならそれも結構。あなたが見なかったとしても、パッチマネージャーがそのパッチをきちんと扱ってくれます。

この仕組みがうまく動作するのは、パッチマネージャーがきちんと処理してくれるとみんなが信頼できるときだけです。つまり、この役割の担当者はノリで決めるのではなく正式な手続きを踏んで決める必要があります。 Subversion プロジェクトの場合は、まず開発者向けメーリングリストとユーザー向けメーリングリストで告知を行いました。何人かが立候補してくれましたが、最初に返事をくれた人を担当者として任命しました。後にその人が担当を降りたとき (本章の後半の「引き継ぎ」をご覧ください) にも、同じ手順を繰り返しました。同時に複数名を任命することは決してしませんでした。なぜなら、そうすると担当者間のコミュニケーションの手間がかかるからです。しかし、パッチの量があまりにも多い場合には複数担当者制を敷くのもよいでしょう。

翻訳マネージャー

ソフトウェアプロジェクトにおける "翻訳" には、ふたつの異なる意味合いがあります。ソフトウェアのドキュメントを翻訳することと、ソフトウェアそのものを翻訳する (エラー表示やヘルプメッセージをユーザーの好きな言語で表示できるようにする) ことです。どちらも複雑な作業ですが、いったん仕組みを確立してしまえばこれは他の開発とは分けて行うことができます。どちらの翻訳もやることはほぼ同じなので、(プロジェクトによっては) 両方の作業を一人の翻訳マネージャーが管理してもいいでしょう。あるいはそれぞれ別の人に管理させてもいいでしょう。

Subversion プロジェクトでは、一人の翻訳マネージャーに両方を管理させています。もちろん彼が実際に自分で翻訳を行うわけではありません。ひとつやふたつの言語については作業できるかもしれませんが、もしすべての翻訳を自分でしようとすると、現時点で彼は 10か国語 (方言も考慮すると12か国語) を操れなければなりません! それは無理なので、彼はボランティアの翻訳者のチームを管理しています。彼の仕事は翻訳者たちがお互いに協力し合えるように支援することであり、翻訳チームがプロジェクトの他のメンバーとうまくやっていけるようにすることです。

翻訳マネージャーが必要となる理由のひとつに、翻訳者たちは一般的な開発者とは少し異なるという点があります。彼らの中にはバージョン管理システムの使用経験が浅い人もいるでしょうし、ボランティアのチームの一員として働いたことのない人がいる可能性もあります。しかし、それを別にすれば、彼らはボランティアとして最高の人たちであるともいえます。特定の分野に関する知識を持っており、それを生かしてプロジェクトに協力してくれているわけです。彼らは、作業をするためならよろこんで勉強してくれるでしょう。彼らに必要なのは、どうすればいいのかを教えてあげる人です。翻訳マネージャーは、翻訳作業が通常の開発を不要に妨げないように注意します。また、翻訳者全体の代表として働くこともあります。翻訳作業に影響を与えるような変更を開発者が行った場合に、それを翻訳者たちに伝えるのがその役目です。

したがって、翻訳マネージャーにとって一番大切なのは技術的な能力ではなく外交力になります。たとえば Subversion プロジェクトの場合、各国語の翻訳は少なくとも 2 人以上で行うことという決まりを設けました。そうしないと、翻訳をレビューすることができないからです。たとえば、Subversion をマラガシ語に翻訳したいという人があらわれたとしましょう。翻訳マネージャーは、6 か月前に同じことを申し出てきた別の人とペアを組ませて翻訳を任せるか、あるいは「だれかもうひとりマラガシ語のわかる人を連れてきて、ふたりで作業をしてほしい」とお願いしなければなりません。人が集まったら、マネージャーは彼らに適切なコミット権を与え、プロジェクト内の決まり事 (コミットメッセージの書き方など) を説明したうえで彼らの作業を見守ります。

翻訳マネージャーと開発者とのやりとり、あるいは翻訳マネージャーと各翻訳チームとのやりとりは、通常はそのプロジェクトが元々使用している言語で行います。つまり、翻訳の元となる言語ということです。ほとんどのフリーソフトウェアプロジェクトでは、これは英語となるでしょう。しかし、プロジェクトの事情によってそれ以外の言語となることがあってもかまいません (とはいえ、そのプロジェクトを世界に広めたいのなら、英語を使うのが一番よいでしょう)。

しかし、個々の翻訳チーム内でのやりとりは彼らの言語で行うことになるでしょう。翻訳マネージャーの仕事のひとつは、個々の翻訳チーム用に専用のメーリングリストを用意することです。そうすれば、翻訳に関する議論をプロジェクト本体のメーリングリストのじゃまをせずに行うことができます。本体のメーリングリストで翻訳の議論をしても、ほとんどの人はその言語を理解できないでしょうから。

国際化 (Internationalization) と地域化 (Localization)

国際化 (I18N) と 地域化 (L10N) はどちらも、元々の言語や文化以外の環境でプログラムを動作させるための手続きのことを指します。これらの用語はよく混同されることがありますが、正確には異なるものです。 http://en.wikipedia.org/wiki/G11n によると、その違いは次のようになります。

The distinction between them is subtle but important: Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale.
(これらの違いは、些細なことではありますが重要です。国際化とは、その製品を事実上どの国でも使えるようにすることですが、地域化とは特定の機能を 特定の ロケールで使えるようにすることを意味します)。

たとえば、あなたのソフトウェアで Unicode (http://ja.wikipedia.org/wiki/Unicode) テキストエンコーディングを扱えるようにすることは「国際化」にあたります。これは特定の言語に関係するものではなく、多国語のテキストを扱えるようにするものだからです。一方「スロベニア語の環境で動かしたときはすべてのエラーメッセージをスロベニア語で表示させるようにする」という変更は「地域化」にあたります。

したがって、翻訳マネージャーの作業は主に地域化にかかわるものであり、国際化に関するものではありません。

ドキュメントマネージャー

ソフトウェアのドキュメントを最新の状態に保つというのは、果てしなく続く作業です。コードに新機能や拡張機能が追加されたら、ドキュメントにもそれを反映させなければなりません。また、そのプロジェクトのドキュメントがある一定のレベルに達したら、コード自体へのパッチだけでなくドキュメントへのパッチも送られてくるようになるでしょう。「コードのバグを修正することはできないけれど、ドキュメントの間違いなら直せる」という人はたくさんいます。ドキュメントはすべてのユーザーが読めますが、実際にプログラムが書けるユーザーはその一部だけだからです。

ドキュメントへのパッチは、コードへのパッチに比べてレビューして適用するのが容易です。テストの必要はほとんどありませんし、変更内容もざっと見ればわかります。パッチの数は多いけれどそのレビューの手間は少ないということもあり、管理作業と実際の生産的な作業の割合はコードのパッチよりドキュメントのパッチのほうが高くなるでしょう。さらに、もとの作者の書き方との一貫性を保つためにはほとんどのパッチに対して多少の調整が必要となることでしょう。多くの場合、ひとつのパッチが他のパッチに影響を及ぼしたり他のパッチと内容が重複していたりします。お互いのパッチの内容を尊重してそれらを調整してからコミットしなければなりません。

ドキュメントのパッチは緊急に処理しなければならないこと、そしてドキュメントを最新に保つにはソースコードの変更内容を逐次監視する必要があることなどを考えると、ドキュメント専任の担当者を何名かおいたほうがいいでしょう。彼らの作業は、ソフトウェアのどこがどう変わったのかを正確にドキュメントに反映させること。そして彼らに必要なのは、大量のパッチを効率よくさばく能力です。

もちろん、そうしたからといってプロジェクトの他のメンバーがドキュメントのパッチを適用できなくなるというわけではありません。ちょっとしたパッチなら、他のメンバーがその場でコミットしてしまってもかまわないでしょう。パッチマネージャー (さきほどの「パッチマネージャー」を参照ください) はコードとドキュメントのパッチを把握しているので、開発チームとドキュメントチームの両方に対して適切な情報を提供してくれます (とはいえ、もしパッチの量が多くなりすぎて 1 人では管理しきれなくなっと場合などは、まずはコードのパッチの担当者とドキュメントのパッチの担当者を分けることになるでしょう)。ドキュメントチームのポイントは、各メンバーが「ドキュメントをきちんとまとめて最新の状態に保ち、一貫性のあるものにする」という役割を自覚することです。実際の作業としては、ドキュメントの構成を熟知したうえでソースコードの変更点を追跡し、また 別の人 によるドキュメントへのコミットやドキュメントに対するパッチをチェックして、しかるべき対応をすることなどがあります。

バグマネージャー

プロジェクトのバグ追跡システムに投稿される問題の数は、そのソフトウェアを使う人の数に比例して増えていきます。したがって、いくらバグを修正して安全なプログラムを公開するようにしても、未対応の問題の数は際限なく増えていくことを覚悟しなければなりません。同じ問題が何度も投稿されることも多くなるでしょうし、何が言いたいのかさっぱりわからないバグ報告も増えてくるでしょう。

バグマネージャーの役割は、これらの問題を軽減するためにバグデータベースを常に監視し、定期的に整理整頓することです。主な作業は、バグ報告の内容を補足することです。バグ報告の中には、いくつかの項目が正しく埋められていないものもあれば既存のバグと同じ内容を報告しているようなものもあるからです。担当者がバグデータベースの内容に精通していればいるほど、既存のバグと重複しているバグ報告を見つけやすくなります。これが、バグ報告の対応に専任の担当者を割り当てる利点のひとつとなります。全員が臨機応変に対応するより、そのほうが効率的だからです。バグ対応を一元管理せずに分散管理しようとすると、結局誰一人としてバグデータベースの内容に精通した人がいなくなってしまいます。

バグマネージャーは、個々のバグ報告に対して個別の開発者を割り当てる作業も手伝います。大量のバグ報告が飛び交うようになると、中にはバグ報告の通知用メーリングリストをチェックするのがおっくうになる開発者も出てくるでしょう。開発チームの誰かがすべての報告にきちんと目を通しておくことにすれば、そんな場合でも適切な担当者にきちんとバグ対応をお願いすることができるでしょう。もちろん、この作業は開発の妨げにならないよう注意して行う必要があります。対応をお願いする相手の状況を考慮することも大切です。これらのことを考えると、バグマネージャーは開発者チームの中から任命するとよいでしょう。

そのプロジェクトでバグ追跡システムをどのように利用するのかにもよりますが、プロジェクト内の優先順位に応じてバグデータベースを調整する役割もバグマネージャーにはあります。たとえば Subversion プロジェクトでは、各バグ報告に対して「将来のどのリリースで対応するか」を設定します。そうすれば、誰かに「あのバグはいつ修正されるの？」と聞かれたときに正確な日付がわからなくても「次の次のリリースで対応します」と答えることができます。この「リリース」は、バグ追跡システム上では「ターゲットマイルストーン」という項目で管理します。IssueZilla ^[33] にはこの項目が存在します。Subversion プロジェクトのルールとして、各リリースにはひとつの大きな新機能追加といくつかのバグ修正を含めることにしています。将来のリリースに向けた各バグ報告 (新機能も含みます。新機能も同じデータベースで管理しています) に対して適切なターゲットマイルストーンを設定しておくことで、それを見れば今後のリリースの予定がわかるようにしています。しかし、一度設定したターゲットマイルストーンがずっとそのままでいることはめったにありません。新しいバグが飛び込んでくると、作業の優先順位が変わることもあるでしょう。そんな場合は既存のバグのマイルストーンを移動させないとリリース計画を管理できなくなります。こういった作業をおこなうには、やはり特定の担当者を割り当ててバグデータベース全体の状況と各報告の内容を把握させておくことが大切です。

バグマネージャーのもうひとつの役割は、バグ報告の内容が現状に即していないものになった場合の対応です。全然関係ない別の変更の結果、偶然にバグがなおってしまうこともあります。あるいは、最初はバグとして対処しようとしていたけれど結局それは仕様ということにしてしまうという場合もあります。現状に即していないバグ報告を見つけるのは大変な手間のかかる作業です。機械的にやるとするなら、データベース内のすべてのバグをチェックしなければなりません。しかし、時を経て報告の量が増えてくればくるほど、総チェックいうのは現実的ではなくなります。ある程度の段階になると、データベースをまともな状態に保つ唯一の方法は「分割して統治」ということになるでしょう。バグ報告をカテゴリ分けし、それぞれを適切な開発者 (あるいはチーム) に振り分けるのです。その後の対応はすべて振り分けられた側が責任を持つことにします。これほどデータベースが巨大化すると、バグマネージャーはどちらかというと全体の調整役として働くことが多くなります。自分自身で個々のバグを処理するのではなく、適切な人にそれを振り分ける役になるということです。

FAQ マネージャー

FAQ の保守という作業は、思いのほか難しいものです。大半のドキュメントは、作者が事前に練り込んだ内容を記述するものです。それとは異なり、FAQ は基本的に受け身のドキュメントとなります (FAQ の管理を参照ください)。どれだけたくさんの量を書いたとしても、次にどんな内容が追加されることになるかは決してわかりません。そして、常に細切れの内容が追加され続けるのでドキュメント全体としての一貫性やまとまりは簡単に崩れてしまいます。ひどい場合は同じ内容が重複してしまったりすることもあるでしょう。そんな問題がないように見えるものでも、目立たないところで関連項目間の相互依存の問題が発生していることはよくあります。たとえば本来はリンクするべきところができていないなどです。お互いの項目が時期をずらして追加された場合などにこれが起こりえます。

FAQ マネージャーの役割は、ふたつあります。まずは FAQ 全体の品質を保持すること。そのためには、FAQ の中でどんな項目が取り上げられているのか少なくとも質問だけでも把握しておく必要があります。そうすれば、既存の項目に関連する内容や重複する内容が新たに追加されたときに適切な処理をすることができます。もうひとつは、プロジェクトのメーリングリストや掲示板をチェックして、どんな問題が発生しているのかやどんな質問が行われているのかを確認することです。それをもとにして、新しい FAQ を書き進めていきます。後者の作業は非常に複雑なものになるかもしれません。各スレッドを追いかけ、そこで行われている質問の内容を把握して新たな FAQ エントリの追加を提案します。そして他のメンバーのコメントなども考慮して (FAQ マネージャーがすべての内容のエキスパートであるとは限りません) エントリの内容をふくらませ、ある程度まとまった段階でそれを実際に追加することになります。

FAQ マネージャーは、FAQ 自体の書式についても責任を持ちます。 FAQ の体裁に関する注意点はさまざまなものがあります (6章コミュニケーション の「全リソースをアーカイブと同様に扱う」を参照ください)。不特定多数が FAQ を編集するようになると、これらの注意事項がおろそかになってしまうことがあります。そんな場合でも FAQ マネージャーがきちんと注意してそれを修正していけば大丈夫です。

FAQ の管理を支援するためのフリーソフトウェアも数多く存在します。 FAQ の品質を低下させない範囲でそれらのソフトウェアを使うのはかまいませんが、過度に自動化してしまわないように注意しましょう。プロジェクトによっては、FAQ の保守を完全に自動化しようとしているところもあります。 wiki (3章技術的な問題 の「Wiki」を参照ください) などを使用して、誰でも自由に FAQ の項目を追加/編集できるようにするなどしています。これは Faq-O-Matic (http://faqomatic.sourceforge.net/) を使っているプロジェクトでよく見かけますが、私の見る限りでは Faq-O-Matic がもともと想定している範囲を超えた使い方だと感じます。 FAQ の管理を分散化することでたとえ全体の作業量を軽減できたとしても、その結果できあがる FAQ はどうしても品質が劣ったものになってしまいます。そこには FAQ 全体を把握している人もいなければ更新を要する項目や時代遅れになってしまった項目を見つける人もいません。さらに各項目間のつながりを管理できる人もいないでしょう。そんな状態でできあがった FAQ は、探したい情報が見つからないどころか間違った情報を与えてしまうものになってしまう可能性があります。プロジェクトの FAQ を管理するのにどんなツールを使うのも自由ですが、ツールの便利さに惑わされて FAQ 自体の品質に妥協してしまわないようにしましょう。

Sean Michael Kerner が書いた The FAQs on FAQs という記事が http://osdir.com/Article1722.phtml で読めます。この記事では、オープンソースの FAQ 管理ツールについての説明とその評価を行っています。

引き継ぎ

時には、何らかの役割 (パッチマネージャーや翻訳マネージャーなど) を受け持っている人がその作業を全うすることができなくなる場合もあります。理由としては「作業量が自分の見込みよりずっと多かった」「子供が生まれた」「転職した」など、いろいろなものがあるでしょう。

担当者がこのような状態に陥った場合、それをすぐに自覚できないこともあります。それは徐々に起こることであり、「もはや自分の任務を果たせない」とはっきりわかる瞬間がないからです。プロジェクトの他のメンバーは「そういえば最近あの人をあまり見かけないね」と感じることになります。そして、ある日突然彼がものすごい勢いで活動を再開します。しばらく作業をしていなかったことに負い目を感じて「徹夜してでもなんとか追いつこう」と感じているのでしょう。その後、彼はまた (もっと長い) 沈黙期間に入ります。しばらくしてまた突然復活するかもしれませんし、しないかもしれません。正式に「この役割から退きます」という表明があることはほとんどありません。彼らは自分の空き時間を使って作業をしているのです。引退を表明するということは、自分の空き時間が今後ずっと少なくなってしまうということを自覚することです。人はそれはなかなか認めたがりません。

したがって、あなた (と他のプロジェクトのメンバー) のすべきことは、現状がどうなっているのか (あるいはなにも起こっていないのか) を把握して、彼に状況を確認することとなります。相手を責めるのではなく、友好的に問い合わせなければなりません。状況を知ることが大切で、人を不快にさせることが目的なのではないからです。一般に、この問い合わせはプロジェクトの他のメンバーにも見えるかたちで行います。しかし、何らかの理由で個人的に問い合わせたほうがいいと判断した場合はそれでもかまいません。公開の場で問い合わせる主な理由は、彼が「もう作業を続けることができない」という返事があった場合にその次の投稿、つまり新しい担当者の募集につなげやすいからです。

時には、自分で引き受けた作業をこなす能力がないにもかかわらず、それを自覚できていないかあるいは認めようとしない人もいます。もちろん、作業を始めたばかりのころは誰でもうまくいかないものです。複雑な作業を与えられた場合などは特にそうでしょう。しかし、他のメンバーができる限りの支援をしてやってもなお彼が作業をこなせないとしたら、彼にはお引き取り願ってだれか他の人に作業を任せるしかありません。もし彼がそれに気づいていないのなら、だれかが教えてやる必要があります。私が思うに、こんな場合の対応方法はひとつだけです。ただ、その方法は何段階かに分かれるもので、各段階がそれぞれ重要となります。

まずは、自分だけの思いこみではないということをはっきりさせましょう。プロジェクトの他のメンバーと個人的に話し、自分が持っている危機意識がみんなと同じくらいのものであることを確認します。確認するまでもなく自明な状況であったとしても、他のメンバーと話すことで「これからこういうことをしようとしている」という気持ちを他のメンバーに伝えることができます。通常は、この相談で相手に反対されることはないでしょう。やっかいな仕事をあなたが引き受けてくれたということで、むしろ感謝してもらえるかもしれません!

次に、問題となっている人に 個人的に 連絡を取ります。そして、やさしく (しかし要点をはぐらかすことなく) あなたが感じている問題点を伝えます。できるだけ、具体例を挙げて伝えるようにしましょう。可能な限りの支援をしたこと、それにもかかわらず問題は改善しなかったことをはっきりさせておきましょう。このメールを書くのにはかなりの時間がかかることを覚悟しなければなりません。この手のメッセージの場合、もし自分が書いている内容にちょっとでも確信の持てない箇所があるのなら、最初からそんなメッセージは書いてはいけません。彼が引き受けた作業をだれか別の人に任せたいと思っていること、プロジェクトに貢献するには他にもいろいろな作業があるということも説明しておきましょう。この時点では、あなたが他のメンバーと相談したことはまだ彼に言ってはいけません。裏でこそこそ話が進められていたなんてことを知ったら誰だって気を悪くするでしょう。

その後は、成り行きに応じていくつかの方法に分かれます。たいていは、彼はあなたの提案に同意してくれるでしょう。少なくとも否定はせず、進んで引き下がってくれることでしょう。その場合は、引き下がることを彼自身で発表してもらうようにお願いします。そして、あなたはその発表への返信で新たな候補者を募集します。

あるいは、問題があったことは認めるものの「もうちょっとだけチャンスがほしい (リリースマネージャーのような役割なら『あと 1 回だけ』など)」とお願いされるかもしれません。あなたはここで審判としての働きをしなければならないわけですが、どう判断するにしてもそこに私情を挟まないようにしましょう。そこで猶予を与えてしまっても、単に苦痛をひきのばすだけのことにしかなりません。このお願いを拒否する理由としてはっきり言えるのは、これまでに何度もチャンスがあったということ。そしてそのチャンスを生かさなかったからこそ今の状態があるということです。以下に示すのは私が送ったメールの例です。これは、リリースマネージャーの役割を引き受けながらその役割を果たせなかった人に対して送ったものです。

> もし私じゃダメだというのなら、喜んで別の人にこの役割を
> 譲ります。ただ、ひとつだけお願いがあります。決して無茶
> なお願いではないと思います。あと一回だけチャンスがほし
> いんです。次のリリースで私の能力を証明させてください。

言いたいことはよくわかります (できればそうしてあげたい) が、
今回については「あと一回だけ」というのはやるべきではないと
思います。

今回が初めてのリリースだったとかならともかく、もう既に６回
目か７回目くらいになるわけです。そしてその間ずっと、あなた
は期待通りの結果を出すことができませんでした (っていうこと
は以前お話しましたよね)。つまり、はっきり言えば「あと一回」
の段階は事実上終わっているわけです。結局のところ、この前の
[過去のリリース] がその「あと一回」だったんです。

最悪の場合は、相手が提案を拒否するかもしれません。この場合は、ちょっと話がやっかいになることを覚悟しなければなりません。ここにきて初めて、事前に他のメンバーとも話し合っていたことを明らかにします (ただ、相手の許可を得るまでは「誰と」話したのかは言ってはいけません。あくまでも私的な相談だったのですから)。そしてこのままではプロジェクトにとってあまりよくないということも説明しましょう。何度も何度も、しかし決して威圧的にならないように注意して。覚えておいてほしいのは、大半の役割については新しい担当者が作業を始めた時点で移行が完了する (前任者が作業をやめた時点ではない) ということです。たとえば、バグマネージャーの資質が問題になっているのなら、あなた (やプロジェクト内の主要メンバー) はいつでも新たなバグマネージャーを仕立て上げることができます。前任者が新たなバグマネージャーの作業を邪魔したりしない限り、前任者が作業をやめるかどうかは大きな問題ではありません。

ふとこんな考えが頭に浮かぶかもしれません。「わざわざお引き取り願わなくたって、だれか補佐役をつけてやるだけでいいんじゃないの?」「バグマネージャーにしたってパッチマネージャーにしたって、別に 2 人いても何も問題はないんじゃないの?」

一見よさげに聞こえますが、一般的にこれはよい考えではありません。マネージャーの役割がなぜうまく機能している (役立っている) のかというと、それは中央集権型だからです。もし分散管理してもうまくいくような作業なら、きっとはじめからそのようにしていることでしょう。ひとつの管理作業を 2 人に任せると、その 2 人の間のコミュニケーションというオーバーヘッドが発生します。そして、お互い責任をなすりつけあう (「きみが救急箱を持ってくるんじゃなかったの?」「まさか。ぼくは君が持ってくるものだとばかり思ってたよ!」) という危険性もあるでしょう。もちろん例外もあります。複数の人間がうまくかみ合って作業が進むこともあるでしょうし、複数の人間で行うのに適した作業もあります。しかし、もともとその作業に適していないと思われる人にとってはあまり意味のないことでしょう。彼が最初の時点で問題をきちんと把握していれば、もっと早い段階で助けを求めてきたはずです。いずれにせよ、作業がうまく進まないで単なる時間の浪費になってしまっているのを見過ごすのはまずいことです。

だれかに手を引いてもらうようお願いするときに最も大切なのは、プライバシーです。みんなに注目される中ではなく、自分一人でどうするかを考える余地を残しておくようにしましょう。私は、かつて間違いを犯しました。明白な間違いをです。ある人に Subversion のリリースマネージャーを退いてもらい、かわりに別の 2 人に任せようと考えたときに、当事者 3 人に対して同時にメールを送ってしまったのです。新たに任せる予定の 2 人には事前に個別に話を持ちかけており、どちらもその気であることはわかっていました。世間知らずで無神経な私は「一通のメールを全員に送ってしまえば話は早いじゃないか。こんな面倒なことはさっさと終わらせてしまおう」と考えたのです。当時のリリースマネージャーもすでに事態を自覚しており、きっとすんなり退いてくれるだろうと想定していました。

私は間違っていました。当時のリリースマネージャーは激高しました。当然です。単に仕事を取り上げられたということだけでなく、新しい担当者が 目の前に いるところでそれを言われたのですから。彼が怒っている理由を知って、私は謝りました。彼は結局私たちの提案に同意してマネージャーを退いてくれました。その後も別の形でプロジェクトに参加し続けてくれています。しかし彼は傷ついたでしょう。言うまでもなく、新たにマネージャーを引き受けることになった側にとってもやりにくかったはずです。

コミッター

あらゆるオープンソースプロジェクトにおいて唯一公式に識別可能なのは、コミッターかそうでないかということです。ここでは「コミッター」について注目してみましょう。メンバーをできる限り平等に扱うことを心がけていたとしても、コミッターだけは別に扱うということは避けられないでしょう。「別に扱う」といっても、特に差別的な意味はありません。コミッターの役割は欠かせないものであり、それなしではプロジェクトがうまく回ることはないと考えます。品質管理のためにはコントロールが必要です。自分にはプログラムに変更を加える能力があると考える人は多くいますが、実際に行うのはそのうちの一部の人となります。プロジェクトは、各個人の自己判断に依存してはいけません。何らかの基準を設け、それを満たした人にのみコミット権を与えるべきです ^[34]。一方、変更を直接コミットできる権限を持つ人たちのまわりにはそうでない人たちも多くいます。彼らにもさまざまな考えがあるでしょう。それをうまく管理して、プロジェクトをうまく動かしていくことが必要です。

4章プロジェクトの政治構造と社会構造 の「誰が投票するのか?」で、新たなコミッターを決める方法については既に説明しました。ここでは、新コミッター候補の能力を見極める方法や大規模コミュニティーで同じ手続きを進める方法について考えてみましょう。

コミッターの選びかた

Subversion プロジェクトでは、コミッターを決める際にはヒポクラテス主義 first, do no harm (何よりもまず、患者に害を与えないこと) を重視しました。技術的なスキルや Subversion のコードに関する知識よりも、単によりよい判断ができるかどうかに重きを置いたのです。「判断ができる」というのは、単に「すべきでないことは何か」を知っているかどうかという意味です。だれかがちょっとしたパッチを送ってきたとしましょう。それは、コードの中のほんの些細な問題を修正するだけのものでした。そのパッチはうまく適用することができてバグもなく、プロジェクトのコーディング規約やログメッセージの規約も守っています。そのようなパッチを数多く送ってきた人に対して、既存のコミッターたちが「コミット権をあげたらどう?」と提案します。少なくとも 3 人のコミッターが賛成し、かつ反対する人が誰もいなければ、正式にコミット権を提供します。もちろん、その人がコード全体を把握していて複雑な問題も解決できるという証拠なんてありません。しかし、そんなことは関係ないのです。はっきりと言えることは、彼は自分自身の能力をきちんと判断することができるということです。技術的なことは、後からでも勉強できます (し、教えることもできます) が、判断力についてはなかなかそうはいきません。したがって、コミット権を与える際には判断力の有無を重視したほうがいいでしょう。

新たにコミッターを追加しようという提案が議論を呼ぶ場合、その原因が技術的なものであることはあまりありません。どちらかというと、メーリングリストや IRC 上でのその人のふるまいが問題になることが多いようです。たまに、技術的には問題がなくプロジェクトの公式指針にしたがって働くこともできるけれども、掲示板ではやたらけんか腰だったり非協力的だったりする人がいます。これはちょっと深刻な問題です。何度か助言をした上でまだ彼がそのような態度をとり続けるようなら、たとえ彼の技術が優れていたとしても私たちは彼をコミッターにはしないでしょう。ボランティアの集まりにおいては、いわゆるソーシャルスキル、つまり「集団の中でうまくやっていく能力」は技術力と同じくらい重要です。すべてはバージョン管理されているわけなので、仮にふさわしくない人をコミッターにしてしまったとしてもコードにはそれほど被害は及びません (何か問題があっても、コードのレビューですぐに見つかることでしょう)。しかし、そんな場合はすみやかにその人のコミット権を剥奪することになるでしょう。これは決して気持ちのいいことではなく、ときには対立が起こることもあります。

多くのプロジェクトでは、重要なパッチを何回か提供することではじめてコミッター候補として認められるような仕組みになっています。これは、単にその人が周りに害を与えないかどうかを見るだけではなくその人がコードにどのように関わっていくかを見るという意味があります。これはこれでいいのですが、コミット権を得るのがまるで会員制の高級クラブに入会するかのようなことになってしまわないように注意しましょう。ここで問うべきことは「コードにとってもっともよい結果をもたらすにはどうしたらいいのか?」であり、決して「こいつを仲間に入れるとコミッターたちの社会的な評判がおちるんじゃないか?」といったものではありません。コミット権を与えるのは個人の自尊心を高めるためではなく、コードに変更を加える際の手間をできるだけ減らすためです。 100 人のコミッターのうち定期的に大規模な変更を行うのが 10 人だけで、残りの 90 人は誤植やちょっとしたバグの修正を年に数度行うだけだったとしましょう。それでもコミッターを 10 人だけにしておくよりもよっぽどましです。

コミット権の剥奪

コミット権の剥奪に関してまずひとこと。そんなことをしなければならない羽目に陥らないように、最初から十分注意するようにしましょう。「誰の」アクセス権を「なぜ」剥奪するのかといった議論は紛糾しやすいものです。たとえ皆の意見が一致していたとしても、そんな作業は全く生産的ではありません。

しかし、どうしてもそうしなければならない状況になったら、まずはその人にコミット権を 与えた ときのメンバーの間で非公開で議論しなければなりません。問題となっている人自身はその議論に加えてはいけません。通常は秘密主義は否定されるものです。その方針には反していますが、この場合は非公開であることが必要なのです。第一の理由として、そうでないと自由に意見を交換することができません。もう一つの理由は、もしコミット権剥奪の試みが失敗したときに「そういう考えがあった」ということを当事者に知られないようにするということです。それを知られてしまうと、きっと「剥奪に賛成したのは誰? 私の味方になってくれたのは誰?」という疑問が頭に浮かぶことになるでしょう。これは、もっともたちの悪い派閥争いの原因となってしまいます。ごくまれに、コミット権を剥奪する (あるいはしようと考えている) ことを警告として知らせたいという状況もあるかもしれません。しかし、そのような場合は必ずグループ全体の同意をとってからにしなければなりません。非公開で行った議論や投票の内容は、参加者全員が了解しない限り公開することはできません。

だれかのアクセス権を剥奪したら、その事実を公表しなければなりません (この章の後半の「秘密主義を避ける」を参照ください)。一般向けへの公表は、できるだけそつなく行うようにしましょう。

部分的なコミット権

プロジェクトによっては、コミット権に何段階かの区別をつけているところもあります。たとえば、ドキュメントについては自由に変更できるけれどもコードそのものにはコミットできないといった権限を用意しているわけです。このように「一部だけに限定」したコミット権を与える場面としてよくあるのは、ドキュメント、翻訳、他のプログラミング言語とのバインディング、パッケージ作成用の設定ファイル (RedHat の RPM スペックファイルなど) などです。これらは、何か間違いがあったとしてもプロジェクトのコアにはあまり影響を及ぼさないところでもあります。

コミット権は、単にコミットすることだけでなく投票権 (4章プロジェクトの政治構造と社会構造 の「誰が投票するのか?」を参照ください) にもからんできます。部分的なコミット権を持つ人の扱いはどうしたらいいのでしょうか? 正解はひとつではありません。そのプロジェクトでどのように部分コミット権を定義しているかによって変わります。 Subversion ではきわめてシンプルに考えています。部分的なコミット権を持つコミッターは、自分がからんでいる範囲の事項については投票できるがそれ以外の範囲についての投票権はないということです。ただ、参考意見としての投票 (advisory vote) という仕組みは存在します (要するに、投票用紙に単に "+1" と書くのではなく "+0" あるいは "+1 (拘束力なし)" と書くようなものです)。公式な効力がないからといって、彼らを完全に黙らせてしまう理由はありません。

フルコミッターは、あらゆることに関して投票権を持ちます。ちょうど彼らがどの部分にでもコミットできるのと同じようなことです。そして、フルコミッターのみが新規コミッターの追加に関する投票権を持ちます。しかし現実的には、部分的なコミッターを追加する手続きについては権限を委譲することもよくあります。フルコミッターが部分的なコミッターの "保証人" となり、その分野だけのコミット権を持つコミッターについては彼らに選ばせるのです (これは、特に翻訳作業などを円滑に進めるために便利です)。

作業の内容によっては、このような決まりをあなたのプロジェクトでそのまま取り入れるわけにはいかないかもしれません。しかし、「すべてのコミッターは自分のコミット権の及ぶ範囲に関する決定への投票権を持ち、コミット権の及ばない範囲に関しては投票できないということ」「プロジェクトの進め方に関する投票は、基本的にフルコミッターのみが行うこと」「ただし、もう少し投票できる人の範囲を広めるようにフルコミッターが決められるということ」という大まかな考えかたはすべてのプロジェクトに適用できるでしょう。

部分的なコミット権の付与に関する注意: 部分的コミット権を与える機能を仮にバージョン管理システムが持っていたとしても、できればそれは使わないようにしましょう。その理由については 3章技術的な問題 の「承認」をご覧ください。

休眠状態のコミッター

プロジェクトによっては、ある程度の期間 (たとえば一年間) いちどもコミットがなかった人のコミット権を自動的に削除しているようなところもあります。私はこれはあまりメリットがないと思っています。というかむしろ逆効果でしょう。理由は次のふたつです。

まず、単にコミット権の有効期限切れを防ぐためだけの目的で、あまり意味のない不要なコミットをする人が増えてくることになるでしょう。次に、そんなことをしたところで何の意味もありません。コミット権を与えるか否かを決める主要な条件は、その人が正しい状況判断をできるかどうかです。単にプロジェクトでの活動から一時離れていただけで判断力が低下したと見なすことなんてできないでしょう? 仮に数年の間完全にプロジェクトから離れており、その間コードも一切見ずに開発関連の議論にも目を通していなかったとしましょう。それでも、プロジェクトに復帰した彼は自分の状況をきちんと把握し、適切に振る舞ってくれることでしょう。彼の判断力を信じたからこそコミット権を与えたはずです。だったら最後まで信頼してあげましょうよ。ハイスクールの卒業証書が期限切れになることがないのと同様に、コミット権にだって有効期限なんかいらないはずです。

時には、コミッター自身から「私を削除してほしい」「休眠状態であることをコミッター一覧 (この一覧についての詳細は下の「秘密主義を避ける」をご覧ください) に明示してほしい」とお願いされることもあります。そんな場合は、当然そのお願いを受け入れなければなりません。

秘密主義を避ける

誰かを新しいコミッターとして認めるかどうかについての議論は内密に行う必要がありますが、認める基準やその手続きについては特に隠す必要はありません。というか、公表してしまったほうがずっといいでしょう。そうすれば、まるで星室庁 (Star Chamber) のような謎めいた組織だと見られることもなくなり、よいパッチを投稿してコミュニティー内で認められさえすればコミッターになれるのだと理解してもらえます。 Subversion プロジェクトでは、この情報を開発者むけガイドラインドキュメントに記載しています。コミット権を取得したいと考える人のほとんどは、コードを書いてプロジェクトに貢献したいと考えているであろうからです。

コミッターになる手順を公開するだけでなく、現在のコミッターの一覧も公開します。この情報を公開する場所として昔からよく使われているのは、プロジェクトのソースコードツリーの最上位にある MAINTAINERS あるいは COMMITTERS という名前のファイルです。このファイルには、まずフルコミット権を持つメンバーの一覧を記載します。その後に、各分野別に部分コミット権を持つコミッターの一覧を続けます。各メンバーについて名前とメールアドレスを記載しますが、メールアドレスについてはメンバーの希望に応じてスパム対策のエンコードを施すこともあります (3章技術的な問題 の「アーカイブでのメールアドレスの処理」をご覧ください)。

フルコミッターと部分コミッターは明確な基準で区別できるものなので、一覧上でも区別しておくとよいでしょう。ただ、プロジェクト内で必然的に発生する非公式な区別 (影響力の大きい人は誰かなど) までも一覧に反映させようとしてはいけません。この一覧は公式な記録なのであり、覚え書きではありません。コミッターの並び順は、単純にアルファベット順にするかコミッターになった時期の順にします。

クレジット

クレジット^[35] は、フリーソフトウェアの世界における通貨のようなものです。プロジェクトに参加する動機が何であれ、匿名や他人の名前で仕事をして喜んでいる開発者を私は知りません。これには明確な理由があります。プロジェクトで尊敬されているかどうかは、そこで行使できる影響力をも左右します。そして、オープンソースプロジェクトに参加していることを履歴書で評価する経営者もいるので、そのことが直接ではないにしろ開発者の市場価値に反映されるかもしれないからです。もっと明確で、説得力のある理由がもう一つあります。人は他人から評価されたいですし、無意識のうちに他人が自分の仕事をわかってくれる証を求めるからです。よって、クレジットはプロジェクトに対するもっとも強い動機付けのひとつになります。小さな貢献をプロジェクトが認めてくれると、認められた人はもっと大きな貢献をするために戻ってくるのです。

共同で開発するソフトウェア(3章技術的な問題 を参照してください) が持つ重要な特徴のひとつとして、誰がいつ、何をしたかを正確に記録していることがあげられます。可能ならいつも、この記録をクレジットを適切に記す目的に使うようにしましょう。そして、行った貢献の種類を明確にしておきましょう。 "ありがとう、J. Random <jrandom@example.com>" のような書き方はせず、 "バグ報告と再現手順を教えてくれた J. Random <jrandom@example.com>、ありがとう" と記すようにします。

Subversion プロジェクトでは、記録されているバグ報告や、記録がなくてもコミットログに残っている報告者にクレジットを与えるやり方について、非公式ですが一貫したポリシーがあります。リビジョン 14525 までの Subversion のコミットログをざっと調査したところ、 10%のコミットに対して名前と電子メールアドレスを記録するクレジットを与えていました。クレジットを与えられたのは、バグを報告したり、そのコミットで修正されたバグを分析したりした人であるのが普通です。クレジットを貰う人たちは、実際にコミットを行った開発者とは違いますし、開発者の名前はいつも自動的にバージョン管理システムに記録されていることに注意してください。 Subversion プロジェクトでは、80数人のコミッターのうち55人が、自身がコミッターになる前に(通常は複数回)コミットログでクレジットを貰っていました。クレジットを貰うことが、継続して開発に参加してくれることを保証してくれるわけではもちろんありません。しかし少なくとも、プロジェクトが貢献を認めることを期待できる雰囲気を作り出すことはできます。

貢献に対してお礼をいうことと、特別なお礼は区別することが重要です。特定のコードや、コード以外の貢献を議論するときは、それらの仕事に対して感謝の意を示すとよいでしょう。たとえば、"我々が機能Xを実装できるのは、ダニエルさんが最近してくれたデルタコードに対する修正のおかげだ" というと、彼の仕事のどの修正について話しているかが同時にわかるようになります。一方で、ダニエルに単にお礼を言う電子メールを出すだけでは、実際すぐに役に立ちません。単に電子メールでお礼を言うだけでは、情報がなにもわかりません。なぜなら、バージョン管理システムなどの仕組みが、変更を行った事実を既に記録しているからです。何に対してもお礼を述べてしまうと、人々の興味が分散してしまい、最終的には価値がなくなってしまいます。なぜなら、お礼は普段している前向きなコメントより目立つほど効果が大きいものだからです。もちろん、これはお礼を述べていけないということではありません。与えるクレジットが多すぎて洪水を起こさないようにしましょう。以下に示す基準が役に立つでしょう。

議論の場が短命であればあるほど、気軽にその場でお礼を述べるようにしましょう。たとえば、IRC上の会話でバグ修正に対してお礼を言うのはよいことです。また、他のトピックについて話している電子メールの中で、余談としてお礼を言うのもよいでしょう。しかし、本当にまれな功績がない限り、お礼を言うだけの電子メールを出してはいけません。同様に、プロジェクトのウェブページのあちこちで感謝の言葉を述べてはいけません。いったんそれをやり始めると、いつどこでやめたらいいのかわからなくなります。そして、絶対に コードのコメントでお礼を言ってはいけません。コードを読む人が理解の助けにする、というコメントの第一義を損なうだけだからです。
プロジェクトに参加する頻度が少ない人であればあるほど、その人に対してお礼を言うのは適切です。これは直感に反するかもしれませんが、お礼は、自分が考えている以上のことをしてくれたときに言うものだ、という考え方とよく合います。よって、普段貢献してくれている人のいつもの仕事に対して頻繁にお礼を言ってしまうと、彼らがしていることは期待されていないものだ、ということを表現することになってしまいます。どちらかというと、反対のことをあなたは言いたいはずですよね！
このルールにはときどき例外があります。誰かが一時的に一生懸命努力しなければならない役割を全うしたときです。良い例が、リリース時には本格的に作業しますが、そうでないときは休眠状態 (リリースマネージャーとしては休眠していますが — そのときは活発な開発者でもあるかもしれません。ですが、これは別問題です) のリリースマネージャーです。
批判することやクレジットを与えることと同様、感謝の意をあらわすのは特別であるべきです。たとえある人が偉大な人であっても、ただそれだけでお礼を述べてはいけません。普段以上の物事をやり遂げたことに対してお礼を言い、それに付け加えて、それをなし遂げたのがなぜ素晴らしいかを述べるようにしましょう。

「プロジェクトが個別の貢献を認めること」と、「個別の貢献を賞賛して積み重ねず、集団全体で努力すること」はいつも対立するのが普通です。この対立関係を理解し、集団の中で試行錯誤するようにすれば、収拾がつかなくなることはないでしょう。

プロジェクトの分裂

4章プロジェクトの政治構造と社会構造 の「プロジェクトが分裂する可能性」では、プロジェクトが分裂する 可能性 がプロジェクトの管理体制に重大な影響を及ぼすことを取り上げました。しかし、実際に分裂した場合はどうなるのでしょう? どうやって処理するのでしょうか? それがどんな影響を及ぼすのでしょうか? 逆に、あなたのほうがそうしなければならないことはあるでしょうか?

その答えは、状況によって変わります。プロジェクトの進む道に関して相容れない意見の相違が出てきたために友好的にプロジェクトが分かれることもありますが、おそらくそれよりもっと多いのは技術的な意見の相違や人間関係の問題によってプロジェクトが分裂することでしょう。もちろん、これらを明確に区別できるとは限りません。技術的な議論は往々にして個人的な議論の要素も含んでいるからです。共通しているのは、ある開発者グループ (あるいはひとりの開発者だけのこともあります) にとってその他のメンバーとの共同作業のコストに見合う利益が得られないと判断したということです。

プロジェクトが分裂したときの、どちらが「本家」だとかどちらが「元祖」だとかいう問いへの明確な答えはありません。「プロジェクト P から分裂した F」というように、あたかも P は何も変わらないままで F がそこから新たに分岐したと話す人もいます。しかし、実際のところこれは「その人がどのように感じているか」を言っているにすぎません。これは基本的に認知度の問題です。周囲の大多数が同意すれば、その主張が真実だということになります。客観的にみた真実が最初からあるというわけではありません。不十分ながらも「なんとなくこうじゃないかな」と考えることしかできません。そして、まわりの認知度こそがむしろ客観的な真実と言えます。結局のところ本家 (あるいは分家) の区別というものは人の心の中にのみ存在するものだからです。

もしプロジェクトを分裂させようと考えた人がメインプロジェクトから離れて新たなブランチを立ち上げたのなら、認知度に関する問題はすぐに解決するでしょう。開発者もユーザーも、新たに登場した競合プロジェクトが新しいプロジェクトであることを認め、新しい名前 (元の名前に由来するものかもしれませんが、容易に区別できるもの) や新しいウェブサイト、新しい目標を持つものであることを認めることでしょう。しかし、両方の陣営が「自分のほうこそがこのプロジェクトの本流であり、名前を使い続ける権利がある」と考えている場合は話がややこしくなります。もしそのプロジェクト名の商標権やドメイン、ウェブページなどを何らかの組織で管理している場合は、通常はその組織の考えで問題を解決されます。どちらが本家でどちらが分家なのかをその組織が決めることになるわけです。というのも、広報合戦になればその組織にはかないっこないからです。当然、そんな事態になることはめったにありません。力関係についてはみんなよくわかっており、結果のわかっているケンカなどしないでしょうから。

幸いなことに、たいていの場合は「どっちが本流でどっちが傍流か」といった争いは起こりません。というのも、実際に分裂してしまうかどうかは、その動きに対する信任投票のような力学で決まるからです。もし開発者の過半数がプロジェクトを分裂させる動きに賛同したのなら、通常はもはやそうする必要はありません。強情な独裁者がプロジェクトを仕切っているのでもない限り、わざわざ分裂させなくてもそのプロジェクトの中で動きを進めていけばいいのです。一方、もし分裂させようと考えているのが全体の半数より少ないのなら、それは明らかに少数派の反乱です。礼儀的な意味でも、また常識で考えても彼らが本流となることはないでしょう。本流から分岐した別のものと考えるべきです。

分裂の動きをうまく処理する

プロジェクト内で誰かが新しい競合プロジェクトを立ち上げる動きを見せ始めたら、まずは落ち着いてあなたの長期目標を思い出しましょう。分裂すること自体はプロジェクトにとって害ではありません。むしろそれによって開発者やユーザーを失うことが問題なのです。つまり、あなたのやるべきことはそうした動きの芽を摘むことではなくその被害を最小限に抑えることなのです。腹が立つかもしれません。そんな動きは不当なものであり、また不要なものであると感じるかもしれません。でも、そんな感情を表に出したところで、態度を決めかねている開発者をあなたから遠ざけることにしかなりません。開発者たちに、態度を明確にするよう要求してはいけません。そして、新しくプロジェクトを立ち上げる人たちともできるだけ協力的に接するようにしましょう。まず第一に、誰かが新しいプロジェクト側で作業をすることになったからといって、その人のコミット権を剥奪するようなことはやめましょう。新しいプロジェクトの側で作業をすることになったからといって、元のプロジェクトにおけるその人の権限が即刻失われるというわけではありません。これまでコミッターであった人は、これからもコミッターであり続けるべきです。さらに、新しいプロジェクト側とはできるだけ仲良くやっていきたいという意志を示すことも大切です。必要に応じて、お互いのプロジェクトの変更内容を相手側にも反映させられるような関係を保ちましょう。もしあなたがプロジェクトのサーバの管理権限を持っているのなら、プロジェクトを始めるにあたってのインフラの支援を提案しましょう。たとえば、そのプロジェクトの過去のバージョン管理リポジトリのデータのコピーを提供すれば、彼らが過去のデータを使えるようになります (使用するバージョン管理システムによっては、わざわざそうしなくても過去のデータを利用できるものもあります)。何か必要なものがないかどうかを彼らに聞き、可能な限り支援するようにしましょう。あなたが邪魔をするつもりがないこと、そして (他の要因ではなく) あくまでも実力次第で新しいプロジェクトの成功か失敗が決まるような状態にすることを態度で示すことが大切です。

これらすべてを (公式に) 行う理由は、新しくプロジェクトを立ち上げる人たちを助けるためではありません。「こっち側にいたほうが何かと安全ですよ」ということを、できるだけ押しつけがましくない方法で開発者たちに伝えるためです。戦争においては、どちらの陣営に属するのかを明確にさせることにはそれなりの意味もあります (戦略的な意味、あるいは人間的な意味において)。しかし、フリーソフトウェアの世界においてはこれはまったく無意味です。実際、プロジェクトを立ち上げた後でも両方のプロジェクトでおおっぴらに活動する開発者も中にはいます。両者の互換性を保つために力を注いでいたりするわけです。彼らのおかげで、分裂した後でも両方のプロジェクトの間の交流ができるようになります。彼らは、新しいプロジェクトの側で追加したすてきな新機能をあなたのプロジェクトにもたらしてくれるかもしれません (そう、あなたの望むものをあちら側で作っている可能性もあるでしょう)。そして、将来ふたたび両者が合流するという望みも残してくれます。

時には新しいプロジェクトのほうが大成功を収めることもあります。最初に分裂させた当事者でさえ自分たちのほうが分家だと認めているにもかかわらず、みんながそちらのバージョンのほうをずっと好むようになり、結局本家に取って代わるようになるといったものです。有名なのは GCC/EGCS の例です。 GNU Compiler Collection (GCC、これは以前は GNU C Compiler という名前でした) は、オープンソースのネイティブコードコンパイラとしてもっともよく知られているもので、またもっとも多くの環境に移植されているコンパイラでもあります。 GCC の公式メンテナーと Cygnus Software ^[36] との間の意見の相違が原因で、GCC のもっとも活発な開発者グループのひとつであった Cygnus は GCC を離れて EGCS という新しいプロジェクトを立ち上げました。 EGCS 側は、意図的にオリジナルと敵対することを避けました。 EGCS の開発者は、決して自分たちのバージョンを公式な GCC にしようとは思わなかったのです。そうではなく、EGCS をよりよいものにすることだけに注力し、パッチを受け入れる頻度も公式の GCC メンテナーより多くしました。 EGCS の人気は増し、大手の OS ディストリビュータの中にもデフォルトのコンパイラとして GCC ではなく EGCS を採用するところが出てきました。ここにきて、さすがに "GCC" の名前を持っている本家 GCC のメンテナーたちもわかってきました。みんなが EGCS に移行するときにわざわざ名前を変更しなければならないのは面倒だということ、そしてもはや GCC の名前を引き渡さざるをえないということを。そこで、GCC は EGCS のコードを受け入れることにしました。 GCC は再び統一されたのです。オリジナルから分かれて、新たにプロジェクトを立ち上げたおかげで、中身はとても改良されたものになっています。

この例ひとつとっても、プロジェクトの分裂を単純に悪とみなすべきではないことがよくわかります。実際に起こったときは苦痛を感じてあまり歓迎されないかもしれませんが、それが成功するかどうかなんてそのときには知ることはできません。したがって、あなたを含むプロジェクトのメンバーができることといえば、彼らを見守り続けて新機能やコードを取り込めるように準備しておくことくらいです。もしそのほうがプロジェクト全体の利益になると皆が同意したら、究極の選択として彼らに合流することも考えるべきでしょう。もちろん、それ加わるメンバーをみればそれが成功するか失敗するかをある程度予測できることも多いでしょう。たとえば、プロジェクト内で文句ばかり言っていた人が一握りの不満分子 (彼らもプロジェクト内では建設的な振る舞いをしていませんでした) を引き連れて新たな競合プロジェクトを立ち上げたとしましょう。こんな場合は、むしろそうしてくれたほうがありがたかったでしょうね。彼らが本家に取って代わることを心配する必要もないでしょう。しかし、もし皆に尊敬されている実力者が新しいプロジェクトに参加しているというのなら、なぜそんなことになったのか自分に問い返してみましょう。おそらく、あなたのプロジェクトには制約が多すぎ、やりたいことの一部 (あるいはすべて) を実現するにはプロジェクトのコピーを使って競合プロジェクトを立ち上げるしかなかったのでしょう。要するに、自らが行動することで他の分裂の動きを避けるということです。

新しいプロジェクトを立ち上げる

ここでのアドバイスは、最後の手段としてオリジナルのコピーを使い、競合プロジェクトを立ち上げざるを得なくなった人たちに向けたものです。立ち上げを始める前に、まず他の可能性を徹底的に試すようにしましょう。実際に競合プロジェクトを立ち上げると、ほとんどの場合は開発者を失うことになります。仮に後で新しい開発者が増えるとしても、そうなる確証はありません。また、競合プロジェクトを立ち上げるということは、ユーザーの気を引くための競争が始まるということを意味します。そのソフトウェアをダウンロードしようとした人たちはみんな悩むことでしょう。 "で、いったい私はどっちをダウンロードすりゃいいの?" あなたがどちらのプロジェクトにいたとしても、状況は混沌としています。そんな質問は、プロジェクトが分裂する前には出なかったわけですから。中には、プロジェクトが分裂することはソフトウェアの生態系上ごく自然なことだという人もいます。自然淘汰の結果、一番環境に適合したものが生き残る。つまり、結局はみんながよりよいソフトウェアを使えるようになるというわけです。生態系という意味ではそれが真実かもしれませんが、個々のプロジェクトにおいては決して真実であるとはいえません。プロジェクトが分裂しても、新たに立ち上がったプロジェクトが成功することはほとんどありません。また、ほとんどのプロジェクトは分裂してもよい結果を生みません。

結論としては、議論のネタとしてプロジェクトが分裂することを持ち出してはいけないということです。 —"俺の言うとおりにしてくれなきゃプロジェクトが分裂しちゃうよ!"— といった具合に。なぜなら、みんな知っているからです。プロジェクトを分裂させたとしても、開発者の興味をひくことができなかったら、新しい競合プロジェクトの行く末は長くないことが多いということを。すべての関係者 (開発者だけではなくユーザーや各 OS 向けのパッケージ作成担当者なども) がどちら側を選ぶのかの判断を迫られることになります。したがって、あくまでもそれ以外のやり方がないことが確実に主張できる状況にならない限りプロジェクトを分裂させるのは避けるようにしましょう。

プロジェクトを分裂させることで生まれる、新しいプロジェクトが成功するかどうかの可能性を評価するにあたっては、 すべての 要素を考慮にいれることを忘れないようにしましょう。たとえば、プロジェクトの開発者の多くが同じ雇い主のもとで働いているとしましょう。たとえ彼らが不満を抱いて個人的に新しいプロジェクトの立ち上げを考えたとしても、雇い主がそれに反対していると知れば声を大にしてそれを言うことはないでしょう。フリーソフトウェアプログラマーの多くは、コードにフリーなライセンスが適用されていたら特定の企業に開発が左右されることはないと考えがちです。究極の意味では、ライセンスが自由を保証しているというのは事実です。だれかが本当に元のプロジェクトから分かれて、新しい競合プロジェクトの立ち上げを望みそれだけのリソースがあるのなら、できないことはないでしょう。しかし実際のところは、いくつかのプロジェクトの開発チームはほぼ特定の団体が資金源になっていることが多く、それを隠そうとしても無意味です。その団体がそうした動きに反対しているようなら、たとえ開発者が参加する気があったとしても実際には参加することがないでしょう。

それでもまだ「今のプロジェクトから分かれて、新しいプロジェクトを立ち上げる以外ない」と思っているなら、まずは個人的に賛同してくれる仲間を集めましょう。それから、そうすることを (けんか腰ではなく) おだやかに宣言します。たとえ現在のメンテナーにたいして怒りや失望の気持ちがあったとしても、それを実際に言ってはいけません。あなたが決心したきっかけは何なのかということ、そして現在のプロジェクトに対して悪意はまったくないということを冷静に説明します。プロジェクトを分裂させるつもり (元のプロジェクトを緊急待避させるのではなく) であるなら、あくまでもコードを派生させるのであってオリジナルと同じ名前を使うのではないということを強調し、元のプロジェクトの名前と衝突することのない名前を選びます。元のプロジェクトときちんと区別できるような名前であれば、その一部に元のプロジェクトの名前を含めることもできます。もちろん、新しいプロジェクトのホームページで「これは元のプログラムから分離したものであり、元のプログラムを置き換えることを目指している」と説明するのはかまいません。区別しにくいような状況にユーザーを陥れてしまうことは避けましょう。

最後に、よいスタートを切るためのひとつの方法として、元のプロジェクトのコミッター全員に対して (たとえ明示的に新しいプロジェクト立ち上げに反対していたとしても) 新しいプロジェクトのコミット権を与えてしまうというものもあります。たとえ彼らがそのアクセス権を一切使用しなかったとしても、あなたからの「意見の不一致はあったけれども、敵になったというわけではない。よいコードならどなたからのものでも歓迎します」というメッセージは伝わります。

^[30] この疑問について詳しく調査したところ、興味深い結果がでました。 Karim Lakhani と Robert G. Wolf による論文 Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects にまとめられています。 http://freesoftware.mit.edu/papers/lakhaniwolf.pdf をご覧ください。

^[31] しかし、http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee の "having authors names in .py files" というスレッド、特に William Stein の投稿は、その反論となるでしょう。私が思うに、この場合のキーとなるのは、作者の多くが「ソースに直接クレジットを書くのが当然であり、それが高く評価される」という文化 (数学者のコミュニティー) の出身であるということです。このような場合はソースファイルに作者名を埋め込んでもいいでしょう。そして個々の作者が具体的に何をしたのかを正確に記載しておきます。そうすれば、今後新たに開発に加わる人たちにも「そういうものなんだ」と認識させることができます。

^[32] 既存のテストをすべて新しいフレームワークに移行させなければならないというわけではありません。両者を共存させることもできるでしょう。必要になったものだけを新しい形式に変換すればいいのです。

^[33] IssueZilla は私たちが使用しているバグ追跡システムで、 BugZilla の後継にあたるものです。

^[34] コミット権の考え方は、分散型のバージョン管理システムでは多少異なることに注意しましょう。分散型のバージョン管理システムでは、各個人がプロジェクトにリンクしたリポジトリを作成することができ、作成したリポジトリに対するアクセス権を得ることができます。それでもなお、コミット権という 考え方 自体は有効です。「コミット権」とは要するに「そのグループが作成し、リリースするソフトウェアのコードに変更を加える権限」ということです。中央管理型のバージョン管理システムでは、これはリポジトリへの直接のコミット権を意味します。分散型の場合は、自分の変更内容を配布ファイル本体に pull できる権限のことを指します。いずれにしても考え方は同じです。裏側の管理方式はそれほど重要ではありません。

^[35]ある物事に対する貢献を明確にするため、貢献があった人物、団体、企業等の名前を明示すること

^[36] 現在は RedHat (http://www.redhat.com/) に吸収されました。

第9章 Governments and Open Source

Be Open Source From Day One, Not Day N

Review Your RFI, RFP and Contract Language

Get the Lawyers Involved Very Early or Very Late

Dispel Myths Within Your Organization

Foster Pools of Expertise in Multiple Places

Decouple Publicity Events from Project Progress

Establish Contact Early with Relevant External Communities

Have a Plan to Handle Negative Reactions

The Open Government / Open Data Community

24 March 2013: If you're reading this note, then you've encountered this chapter while it's undergoing substantial revision; see producingoss.com/v2.html for details.

NOTES: poss2: mil-oss, Gunnar's timeline, procurement & the question of where expertise should reside; how to write a contract; liability; ownership; where to host; use vs creation; be open source from day one. Mention ORM, CfA, CivComs. What other orgs? Open source policies, open data policies.

This chapter is mainly about government agencies producing new open source software, and participating in existing open source projects; I'll also look at government usage of open source software, to the extent that it overlaps with those main topics.

Since the first edition of this book in 2005, I've worked with various U.S. government agencies — at the federal, state, and municipal levels — helping them release open source software. I've also been lucky enough to observe, and in a few cases work with, some government agencies outside the U.S. These experiences have convinced me of one thing: government is different. If you work at a government agency and the material in this book so far has made you shake your head and think "Sure, but it'll never work here", you don't have to convince me — I already know what you mean. Governments differ from individuals and from private-sector organizations in some fundamental ways:

Governments often aren't trying to retain technical expertise in-house (that's what contractors are for).
Governments have labyrinthine and in certain ways inflexible procurement and employment policies. These policies can make it difficult for a government agency to be nimbly responsive in an open source development community.
Government agencies tend to be unusually risk-averse. Somewhere at the top there's an elected official who, reasonably, sees an open source project as just one more surface area for opponents to attack. After all, when development happens in public, the inevitable false starts and wrong turns are also public; if development were internal, no one else would know about it when those things happen.
Government officials hunger for well-timed and well-controlled publicity events. This has certain benefits, but it can sometimes come at the expense of overall project health. This need for publicity is the complement of being risk-averse: elected officials and those who work for them understand that most people aren't paying much attention most of the time — therefore, those who work in government want to ensure that in the few moments when people are paying attention, they see something good. This is understandable, but it can cause them to delay certain actions — or, in some cases, do them too soon — based on external publicity implications rather than on what's best for the project technically and socially.

There are good reasons for all of these things; they've been true for decades if not centuries, and they're not going to change. So if you're a government agency and you want to start a successful open source project, certain adjustments will be necessary to compensate for the structural idiosyncracies above. The advice that follows is most applicable to the U.S. and countries with similar systems of government and civil service.

Be Open Source From Day One, Not Day N

(poss2: recast blog post of the same name)

Review Your RFI, RFP and Contract Language

(poss2: make sure you own copyrights (ref ch10). There are some good examples out there of RFI/RFP language; what about contracts? Also, look at how RFP-EZ project is doing.)

Get the Lawyers Involved Very Early or Very Late

tbd

Dispel Myths Within Your Organization

(poss2: note that government agencies are targets of heavy sales attention from vendors of proprietary services. Myths you'll need to dispel: insecure; no support; OSS is cheaper; if it's open that means anyone can change our code; if it's open that means we'll have to spend a lot of resources interacting with outside developers; if it's open then we'll have to release all our other stuff as open source too; developers will devote attention to this just because we released it; other cities will pick this up and use it right away. Note that many of these could/should be referenced from other places, like chapter 5.)

Foster Pools of Expertise in Multiple Places

(poss2: foster concentrations of expertise in the software outside the contractor who is writing it. This is not because you don't want to use them for future maintenance; it's so that you'll have a better bargaining position and not be locked in. Ref hackathons section, licensing section.

Decouple Publicity Events from Project Progress

poss2: tbd

Establish Contact Early with Relevant External Communities

poss2: pre-announce; ask for help not admiration; use contracts (e.g., security audits) to establish bona fides, etc

Have a Plan to Handle Negative Reactions

poss2: anticipate reactions re licensing, code, APIs, documentation, choice of hosting platform, etc. Don't let them catch you by surprise.

The Open Government / Open Data Community

poss2: there's a community of people now who talk to each other, read and write for overlapping publications, go to conferences, etc. You don't need to do anything special to find them, but be aware that reactions can balloon in there and then take you by surprise.

第10章ライセンス、著作権、特許

MIT/X Window System ライセンス

GPL

GPL はフリーなライセンスなのか?

BSDライセンスはどうなの?

著作権の保有と譲渡

何も対処しない
貢献者ライセンス同意書(CLA)
著作権の譲渡

デュアルライセンスの仕組み

特許

さらなる情報源

あなたが選ぶライセンスは、それがオープンソースである限り、プロジェクトで採用するにあたって大きな影響を与えないはずです。ユーザーは、ソフトウェアを機能や質を見て選ぶことが一般的で、ライセンスの詳細を見て選んだりはしません。それでも、プロジェクトが採用するライセンスが目的に確実に合ったものにすることと、ライセンスに関する決定を他の人と議論できるようにするために、フリーソフトウェアのライセンス問題に関する基本的なことがらはやはり理解する必要があります。しかしながら私は法律家ではないですし、この章の内容も、法的なアドバイスを正式に受けて書いているわけではないことに注意してください。そうするには、法律家を雇うか、あなた自身が法律家になる必要があるでしょう。

使用する用語

オープンソースライセンスについて議論するときにまず明らかになることは、同じ意味を持つ異なる単語がたくさんあるらしいということです。たとえば フリーソフトウェア、 オープンソース、FOSS、 F/OSS、そして FLOSS です。ここでは、そうした用語を他の言葉と一緒に整理することにしましょう。

フリーソフトウェア

ソースコードを自由に共有し、かつ変更を加えることができるソフトウェアのことです。この用語はリチャード・ストールマンがはじめに作り、 GNU General Public Licence (一般公衆利用許諾契約書、以下 GPL) に盛り込みました。そして Free Software Foundation (フリーソフトウェア財団、以下 FSF、http://www.fsf.org/) を設立してこの概念を広めたのです。

「フリーソフトウェア」という用語は、ソフトウェアの範疇では「オープンソース」とほとんど同じ意味です。しかし、とりわけ FSF は前者を好みます。なぜなら、「フリーソフトウェア」の方が、自由という考え方や、技術的な流行ではなくて何より社会運動としての、自由に再配布可能なソフトウェア、という考えを強調しているからです。 FSF は、「フリー」という単語が — 「自由」ではなく、「コストがかからない」、と解釈され得るという意味で — 曖昧なものだと認めています。しかしながら色々考えてみて、フリーという単語がやはり一番だと考えていますし、他の英単語にも曖昧な部分があるとも考えています。 (本書では、「フリー」という単語を「コストがかからない」という意味ではなく、「自由」という意味で使っています。)

オープンソースソフトウェア

フリーソフトウェアの別名です。しかしながら、この名前の違いは重要な哲学の違いを反映しています。「オープンソース」という単語は、Open Source Initiative (オープンソース・イニシアティブ、以下 OSI。 http://www.opensource.org/) が社会運動よりはむしろ開発の方法論としての意味を強調することで、フリーソフトウェアをより企業が受け入れやすくするために作りました。 OSI は「フリー」という言葉を使うことで、低品質に違いないと思われてしまう点も克服したかったのかもしれません。

フリーなライセンスはオープンソースでもあり、 (2,3 の小さな例外を除き) 逆も同じことが言えますが、人々はひとつの用語を取り上げてそれに固執しがちです。一般的に、「フリーソフトウェア」を好む人たちは「フリー」が持つ意味について、哲学的、または道徳的な立場を好むのに対して、「オープンソース」を好む人たちはそれが「自由」に関する問題だとは考えませんし、「フリーソフトウェア」を好む人の考え方を広めることにも興味がありません。この二つの用語に関する分裂の歴史については、 1章導入の「「フリー」と「オープンソース」の違い」を参照してください。

FSF は — 私の完全な主観ですが、微妙ながら極めて公平という意味で — これらの二つの用語について優れた解釈を http://www.fsf.org/licensing/essays/free-software-for-freedom.html で示しています。OSI は、自らの解釈を2ページに分けて紹介しています。: http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing と http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/free-notfree.php です。

FOSS, F/OSS, FLOSS

二つあるものが三つになる。これは「フリーソフトウェア」という用語で起こっていることと全く同じです。学問の世界では、言葉の上っ面の美しさよりも正確さと包括性を求めて、 "Free / Open Source Software" を表す FOSS や F/OSS に移っているようです。勢いがある別の表現として、 "Free / Libre Open Source Software" があります。 (libre^[37] という単語は、多くの言葉に存在していながら、「フリー」が持つ曖昧な意味がありません。詳しくは http://en.wikipedia.org/wiki/FLOSS を参照してください。)

これらの用語は全て、本質的には同じ意味です。改造し、万人が配布できますが、時に — 必ずしも常にそうであるわけではないですが — 派生したものについては、オリジナルの配布条件と同条件で自由に配布することを求めることがあるソフトウェアのことなのです。

DFSG 互換の ...

Debian フリーソフトウェアガイドライン (以下 DFSG、http://www.debian.org/social_contract#guidelines) と互換性があるライセンスのことです。 DFSG 互換かどうかは、特定のライセンスが本当の意味でのオープンソース (フリー、自由) かどうかを確認する基準として広く使われています。 Debian プロジェクトの任務は、システムの一部または全部を改変、再配布する権利があるかどうかを疑わずにインストールできる、全体がフリーなオペレーティングシステムを維持することです。 DFSG は、Debian にソフトウェアを含める際に、そのライセンスが満たさなければならない基準となります。 Debian プロジェクトは、 DFSG の基準を満たしているかを確認するやり方を考えるのに多くの時間を割いてきました。よって、彼らが考えたガイドラインは非常に堅固で、私が知る限りでは、 FSF からも OSI からも強く異議を唱えられたことはありません。特定のライセンスが DFSG 互換であることがわかれば、 (オリジナルの作者の意に反してでもコードを派生させられること、のような) オープンソースプロジェクトの力学を維持するのに必要なすべての「自由」を、そのライセンスが保証していることになります。この章で議論しているすべてのライセンスは DFSG互換です。

OSIの承認を得た ...

OSI が認めたライセンスということです。これは特定のライセンスが、必要とされている自由をすべて満たしているかどうかを確かめるのに広く使われているもう一つの基準です。 OSI が定義しているオープンソースソフトウェアの定義は、 DFSG を基にしており、この定義を満たしているライセンスは、DFSG も満たしています。このことは、長い歴史の中で 2、3の例外はあるものの、その例外はニッチなライセンスや、全く関連のないものだけです。 Debian Project とは異なり、 OSI はこれまで承認してきたすべてのライセンスを http://www.opensource.org/licenses/ で一覧にしています。よって、「OSIが承認する」ことには曖昧さがありません。なぜなら、ライセンスがその一覧にあるかどうかで、 OSIが承認したかどうかが決まるからです。

FSF も、自らが認めたライセンスの一覧を http://www.fsf.org/licensing/licenses/license-list.html で管理しています。 FSF はフリーであるかどうかだけでなく、 GPL と互換性があるかどうかでもライセンスを分類しています。 GPL と互換性があるかどうかは重要な話題なので、後にある「GPL とライセンスの互換性」で扱っています。

独占的(プロプライエタリ）な、 クローズドソース

「フリー」や「オープンソース」とは反対の意味です。コピーひとつ毎にお金を支払うか、オープンソースの力学を妨げるのに充分制限的な条件を適用した、伝統的なロイヤリティベースのライセンスで配布されるソフトウェアのことです。無料で配布されるソフトウェアでも、ライセンスが自由な改変や再配布を認めていない場合には、独占的なソフトウェアになり得ます。

「独占的なソフトウェア」や「クローズドソース」は一般的に同じ意味です。しかし、「クローズドソース」は、さらにソースコードを見ることさえできないことも意味しています。ソースコードはほとんどの独占的なソフトウェアで見ることはできませんので、これらを区別することは普通ありません。しかしながら、ソースコードを見るのを許可するライセンスで独占的なソフトウェアをリリースする人もいます。彼らはそれを、「オープンソース」や「オープンソースに近い」などと紛らわしい呼び方をするのですが、これは誤解を招く言い方です。ソースコードが 手に入る かどうかの問題ではないのです。重要なのは、それを使って何ができるのか、ということなのです。よって、「独占的なソフトウェア」と「クローズドソース」の違いはほとんど無意味ですから、これらは同じ意味として扱われるのです。

「商用の」という言葉が、「独占的なソフトウェア」の別名として使われることがあります。しかし、正確に言うと、これらは同じではありません。フリーソフトウェアも商用にすることができます。結局、買う人がコピーする権利を制限しない限り、フリーソフトウェアは売ることもできるのです。フリーソフトウェアは他のやり方、たとえばソフトウェアのサポートや、ソフトウェアを使ったサービスや、資格を売ったりすることで、商用にすることができるのです。フリーソフトウェアを使って巨万の富を築いた企業も存在します。よって、フリーソフトウェアは商用にできないわけではありませんし、企業が使えないわけでもありません。一方で、フリーソフトウェアは本質的に独占的なソフトウェアとは 相容れないものです。それこそが、コピーする毎にお金が必要な、伝統的なライセンスモデルと異なる重要な点なのです。

パブリックドメイン

著作権を持っている人がいないことです。つまり、ソフトウェアのコピーを制限する人がいないということです。パブリックドメインであることは、作者がいないことと同じです。どんなソフトウェアにも作者がいますが、その作者が書いたものをパブリックドメインにすることを選んだとしても、特定の人が書いたという事実を動かすことはできません。

ソフトウェアがパブリックドメインに置かれた場合、その構成要素は著作権があるソフトウェアに組み込むことができ、組み込まれた部分の コピー にも、組み込んだソフトウェアの著作権が適用されます。しかし、それによって元のソフトウェアが利用できなくなるわけではなく、パブリックドメインのままです。よって、リリースしたものをパブリックドメインに置くことは、ほとんどのフリーソフトウェアを認定している組織のガイドラインに照らして、技術的に「フリー」にする方法の一つです。しかしながら、たとえフリーソフトウェアであっても、パブリックドメインに置くよりは何らかのライセンスを採用した方がよい理由があります。ソフトウェアの著作権を持つ人だけでなく、それを受け取る人たちに対しても、制限を課せば役に立つ場合があるからです。こうした側面については、次のセクションで明らかにしていきます。

コピーレフト

伝統的な著作権と反対の結果を得るために、著作権に関する法律を利用しているライセンスのことです。この意味は、この章で議論している自由を認めたライセンスのこともあれば、もっと狭義では、その自由が伝播していくことを義務付けることで、自由を認めるだけでなく強制もしているライセンスのことです。 FSF は後者の定義だけを使っていますが、それ以外の場合は5分5分です。つまり、多くの人々は FSF と同じ使い方をしていますが、それ以外は — 主流となっているメディアの記事を書く人たちは — 前者の定義を使う傾向があります。この用語を使っている人たちが、区別すべき使い方があるのを知っているのかはわかりません。

後者の意味での標準的な使い方の例や、厳密な定義としては、派生物のライセンスを同じライセンスにすることを義務付けている GPL があります。詳しくは、後にある「GPL とライセンスの互換性」を参照してください。

ライセンスの特徴

多くのフリーソフトウェアライセンスが利用できますが、それらが述べている重要な点はすべて同じです。つまり、誰もがコードを改造でき、オリジナルのままでも、改造を加えた形でも再配布できること、そして著作権を持つ人、そしてソフトウェアの作者はいかなる保証もしない (無保証であること、責任を回避することは、特にソフトウェアが改変されたことを知らないで実行する人がいる可能性を考えると特に重要です) ことです。それぞれのライセンスの違いは、以下のよく起こる問題に集約できます。

独占的なライセンスとの互換性: フリーなライセンスの中には、それが適用されるコードを独占的なプログラムで使うことを認めるものがあります。これは独占的なプログラムのライセンス条件に影響を与えません。独占的なプログラムはそのままで、独占的でないソースコードがいくらか混入するだけです。 Apacheライセンス、Xコンソーシアムライセンス、 BSDスタイルのライセンス、そして MITスタイルのライセンスは、すべて独占的なライセンスと互換性があるライセンスの例です。
他のフリーなライセンスとの互換性: ほとんどのフリーなライセンスはお互いに互換性があります。つまり、あるライセンスが適用されたコードは、別のライセンスが適用されたコードと組み合わせることができます。組み合わせた結果できたものは、それぞれのライセンス条件を破ることなく再配布することができます。このことの重要な例外は、GPL (GNU General Public License) です。 GPL は、 GPL で配布されたコードを使ったいかなる派生物も、 GPL として配布しなければならず、かつ GPL が必要とすること以上の制限をつけてはならない、ことを要求しています。 GPL と互換性があるライセンスもあれば、ないものもあります。詳しくは、後の方にある「GPL とライセンスの互換性」で議論しています。
クレジットの強制: フリーなライセンスの中には、それが適用されたソースコードを使ういかなるコードにも、注意書きを記すことを強制するものがあります。注意書きの位置や内容も決まっているのが普通です。内容はコードの作者や著作権を持つ人へのクレジットです。こうしたライセンスでも、独占的なライセンスと互換性があるものがあります。なぜなら、派生物がフリーであることを要求するのではなく、フリーなコードに対してクレジットを与えることだけを要求しているからです。
商標の保護: クレジットを強制するやり方の変形として、商標で保護されたライセンスは、オリジナルのソフトウェア (またはその著作権を持つ人や組織など) の名前を、事前の書面での許可なく派生物で使っては いけない と定めています。クレジットを強制するやり方は、ある名前をどこかで使うことを求めますし、商標で保護するやり方は、使わないことを求めますが、どちらも同じ要求を表しています。つまり、オリジナルのソースコードへの敬意を払い、それを伝播させたいけれども、どこからもそうした敬意を傷つけられたくないのです。
特許からの防衛: GPL バージョン3 や Apache Software Licence バージョン2 には、(著作権に関する法律で)ライセンスが与えている権利を特許を使って奪うことを防ぐための文言が含まれています。これらのライセンスは、成果物とそれに付随した特許ライセンスを与えることを貢献する人に要求します。この特許ライセンスには、彼らの貢献によって(または、貢献がソフトウェアに取り込まれることで)侵害されるあらゆるライセンス可能な特許が含まれます。その上で、GPL バージョン3 や Apache Software License バージョン2 はさらにその一歩先を行っています。つまり、これらのライセンスによって配布されているソフトウェアのユーザーが、そのソフトウェアに含まれている特許を侵害したと主張して第三者に訴訟を起こした場合、そのユーザーはソフトウェアのライセンスによって与えられていた特許の全てを自動的に 失います。さらに GPL バージョン3 の場合は、ライセンスに基いてソフトウェアを配布する権利もなくなってしまいます。
「ソースコードの完全性」を保護する: ライセンス (たとえば、プログラミング言語 Perl で実装されたソフトウェアで最も人気がある Artistic License や、Donald Knuth の TeX License) によっては、オリジナルのコードと改変した部分を区別できるやり方で、改変と再配布を行うように要求するものがあります。こうしたライセンスは、本質的に他のフリーなライセンスと同じ自由を認めていますが、オリジナルなコードの完全性を容易に確認できるようにするために、ある制限を課しています。これらのライセンスは特定のプログラム以外では受け入れられていません。よってこの章でも議論しません。ただ、完全を期すためにここで触れています。

これらの条件は、相互に排他的なものではありませんし、ライセンスによっては複数の条件を含むものがあります。共通しているのは、ソフトウェアを受け取る人が、それを使ったり再配布するのを認めるのと引き換えに、ライセンスが義務を課すというものです。たとえば、自分たちの名前とコードへの敬意を、コードで伝播させたいと願って、クレジットや商標について条件を課すプロジェクトが存在します。条件から出てくる負担によっては、面倒だと考えて制限が緩いライセンスを採用したパッケージを選ぶユーザーが出てくるかもしれません。

GPL とライセンスの互換性

ライセンスをくっきりと分ける境界線は、独占的なライセンスと互換性があるか、ないかです。つまり、GPL (GNU General Public License) とそれ以外全てです。 GPL の第一の目的はフリーソフトウェアを広めることなので、 GPL を書いた人は、意図的に独占的なコードと GPL のコードを混ぜることができないようにしました。特に GPL が要求していること (全文は http://www.fsf.org/licensing/licenses/gpl.html を参照してください) は以下の二つです。

すべての派生物 — つまり、GPL が適用されたコードを含んだあらゆるプログラム — は、それ自体も GPL で配布しなければならない。
オリジナルでも、派生物であっても、それを再配布する場合には制限を追加してはいけない。 (原文の該当箇所を以下に引用します: 「あなたは、このライセンスが与えた、または認めた権利を行使することに関して、これ以上他のいかなる制限も課してはならない。」)

これらの条件によって、GPL は自由を伝播させることに成功しています。いったんプログラムが GPL で保護されると、再配布の条件が 伝染する のです — つまり、取り込んだコード以外のあらゆる部分にその条件を適用させ、かつ GPL を採用したコードをクローズドソースなプログラムで使うのを不可能にしているのです。しかしながら、これらの条項は他のフリーなライセンスと GPL を非互換にするものでもあります。通常は、他のライセンスが追加の条件を課したときに非互換が起きます — たとえば、何らかの方法でオリジナルの作者へのクレジットを要求する場合です — これは、GPL の「あなたは、これ以上他のいかなる制限も課してはならない ...」という文言に反しています。こうした二次的な結果は、望ましいものか、少なくとも悪いことではない、というのが FSF の見解です。 GPL はあなたのソフトウェアをフリーな状態に保つだけでなく、他のソフトウェアにも自由を強制する媒体にもするのです。

この手法がフリーソフトウェアを広める優れた手段なのかどうかは、インターネット上でずっと続いている宗教論争 (6章コミュニケーション の「宗教論争を回避する」を参照してください) のひとつであり、ここでは深く触れません。重要なのは、 GPL と互換性があるかどうかがライセンスを選ぶ際に重大な問題になるということです。GPL は非常に重要なオープンソースライセンスです。ある時点での Freecode 上では、GPL が 68% を占めており、次に高いのは 6% です ^[38]。 GPL で保護されたコードと自分のコードを混ぜた上でフリーにしたいのなら — GPL なコードがたくさんあるのだから — GPLと互換性があるライセンスを選ぶべきです。 GPL と互換性があるオープンソースライセンスのほとんどは、独占的なライセンスとも互換性があります。よって、そうしたライセンスを採用したコードは、 GPL なコードでも使うことができますし、独占的なプログラムでも使うことができるのです。もちろん、そうやってコードを混ぜた 結果生じたもの は相互に互換性がありません。なぜなら、一方は GPL となり、一方はクローズドソースなライセンスが適用されるからです。問題が及ぶのは派生物に対してのみであり、はじめに配布したオリジナルなコードは影響を受けません。

ありがたいことに、FSF は GPL と互換性があるライセンスと、互換性がないライセンスの一覧を http://www.gnu.org/licenses/license-list.html で示してくれています。この章で議論しているすべてのライセンスがこのリストにありますが、GPL と互換性があるものもあれば、ないものもあります。

ライセンスを選ぶ

プロジェクトに適用するライセンスを選ぶときは、できる限り新しいものを作らずに既にあるものを使うようにしましょう。有り物を使う理由はふたつあります。

ライセンスが既に知られているからです。あなたが人気のあるライセンスのうちのひとつを使えば、コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。ずっと以前に読んだことがあるからです。
ライセンスの質が保たれているからです。自分の思い通りになる弁護士のチームがいなければ、法的に隙がないライセンスを生み出すことはできないでしょう。この章で触れているライセンスには、多くの人々の経験や思考が詰まっています。つまり、あなたのプロジェクトに本当に変わった要求がない限り、さらに行動する必要はないということです。

プロジェクトにライセンスを適用するには、 2章さあ始めましょう の「ライセンスを適用する方法」を参照してください。

MIT/X Window System ライセンス

自分のコードをできる限り多くの開発者と派生物で使ってもらい、かつ独占的なコードで使われるのを気にしないのならば、 MIT/X Window System ライセンス(以下 MIT/X ライセンス) (マサチューセッツ工科大学がオリジナルの X Window System のコードをこのライセンスでリリースしたので、そう呼ばれています) を選びましょう。このライセンスが言っているのは基本的に「あなたはこのコードを自由に、無料で使うことができますよ」ということです。このライセンスは GNU GPL と互換性があり、短く、簡単で、理解しやすいものです。

Copyright (c) <year> <copyright holders>

以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うこと
を無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提
供する相手に同じことを許可する権利も無制限に含まれます。

上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。

ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、およ
び権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフト
ウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとし
ます。

(原文は http://www.opensource.org/licenses/mit-license.php にあります。日本語訳については http://sourceforge.jp/projects/opensource/wiki/licenses%2FMIT_license から引用させて頂きました。)

GPL

あなたのプロジェクトが、自分達が作ったものが独占的なプログラムで使われるのを望まなかったり、少なくともそうしたことを気にしないのであれば、GPL (GNU General Public License) (http://www.fsf.org/licensing/licenses/gpl.html) を選ぶとよいでしょう。 GPL はおそらく、現在世界でもっとも広く使われているフリーソフトウェアライセンスです。認知度が高いことが、それ自体 GPL の主な利点のひとつです。

他のプログラムの一部として使われるライブラリを書いている場合は、あなたのプロジェクトの目標に照らして、GPL の制限を注意深く考える必要があります。場合によっては — たとえば、自分達のライブラリと同じことをしている独占的なプログラムのシェアを奪おうとしている場合 — あなたがたとえ望まなくても、独占的なプログラムで使えるようにするやり方で、プログラムをライセンスするのが戦略として優れているかもしれません。 FSF は、こうした場合のために GPL とは別の選択肢を用意しました。それが GNU Library GPLであり、後にGNU Lesser GPL と改称されたものです。 (ほとんどの人はその頭文字をとって、LGPL という用語を使います) LGPL は GPL よりも制限が緩く、フリーでないコードと容易に混ぜることができます。しかしながら、LGPL はちょっと複雑で理解するのに少し時間がかかります。よって、GPL を使うつもりがないなら、MIT/X スタイルのライセンスを使うことを私は勧めます。

GNU Affero GPL: サーバサイドにあるコード向けの GNU GPL

2007年、FSF は GPL の派生ライセンスとして、GNU Affero GPL (http://www.fsf.org/licensing/licenses/agpl.html) と呼ばれるライセンスをリリースしました ^[39]。

GNU AGPLv3 が示したやり方は、通常の GPL を採用した上で「ネットワーク越しにリモートとやりとりする際の」条件を加えたことです。この条件は、次のようなものです。「... このプログラムを改変した場合、あなたが改変したバージョンはすべてのユーザーに目立つやり方で、コンピューターネットワーク越しにアクセスできるようにしておかなければならない ... 無償で、ソフトウェアのコピーを容易にする通常の手段を使って ... あなたが改変したバージョンに相当するソースコードをユーザーが受け取る機会を与えなければならない」このように GPL を拡張したことで、アプリケーションサービスを提供する人たちの世界に GPL の強制力が及びます。 FSF は通常ネットワーク越しに実行されるあらゆるソフトウェアに対して GNU AGPLv3 を使うことを推奨しています。

AGPLv3 は、GPLv2 とは直接の互換性がないことに注意してください (ただし、GPLv3 とはもちろん互換性があります)。しかし、 GPLv2 でライセンスされた殆どのソフトウェアには「GPLv2 以降のバージョンで」という条件が入っています。よって、この場合に GPLv2 のコードと AGPLv3 のコードを混ぜたければ、単純に GPLv3 に移行すればよいのです。しかし、GPLv2 だけが厳格に適用されるプログラム (つまり、「GPLv2 以降のバージョンで」という文言が入ってない場合) は、 AGPLv3 のプログラムと混ぜることができません。

AGPLv3 の歴史はちょっと複雑ですが、ライセンスそのものは単純です。なぜなら、これは GPLv3 の条項に、ネットワーク越しでやりとりする際の追加条件を加えただけのものだからです。 AGPLv3 については、Wikipedia の記事が秀逸です。 http://en.wikipedia.org/wiki/Affero_General_Public_License

GPL はフリーなライセンスなのか?

GPL を選んだ結果、プロジェクトがコードに対してできることを制限された場合 — すなわち他のライセンスでコードを配布できなかった場合 — GPL が本当の意味で「フリー(自由)」なのかどうかに関する論争がプロジェクトで起こるかもしれません — これが起こる可能性は小さいですが、ゼロとはいえません。人によっては、他のライセンスでコードを配布できないという制限が、 MIT/X ライセンスのような制限の緩いライセンスよりも GPL が「自由度が低い」ように映るのです。もちろん、こうした主張が行き着くところは、「自由度は低いより高い方がいいに決まっている」というものですが (自由であることに賛成しない人がいるでしょうか?)、これに従うと、制限の緩いライセンスが GPL よりも優れているということになります。

この手の議論は、宗教論争 (6章コミュニケーション の「宗教論争を回避する」を参照してください) になるお題のひとつです。少なくも公開されているフォーラムでは、これに参加しないようにしましょう。 GPL が他のライセンスより自由度が高いとか、低いとか、同じだとか、そういうことを証明しようとしてはいけません。そうではなくて、あなたのプロジェクトがなぜ GPL を選んだのかを強調するようにしましょう。ライセンスの認知度が高いことが理由なら、そう言えばいいのです。派生物に同じ条件を強制するのが理由なら、それも伝えましょう。しかし、GPL のやり方がコードの「自由度を高くするのか、低くするのかどうか」という議論には絶対にしないでください。「自由とは何か」というお題は複雑なものですし、「自由」という言葉が本質を隠すために使われる限り、語るに値しないものです。

この本はメーリングリストではありませんが、それでも敢えて言えば、私は「GPLはフリーなライセンスではない」という主張は全く理解できません。 GPL が課している制限は、GPL が課す以上の 制限をしてはいけない、ということだけです。この制限こそがライセンスの自由度を下げているという主張は、奴隷制度を違法化することが自由度を下げていると言っているように聞こえます。なぜなら、GPL は特定の人が奴隷を所有することを防ぐものだからです。

(おっと、あなたがこの手の議論に巻き込まれたのなら、人を怒らせるような例え話をして危険な目にあわないようにしてくださいね。)

BSDライセンスはどうなの?

かなりの数のオープンソースソフトウェアが、BSD ライセンス (または BSD スタイルのライセンス と呼ばれることもあります) で配布されています。オリジナルのBSDライセンスは、カリフォルニア大学バークレー校がUnixの実装としてリリースした Berkeley Software Distribution (BSD) のライセンスとして使われていました。このライセンス (原文は http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6 の 2.2.2 にあります) の考え方は MIT/X ライセンスと似ていますが、以下の一節だけは異なっています。

このソフトウェアの機能や、このソフトウェア自体を使っていることを言及する広告媒体には、必ず以下の謝辞を記載しなければならない。「この製品にはカリフォルニア大学バークレー校と、ローレンスバークレー研究所が開発したソフトウェアが含まれています。」

この一節こそが、オリジナルのBSDライセンスを GPL と非互換にしてしまっているばかりか、危険な先例を作ってしまっています。つまり、他の組織も似たような宣伝条項を — 「カリフォルニア大学バークレー校と、ローレンスバークレー研究所」の部分を自分の組織の名前に置き換えることで — 自分達の フリーソフトウェアに付け加えてしまいます。ソフトウェアを再配付する人達にとっては、記載しなければならない謝辞が増え続けることが負担になってしまいます。幸運なことに、このライセンスを使っていた多くのプロジェクトがこの問題に気付き、この宣伝条項を削除していました。そして1999年には、カリフォルニア大学もこの条項を削除したのです。

この結果生まれたのが、修正BSDライセンスと呼ばれるものです。これはオリジナルのBSDライセンスから宣伝条項を削除したものです。しかしながら、こうした歴史的な経緯が「BSDライセンス」という言葉をちょっと曖昧にしています。「BSDライセンス」と言ったとき、オリジナルのBSDライセンスを指すのでしょうか？それとも修正BSDライセンスを指すのでしょうか？この曖昧さから、私は MIT/X ライセンスの方が好みです。 MIT/X ライセンスとBSDライセンスは本質的には同じものですし、 MIT/X ライセンスには、こうした言葉の上での曖昧さがないからです。しかし、MIT/X ライセンスより修正BSDライセンスが好ましい理由がひとつだけあります。それは、BSDライセンスには以下の一節が含まれているからです。

書面による特別な許可なく、本ソフトウェアから派生した製品を宣伝するために <組織> の名前、または本ソフトウェアに貢献した人の名前を使用してはならない。

この条項がなければ、ソフトウェアを受け取った人が、ライセンスを与えた人(組織) の名前を使う権利があるかどうかがはっきりしませんが、そうした疑いをこの条項が払拭しています。よって、商標の管理に関心がある組織にとっては、修正BSDライセンスが MIT/X ライセンスよりも好ましいものとなります。しかし一般的には、自由主義的なライセンスだからといって、それが商標を自由に使ったり、商標の価値を弱める権利を与えることにはなりません。 — 著作権に関する法律と商標に関する法律は全く異なるものだからです。

もし修正BSDライセンスを使いたいと思ったら、雛型は http://www.opensource.org/licenses/bsd-license.php に置いてあります。

著作権の保有と譲渡

多くの人の貢献によって成り立っている、フリーなコードやドキュメントの著作権をうまく扱う方法は3つあります。ひとつめは、(私はお勧めしませんが) 著作権にまつわる問題をすべて無視してしまうことです。ふたつめは、contributor license agreement (貢献者ライセンス同意書、以下 CLA) をプロジェクトで働く人達から集め、個人が行った貢献をプロジェクトが使う権利を明示的に与えてもらうことです。ほとんどのプロジェクトは通常これで十分です。また、裁判の管轄区域によっては、 CLA は電子メールで送ることができるのも優れています。三つめは、プロジェクト (通常は非営利な法的主体) が全ての著作権を保持するために、貢献する人から著作権を実際に譲ってもらうことです。これがもっとも法的には隙のない方法ですが、貢献する人にとってはもっとも厄介です。よって、この方法を求めてくるプロジェクトはわずかです。

著作権を一ヶ所に集めたとしても、コード^[40] はフリーのままであることに注意してください。なぜなら、オープンソースライセンスは、著作権を持つ人にコードのコピーを過去に遡って独占的なコードにする権利を認めていないからです。よって、たとえ法的な主体としてのプロジェクトが突然方針を転換し、すべてのコードを制限が強いライセンスで配布し始めたとしても、そんなことはコミュニティーにとって決して問題になりません。他の開発者は単に最新のフリーなコードをコピーして新しいプロジェクトを始め、何事もなかったかのように開発は続くでしょう。そうできることを知っているからこそ、貢献する人達のほとんどは CLA へのサインや、著作権の譲渡を求められたときに協力するのです。

何も対処しない

ほとんどのプロジェクトは、貢献する人から CLA を集めたり、著作権を譲ってもらったりはしません。そのかわり、貢献する人のプロジェクトに取り入れてもらいたいという意志が、適度に明確である場合にはいつでもコードを受け入れています。

通常の状態ではこれで構いませんが、誰かが自分こそが問題となるコードの真の持ち主であり、自分たちはそのコードをオープンソースライセンスの下で配布することを認めないと主張して、著作権法違反で裁判を起こすかもしれません。たとえば、SCO グループはこれと似たようなことを Linuxカーネル開発プロジェクトに対して行いました。詳しくは、http://en.wikipedia.org/wiki/SCO-Linux_controversies を参照してください。こんなことが起きてしまうと、プロジェクトは貢献した人から正式にコードを使う権利を得ていることを証明する文書がありません。こうなると、法的な防御が難しくなるかもしれません。

貢献者ライセンス同意書(CLA)

CLA はおそらく、法的な安全性と利便性のトレードオフを解決する最良のものでしょう。 CLA は開発者が内容を記入し、プロジェクトに送付する電子的な書式が典型的なものです。多くの裁判の管轄地域では、電子メールで送付すれば十分です。安全な電子署名が必要な場合もあります。どの方法があなたのプロジェクトに合っているかを知るには、弁護士に相談してください。

多くのプロジェクトではふたつのちょっと異なる CLA を使います。ひとつは個人用、そしてもうひとつは企業用のものです。しかしどちらであっても、中心となる文言は同じです: 貢献する人(組織) はプロジェクトに "... あなたの貢献を複製したり、派生物を準備したり、公に表示したり、公に実行したり、サブライセンスするために、「半永久的で、全世界規模で、非独占的で、無償で、ロイヤリティーがなく、取り消すことができないライセンス」" を与える。というものです。繰り返しますが、どんな CLA を受け入れる場合でも弁護士に相談すべきです。しかし、あなたがこれらの文言に慣れていれば、おそらく問題はないでしょう。

CLA へのサインを、貢献する人に頼むときは、実際に著作権を譲渡するよう求めているわけではないことを必ず強調するようにしましょう。実際、多くの CLA はサインする人にこのことを念押しする文言で始まります。

これはライセンスに同意するだけの文書です。つまり、著作権を譲渡したり、あなたの貢献を他の目的に使うためにあなたの権利を変更したりしません。

以下にいくつか例を示します:

個人向けの CLA:
- http://apache.org/licenses/icla.txt
- http://code.google.com/legal/individual-cla-v1.0.html
企業向けの CLA:
- http://apache.org/licenses/cla-corporate.txt
- http://code.google.com/legal/corporate-cla-v1.0.html

著作権の譲渡

著作権の譲渡とは、貢献する人が、自分が行った貢献の著作権をプロジェクトに譲り渡すことです。これは書面を郵送するか、ファックスすることで行うのが望ましいです。

プロジェクトによっては、著作権を完全に譲渡するよう求めるところがあります。これは、すべてのコードの著作権をひとつの法的主体が持っていた方が、オープンソースライセンスの条件に違反した人を訴える場合に便利だからです。著作権を譲ってもらうときにどの程度の厳密さを求めるのかは、組織によって異なります。公開されているメーリングリストで「私はここで、このコードの著作権をプロジェクトに譲り、このコード以外のものと同じライセンスを適用させます。」と言うことと同じ効果がある、非公式な声明を集めるだけのところもあります。私が話をした弁護士のうち少なくともひとりは、これで十分だと述べています。おそらくこれは、著作権の譲渡が通常期待される状況下で行われていること、そしてプロジェクトが開発者の本当の意志を確定させようとする努力が 本物である ことを表しているからだと思われます。一方で、フリーソフトウェア財団 (FSF)は、全く逆の立場をとっています。彼らは著作権を譲渡する正式な声明文が書かれた一枚の紙切れに直接サインし、郵送 (あるいは FAX) することを求めてきます。たった一度貢献しただけでもFSFはこれを要求することがあります。また、現在、そして将来するであろう貢献に対して要求することもあります。対象となる開発者が雇われていた場合、雇用主もサインを求められます。

FSF が潔癖なのは理解できます。仮に誰かが FSF のソフトウェアを独占的なプログラムに組み込んで GPL の条件に違反した場合、FSF は裁判で争う必要が出てきます。そうした事態になったときに、 FSFは自らが持つ著作権を全く隙がない状態にしたいからです。 FSF は多くの人気があるソフトウェアの著作権を持っているので、彼らはこうした可能性が実際にあり得ることだと考えています。あなたの組織が同じように細心の注意を払うべきかは、弁護士に相談してから決めるようにしましょう。一般的には、著作権を完全に譲ってもらう理由がなければ、 CLA を使うようにします。なぜなら、皆が扱いやすいからです。

デュアルライセンスの仕組み

プロジェクトによっては、お金を稼ぐためにデュアルライセンスの仕組みを使うところがあります。これは独占的な派生物については、コードを使う権利を得るために著作権者にお金を払ってもらう一方で、オープンソースプロジェクトで使う目的ならコードをフリーのままにしておく、というものです。これは当然、単独のアプリケーションよりはライブラリのコードと相性がよい仕組みです。正確な条件は場合によって異なります。オープンソースプロジェクトで使う場合のフリーなライセンスは GNU GPL がよく使われます。なぜなら、 GPL は著作権者の許可なく独占的な製品にコードを取り込むことを既に禁止しているからですが、これと同じ効果を持つ独自のライセンスが使われることもあります。前者の例は MySQLのライセンスであり、http://www.mysql.com/company/legal/licensing/ に説明があります。後者の例は Sleepycat Software が採用しているライセンス戦略で、 http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html に説明があります。

こんな疑問があるかもしれません「GNU GPL が、制限が緩い方法でコードを利用させるように要求していたとしたら、著作権者はどうやってお金と引換えにライセンスを与えればいいの？」これに対しては「GPL の条件は、著作権者が他人に課すものです。よって、著作権者には GPL の条件を 課さずに 独占的な条件のみを課す自由もあるのです。」というのが答えになります。これについては、著作権者がソフトウェアのコピーを無限に在庫として持っていると考えるとよいでしょう。彼らはソフトウェアのコピーを一つ取り出して世に送り出すたびに、どのライセンスを付けるか、つまり GPL なのか、独占的なライセンスか、それ以外かを決めることができるのです。ライセンスを選んで決める権利は、 GPL や他のオープンソースライセンスが課しているものではありません。単に著作権に関する法律が与えたものなのです。

デュアルライセンスの魅力は、フリーソフトウェアプロジェクトに安定した収入の道を開くことです。不幸なことに、これがオープンソースプロジェクトの通常の力学を妨げてしまう可能性があります。問題なのは、コードを提供するボランティアたちが、フリーなバージョンのものと、独占的なものの、全く別なふたつのバージョンに貢献するようになることです。貢献するボランティアたちは、フリーなバージョンには喜んでコードを提供するでしょう。なぜなら、提供したコードをフリーにするのがオープンソースプロジェクトでは普通だからです。しかし、他の人が半ば独占的なやり方で利益を得るのに加担するのはおかしいと感じるかもしれません。このジレンマは、デュアルライセンスを採用した場合に、独占的なやり方で得た利益からボランティアがロイヤリティを請求することを防ぐために、著作権者が彼らのコードの著作権を自らに譲渡する契約にサインするよう求めてきたときにさらに大きくなります。こういう契約書にサインさせるプロセスは、ボランティア達に、自分が誰かを儲けさせるために動いているという事実をいやがおうでも突きつけることになります。

ボランティア全員がこの問題で悩むとは限りません。結局、提供したコードはオープンソースなバージョンにも取り込まれるわけで、それこそが彼らの関心事かもしれないからです。それにも関わらずデュアルライセンスは、著作権者がプロジェクトの他のメンバーが持っていない特別な権利を、自らに与えるものです。それゆえに、ボランティアの中にはある時点で著作権者と対立してしまう人が必ずいます。

デュアルライセンスを採用したソフトウェアを基盤にしている企業では、ボランティアの開発コミュニティーと本当の意味で平等な関係を築いているわけではないようです。彼らは小規模なバグ修正やコードを整理する修正プログラムは外部に依存するものの、難しい仕事はほとんど内部でこなしてしまうのです。たとえば、MySQL のマーケティング部門副社長の Zack Urlocker は、活発なボランティアは結局企業が雇ってしまうのが一般的だと述べています。それゆえに、MySQL そのものは GPL でライセンスされたオープンソースソフトウェアですが、開発そのものは多かれ少なかれ企業がコントロールしています。 (可能性は極めて小さいものの) 誰かが企業のソフトウェアの扱いに不満を持ってしまうと、プロジェクトが分裂してしまう可能性も孕んでいます。こうした懸念がどの程度企業の方針に影響しているのかはわかりませんが、いずれにせよ、MySQLという企業は、オープンソースの世界に留まるか、そうでないかは問題視していないようです。

特許

ソフトウェア特許は、フリーソフトウェアの世界で現在注目されている問題です。なぜなら、フリーソフトウェアのコミュニティーが防ぐことができない、現実的な唯一の脅威となっているからです。著作権と商標の問題はいつでも回避することができます。仮にあなたのコードが他の人のコードと似ていて、誰かの著作権を侵害していたとしても、あなたはその部分を書き直せばよいのです。また、誰かがあなたのプロジェクトの名前に対して商標権を持っていたとしても、最悪プロジェクトの名前を変えれば済みます。プロジェクト名の変更は一時的には不便かもしれませんが、長い目で見れば問題にならないでしょう。なぜなら、コードそれ自体はいつも通り動くからです。

しかし、特許はあるアイディアを実装することに対して一律に適用されるものです。誰がコードを書くかは関係ありませんし、どのプログラミング言語を使うかさえ関係ないのです。誰かが特許を侵害していると主張してフリーソフトウェアプロジェクトを訴えた途端、プロジェクトは特定の機能の実装をやめるか、カネと時間がかかる裁判をしなければなりません。このような裁判を起こすのは、十分な資力がある企業なのが普通です — つまり、はじめから特許を買収する資金があり、そうする傾向がある組織です — ほとんどのフリーソフトウェアプロジェクトは特許を買い取る余裕はありませんし、対象となる特許が法廷で拘束力がないと強く思っていたとしても、すぐに降伏しなければならないのです。こういう状況をはじめから防ぐには、フリーソフトウェアプロジェクトがコードを用心深く書いて、たとえ最良かつ唯一の解決策であったとしても、特許になっているアルゴリズムをあらかじめ使わないようにすることです ^[41]。

調査や事例が示す通り、これは大多数のオープンソースプログラマーだけでなく、 すべての プログラマーの多くが、ソフトウェア特許を全面的に廃止すべきだと考えています ^[42]。オープンソースプログラマーは、特に強くそう感じており、ソフトウェア特許を集めたり、強制することに強く関係しすぎているプロジェクトで働くのを拒否するかもしれません。あなたの組織がソフトウェア特許を集めているのなら、オープンソースプロジェクトに特許を適用しないこと、そして別の組織が特許違反の裁判を起こした場合の、防御の手段としてのみ特許を使っていることを取り消せないやり方で明確にしておきましょう。これが唯一の正しい手段ではありません。オープンソースプロジェクト同士が連携することもよいことです。 ^[43]

不幸なことですが、法的な防御を目的として特許を集めるのは合理的な行動です。現在の特許の仕組みはその本質上、少なくともアメリカでは軍拡競争です。つまり、競争相手がたくさんの特許を取得した場合、最良の防御方法は、特許違反で訴えられたときに逆に訴え返せるように、多くの特許を取得することです — こうしておけば、お互いがお金を払わないで済むよう、双方が机についてクロスライセンスの取引をするのが普通です。もちろん知的財産権専門の法律家には払わないといけませんが。

しかし、ソフトウェア特許がフリーソフトウェアに及ぼす害は、コードの開発に及ぼすものよりも陰湿なものです。ソフトウェア特許はファームウェアの設計者達に秘密主義の雰囲気を助長しています。彼らは自分たちが設計したインターフェイスの詳細を公にすると、特許違反で訴えるためにあら探しをしている競争相手を技術的に助けてしまうのではないかと心配しているのです。これは単なる机上の空論ではありません。たとえばビデオカード業界で明らかに起きてきたことなのです。多くのビデオカードメーカーは、高速に動くオープンソースなデバイスドライバを作るのに必要なプログラミング仕様を公にしてきませんでした。よって、そうしたカードの機能を完全にサポートするフリーなオペレーティングシステムを作るのが不可能になっているのです。なぜメーカーはそんなことをするのでしょうか？ソフトウェアをサポートすることに 反対すること は理にかなっていません。なぜなら、多くのオペレーティングシステムで動くことが、ビデオカードの売り上げにつながるからです。しかし、あるときは故意に、あるときは偶然、こうしたメーカーすべてがデザインルームの裏で互いに特許を侵害していることが明らかになってきています。よって、メーカーは敢えて完全なインターフェイス仕様を公開しないのです。公開することで、特許を侵害していることが競争相手にわかりやすくなってしまうからです。 (もちろん、こういった性質のことは一次情報源から許可を得て書けることではありません。私はこのことを個人的なやりとりで知りました。)

フリーソフトウェアライセンスの中には、ソフトウェア特許と戦ったり、もしくは拒絶するための特別な文言を入れているものがあります。たとえば、GNU GPL は次のような文言を含めています。

    7. 特許侵害あるいはその他の理由(特許関係に限らない)から、裁判所の判決あるいは
       申し立ての結果としてあなたに(裁判所命令や契約などにより)このライセンスの条
       件と矛盾する制約が課された場合でも、あなたがこの契約書の条件を免除されるわ
       けではない。もしこの契約書の下であなたに課せられた責任と他の関連する責任を
       同時に満たすような形で頒布できないならば、結果としてあなたは『プログラム』
       を頒布することが全くできないということである。例えば特許ライセンスが、あな
       たから直接間接を問わずコピーを受け取った人が誰でも『プログラム』を使用料無
       料で再頒布することを認めていない場合、あなたがその制約とこの契約書を両方と
       も満たすには『プログラム』の頒布を完全に中止するしかないだろう。 

       [...]

       特許やその他の財産権を侵害したり、そのような権利の主張の効力に異議を唱えた
       りするようあなたを誘惑することがこの節の目的ではない。この節には、人々によ
       ってライセンス慣行として実現されてきた、フリーソフトウェア頒布のシステムの
       完全性を護るという目的しかない。多くの人々が、フリーソフトウェアの頒布シス
       テムが首尾一貫して適用されているという信頼に基づき、このシステムを通じて頒
       布される多様なソフトウェアに寛大な貢献をしてきたのは事実であるが、人がどの
       ようなシステムを通じてソフトウェアを頒布したいと思うかはあくまでも作者/寄与
       者次第であり、あなたが選択を押しつけることはできない。
       ^[44]

Apache License バージョン 2.0 (http://www.apache.org/licenses/LICENSE-2.0) も特許に反対する条件を含めています。まず第一に、このライセンスでコードを配布する人は、自分が保有している特許で、配布するコードに適用できるものについては、ロイヤリティーがかからない特許ライセンスを与えなければなりません。二つめに、配布したコードを根拠に特許侵害の訴えを起こした時点でその特許ライセンスを自動的に終了させることで、そうした人を巧みに排除しています。

    3. 特許ライセンスの付与

       本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物
       を作成したり、使用したり、販売したり、販売用に提供したり、インポートし
       たり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料
       無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与
       します。ただし、このようなライセンスは、コントリビューターによってライ
       センス可能な特許申請のうち、当該コントリビューターのコントリビューショ
       ンを単独または該当する成果物と組み合わせて用いることで必然的に侵害され
       るものにのみ適用されます。あなたが誰かに対し、交差請求や反訴を含めて、
       成果物あるいは成果物に組み込まれたコントリビューションが直接または間接
       的な特許侵害に当たるとして特許訴訟を起こした場合、本ライセンスに基づい
       てあなたに付与された特許ライセンスは、そうした訴訟が正式に起こされた時
       点で終了するものとします。
       ^[45]

このように、フリーソフトウェアライセンスに特許から防御するための仕掛けをしておくのは、法的にも政治的にも役に立つものです。しかし最終的には、フリーソフトウェアに対する特許違反裁判の脅威がもたらす、萎縮的効果を払拭するには不十分です。それができる唯一の手段は、国際的な特許法の本質や解釈を変更することです。この問題について、そしてこの問題と人々がどう戦ってきたのかをさらに知るには、 http://www.nosoftwarepatents.com/ を訪れるとよいでしょう。 Wikipedia の記事 (http://en.wikipedia.org/wiki/Software_patent) にも、ソフトウェア特許に関する有益な情報が多くあります。私自身も、ソフトウェア特許に反対する議論をまとめたエントリをブログに載せています。 http://www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad-idea/

さらなる情報源

この章は、フリーソフトウェアに関するライセンス問題をさわりだけ紹介したに過ぎません。この章の説明が、オープンソースプロジェクトをはじめるための十分な情報源になることを願っていますが、真面目にライセンス問題を調べようとすると、すぐに紙面が尽きてしまうでしょう。以下には、オープンソースライセンスに関するさらなる情報源を一覧で示します。

Understanding Open Source and Free Software Licensing Andrew M. St. Laurent著。出版: O'Reilly Media、2004年8月初版。ISBN: 0-596-00581-4.
この本は、オープンソースライセンスに関する複雑な問題全般を余すところなく記した本です。詳細は http://www.oreilly.com/catalog/osfreesoft/ を参照してください。
Make Your Open Source Software GPL-Compatible. Or Else. David A. Wheeler作。 http://www.dwheeler.com/essays/gpl-compatible.html.
これは、たとえあなたがGPLを採用しない場合でも、なぜGPLと互換性があるライセンスを使うことが重要なのかについて、詳細にうまく書かれた記事です。この記事は、他のライセンスに関する疑問についても触れており、密度の濃い優れたリンク集も提供しています。
http://creativecommons.org/
クリエイティブコモンズは、これまでの伝統的な著作権が推し進めてきたものよりも、多様、かつ柔軟で、リベラルな著作権を広めている組織です。彼らはソフトウェア向けのライセンスだけでなく、文章、芸術、音楽向けのライセンスも提供しています。これらのライセンスは、使いやすいライセンス選択システムによって全てが使えるようになっています。これらのライセンスの中には、コピーレフトのものもありますし、コピーレフトではありませんが、フリーなものもあります。また、伝統的な著作権の仕組みを持つライセンスでありながら、その制限をいくらか緩めただけのものもあります。クリエイティブコモンズのウェブサイトは、ライセンスがどんなものなのかを極めて明快に説明しています。フリーソフトウェア運動が持つ、哲学的で幅広い意味合いを示しているサイトを私がひとつあげるとすれば、このサイトを選ぶでしょう。

^[37]フランス語で「自由な」という意味。

^[38] かつて、ライセンスに関する統計情報が Freecode.com にありました。まだ Freshmeat.net と呼ばれていた頃のものです。しかし 2008 年に彼らはプロジェクトを自由にタグ付けできるように切り替えました。その結果、信頼できるライセンス統計を取得するのが難しくなりました。 http://help.freecode.com/discussions/questions/187-where-did-the-license-statistics-page-go に、統計情報を取得する方法についての議論があります。

^[39] このライセンスと名前の歴史はちょっと複雑です。このライセンスのはじめのバージョンは Affero, Inc. によってリリースされ、 GPL バージョン2 (GPLv2) を基にしたものでした。これは通常 AGPL と呼ばれていました。のちに FSF はこのライセンスの考え方を採用することを決めましたが、それより前に GPL のバージョン3 (GPLv3) をリリースしていたのです。よって、FSF は AGPL に基づいて自分たちのライセンスを作り、それを "GNU AGPL" と呼んだのです。現在、Affero, Inc. が作った古いライセンスは事実上推奨されていません。もしあなたが Affero のような条件を望むなら、GNU AGPL を使うべきです。曖昧にならないように、このライセンスを "AGPLv3" とか、"GNU AGPL"、もしくは最大限正確を期すために "GNU AGPLv3" と呼びます。

^[40]ここから私は、「コード」という言葉を「プログラムとドキュメント両方」という意味で使います。

^[41] サン・マイクロシステムズと IBM は、この問題に対して少なくとも別の方向性を打ち出しています。彼らは大量のソフトウェア特許 — それぞれ 1600 と 500 個 — をオープンソースコミュニティーが使えるようにフリーにしました。私は法律家ではないので、これらの特許が付与されたことがどれくらい有用なのかを評価できません。しかしたとえこれらがすべて重要な特許であり、特許を付与する条件をオープンソースプロジェクトが使うために本当にフリーなものにしたとしても、それは氷山の一角に過ぎないでしょう。

^[42] 調査の一例として、以下を参照してください。 http://groups.csail.mit.edu/mac/projects/lpf/Whatsnew/survey.html

^[43] たとえば RedHat は、オープンソースプロジェクトは特許に違反しないことを約束しています。 http://www.redhat.com/legal/patent_policy.html を参照してください。

^[44] GNU General Public License バージョン 2 のもの。 http://www.opensource.jp/gpl/gpl.ja.html.euc-jp より引用。

^[45] オープンソースグループ・ジャパン wiki より引用。 http://sourceforge.jp/projects/opensource/wiki/licenses%2FApache_License_2.0

付録A Canned Hosting Sites

These are all the credible, well-established canned hosting sites that I know about as of early 2013. As noted in 「ツールが一通り揃ったホスティングサイト」, each site imposes its own particular restrictions in exchange for the convenience of hosting your open source project's collaboration infrastructure: each one supports only particular version control systems, bug trackers, etc. Again, en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities has a good comparison of canned hosting sites.

This is not a complete list (the Wikipedia page above comes closer). Instead, this appendix describes the canned hosting sites that I see being used most often by open source projects. I include both proprietary sites, i.e., sites for which the source code behind the service is proprietary, and open source ones, i.e., those for which full source code is available under a free license. In both cases the services themselves are zero-cost to open source projects; however, the open source sites enable others to replicate the service on their own servers (though in practice it would take some effort to do so).

In general, new open source projects should choose one of the sites below, unless they have some special reason to use a different site (e.g., Debian GNU/Linux projects might prefer alioth.debian.org, and Free Software Foundation projects might choose savannah.gnu.org).

GitHub — http://github.com/

TBD (mention the interesting visibility-not-oss-per-se requirement of github)

Google Code Hosting — http://code.google.com/hosting/

TBD

SourceForge — http://sourceforge.net/

TBD

Launchpad.net — https://launchpad.net/

TBD

Gitorious — http://gitorious.org/

TBD

fooo — http://fooo.com/

TBD

fooo — http://fooo.com/

TBD

TBD — http://example.com/

TBD

付録B フリーなバージョン管理システム

2007 年半ばの時点で私が把握しているオープンソースのバージョン管理システムは、これらがすべてです (その後、2011 年後半にいくつか追加しました)。このうち、私が常用しているのは Subversion と Git で、それ以外に Bazaar と CVS もよく使っています。その他の大半のシステムについては、使用経験がないに等しいものばかりです。ここにあげた情報は、それぞれのシステムのウェブサイトを参考にしたものです。 http://en.wikipedia.org/wiki/List_of_revision_control_software もご覧ください。

Subversion — http://subversion.tigris.org/

Subversion が書かれた最大の目的は、CVS にとってかわるシステムを作ることです。 CVS とほぼ同じような方法でバージョン管理を行いますが、 CVS ユーザーがしばしば悩まされていた問題点や機能不備などを解消するようにしています。 Subversion の目標のひとつは、CVS になじみのある人たちが比較的スムーズに Subversion に移行できるようにすることです。 Subverion の機能についてここで事細かに語ることは控えます。詳細はウェブサイトをご覧ください。 [注: 私は Subversion の開発に参加しています。また、この一覧の中で私が常用しているシステムは Subversion だけです。]

GIT — http://git.or.cz/

GIT は、Linus Torvalds が Linux カーネルのソースツリーを管理するためにはじめたプロジェクトです。最初のうちはカーネルの開発で必要となる機能に特化したものでしたが、今では機能も増え、Linux カーネル以外のプロジェクトでも用いられるようになっています。ホームページでの説明によると、GIT は「……巨大なプロジェクトを高速かつ効率的に管理するように設計されており、主に各種オープンソースプロジェクトで使用されています。中でも有名なのは Linux カーネルです。 Git は分散型ソースコード管理ツールの一種で、GNU Arch や Monotone (あるいは独占的ソフトウェア界での BitKeeper) と似ています。 Git のすべての作業ディレクトリは、それ単体で完全なリビジョン追跡機能を持つリポジトリであり、ネットワークアクセスや中央サーバがなくても機能します」。

Mercurial — http://www.selenic.com/mercurial/

Mercurial は分散型のバージョン管理システムで、 "ファイルやチェンジセットの完全なクロスインデクシング、ネットワーク帯域や CPU に優しい同期プロトコル (HTTP および SSH)、任意の開発ブランチ間でのマージ、単体で動作するウェブインターフェイスの同梱、 UNIX でも MacOS X でも Windows でも同じように動作する" といった機能を持っています (この機能一覧は、Mercurial のウェブサイトの内容をまとめたものです)。

Bazaar — http://bazaar-vcs.org/

Bazaar (bzr) は使いやすさと柔軟なデータモデルを追及した分散型のバージョン管理システムです。これは GNU の公式プロジェクトであり、フリーソフトウェアプロジェクトをホスティングしている Launchpad.net で採用されています。Bazaar は完全に分散したバージョン管理を実現します。つまり、すべての仕事をブランチでこなします。開発者は通常ブランチの変更履歴のコピーを持ちます。それぞれのブランチは、分散型のやり方で互いをマージできますが、Bazaar は中央管理型のやり方も使えるように設定できます。 Bazaar は GNU Arch の派生プロジェクトとして出発しましたが、のちに1から書き直され、GNU Arch とは直接の関連がなくなっています。

SVK — http://svk.elixus.org/

Subversion 上で構築されているシステムではあるものの、SVK はおそらく Subversion よりも以下にあげる分散管理型のシステムに似ています。 SVK は、分散型の開発やローカルでのコミットをサポートしています。また変更点のマージ機能も洗練されており、 SVK 以外のバージョン管理システムのツリーを複製する機能もあります。詳細はウェブサイトをご覧ください。

Veracity — http://veracity-scm.com/

Veracity は分散型のバージョン管理システムです。 Git や Mercurial、Bazaar などと同様にすべての開発者が完全なローカルリポジトリを持ち、必要に応じてリポジトリ間で変更のプッシュやプルを行います。コマンドについてはこれらのシステムとほぼ同じですが、Veracity はファイルのバージョン管理以外に分散型のバグ追跡データベースも持っています。このデータベースも、ファイルとともにバージョン管理されます。言い換えると、Veracity がやろうとしていることは、開発に必要となるすべての成果物を (ソースコードツリーだけでなく、バグレポートも含めて) バージョン管理システムの配下に置くということです。かなり野心的な考えです。残念ながら私はまだ使う機会がないのですが、使ったことがある人の感想をぜひ聞いてみたいと思います。Veracity は主に SourceGear, Inc が開発しています。同社は長い歴史を持ち、バージョン管理やソフトウェア構成管理などにかかわっています。

よく似たシステムである Fossil も参照ください。

Fossil — http://www.fossil-scm.org/

Fossil が Veracity と似ている点は、どちらも分散型バージョン管理システムであり、さらにどちらも単にコードだけをバージョン管理するわけではないというところです。 Fossil は、バグ追跡データベースや分散型の Wiki、そして分散型のブログなどもバージョン管理します。その他の機能としてはデフォルトの "autosync" モードがあり、このモードは、衝突しない変更はすべて自動的にマージします (つまり、Fossil は中央管理型の環境でもそうでない環境でも動かせます。他の分散型システムも理屈の上ではそのとおりなのですが、 Fossil はさらにもう一歩進んで、実際に中央管理型のワークフローに対応しているのです)。ウェブインターフェイスも同梱されており、コードリポジトリをブラウザで閲覧することもできます。

Fossil を主に開発しているのは Dr. Richard Hipp です。おそらく SQLite データベースエンジンの作者としてのほうがよく知られていることでしょう。 Veracity と同様、私は Fossil も使ったことがありません。使ったことがある人は、ぜひ感想を聞かせてください。

CVS — http://www.nongnu.org/cvs/

CVS は長い歴史を持っており、多くの開発者にとっておなじみのものです。公開された当時は革命的な存在でした。オープンソースのバージョン管理システムとしては初めて (少なくとも私の知る限り) 離れた場所にいる開発者達によるネットワーク経由のアクセスに対応し、また初めて匿名での読み込み専用チェックアウトに対応しました。これにより、新しい開発者が容易にプロジェクトに参加できるようになったのです。 CVS がバージョン管理するのはファイルのみであり、ディレクトリのバージョンは管理しません。ブランチやタグの機能を持っており、クライアント側でも高速に動作しますが、巨大なファイルやバイナリファイルはうまく扱うことができません。また、アトミックなコミットにも対応していません。 [注: 私はかつて、約 5 年にわたって精力的に CVS の開発に携わってきました。その後、CVS にかわるシステムとしての Subversion プロジェクトの立ち上げにかかわりました。]

Darcs — http://darcs.net/

「David's Advanced Revision Control System は、 CVS のかわりとなるソフトウェアのひとつです。Haskell で書かれており、 Linux や MacOS X、FreeBSD、OpenBSD そして Microsoft Windows で動作します。Darcs には cgi スクリプトも含まれており、これを用いてリポジトリの中身を見ることができます。

Arch — http://www.gnu.org/software/gnu-arch/

GNU Arch は、分散型の開発と中央管理型の開発の両方に対応しています。開発者は、変更内容を「アーカイブ」にコミットします。アーカイブはローカルに持つこともできます。また、変更内容を他のアーカイブとの間でやりとりし、アーカイブの管理者がそれを適用することもできます。その方式からも想像できるように、Arch のマージ機能は CVS のものより洗練されています。Arch はまた、コミット権を持たない人でも簡単にアーカイブのブランチを作れるようになっています。ここで紹介したのは概要にすぎません。詳細は Arch のウェブページをご覧ください。

monotone — http://www.venge.net/monotone/

「monotone は、フリーな分散型バージョン管理システムです。単一のファイルからなるシンプルかつトランザクショナルな形式でデータを格納し、ネットワークから切断されていても完全に機能します。また、効率的なピアツーピア同期プロトコルを持っています。履歴を考慮したマージ、軽量なブランチ作成、コードレビュー、サードパーティによるテストなどの機能があります。バージョンの命名は暗号化されており、クライアント側で RSA 証明書を使用します。国際化対応も十分にされており、別のソフトウェアに依存することもありません。 linux や solaris、OSX、windows で動作し、GNU GPL のもとで公開されています」

Codeville — http://codeville.org/

「なぜいまだにそんなバージョン管理システムを使ってるんですか? ほかのバージョン管理システムってみんな、ブランチをマージするときの衝突を起こさないように細心の注意を払わなければならないじゃないですか。 Codeville ならそんな心配は無用。いつでもどのリポジトリからでもアップデート可能で、無駄なマージは発生しません」

「Codeville は、それぞれの変更に対して ID を作成します。そして、各ファイルに対して行われたすべての変更の一覧とファイル内の各行がどの変更で更新されたのかを覚えておきます。衝突が発生した場合は、お互いが相手側の変更を適用済みかどうかを調べ、変更済みであった場合は自動的にそちらが優先されます。自動的にマージできない衝突があった場合は、Codeville の挙動は CVS とほぼ同じものとなります」

Vesta — http://www.vestasys.org/

「Vesta はポータブルな SCM [ソフトウェア設定管理] システムで、小規模 (ソースコード 10,000 行未満) から大規模 (ソースコード 10,000,000 行以上) まであらゆる規模のソフトウェアシステムの開発をサポートします」

「Vesta は円熟したシステムです。Compaq/Digital Systems Research Center における 10 年以上の研究開発の結果として生まれたものであり、 2 年半以上にわたって Compaq の Alpha マイクロプロセッサグループが実際に使用しています。 Alpha グループには 150 人以上のアクティブな開発者がおり、彼らは何千マイルも離れた 2 拠点 (アメリカの東海岸と西海岸) で働いています。彼らが Vesta を使って管理しているのは、 130 MB におよぶソースデータとビルドで、そこから生成される派生データは 1.5 GB になります。ビルド作業は東海岸の拠点で行われ、平均して 10-15 GB の派生データを生成しますが、これらもすべて Vesta で管理しています。 Vesta はソフトウェア開発のために設計されたものですが、 Alpha グループはこのシステムがハードウェア開発にも使えることを示しました。ハードウェア記述言語ファイルを Vesta のソースコード管理機構にチェックインし、 Vesta のビルダーを使ってシミュレータやその他の派生オブジェクトをビルドしたのです。かつての Alpha グループのメンバーは今は Intel にいますが、今もなお新しいマイクロプロセッサのプロジェクトで Vesta を使い続けています」

Aegis — http://aegis.sourceforge.net/

「Aegis は、トランザクションベースのソフトウェア構成管理システムです。 Aegis が提供するフレームワークを使用すると、開発者チームの各メンバーがそれぞれ独自にプログラムに変更を加えることができます。 Aegis が各変更点を統合してプログラムのマスターソースに書き戻しますが、その際に面倒な作業が極力起こらないようにします」

CVSNT — http://cvsnt.org/

「CVSNT は、高機能なマルチプラットフォーム対応バージョン管理システムです。業界標準の CVS プロトコルをサポートしているだけでなく、さまざまな機能があります。 CVSNT はオープンソースで、GNU Geleral Public License で公開されているフリーソフトウェアです」機能一覧には以下のような内容が書かれています。すべての標準 CVS プロトコルによる認証だけでなく Windows 固有の SSPI や Active Directory による認証、 sserver あるいは暗号化 SSPI による安全な転送のサポート、クロスプラットフォーム (Windows でも Unix 環境でも動作する)、 Win32 システムと完全に統合した NT バージョン、マージポイント処理 (タグを打たなくてもマージができる)、活発に開発が進行中です。

META-CVS — http://common-lisp.net/project/meta-cvs/

「Meta-CVS は CVS を基にしてつくられたバージョン管理システムです。ネットワーク対応を含む CVS のほとんどの機能を保持しているだけでなく、 CVS よりも機能的で簡単に使用できます」 META-CVS のウェブサイトの機能一覧には、次のような機能が記載されています。ディレクトリ構造のバージョン管理、より改善されたファイルタイプ処理、シンプルでユーザーに優しいブランチ/マージ処理、シンボリックリンクのサポート、バージョン管理データへのプロパティリストの付加、より改善されたサードパーティデータの取り込み処理、そして CVS からの移行が容易であるということです。

OpenCM — http://www.opencm.org/

「OpenCM は、安全で高品質な CVS 代替システムとして設計されています。主要な機能については機能一覧ページに掲載されています。CVS ほど『機能満載』なわけではありませんが、CVS にはない便利な機能をいくつか持っています。簡単にまとめると、OpenCM はファイルのリネームに対応しており、また暗号化した認証処理やアクセス制御、そして高機能なブランチ処理にも対応しています」

PRCS — http://prcs.sourceforge.net/

「PRCS は Project Revision Control System の略で、(CVS のように) ファイルやディレクトリのバージョンを管理するツール群のフロントエンドとなります。その目的は SCCS や RCS、CVS と同じですが、(少なくとも作者によると) それらのシステムよりもずっとシンプルだということです」

ArX — http://www.nongnu.org/arx/

ArX は分散型のバージョン管理システムです。ブランチやマージ機能、暗号化したデータの整合性の検証機能があります。また、任意の HTTP サーバ上で容易にアーカイブを公開できる機能もあります。

SourceJammer — http://www.sourcejammer.org/

「SourceJammer は、Java で書かれたソース管理/バージョン管理システムです。サーバサイドのコンポーネントとクライアントサイドのコンポーネントで構成されており、サーバサイドではファイルやバージョン履歴の管理、チェックインやチェックアウトなどの処理、そしてその他のコマンドを扱います。クライアントサイドでは、サーバからのリクエストを受けてファイルシステム上のファイルを管理します」

FastCST — http://www.zedshaw.com/projects/fastcst/index.html

「ファイル単位のリビジョンではなくチェンジセットを扱い、中央管理ではなく分散型で処理を行う『モダンな』システムです。メールアカウントさえあれば FastCST を使うことができます。大規模な分散開発に必要なのは、FTP サーバあるいは HTTP サーバのみです。あるいは、組み込みの 'serve' コマンドを使って直接管理することもできます。すべてのチェンジセットは完全に一意であり、大量のメタデータを含んでいます。そのため、チェンジセットをわざわざ適用してみなくても、不要なものを判断することができます。マージ処理は、別のチェンジセットにマージするのではなく、マージされたチェンジセットを現在のディレクトリの内容と比較することで行います」

Superversion — http://www.superversion.org/

「Superversion は、マルチユーザー対応の分散型バージョン管理システムで、チェンジセットにもとづいた処理を行います。商用製品に取って代わるオープンソースの選択肢として、商用製品なみ (あるいはそれ以上) の使いやすさと同等の機能を持つことを目指しています。実際のところ、直感的で使いやすい操作性というのは Superversion の開発が始まった当初から最も重視してきたものです」

付録C フリーなバグ追跡システム

プロジェクトでどのバグ追跡システムを採用していても、文句を言う開発者は必ずいます。この傾向は他の標準的な開発ツールよりも強いようです。私は、バグ追跡システムが使う人の目に見えることと、ユーザーと開発者がやりとりを双方向に行うツールであることから、 (時間があれば)改善したいと思う点が想像しやすいこと、そしてそれを口に出して説明しやすいのが理由だと思っています。こうした不平不満は話半分に聞いておきましょう — 以下に示すバグ追跡システムの多くはとても優れたソフトウェアです。

以下の一覧では、バグ追跡システムが追跡するものとして「問題」という用語を使います。しかし、それぞれのシステムは、これに対応するものとして「欠陥」や「バグ」あるいは「チケット」などの独自の用語を使うこともあることに注意してください。

注意: この調査が最初に行われたのは 2005 年であり、それ以降にもいくつか新たにオープンソースのバグ追跡システムが作られています。 2011 年後半に以下の記述を多少更新しましたが、調査自体の全体的な更新はできていません。 Wikipedia での問題追跡システムの比較や DMOZ によるバグ追跡システムの調査、 Ask Slashdot: How do you track bugs for personal software projects? の記事 (とコメント)、あるいは WebResourcesDepot による一覧も参照ください。

Redmine — http://www.redmine.org/

Redmine は (2011 年の時点で)、比較的最近に誕生した非常に洗練されたプロジェクト管理システムです。単なるバグ追跡システムにとどまらず、 Wiki やディスカッション用フォーラムなどの機能も備えています。とはいえ、その主要な機能はやはりバグ管理でしょう。極めて直感的なウェブベースのユーザーインターフェイス、柔軟な設定 (複数プロジェクトの管理やロールベースのアクセス制御、カスタムフィールドなど)、ガントチャート、スケジュール調整、双方向のメールでのやりとりなどの機能を持っています。新しいプロジェクトを立ち上げたときに何かバグ追跡システムが必要なら、 Redmine を選ぶとよいでしょう。

Bugzilla — http://www.bugzilla.org/

Bugzilla はとても人気があり、活発に開発が行われていて、ユーザーをとても満足させるソフトウェアのようです。私はこれを改造したものを４年ほど使っていますが、満足しています。 Bugzilla は挙動を大きく変えられるわけではありませんが、奇妙なことに、それがウリの一つでもあります。つまり、Bugzilla をインストールすると、どこに行っても挙動や見た目が同じなのです。これは多くの開発者がそのインターフェイスに既に慣れていて、自分たちが親しんだ世界にいると感じるということです。

GNATS — http://www.gnu.org/software/gnats/

GNU GNATS は、もっとも古いオープンソースなバグ追跡システムのうちのひとつであり、広く使われています。もっとも大きな強みは、インターフェイスが多様なこと (GNATS はウェブブラウザからだけでなく、電子メールやコマンドライン経由でも使えます) と、問題の情報がテキストで格納されることです。全ての問題がテキストファイルでディスクに格納されるということは、 (統計レポートの生成のような) データを走査したり解釈する独自のツールを書くのが簡単になるということです。また、GNATS は電子メールを自動的にいろいろな手段で取り込むことができ、電子メールのヘッダの形式に応じて、適切な問題に追加することができます。これにより、ユーザーと開発者の対話がとても容易になります。

RequestTracker (RT) — http://www.bestpractical.com/rt/

RT のウェブサイトはその概要として「企業レベルでも使えるチケットシステムで、コミュニティーのユーザーが出してくる仕事や問題、要望を知的に、かつ効率的に管理できます」と述べています。 RT は極めて洗練されたウェブインターフェイスを持ち、多くの環境にインストールできるようです。インターフェイスはちょっと見た目複雑ですが、慣れれば気にならなくなるでしょう。 RT は GNU GPL でライセンスされています。(いくつか理由があって、 RT のウェブサイトではこのことを大っぴらには言っていないようです)

Trac — http://trac.edgewall.com/

Trac はバグ追跡システム以上の役割を果たします。つまり、 Trac はバグ追跡システムと wiki が統合されたものです。問題やファイル、バージョン管理の差分、そして wiki のページを結び付けながら wiki を使います。 Trac を使えるようにするための作業は簡単で、Subversion と統合されています。 (付録B フリーなバージョン管理システム も参照してください)

Roundup — http://roundup.sourceforge.net/

Roundup はインストールがとても簡単 (必要なのはPython 2.1 以降だけです) で、使うのも容易です。ウェブ、電子メール、コマンドラインのインターフェイスを持っています。問題のデータの雛形と、ウェブのインターフェイスは変えられますし、 (保留中 → 診断済み → 修正済み → 完了のような) 問題の状態遷移も変えられます。

Mantis — http://www.mantisbt.org/

Mantis は、ウェブベースのバグ追跡システムで、PHPで書かれています。そして、問題を格納する場所として、MySQL データベースを使います。 Mantis には、ユーザーが期待する機能が備わっています。個人的には、ウェブインターフェイスが綺麗で、直感的で、見やすいと思っています。

Flyspray — http://www.flyspray.org/

Flyspray は、PHP で書かれたウェブベースのバグ追跡システムです。 Flyspray のウェブページには「複雑でない」と説明されていて、次のような機能が含まれています: 複数のデータベースシステム (現状は MySQL と PostgreSQL)のサポート、複数プロジェクトのサポート、タスクを「見張る」機能、変更があれば (Jabber または電子メールで) 通知する機能、タスクの履歴を包括的に見る機能、CSSによる外見の変更機能、ファイル添付機能、高度な(使いやすい)検索機能、RSS/Atom フィード配信機能、 wiki とプレーンテキストによる入力機能、投票機能、タスクの依存グラフを表示する機能

Scarab — http://scarab.tigris.org/

Scarab は多くの動作を変更でき、必要な機能がすべて揃ったバグ追跡システムで、他のバグ追跡システムが提供している機能を多かれ少なかれ統合しています: つまり、データ入力、問い合わせ、レポート、関心がある人々への通知、コメントの収集、問題の依存グラフを表示する機能があります。

Scarab は、ウェブ上の管理ページで動作を変更することができます。複数の「モジュール(プロジェクト)」をひとつの Scarab で管理できます。ひとつのモジュールで、問題の種類 (欠陥、機能追加、タスク、サポート要望など) を新しく作ることができ、それに任意の属性を追加できます。こうすることで、プロジェクトの特定の要求にバグ追跡システムを適応させることができます。

2004 年の後半には、バージョン 1.0 のリリースが間近でした。

Debian Bug Tracking System (DBTS) — http://www.chiark.greenend.org.uk/~ian/debbugs/

Debian バグ追跡システム (DBTS) は、問題の入力と管理すべてを電子メール経由で行うところが独特です。つまり、すべての問題には専用の電子メールアドレスが割り当てられます。 DBTS は大規模化してもとてもうまくいきます。たとえば、http://bugs.debian.org/ には 277,741件のバグが登録されています^[46]。

やりとりは普通の電子メールクライアントで行います。つまり、ほとんどの人に馴染みがあり、簡単に使える環境で行うということです。 DBTS はたくさんの量の報告を素早く整理し、応答しなければならない状況下で優れています。もちろん、欠点もあります。開発者は電子メールのコマンドシステムを学ぶのに時間を使わなければいけませんし、ユーザーは、どんな情報を書くべきかを選ぶガイドとなるウェブ上のフォームなしでバグレポートを書かなければなりません。 Emacs 向けの debbugs-el パッケージや、 reportbug コマンドのような、ユーザーによりよいバグレポートを送ってもらうためのツールも利用できます。しかし、ほとんどのユーザーはこれらのツールを使いません。彼らは電子メールを手動で書くだけですし、プロジェクトのバグ報告に関するガイドラインに従う人もいれば、従わない人もいるからです。

DBTS は問題を参照したり、検索する目的であれば、ブラウザで見ることができますが、読み取り専用になっています。

Trouble-Ticket Trackers

ここに挙げる一連のソフトは、ソフトウェアのバグを追跡することよりは、ヘルプデスクにあがってきた報告を追跡することを重視しています。普通のバグ追跡システムの方が多分うまくいくでしょう。しかし、これらは完全を期すために挙げておきます。また、ひょっとしたら、伝統的なバグ追跡システムよりはこうしたシステムの方がよく合う、風変わりなプロジェクトがあるかもしれないからです。

WebCall — http://myrapid.com/webcall/

Bluetail Ticket Tracker (BTT) — http://btt.sourceforge.net/

BTT は、トラブルをチケットとして管理するシステムと、バグ追跡システムの中間に位置するものです。 BTT は、オープンソースのバグ追跡システムの中では、幾分変わったプライバシー機能を提供します。つまり、 BTT 内部のユーザーはスタッフ、友達、顧客、匿名ユーザーに分類され、データは多かれ少なかれその分類に応じて表示されます。電子メールとの統合や、コマンドラインインターフェイス、そして電子メールをチケットに変換する仕組みも備えています。また、チケットとは関係ない情報、たとえば内部文書や FAQ を管理する仕組みもあります。

^[46]この数は原著出版当時(2005年)のものと思われる。2009年3月現在では、登録されているバグの数は51万件を超えている

付録D なんで自転車置場の色まで気にしなきゃならないの？

別にそんな必要はありません。だって、そんなのどうでもいいことじゃないですか。それに、もっとマシな時間の使い方もあるでしょ？

Poul-Henning Kamp による、かの有名な "bikeshed" メール (その一部を 6章コミュニケーション で取り上げました) は、集団での議論が陥りがちな罠について非常にうまく説明した論考です。彼の承諾を得て、ここにそれを掲載します。原文の URL は http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers です。リンクしやすいように、bikeshed.com を示してもよいでしょう。

Subject: A bike shed (any colour will do) on greener grass...
From: Poul-Henning Kamp <phk@freebsd.org>
Date: Sat, 02 Oct 1999 16:14:10 +0200
Message-ID: <18238.938873650@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Bcc: Blind Distribution List: ;
MIME-Version: 1.0



[committers と hackers にも bcc しておいた]


この前送ったパンフレットはよく受け取ってもらえたし、また別のを送っても
いいかなって思ってた。で、今日はその時間と気力があったんで。


この手の話題をどこに送ればいいのかちょっと迷ったけれど、結局
committers と hackers にも bcc することにした。たぶんこれでよかったん
だろう。実は私は hackers を購読していないんだが、それについてはまた後
で説明する。


このメールの発端となったのは「sleep(1) で小数点以下の秒を使えるように
すべき」というスレッドだ。こいつは最近私たちの生活を脅かし続けてきた。
おそらく数週間ほど。面倒なのできちんと調べてないけどね。


「そんなスレッドあったかなぁ」と思ったみなさん、あなたたちは幸せものだ。


炎上のきっかけとなったのは「sleep(1) に非整数の引数を渡したときにも正
しく動作するようにしよう」という提案だった。ここではそれ以上のことは言
わない。ほんの些細な提案のためにあのスレッドで散々騒がれ続けてたから、
もうみんな十分に知りすぎていることだろう。そのおかげで、ほんとうに重要
な「問題」たちがかすんでしまってるよ。


この sleep(1) の話は、FreeBSD が始まって以来最もわかりやすい「自転車置場
の議論」の例といえるだろう。あの提案はとてもよく考えられたものだった
し、OpenBSD や NetBSD との互換性を向上させるものでもあった。そして、こ
れまでに書かれてきたコードとの互換性もまったく損なわないものだったんだ。


なのに、反論や別の提案や修正案などが続出した。まるで奴らは、この提案が
「スイスチーズの穴を全部埋めてしまう」だとか「コカコーラの味を変えてし
まう」などといったものすごく重大な話だと思い込んでいるようだった。


「ところで、いったい自転車置場ってどういうこと？」と思った人もいること
だろう。


話せば長くなる昔話だけど、実際のところは単純な話だ。C・ノースコート・
パーキンソンが 1960 年代初期に書いた「パーキンソンの法則」という本があっ
て、そこにはものごとの管理に関するさまざまな洞察が書かれていたんだ。


今でもアマゾンで買えるし、君たちの父親の本棚にも入っているかもしれない。
この本は、お金を出して購入し時間をかけて読むだけの価値があるものだ。ディ
ルバートが好きな人なら、きっとパーキンソンも気に入ることだろう。


かつてこの本を読んだ誰かが「現代じゃこの本に書かれてることの 50% くら
いしかあてはまらないね」と言ってた。上等じゃないか。いまどきの本なんか、
もっと惨めなもんだ。しかもこの本、35年以上前のものなんだぜ？


自転車置場の例にでてくるもう一方の役者が、原子炉だ。なんだか、いかにも
時代を感じさせるなぁ。


パーキンソンは、委員会に乗り込んで数百万から数億ドルもの原子炉建設計画
を承認させる方法を説明している。しかし、原子炉ではなく自転車置場を作り
たいと思ったら終わりのない議論に巻き込まれることになるだろうとも言って
いる。


パーキンソンによると、原子炉はあまりに巨大で高価そして複雑であるために
みんながその内容を把握できなくなるということだ。考えようともせずに思考
停止してしまい、「まぁここまで来る前に誰か他の人が一部始終をチェックし
ただろう」ということになってしまう。リチャート・P・ファインマンの著書に
は、これに関連するロス・アラモスでの興味深い事例がいくつか紹介されてい
る。


さぁ一方自転車置場だ。週末をつぶせばだれでも作ることができ、余った時間
にテレビで試合を見て楽しむことさえできるだろう。どんなに用意周到であっ
たとしても、どんなに妥当な提案だったとしても、だれかが機会をとらえては、
自分もなにかやっていることを示したり、自分もそれに注目してることを示し
たり、「俺を忘れるな」と言ったりするだろう。


デンマークでは、こういったことを「指紋をつける」って言うんだ。個人的な
プライドや見栄のために何かをして、あとからその証拠を見せられるようにす
る。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものよく
やりそうなことでもあるが、一般人だって機会があればやりそうだよ。ほら、
よく生乾きのセメントに足跡がついてたりするだろう？


最初にこの提案をした人には敬意を表したい。だって、くだらぬ批評家たちの
妨害行為にもめげず自分の信念を貫き通して、その変更がいまやツリーに取り
込まれてるわけだから。私ならあのスレッドの一握りのメッセージすら受け取
る前に諦めて逃げてただろうね。


さぁ、そしてさっき言ってた話。なぜ私が -hackers を購読していないのか。


私が数年前に -hackers の購読をやめた理由は、大量のメールをさばききれな
くなったからだ。あれ以来、同じ理由で他のメーリングリストもいくつか購読
をやめている。


それでもまだ大量のメールを受け取っている。まぁ多くのメールはフィルタリ
ングして /dev/null 行きにしてるけどな。(個人名省略) みたいな野郎からの
メールは私の画面上には決してあらわれない。外国語のドキュメントへのコミッ
トとか ports へのコミットとかの通知メールも同じだ。そういったメールは、
私の目に触れることなくどこかに行ってしまうってわけだ。


でも、これだけ必死になって受信箱を守ろうとしてるってのに、いまでも大量
にメールが届いている。


なにかいい案はないだろうか？


メーリングリストから余計なノイズをできるだけ減らしたいんだ。自転車置場
を作りたい人は気兼ねせずに作れるようにしてあげたいんだ。自転車置場を何
色に塗るかなんていちいち気にしなくてもいいじゃないか。


最初の件は、メールを使うときにみんなもっと礼儀を考えようってことだ。も
う少し気を使おうじゃないか。もう少し頭を使おうじゃないか。


メールに返信すべきとき/すべきでないときを、みんなが納得する形で簡潔か
つ正確に定義できたらどんなに幸せなことだろう。でも私は、できもしないこ
とを試みるほどのバカじゃない。


でも、こんな機能があったらいいなぁと思ってる。メーリングリストへの投稿
に返信しようとすると、メールソフトが自動的にこんなポップアップウィンド
ウを表示するんだ。どうだろう？


      +------------------------------------------------------------+
      | 今あなたが送ろうとしているメールは何10万人もの人に届きます.|
      | 受け取った人がそれを読むべきかどうかを判断するのに少なくと |
      | も10秒はかかるでしょう。つまり、あなたのメールを読むために |
      | 少なくとも0.5人月が費やされるわけです。さらに、多くの人は  |
      | メールをダウンロードするのにお金を払わないといけません。   |
      |                                                            |
      | あなたのメールは、ほんとうにみんながそれだけの手間をかけて |
      | でも読む価値のあるものですか？                             |
      |                                                            |
      |              [はい]  [書き直す]  [キャンセル]              |
      +------------------------------------------------------------+


      +------------------------------------------------------------+
      | 警告：あなたはまだこのスレッドのメールを全部読み終えていま |
      | せん。今あなたが書いている内容を、他の誰かが既に言っている |
      | かもしれません。まずスレッドを全部読んでから返信を書くよう |
      | にしましょう。                                             |
      |                                                            |
      |                    [キャンセル]                            |
      +------------------------------------------------------------+


      +------------------------------------------------------------+
      | 警告：まだこのメールソフト上でメッセージ全体を表示し終えて |
      | いません。論理的に考えて、あなたがメッセージの内容をすべて |
      | 読んで理解するのは不可能なはずです。                       |
      |                                                            |
      | メールを全部読んでちゃんと考えてから返信しないと相手に失礼 |
      | です。                                                     |
      |                                                            |
      | あなたに頭を冷やしてもらうためのタイマーが発動しました。今 |
      | 後１時間、このスレッドのいかなるメールにも返信はできません.|
      |                                                            |
      |                     [キャンセル]                           |
      +------------------------------------------------------------+


      +------------------------------------------------------------+
      | あなたはこのメールを秒速 N.NN 文字以上の速さで書き終えまし |
      | た。一般に、きちんと考えて書いていたなら秒速 A.AA 文字をこ |
      | えることは不可能です。おそらく、あなたが今書いた返信は支離 |
      | 滅裂で意味不明かつ感情的なものだと思われます。             |
      |                                                            |
      | あなたに頭を冷やしてもらうためのタイマーが発動しました。今 |
      | 後１時間、一切メールは送信できません。                     |
      |                                                            |
      |                     [キャンセル]                           |
      +------------------------------------------------------------+


私の願いの２番目はもっと感情的なものだ。sleep(1) スレッドで敵対的な批判
をした古参たちは、プロジェクトへの参加歴が長いというのに、このちょっと
したことをやろうとなんて思わなかった。明らかにね。それなのに、自分より
かなり下の後輩がそれをやろうとすると、なぜいきなり彼らはすごい勢いで燃
え上がるんだろうか？


わかっていればなぁ。


わかってるとも。いくらこんな分析をしたところで、あんな「反動保守主義者」
どもの抑止力にはならないってことくらい。たぶん奴らは、最近自分が何も貢
献できていないことにいらついているんだろう。あるいは「わしら年長者こそ
が、若造たちを正しく導いてやらねばならぬ」などと偉ぶってるんだろう。


どっちにせよそれはプロジェクトにとってまったく非生産的なことであるわけ
だが、私にはそれをやめさせる方法がわからない。とりあえず言えることは、
メーリングリストに潜むモンスターどもに餌を与えるのはやめろってことだ。
とにかく無視する。決して返信しない。奴らがそこにいることを忘れるんだ。


私は、FreeBSD への貢献者がもっと増えてもっと力強くなることを願っている。
そして、彼らを気難しい爺さんどもや (個人名省略) みたいな奴らから守るん
だ。あいつらがこの世界に足を踏み入れて彼らを脅かし、追い出してしまうよ
うなことになってしまってはいけない。


ガーゴイルどもにおびえてプロジェクトへの参加を躊躇している皆さんへ。た
だただごめんなさいとしか言いようがない。何とか仲間に加わって欲しい。今
の状況は、決して私の望んだ状況ではないんだ。

Poul-Henning

付録E バグ報告のやり方を説明した例

以下に示すのは、Subversion プロジェクトが新しいユーザー向けに作った、バグ報告に関する説明書をちょっと編集したものです。こうした説明書がなぜ重要なのかについては、 8章ボランティアの管理 の「すべてのユーザーの協力を得るために」を参照してください。オリジナルの文書は、 http://svn.collab.net/repos/svn/trunk/www/bugs.html にあります。




                    Subversion に関するバグ報告のやり方

この文書は、どこに、どうやってバグを報告すればいいかを説明したものです。(未解決のバグをすべて一覧
にしているわけではありません ー そのかわり、バグを報告する方法がわかります。)



どこにバグを報告すべきか
------------------------

    * バグが Subversion そのものに関することなら、users@subversion.tigris.org にメールを送ってく
      ださい。それがバグだと確認したら、誰かが (たぶんあなたが) バグ追跡システムに登録することができます。
      (バグであることを確信している場合は、私達の開発用メーリングリスト dev@subversion.tiglis.org
      に直接メールしてください。しかし、バグかどうか自信がない場合は、users@subversion.tigris.org
      にはじめにメールした方がよいです。なぜなら、そこにいる誰かが、あなたが遭遇した subversion の
      挙動が正しいかそうでないかを教えてくれるからです。)

    * バグが APR ライブラリに関することなら、以下のメーリングリスト両方にメールを送ってください:
      dev@apr.apache.org, dev@subversion.tigris.org

    * バグが Neon HTTPライブラリに関することなら、以下にメールを送ってください:
      neon@webdav.org, dev@subversion.tigris.org

    * バグが Apache HTTPD 2.0 に関することから、以下のメーリングリスト両方にメールを送ってください:
      dev@httpd.apache.org, dev@subversion.tigris.org
      Apache httpd 向けの開発者メーリングリストは非常にたくさんのメールが流れています。よって、あ
      なたのバグ報告のメールは見落とされるかもしれません。その場合は、バグ報告を 
      http://httpd.apache.org/bug_report.html に投稿することもできます。

    * バグが敷物(rug)の下にあったら、抱きしめて(hug)あげて、快適なもの(snug)にしましょう。



バグ報告のやり方
----------------

まず、バグかどうかを確認してください。Subversion があなたの思ったように動かないなら、ドキュメント
とメーリングリストのアーカイブを調べて、subversion があなたの思ったように動くはず、という証拠を探
してください。勿論、subversion があなたのデータを壊してしまったとか、モニターから煙が出てきた、な
ど常識の範囲であれば、あなたの判断を信じてよいでしょう。しかし、自信がないのであれば、まずはユーザ
ー向けのメーリングリスト、users@subversion.tigris.org か、irc.freenode.net の IRC チャンネル #svn
で聞いてみましょう。

いったんそれがバグだとわかったら、もっとも重要なのは、バグに関する簡単な説明と再現方法を考えること
です。たとえば、仮にバグであれば、はじめに見つけたときには5つのファイルに対して10回以上のコミット
をしていた場合、1ファイルに対して1回だけコミットして現象を再現させてみましょう。再現手順が簡単なも
のであればあるほど、開発者がバグを再現し、修正する確率が高くなります。

バグかどうかの簡易チェック: Subversion の最新バージョンを使ってますか? ホントに? :-) そ
のバグは既に修正されているかもしれませんよ。最新の Subversion 開発ツリーでもあなたのバグの再現手順
が再現できるかを確認してみましょう。

再現手順に加えて、そのバグを再現させた環境を完璧に説明する必要もあります。つまり、以下のような情報です:

    * あなたのオペレーティングシステム
    * Subversion のバージョン、かつ/または リビジョン番号
    * ビルドに使ったコンパイラと、ビルドの設定オプション
    * あなたが独自に加えたあらゆる変更
    * もしあれば、一緒に使っている Barkley DB のバージョン
    * 関連がありそうなその他全ての情報。できるだけ多くの情報を含んだエラー情報。

この情報が全て揃えば、バグレポートを書く準備ができました。どんなバグであるかの説明をわかりやすく書
くことから始めましょう。つまり、Subversion がどう動いてほしいのか、それに対して実際はどう動いてい
るのかを書きましょう。あなたにとっては明らかにバグであっても、他の人にとってはそうでないかもしれま
せん。よって、推測ゲームになるのを避けるのがベストです。次に再現した環境に関する説明をして、再現手
順を書きます。バグの原因に関する考察や、それを修正するためのプログラムを含めたいのなら、それは素晴
らしい！ 修正プログラムの送り方を http://subversion.apache.org/docs/community-guide/#patches 
で見てください。

これら全ての情報を dev@subversion.tigris.org に投稿しましょう。もしあなたが既にそうしているか、バ
グ追跡システムに登録するように頼まれたのなら、バグ追跡システムのページに行き、そこの指示に従ってく
ださい。

ここまで読んでくれてありがとう。優れたバグ報告を行うには、たくさんの努力が必要なのはわかっています。
しかし、優れた報告は開発者の時間を多く節約でき、バグが修正される確率を一層高めるものなのです。

付録F 訳者あとがき

高岡芳成 [FAMILY Given]

2009年3月

高木さんがとあるソーシャルブックマークサービスに原著のオンライン版をブックマークしたこと。それが全てのはじまりだった。ざっと読んでみたあと、これまでオープンソースソフトウェアの開発者が暗黙のうちに受け入れてきた、または実践してきたノウハウをここまではっきりと言葉にした文章は見たことがないと直感した。「これは皆に伝えなければならない」と思った瞬間、コミット権限を貰うべく奔走していた。

それから1年半、彼とふたりで亀のようなスピードで翻訳を続けてきた。正直、よく続いたものだと思う。お互いに本業がある中でペースを維持できたのは、原著が持つ濃い内容を日本語で是非伝えたいと思うモチベーションと、メーリングリストで原著者の Karl Fogel がくれた様々な励ましがあったからに他ならない。Karl はまさに「気配り」の人である。本書でもコミュニティを統治するに当たっての様々なものの言い方、気配りについて触れているが、彼はそれを忠実に実行しているように思えた。私は本書の翻訳を通して多くのことを学び、実際にメンテナーをしているプロジェクトの運営に生かすことができている。

日本語版を刊行するにあたっては、Karl と高木さんの他にも様々な方々の助けを頂いた。ここで全ての名前を挙げることはできないが、翻訳をレビューし、コメントをくれたスラッシュドットジャパンのユーザーの方々、そして直接メールで様々な指摘をしてくれた読者の存在は見逃せない。また、編集者の毛利さんには様々な細かい作業をして頂いた。さらに、フリーのオンライン版があることを知りながら、本書の出版を決めてくれたオライリー・ジャパンの懐の深さには敬服せざるを得ない。このあとがきを書いている今、ここまで辿り着いたことを素直に喜び、彼らに心から感謝の意を表したいと思う。

翻訳というのは「代弁」ともいえる。たとえ代弁であっても、労力を払って伝えたいと思うネタってそうはないと思う。本書は私にとってまさにその労力を払うに値する内容であると信じているし、オープンソースソフトウェアに関心がある開発者にも影響を与えられる内容であると信じてやまない。この本がオープンソースの世界に飛び込む一助となることを願っている。

May the Source Be With You!



--------------------------------------------------------------------------------

高木正弘 [FAMILY Given]

2009年3月

原著「Producing Open Source Software」の全文がオープンソースで公開されていることを知ったのは2007年5月のこと。あるオープンソースコミュニティのメーリングリストが荒れているのを見かねた人が「みんなこれを読むといいよ」と紹介していらしたのがきっかけでした ^[47]。彼が紹介していた部分を読んで深く感銘を受けた私は、さっそくその日本語訳の作成に取り組むことを決めたのです。その頃には、まさか2年後に日本語版が出版されることになるとは思ってもいませんでした。

オープンソースソフトウェアのコミュニティを運営していくには、よいソフトウェアを書くこと以外にもさまざまなことを考えなければなりません。メーリングリスト上での争いのしずめかたなどもそのひとつです。これまで口伝で受け継がれていくことが多かったこれらの事柄を１冊の書籍としてまとめあげた本書は、オープンソースソフトウェアにかかわるすべての方にとって有用なものとなることでしょう。

日本語訳を進めていく上で、多くの方にお世話になりました。原著者のKarlFogelさんは、すばらしい内容の文章をオープンソースで提供してくださっただけでなく、私たちの翻訳作業を力強くフォローしてくださりました。彼からいただいたアドバイスや励ましのおかげで、翻訳作業をスムーズに進めることができました。翻訳作業の中盤以降は、共同翻訳者の高岡さんのパワーに助けられっぱなしでした。彼がいなければ、この翻訳が完成することもなかったでしょう。原著と同様、日本語版の原稿もまたオープンソースで公開されています ^[48]。そのおかげで、多くの方から翻訳へのフィードバックをいただきました。IRCやメールなどで何度となく細かい指摘をしてくださった方もいらっしゃいましたし、スラッシュドットジャパンにパッチを投稿してくださった方もいらっしゃいました。ここで全員のお名前をあげることはできませんが、みなさんの指摘はとても役立ちました。

そして最後に。全文がウェブ上で公開されている本書の書籍化を決断してくださったオライリー・ジャパン、出版にあたって数多くの手助けをいただいた編集の毛利さんのおかげで、みなさんのお手元に本書をお届けできるようになりました。私が原著から影響を受けたのと同様、みなさんが本書から何かを得ていただくことがあれば幸いです。

^[47] http://blog.thepimp.net/archives/Good-reading-for-Mailing-list-members.html

^[48] http://producingoss.com/ja/index.html

付録G 著作権表示



この本の内容は、クリエイティブコモンズ Attribution-ShareAlike (表示-継承) ライセンス
によってライセンスされています。
このライセンスのコピーを見るには、http://creativecommons.org/licenses/by-sa/2.1/ を
見るか、以下の住所に郵便を送ってください^[49]。
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. 
以下でははじめにこのライセンスの要約を示し、完全な条文がその後に続きます。あなた
がこの本の全部または一部を別の条件で再配布したい場合は、作者に連絡をとってください。
Karl Fogel <kfogel@red-bean.com>

-*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*-



あなたは以下の条件に従う場合に限り、自由に:

    * 本作品を複製、頒布、展示、実演することができます。
    * 二次的著作物を作成することができます。



あなたの従うべき条件は以下の通りです。:

    * 表示. あなたは原著作者のクレジットを表示しなければなりません。

    * 継承. もしあなたがこの作品を改変、変形または加工した場合、あなた
      はその結果生じた作品をこの作品と同一の許諾条件の下でのみ頒布する
      ことができます。

    * 再利用や頒布にあたっては、この作品の使用許諾条件を他の人々に明ら
      かにしなければなりません。

    * 著作[権]者から許可を得ると、これらの条件は適用されません。

    * この許諾条件は、原著作者の著作者人格権を損ねたり、制限するもので
      はありません。

-*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*-

   Creative Commons Legal Code: アトリビューション—シェアアライク 2.1
                                （帰属—同一条件許諾）

クリエイティブ・コモンズ及びクリエイティブ・コモンズ・ジャパンは法律事務所ではありま
せん。この利用許諾条項の頒布は法的アドバイスその他の法律業務を行うものではありません。
クリエイティブ・コモンズ及びクリエイティブ・コモンズ・ジャパンは、この利用許諾の当事
者ではなく、ここに提供する情報及び本作品に関しいかなる保証も行いません。クリエイティ
ブ・コモンズ及びクリエイティブ・コモンズ・ジャパンは、いかなる法令に基づこうとも、あ
なた又はいかなる第三者の損害（この利用許諾に関連する通常損害、特別損害を含みますがこ
れらに限られません）について責任を負いません。

利用許諾:

本作品（下記に定義する）は、このクリエイティブ・コモンズ･パブリック･ライセンス日本版
（以下「この利用許諾」という）の条項の下で提供される。本作品は、著作権法及び／又は他
の適用法によって保護される。本作品をこの利用許諾又は著作権法の下で授権された以外の方
法で使用することを禁止する。

許諾者は、かかる条項をあなたが承諾することとひきかえに、ここに規定される権利をあなた
に付与する。本作品に関し、この利用許諾の下で認められるいずれかの利用を行うことにより、
あなたは、この利用許諾（条項）に拘束されることを承諾し同意したこととなる。

第1条　定義

この利用許諾中の用語を以下のように定義する。その他の用語は、著作権法その他の法令で定
める意味を持つものとする。

   a. 「二次的著作物」とは、著作物を翻訳し、編曲し、若しくは変形し、
      または脚色し、映画化し、その他翻案することにより創作した著作
      物をいう。ただし、編集著作物又はデータベースの著作物（以下、
      この二つを併せて「編集著作物等」という。）を構成する著作物は、
      二次的著作物とみなされない。また、原著作者及び実演家の名誉又
      は声望を害する方法で原著作物を改作、変形もしくは翻案して生じ
      る著作物は、この利用許諾の目的においては、二次的著作物に含ま
      れない。 

   b. 「許諾者」とは、この利用許諾の条項の下で本作品を提供する個人
       又は団体をいう。

   c. 「あなた」とは、この利用許諾に基づく権利を行使する個人又は団
       体をいう。 

   d. 「原著作者」とは、本作品に含まれる著作物を創作した個人又は団
       体をいう。 

   e. 「本作品」とは、この利用許諾の条項に基づいて利用する権利が付
       与される対象たる無体物をいい、著作物、実演、レコード、放送に
       かかる音又は影像、もしくは有線放送にかかる音又は影像をすべて
       含むものとする。 
   
   f. 「ライセンス要素」とは、許諾者が選択し、この利用許諾に表示さ
       れている、以下のライセンス属性をいう：帰属・同一条件許諾 

第2条　著作権等に対する制限

この利用許諾に含まれるいかなる条項によっても、許諾者は、あなたが著作権の制限（著作権
法第30条〜49条）、著作者人格権に対する制限（著作権法第 18条2項〜4項、第19条2項〜4項、
第20条2項）、著作隣接権に対する制限（著作権法第102条）その他、著作権法又はその他の適
用法に基づいて認められることとなる本作品の利用を禁止しない。

第3条　ライセンスの付与

この利用許諾の条項に従い、許諾者はあなたに、本作品に関し、すべての国で、ロイヤリティ
・フリー、非排他的で、（第7条bに定める期間）継続的な以下のライセンスを付与する。ただ
し、あなたが以前に本作品に関するこの利用許諾の条項に違反したことがないか、あるいは、
以前にこの利用許諾の条項に違反したがこの利用許諾に基づく権利を行使するために許諾者か
ら明示的な許可を得ている場合に限る。

   a. 本作品に含まれる著作物（以下「本著作物」という。）を複製するこ
      と（編集著作物等に組み込み複製することを含む。以下、同じ。）
   
   b. 本著作物を翻案して二次的著作物を創作し、複製すること

   c. 本著作物又はその二次的著作物の複製物を頒布すること（譲渡または
      貸与により公衆に提供することを含む。以下同じ。）、上演すること、
      演奏すること、上映すること、公衆送信を行うこと（送信可能化を含
      む。以下、同じ。）、公に口述すること、公に展示すること、
   
   d. 本作品に含まれる実演を、録音・録画すること（録音･録画物を増製
      することを含む）、録音･録画物により頒布すること、公衆送信を行
      うこと

   e. 本作品に含まれるレコードを、複製すること、頒布すること、公衆送
      信を行うこと

   f. 本作品に含まれる、放送に係る音又は影像を、複製すること、その放
      送を受信して再放送すること又は有線放送すること、その放送又はこ
      れを受信して行う有線放送を受信して送信可能化すること、そのテレ
      ビジョン放送又はこれを受信して行う有線放送を受信して、影像を拡
      大する特別の装置を用いて公に伝達すること

   g. 本作品に含まれる、有線放送に係る音又は影像を、複製すること、そ
      の有線放送を受信して放送し、又は再有線放送すること、その有線放
      送を受信して送信可能化すること、その有線テレビジョン放送を受信
      して、影像を拡大する特別の装置を用いて公に伝達すること

上記に定められた本作品又はその二次的著作物の利用は、現在及び将来のすべての媒体・形式
で行うことができる。あなたは、他の媒体及び形式で本作品又はその二次的著作物を利用する
のに技術的に必要な変更を行うことができる。許諾者は本作品又はその二次的著作物に関して、
この利用許諾に従った利用については自己が有する著作者人格権及び実演家人格権を行使しな
い。許諾者によって明示的に付与されない全ての権利は、留保される。

第4条　受領者へのライセンス提供

あなたが本作品をこの利用許諾に基づいて利用する度毎に、許諾者は本作品又は本作品の二次
的著作物の受領者に対して、直接、この利用許諾の下であなたに許可された利用許諾と同じ条
件の本作品のライセンスを提供する。

第5条　制限

上記第3条及び第4条により付与されたライセンスは、以下の制限に明示的に従い、制約される。

   a. あなたは、この利用許諾の条項に基づいてのみ、本作品を利用するこ
      とができる。

   b. あなたは、この利用許諾又はこの利用許諾と同一のライセンス要素を
      含むほかのクリエイティブ･コモンズ・ライセンス（例えば、この利
      用許諾の新しいバージョン、又はこの利用許諾と同一のライセンス要
      素の他国籍ライセンスなど）に基づいてのみ、本作品の二次的著作物
      を利用することができる。 

   c. あなたは、本作品を利用するときは、この利用許諾の写し又はURI
     （Uniform Resource Identifier）を本作品の複製物に添付又は表示し
      なければならない。

   d. あなたは、本作品の二次的著作物を利用するときは、この利用許諾又
      はこの利用許諾と同一のライセンス要素を含むほかのクリエイティブ･
      コモンズ･ライセンスの写し又はURIを本作品の二次的著作物の複製物
      に添付または表示しなければならない。

   e. あなたは、この利用許諾条項及びこの利用許諾によって付与される利
      用許諾受領者の権利の行使を変更又は制限するような、本作品又はそ
      の二次的著作物に係る条件を提案したり課したりしてはならない。

   f. あなたは、本作品を再利用許諾することができない。

   g. あなたは、本作品又はその二次的著作物の利用にあたって、この利用
      許諾及びその免責条項に関する注意書きの内容を変更せず、見やすい
      態様でそのまま掲載しなければならない。 

   h. あなたは、この利用許諾条項と矛盾する方法で本著作物へのアクセス
      又は使用をコントロールするような技術的保護手段を用いて、本作品
      又はその二次的著作物を利用してはならない。 

   i. 本条の制限は、本作品又はその二次的著作物が編集著作物等に組み込
      まれた場合にも、その組み込まれた作品に関しては適用される。しか
      し、本作品又はその二次的著作物が組み込まれた編集著作物等そのも
      のは、この利用許諾の条項に従う必要はない。

   j. あなたは、本作品、その二次的著作物又は本作品を組み込んだ編集著
      作物等を利用する場合には、（1）本作品に係るすべての著作権表示を
      そのままにしておかなければならず、（2）原著作者及び実演家のクレ
      ジットを、合理的な方式で、（もし示されていれば原著作者及び実演
      家の名前又は変名を伝えることにより、）表示しなければならず、
      （3）本作品のタイトルが示されている場合には、そのタイトルを表示
      しなければならず、（4）許諾者が本作品に添付するよう指定したURI
      があれば、合理的に実行可能な範囲で、そのURIを表示しなければなら
      ず（ただし、そのURIが本作品の著作権表示またはライセンス情報を参
      照するものでないときはこの限りでない。）（5）二次的著作物の場合
      には、当該二次的著作物中の原著作物の利用を示すクレジットを表示
      しなければならない。これらのクレジットは、合理的であればどんな
      方法でも行うことができる。しかしながら、二次的著作物又は編集著
      作物等の場合には、少なくとも他の同様の著作者のクレジットが表示
      される箇所で当該クレジットを表示し、少なくとも他の同様の著作者
      のクレジットと同程度に目立つ方法であることを要する。 

   k. もし、あなたが、本作品の二次的著作物、又は本作品もしくはその二
      次的著作物を組み込んだ編集著作物等を創作した場合、あなたは、許
      諾者からの通知があれば、実行可能な範囲で、要求に応じて、二次的
      著作物又は編集著作物等から、許諾者又は原著作者への言及をすべて
      除去しなければならない。

第6条　責任制限

この利用許諾の両当事者が書面にて別途合意しない限り、許諾者は本作品を現状のまま提供す
るものとし、明示・黙示を問わず、本作品に関していかなる保証（特定の利用目的への適合性、
第三者の権利の非侵害、欠陥の不存在を含むが、これに限られない。）もしない。

この利用許諾又はこの利用許諾に基づく本作品の利用から発生する、いかなる損害（許諾者が、
本作品にかかる著作権、著作隣接権、著作者人格権、実演家人格権、商標権、パブリシティ権、
不正競争防止法その他関連法規上保護される利益を有する者からの許諾を得ることなく本作品
の利用許諾を行ったことにより発生する損害、プライバシー侵害又は名誉毀損から発生する損
害等の通常損害、及び特別損害を含むが、これに限らない。）についても、許諾者に故意又は
重大な過失がある場合を除き、許諾者がそのような損害発生の可能性を知らされたか否かを問
わず、許諾者は、あなたに対し、これを賠償する責任を負わない。 

第7条　終了

   a. この利用許諾は、あなたがこの利用許諾の条項に違反すると自動的に
      終了する。しかし、本作品、その二次的著作物又は編集著作物等をあ
      なたからこの利用許諾に基づき受領した第三者に対しては、その受領
      者がこの利用許諾を遵守している限り、この利用許諾は終了しない。
      第1条、第2条、第4条から第9条は、この利用許諾が終了してもなお有
      効に存続する。

   b. 上記aに定める場合を除き、この利用許諾に基づくライセンスは、本
      作品に含まれる著作権法上の権利が存続するかぎり継続する。

   c. 許諾者は、上記aおよびbに関わらず、いつでも、本作品をこの利用許
      諾に基づいて頒布することを将来に向かって中止することができる。
      ただし、許諾者がこの利用許諾に基づく頒布を将来に向かって中止し
      た場合でも、この利用許諾に基づいてすでに本作品を受領した利用者
      に対しては、この利用許諾に基づいて過去及び将来に与えられるいか
      なるライセンスも終了することはない。また、上記によって終了しな
      い限り、この利用許諾は、全面的に有効なものとして継続する。 

第8条　その他

   a. この利用許諾のいずれかの規定が、適用法の下で無効及び／又は執行
      不能の場合であっても、この利用許諾の他の条項の有効性及び執行可
      能性には影響しない。 

   b. この利用許諾の条項の全部又は一部の放棄又はその違反に関する承諾
      は、これが書面にされ、当該放棄又は承諾に責任を負う当事者による
      署名又は記名押印がなされない限り、行うことができない。 

   c. この利用許諾は、当事者が本作品に関して行った最終かつ唯一の合意
      の内容である。この利用許諾は、許諾者とあなたとの相互の書面によ
      る合意なく修正されない。

   d. この利用許諾は日本語により提供される。この利用許諾の英語その他
      の言語への翻訳は参照のためのものに過ぎず、この利用許諾の日本語
      版と翻訳との間に何らかの齟齬がある場合には日本語版が優先する。

第9条　準拠法

この利用許諾は、日本法に基づき解釈される。

本作品がクリエイティブ・コモンズ・ライセンスに基づき利用許諾されたことを公衆に示すと
いう限定された目的の場合を除き、許諾者も被許諾者もクリエイティブ・コモンズの事前の書
面による同意なしに「クリエイティブ・コモンズ」の商標若しくは関連商標又はクリエイティ
ブ・コモンズのロゴを使用しないものとします。使用が許可された場合はクリエイティブ・コ
モンズおよびクリエイティブ･コモンズ･ジャパンのウェブサイト上に公表される、又はその他
随時要求に従い利用可能となる、クリエイティブ・コモンズの当該時点における商標使用指針
を遵守するものとします。クリエイティブ・コモンズは http://creativecommons.org/から、
クリエイティブ・コモンズ・ジャパンはhttp: //www.creativecommons.jp/から連絡すること
ができます。

^[49]元々本書はクリエイティブコモンズ Attribution ShareAlike 3.0 に基づいてライセンスされていたが、2009年2月17日現在日本で最新とされていた 2.1 でも OK との許可を著者から頂いた。よって、ここではバージョン 2.1 の日本語版を掲載している。http://creativecommons.org/licenses/by-sa/2.1/jp/ も参照すること。

オープンソースソフトウェアの育て方

フリーソフトウェアプロジェクトを成功させるコツ

Fogel Karl [FAMILY Given]

高木 正弘 [FAMILY Given]

Takaoka Yoshinari(a.k.a mumumu) [FAMILY Given]

謝辞

日本語版に寄せて

Fogel Karl [FAMILY Given]

序文

この本を書いた理由は？

どんな人たちに読んでほしい？

情報源

謝辞

免責

日本語版について

第1章 導入

歴史

独占的なソフトウェアとフリーソフトウェア

意識的な抵抗

無意識な抵抗

「フリー」と「オープンソース」の違い

現状

第2章 さあ始めましょう

まずは周りを見渡すことから

手持ちのもので始めよう

名前の決定

明確な目標を掲げる

フリーであることを宣言する

機能一覧・要件一覧

開発の進捗状況

ダウンロード

バージョン管理システムやバグ追跡システムへのアクセス

連絡手段

開発者向けのガイドライン

ドキュメント

ドキュメントの公開方法

開発者向けドキュメント

使用例とスクリーンショット

公開場所

ライセンスの選択と適用

「何でもできる」ライセンス

GPL

ライセンスを適用する方法

うまく引っ張っていく

個人的な議論を避ける

炎上を阻止する

きちんとしたコードレビューの習慣

もともと非公開だったプロジェクトをオープンにするときには、 変化の大きさに気をつけよう

広報

第3章 技術的な問題

プロジェクトに必要なもの

メーリングリスト

スパム対策

投稿のフィルタリング

アーカイブでのメールアドレスの処理

識別しやすいヘッダ

Reply-to はどうすべきか

私のふたつの夢

アーカイブ

ソフトウェア

バージョン管理

バージョン管理に関する用語集

バージョン管理システムの選択

バージョン管理システムの使用法

すべてをバージョン管理する

ウェブで閲覧できるようにする

コミットメール

ブランチの活用

情報の一元管理

承認

バグ追跡システム

議論の場としてメーリングリストを使う

バグ追跡システムをあらかじめフィルタする

IRC / リアルタイムに行なわれるチャットシステム

ボット

IRCの会話を保存する

RSS フィード

Wiki

ウェブサイト

ツールが一通り揃ったホスティングサイト

高木正弘 [FAMILY Given]

第1章導入

第2章さあ始めましょう

もともと非公開だったプロジェクトをオープンにするときには、変化の大きさに気をつけよう

第3章技術的な問題

第4章プロジェクトの政治構造と社会構造

第5章カネに関する問題

第6章コミュニケーション

第7章パッケージの作成、リリース、日々の開発

奇数/偶数に意味を持たせるやり方