オープンソースソフトウェアの育て方 フリーソフトウェアプロジェクトを成功させるコツ Fogel Karl [FAMILY Given] (著者) 高木 正弘 [FAMILY Given] (翻訳者) Takaoka Yoshinari(a.k.a mumumu) [FAMILY Given] (翻訳者) 製作著作 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka (a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 謝辞 親友である Karen Underhill と Jim Blandy に本書をささげます。 ふたりがいなけれ ば、本書を完成させることはできなかったでしょう。 目次 日本語版に寄せて 序文 この本を書いた理由は？ どんな人たちに読んでほしい？ 情報源 謝辞 免責 日本語版について 1. 導入 歴史 独占的なソフトウェアとフリーソフトウェア 意識的な抵抗 無意識な抵抗 「フリー」と「オープンソース」の違い 現状 2. さあ始めましょう 手持ちのもので始めよう 名前の決定 明確な目標を掲げる フリーであることを宣言する 機能一覧・要件一覧 開発の進捗状況 ダウンロード バージョン管理システムやバグ追跡システムへのアクセス 連絡手段 開発者向けのガイドライン ドキュメント ドキュメントの公開方法 開発者向けドキュメント 使用例とスクリーンショット 公開場所 ライセンスの選択と適用 「何でもできる」ライセンス GPL ライセンスを適用する方法 うまく引っ張っていく 個人的な議論を避ける 炎上を阻止する きちんとしたコードレビューの習慣 もともと非公開だったプロジェクトをオープンにするときには、 変化の大きさ に気をつけよう 広報 3. 技術的な問題 プロジェクトに必要なもの メーリングリスト スパム対策 投稿のフィルタリング アーカイブでのメールアドレスの処理 識別しやすいヘッダ Reply-to はどうすべきか 私のふたつの夢 アーカイブ ソフトウェア バージョン管理 バージョン管理に関する用語集 バージョン管理システムの選択 バージョン管理システムの使用法 すべてをバージョン管理する ウェブで閲覧できるようにする コミットメール ブランチの活用 情報の一元管理 承認 バグ追跡システム 議論の場としてメーリングリストを使う バグ追跡システムをあらかじめフィルタする IRC / リアルタイムに行なわれるチャットシステム ボット IRCの会話を保存する RSS フィード Wiki ウェブサイト ツールが一通り揃ったホスティングサイト ホスティングサイトを選ぶ 匿名性とプロジェクト参加 4. プロジェクトの政治構造と社会構造 優しい独裁者 誰がよき「優しい独裁者」になれるか？ 合意に基づく民主主義 バージョン管理を行なうと堅くならずに済む 合意に至らなければ投票する いつ投票を行なうべきか? 誰が投票するのか? 世論調査 v.s 投票 拒否権 全てを記録しておく 5. カネに関する問題 プロジェクトへの関わり方 開発者を長期に渡って雇用する 企業の人間としてではなく、個人として振る舞う 動機を隠し立てしない カネで愛は買えない 契約する レビューを行い、変更をソースコードに取り入れる ケーススタディ: CVS パスワード認証プロトコルの場合 プログラミング以外の活動を支援する 品質保証 (テストの専門家など) 法律上の助言、権利の保護 ドキュメントやユーザビリティの改善 ホスティングサイトや接続回線を提供する マーケティング 見られていることを意識する 競合するオープンソースプロジェクトを攻撃しない 6. コミュニケーション 書いたことがすべて 構成や体裁 中身 口調 何が失礼にあたるのか 顔 陥りがちな罠 目的のない投稿をしない 生産的なスレッドとそうでないスレッド 簡単な議題ほど長引く 宗教論争を回避する "口やかましい少数派" について 扱いにくい人たち 扱いにくい人たちへの対応 実例 巨大化への対応 アーカイブを目に付きやすくする方法 全リソースをアーカイブと同様に扱う しきたりの成文化 バグ追跡システムでは議論しない 宣伝・広報 セキュリティ脆弱性の告知 バグ報告を受ける 大至急それを修正する CAN/CVE 番号 事前通知 修正を一般に公開する 7. パッケージの作成、リリース、日々の開発 リリースに番号を付ける リリース番号の構成要素 単純なやり方 奇数/偶数 に意味を持たせるやり方 リリースブランチ リリースブランチの使い方 リリースを安定させるプロセス リリースオーナーによる独裁 リリースに含める変更を投票で決める リリースを安定させるプロセスを管理する リリースマネージャー パッケージング パッケージのフォーマット パッケージ名とレイアウト 大文字にするか、小文字のままにするか プレリリース版 コンパイルとインストール バイナリパッケージ テストとリリース リリース候補 リリースを告知する 複数のリリースラインを管理する セキュリティリリース リリースと日々の開発 リリースの計画を立てる 8. ボランティアの管理 ボランティアを最大限に活用する 委任 作業依頼と担当者の決定を明確に区別する 委任したあとのフォロー みんなの好みを知る 賞賛と批判 縄張り意識の回避 自動化の割合 自動テスト すべてのユーザーの協力を得るために 技術的な作業だけでなく管理作業もみんなで パッチマネージャー 翻訳マネージャー ドキュメントマネージャー バグマネージャー FAQ マネージャー 引き継ぎ コミッター コミッターの選びかた コミット権の剥奪 部分的なコミット権 休眠状態のコミッター 秘密主義を避ける クレジット プロジェクトの分裂 分裂の動きをうまく処理する 新しいプロジェクトを立ち上げる 9. ライセンス、著作権、特許 使用する用語 ライセンスの特徴 GPL とライセンスの互換性 ライセンスを選ぶ MIT/X Window System ライセンス GPL GPL はフリーなライセンスなのか? BSDライセンス はどうなの? 著作権の保有と譲渡 何も対処しない 貢献者ライセンス同意書(CLA) 著作権の譲渡 デュアルライセンスの仕組み 特許 さらなる情報源 A. フリーなバージョン管理システム B. フリーなバグ追跡システム C. なんで自転車置場の色まで気にしなきゃならないの？ D. バグ報告のやり方を説明した例 E. 訳者あとがき F. 著作権表示 日本語版に寄せて Fogel Karl [FAMILY Given] 2009年5月6日 ニューヨークにて記す 　本書の英語版（『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 プロジェクトの見解を代表しているとは限りません。 日本語版について 『オープンソースソフトウェアの育て方』は、 「Producing Open Source Software」（ Karl Fogel著、2005年10月、 O'Reilly Media発行、ISBN0-596-00759-0）のオンライン 版を底本にして日本語訳が行われました。 原文は http://producingoss.com/en/ index.html で公開されています。 このサイトに掲載している内容を書籍化し、出版した「書籍版」として 「オープンソー スソフトウェアの育て方」(Karl Fogel著、2009年7月、高木正弘、高岡芳成訳 株式会社 オライリー・ジャパン発行、ISBN978-4-87311-412-5) があります。 これは http:// www.oreilly.co.jp/books/9784873114125/ で購入できます。 このサイトに掲載している内容には、 上記の「書籍版」の内容を株式会社オライリー・ ジャパンから書面で許可を得た ^[4] 上で転載したものが含まれていますが、 そのこと がこのサイトの内容を改変、 再配布する条件（付録 F. 著作権表示) に影響を与えるわ けではありません。 ━━━━━━━━━━━━━━ ^[2] ここでは「オープンソース」と「フリー」をほぼ同じ意味で使用しています。 詳 細は、第1章 の 「フリー」と「オープンソース」の違い項 で説明します。 ^[3] 日本語版注：Karl Fogel氏のウェブサイト（http://www.red-bean.com/kfogel/） などによると、 2009年7月現在は CollabNet ではなく、Ubuntuプロジェクトのコマーシ ャルスポンサーでもある Canonical社 （http://canonical.com/）で、ソフトウェアプ ロジェクトのホスティングサービス Launchpad （http://launchpad.net/）などに関係 しているようです。本書の本文では、 氏とCollabNetの雇用関係に基づいた記述がいく つかありますが、すべて執筆時点のものとしてお読みください。 ^[4] 書籍版はこのサイトで掲載しているオンライン版の派生物なので、そもそも許可を 得る必要すらありませんでした。しかし、出版された書籍版の最後のページに 「本書は 著作権上の保護を受けています。本書の一部あるいは全部について、株式会社オライリ ー・ジャパンから文書による許諾を経ずに、いかなる方法においても無断で複写、複製 することは禁じられています。」という定型的な文言が含まれてしまったため、念のた め書面を出して貰ったものです。 第1章 導入 目次 歴史 独占的なソフトウェアとフリーソフトウェア 意識的な抵抗 無意識な抵抗 「フリー」と「オープンソース」の違い 現状 ほとんどのフリーソフトウェアプロジェクトは失敗します。 しかし、失敗例について聞くことはあまりありません。 みんなの気を引くのは成功した プロジェクトだけだからです。 世の中には途方もない数のフリーソフトウェアプロジェ クトが存在する ^[5] ので、たとえ成功するプロジェクトがその中のごく一部に過ぎな かったとしても、 多くのプロジェクトが成功しているように見えてしまうのです。 ま た、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも 私たちが失 敗について聞くことがない理由のひとつでしょう。 「そのプロジェクトが消滅した瞬間 」というのを特定することはできません。 参加者が少しずつ他へ移っていき、プロジェ クトで作業するのをやめるだけなのです。 「プロジェクトに対して最後に変更が加えら れたとき」を知ることはできますが、 実際にその変更を加えた人は「それがプロジェク トに対する最後のコミットとなる」 とは決して思っていなかったことでしょう。 また 、どれぐらい動きがなければ「止まってしまった」 とみなすのかについてもはっきりし た定義がありません。 目だった動きが半年間なかったとき？ ユーザー数の伸びが止ま ってしまい、結局開発者の数を超えることがなかったとき？ 自分の参加しているプロジ ェクトが結局他のプロジェクトの焼き直しであることに気づいた開発者が、 現在参加し ているプロジェクトを捨ててもうひとつのほうに移動したとしましょう。 そして移った 先のプロジェクトをどんどん成長させていきました。 この場合、元のプロジェクトは「 消滅した」のでしょうか？ それとも「あるべき場所に移動しただけ」なのでしょうか？ このように複雑な側面があるので、 いったいどの程度の割合でプロジェクトが失敗して いるのかを正確に知るのは不可能です。 しかし、過去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 研は「ハッカー倫理」 ^[6] を前面に押し出しており 、何かシステムに改良を加えた場合は それを皆で共有するのが当然のことであるとみな されていました。 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 ^[7] の目標は、完全にフリーでオープンなオペレーティングシス テムと アプリケーションソフトウェアを作成することです。 ユーザーがコードをハッ クしたり他人と共有したりすることは決して妨げられません。 簡単に言うと、彼は AI 研にかつてあった (そして今は破壊されてしまった) 空気を新たに作り直そうとしてい たのです。 今度は世界中を巻き込む規模で。 そして AI 研の空気が破壊されてしまっ たのと同じようなことを起こさないように。 新しいオペレーティングシステムの開発のかたわら、Stallman は新しい著作権ライセン スを考案しました。 自分のコードが永久に自由であることを保証するためです。 GNU General Public License (GPL) は、法律における見事な柔術です。 コードの複製や変 更には一切の制限を設けません。コピーしたものやその派生物 (改造したものなど) の 配布は同じライセンスのもとで行われなければならず、 いかなる制限も付加されてはい けません。 このライセンスは著作権法を利用していますが、 狙っている効果は伝統的 な著作権とは正反対のものなのです。 つまり、ソフトウェアの再配布を制限するのでは なく、たとえ作者であっても 再配布を制限すること 自体を禁止しているのです。 Stallman にとって、自分のコードを単にパブリックドメインにするよりも そのほうが 好都合だったのです。 パブリックドメインにしてしまうと、誰かがそれを独占的なプロ グラム (あるいは、より規制のゆるい別のライセンスを適用したプログラム) に使用し てしまうかもしれません。 そうされたところで元のコードは自由なままで残り続けるわ けですが、 でも結局は Stallman の努力した結果が敵陣営 —独占的ソフトウェア—に利 益をもたらすことになってしまいます。 GPL は、フリーソフトウェアに対する保護主義 の一形式と考えることができます。 というのは、自由でないソフトウェアが GPL のコ ードを完全に好きなように利用することはできないからです。 GPL とその他のフリーソ フトウェアライセンスとの関係については、 第9章 で詳しく説明します。 数多くのプログラマー (Stallman の思想に賛同する人もいれば、 ただ単に自由にコー ドを使いたいだけという人もいました) の協力を得て、GNU プロジェクトは OS の基幹 部品を置き換えるフリーソフトウェアを次々にリリースしていきました。 当時はすでに コンピュータのハードウェアやソフトウェアが標準化されていたので、 GNU のソフトウ ェアを自由でないシステム上で使用することもできました。 また実際に多くの人がその ようにしていました。 中でも最も成功したのが GNU テキストエディタ (Emacs) と C コンパイラ (GCC) でした。これらは、その思想に共感する人たちだけでなく 単にソフ トウェアとして優れているからという理由で使う人たちも引き込むことになりました。 1990 年ごろには、GNU は自由なオペレーティングシステムをほぼ完成させつつあり、 残っていたのはカーネルだけでした。カーネルとはマシンを実際に立ち上げる部分であ り、 メモリやディスク等のシステムリソースの管理を行うものです。 不幸にも、GNU プロジェクトが選択したカーネル設計は 当初予想していたよりも実装が 困難なものでした。 カーネルの作成は遅れに遅れ、Free Software Foundation が完全 に自由なオペレーティングシステムを公開する日はなかなかやってきませんでした。 そ こに登場したのが Linus Torvalds です。 彼はフィンランド人の学生で計算機科学を専 攻していました。 彼は世界中の有志と力をあわせ、より保守的な設計のフリーなカーネ ルを完成させました。 彼はそれを Linux と名づけました。Linux を既存の GNU プログ ラム群と組み合わせることで、 完全に自由なオペレーティングシステムを得ることがで きるようになったのです。 ここにきて初めて、独占的ソフトウェアを一切使用せずに コンピュータを立ち上げて作業ができるようになりました。 ^[8] この新しいオペレーティングシステム上で動作するソフトウェアの多くは、 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 ウィンドウ ^[9] 自体 はフリーソフトウェアですが、 その主な目的は、いわば競争する参加企業間の試合の場 をならすことであり、 独占的ソフトウェアの支配を終わらせるといった意図はありませ んでした。 もうひとつの例を挙げましょう。GNU プロジェクトの数年前に開発が始まっ た TeX です。これは、Donald Knuth によるフリーで高品質な組版システムです。 彼は 、誰でもコードを改変して再配布できるというライセンスのもとで Tex を公開しました 。 ただし、改変したコードを再配布する際には、非常に厳しい互換性テストをクリアし ない限り "TeX" の名を使ってはならないという制限をつけました (これは、フリーなラ イセンスにおける "商標保護" の例です。詳細は 第9章 で説明します)。Knuth は、自 由なソフトウェアか独占的なソフトウェアかといった問題については 特に立場を表明し ていませんでした。彼は、単に 真の 目的 (コンピュータプログラミングに関する書籍 の出版) を達成するためのまともな組版システムがほしかっただけなのです。 そして彼 にとって、自分の作ったシステムを一般に公開しない理由はなかったのです。 すべてのプロジェクトやライセンスをここで挙げることはしませんが、 1980 年代後半 にはさまざまなライセンスのさまざまなフリーソフトウェアが存在したということは こ こまでの例でも十分に伝わるでしょう。 さまざまなライセンスが存在するということは 、 フリーソフトウェアを公開する動機にもさまざまなものがあるということを表してい ます。 GNU GPL を選択したプログラマーであっても、 GNU プロジェクトほどにはイデ オロギーを押し出していない人も存在します。 彼らはフリーソフトウェアの開発を楽し んでいますが、 その多くは、特に独占的ソフトウェアを敵視しているわけではありませ ん。 この世から「ソフトウェアの囲い込み (software hoarding)」(Stallman がフリー でないソフトウェアを指すときに使用する用語) をなくすんだ！ という道徳的な衝動に かられる人もいましたが、 単に技術的な興味からフリーソフトウェアを開発している人 もいました。 また、同じ趣味を持つ人と共同作業をするのが楽しいとか、 有名になり たいとかいう理由の人もいたことでしょう。 しかし、このように本質的に異なる動機を 持った人たちが お互いに悪影響を及ぼしあうことはありませんでした。 小説や絵画と 異なり、ソフトウェアには最低限の基準 (きちんと動くこと、バグが存在しないこと) があったことも理由のひとつでしょう。 そのため、プロジェクトの参加者が共同で作業 する際に 技術面以外の適性をあまり気にする必要がありませんでした。 開発者たちが手を取り合う理由がもうひとつありました。 フリーソフトウェア界が非常 に高品質なコードを生み出していることがわかってきたのです。 時には、フリーでない 同等製品より明らかに技術面で上回っているものもありました。 あるいは、少なくとも 同等の機能を持っているものも多くありました。当然、 これは低コストで入手すること ができます。 フリーソフトウェアの思想に厳密に従うためにフリーソフトウェアを使用 するという人は あまり多くなかったかもしれません。多くの人たちは、 単にそちらの ほうが高性能だからという理由でフリーソフトウェアを選択していました。 そしてソフ トウェアを使う人たちの中には、 そのソフトウェアの保守や改善のために時間と力を貸 してくれる人が常にある程度以上いたのです。 この「よいコードを生み出す」という傾向はまだ普遍的なものとはなっていませんでし たが、 徐々に世界中のフリーソフトウェアプロジェクトでも同様の現象が見られるよう になってきました。 ソフトウェアに強く依存する産業界でも、徐々にそのことに気づき 始めました。 彼らの多くは、すでに日常の作業にフリーソフトウェアを使用していまし たが、 それに気づいていませんでした (上級管理職が IT 部門の動きを常に把握してい るとは限りません)。 企業は、フリーソフトウェアプロジェクトに対して より積極的、 公共的な役割を担うようになりました。 彼らのために時間や設備を提供したり、 ある いはもっと直接的に資金を提供したりすることもありました。 うまくいった場合は、そ のような投資が何倍にもなって返ってくるかもしれません。 そのプロジェクトにフルタ イムで専念している一部の専門プログラマーに対して資金を提供することで、 プロジェ クト全体 (無償のボランティアや他の企業に属するプログラマーなど) の活動の利益を 得られることになります。 「フリー」と「オープンソース」の違い 産業界がますますフリーソフトウェアに注目するようになると、 プログラマーたちはま た新たな問題に直面することとなりました。 そのひとつは「フリー」という言葉の意味 についてです。 「フリーソフトウェア」という言葉を聞いて、多くの人がそれを単なる 「無料のソフトウェア」というように勘違いしてしまいます。 確かにすべてのフリーソ フトウェアは無料ですが、 ^[10] 無料のソフトウェアがすべてフリー (自由) であると は限りません。 たとえば、1990 年代のブラウザ戦争の際に Netscape と Microsoft は ともにブラウザを無償でばらまき、 市場のシェアを獲得しようと躍起になりました。 このどちらのブラウザも、"自由なソフトウェア" という意味でのフリーではありません でした。 そのソースコードを見ることができなかったり、 あるいはたとえ見ることが できたとしてもそれを改造して再配布する権利がなかったりしたのです。 ^[11] できる ことといえば、実行ファイルをダウンロードして動かすことだけでした。 これらのブラ ウザには、店頭で箱売りされているソフトウェア以上の自由などありませんでした。 単 に価格が安かっただけです。 この「フリー」という言葉が混乱を招く原因は、 不幸にもこの英単語がいろいろな意味 を持ってしまっていることにあります。 他の大半の言語では、価格が安いことと自由で あることは簡単に区別できるでしょう (たとえばロマンス諸語を話す人にとっては gratis と libre の違いは明確です)。 しかし、英語がインターネット上での標準言語 として使われている現状では、 英語の問題は、ある意味ではすべての人たちの問題であ るともいえます。 この「フリー」という言葉の意味の履き違えがあまりにも広まってし まったので、 フリーソフトウェア開発者は決まり文句をつくり出しました。 "フリー (free) とは、自由 (freedom) のことです。つまり、フリースピーチ (言論の自由) と いうときの「フリー」であり、フリービール (無料のビール) というときの「フリー」 とは違います。" しかし、何度も何度もこれを説明しなければならないのは大変です。 多くのプログラマーが、この「フリー」というあいまいな単語のせいで 自分たちのソフ トウェアが世間に正しく理解されないと感じるようになりました。 しかし、問題はもっと深いところにありました。 「自由」という言葉には道徳的な意味 が含まれています。 自由であることが目的なのならば、フリーソフトウェアがよりよい ものになろうが 特定の状況において特定のビジネスで有益になろうが、 そんなことは どうでもよかったのです。 単にその動機にちょっとしたよい副作用があっただけです。 心底は技術的でも商業的でもなく、道徳的な動機だったのです。 さらに「自由という意 味のフリー」という立ち位置は、 フリーなプログラムのサポートもしたいが別の独占的 ソフトウェアの商売も続行したい という企業にとってはちょっと不便なものでした。 このジレンマは、すでに自己喪失状態になっていたコミュニティーに突き刺さりました 。 実際にフリーソフトウェアを書いているプログラマーたちは、 仮にフリーソフトウ ェア運動全体としての目標があったとしても そのために一致団結することはありません でした。 彼らの考えには両極端のものがあったと言ってしまうのもちょっと違います。 そんな風に言ってしまうと、まるで彼らの違いが単一の基準だけにもとづくものだと勘 違いされてしまいます。 しかし、些細な違いをとりあえず無視するなら、 彼らの考え 方は大きく２種類に分けることができます。 一方のグループは Stallman の考え方に共 鳴する人たちです。 ソフトウェア自由に共有できて自由に改変できることこそが最も重 要で、 自由について語ることをやめた瞬間に本質的な問題から離れることになります。 もう一方のグループは、ソフトウェアそのものこそが最も重要であると考えており、 独 占的ソフトウェアを敵視するような考え方は好みません。 すべての人がそうだというわ けではありませんが、プログラマーの中には、 作者 (あるいは雇用主) は再配布権をコ ントロールできるようにすべきだと考えている人たちもいます。 再配布権を考える際に 、道徳的な視点は不要だということです。 長い間、これらの違いをきちんと調べたり あえて明確にしたりすることはありませんで した。 しかしフリーソフトウェアがビジネスの世界に広まっていく中で この問題は避 けられないものとなってきたのです。 1998 年に、「フリー」にかわる言葉として オー プンソース が登場しました。 これは、後に Open Source Initiative (OSI) となるプ ログラマーの集団が定義したものです。 ^[12] 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章 で改めて説明します。 もちろんこれは、企業の支援を受けていなければ何も心配する必 要がないということではありません。 カネの問題は、プロジェクトが失敗する要因のう ちのほんのひとつでしかありません。 どんな開発言語を選択するか、どんなライセンス を選択するか、 開発手順はどうするか、どんなツールを使用するか、 あるいは新しい プロジェクトをどのように宣伝するかなど、 さまざまな要因がほかにも考えられます。 では、実際にプロジェクトを開始するにはどうしたらいいのか。 それを 次の章 で取り 上げます。 ━━━━━━━━━━━━━━ ^[5] 有名なホスティングサイトのひとつである SourceForge.net には、2004 年 4 月 中旬の時点で 79,225 のプロジェクトが登録されています。 もちろん、これがインター ネット上のフリーソフトウェアプロジェクトの総数である というわけではありません。 これは単に、その時点で SourceForge を選択したプロジェクトの数に過ぎません。 ^[6] Stallman は「ハッカー」という単語を 「プログラミングが大好きでそれを楽しん でいる賢い人」という意味で使っています。 最近よく使われるようになった「コンピュ ータに不正侵入する人」 という意味ではありません。 ^[7] これは "GNU's Not Unix" の頭文字をとったものです。 そしてこの中の "GNU" は 何の略かといえば…… 同じです。 ^[8] 厳密に言うと、Linux が最初だったわけではありません。 IBM 互換機上で動作す る 386BSD というフリーなオペレーティングシステムが Linux のほんの少し前に登場し ています。 しかし、386BSD を動かすのは非常に難しいことでした。 Linux が騒がれた 理由は、単にフリーなだけでなく インストールして動作させるのが簡単であったという こともあります。 ^[9] 彼らは "X ウィンドウシステム" と呼んでほしいようですが、 現実には "X ウィ ンドウ" ということのほうが多いでしょう。 だっていちいちそんな長い名前を言うのは 面倒くさいから。 ^[10] フリーソフトウェアを配布する際に代金を徴収することもあるかもしれません。 しかし、購入した人がそれを他人に無料で再配布するのを禁じることはできないので、 結局のところ価格は無料同然となります。 ^[11] Netscape Navigator のソースコードは、結局は 1998 年にオープンソースライセ ンスのもとで公開されることとなりました。 これをもとにして作られたのが Mozilla ウェブブラウザです。詳細は http://www.mozilla.org/ をご覧ください。 ^[12] OSI のウェブページは http://www.opensource.org/ です。 第2章 さあ始めましょう 目次 手持ちのもので始めよう 名前の決定 明確な目標を掲げる フリーであることを宣言する 機能一覧・要件一覧 開発の進捗状況 ダウンロード バージョン管理システムやバグ追跡システムへのアクセス 連絡手段 開発者向けのガイドライン ドキュメント ドキュメントの公開方法 開発者向けドキュメント 使用例とスクリーンショット 公開場所 ライセンスの選択と適用 「何でもできる」ライセンス GPL ライセンスを適用する方法 うまく引っ張っていく 個人的な議論を避ける 炎上を阻止する きちんとしたコードレビューの習慣 もともと非公開だったプロジェクトをオープンにするときには、 変化の大きさに気 をつけよう 広報 フリーソフトウェアプロジェクトがどのようにして始まるのかについては、 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: //freshmeat.net/ (オープンソースプロジェクトに関するニュースサイト。 詳細は後ほ ど説明します) や http://www.sourceforge.net/、 そして Free Software Foundation のフリーソフトウェアディレクトリ (http://directory.fsf.org/) を調べてみましょう 。 そのものずばりのものが見つからなかったとしても、 よく似たものが見つかるかもしれ ません。 そんな場合は、そのプロジェクトに合流して必要な機能を追加するほうが、 １から作り直すよりもいいでしょう。 手持ちのもので始めよう まわりを見渡してみたけれど望みどおりのものが見つかりませんでした。 ということで 、結局新しいプロジェクトを始めることになりました。 さて何をしたらいいのでしょう？ フリーソフトウェアプロジェクトの立ち上げ時に最も厄介なのは、 個人的なビジョンを みんなにわかる形に置き換えることです。 あなた (あるいはあなたの属する組織) にと っては何がやりたいのかは明白でしょう。 しかし、そのプロジェクトの目標が何なのか を一般にもわかるように表明することは、 それなりに大変な作業です。しかし、 かな らず時間を割いてそれをやらなければなりません。 あなた (そして共同でプロジェクト を立ち上げた他のメンバー) は、まず「プロジェクトが実際何なのか」、すなわち、 「 何をやるのか」と同時に 「何をやらないのか」という限界を決定し、 ミッションステ ートメントを書き上げなければなりません。 普通は、これはそれほど困難なことではあ りません。 しかし、この作業によって、プロジェクトの本質に関する暗黙の了解やさら には意見の相違まで浮かび上がってくるかもしれません。 それでいいんです。後になっ てからそれが判明するよりも、 早いうちに見つけてしまったほうが解決しやすくなりま す。 この作業が終われば、次にすることは 一般公開用のパッケージを作成することで す。 これは、ぶっちゃけて言うと単純でつまらない純然たる骨折り仕事です。 何がそんなに面倒くさいのかというと、その作業の大半が、既にみんなが知っている — ここでいう「みんな」とは、これまでずっとプロジェクトにかかわってきた人のことで す— ことをまとめ上げて文書化するということだからです。 つまり、その作業を実際に 行う人には直接的なメリットは何もないのです。 彼らにとっては「このプロジェクトは ……」というような README ファイルは不要ですし、もちろん設計文書やユーザーマニュ アルなんかも不要です。 ソフトウェアをソースで配布するときにみんなが標準的に使っ ているような コードツリーを構成する必要も感じていないでしょう。 別にディレクト リ構成がどうであっても彼らは気にしません。 だってもうそのコードの内容を熟知して いるのだし、 コードが動き出せば、あとはどう使えばいいのかも知っているわけですか ら。 彼らにとっては、そのプロジェクトの基本的な設計方針が文書化されていなくても 平気です。 だってそれは彼らの頭の中にちゃんとあるのですから。 一方、新参者にとってはそのようなドキュメントは必須です。 とはいえ、幸いなことに すべてのドキュメントが一度に必要となるわけではありません。 プロジェクトを公開す る前に、あらゆるリソースを提供できるようにしておく必要はありません。 理想を言え ば、新しいオープンソースプロジェクトを始めるときには 設計文書や完全なユーザーマ ニュアル (今後実装予定の機能についての説明も含む)、 複数プラットフォームで動作 するきれいにパッケージされたコードなどがそろっているといいのでしょう。 しかし現 実的には、これらをばっちりそろえることは手間がかかりすぎます。 それになにより、 ひとたびプロジェクトが動き出せば、 これらの作業に対するボランティアの協力を正当 に期待できるのです。 しかし、何が本当に必要なのかといえば、 見栄えの調整に十分に力をいれ、 新入りさ んが不慣れという名の最初の障壁を乗り越えられるようにすることです。 この作業をブ ートストラップ過程の第一段階、 プロジェクトをいわば活性化エネルギー最小の状態に 持っていくことだと考えてください。 新入りさんが「このプロジェクトに対して何らか のかかわりと持とう」 と考えるために必要なエネルギーの閾値のことを、どこかの誰か が ハクティベーション (hacktivation) ^[13] エネルギー と呼んでいました。ハクテ ィベーションエネルギーが低ければ低いほどいい、 というわけです。あなたが最初に行 う作業は、 プロジェクトのハクティベーションエネルギーを下げて いろいろな人たち がプロジェクトに参加しやすくすることとなります。 以下の各項では、新しいプロジェクトをはじめるにあたって重要となる内容について個 別に説明します。 そのプロジェクトをはじめて知った人が遭遇するであろう順に並べて いますが、 もちろんこのとおりの順で作成しなければならないというわけではありませ ん。 これらの項目を、チェックリストとして用いるといいでしょう。 プロジェクトを はじめる際にはこれらの各項目が網羅されていることを確認するか、 あるいはもし省略 した項目がある場合は、 せめて予想される結果が満足のいくものであることを確認しま しょう。 名前の決定 どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。 おそらく、何 かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。 彼 らが真っ先に目にするのは、そのプロジェクトの名前です。 すばらしい名前をつけたからといって、 そのプロジェクトの成功が約束されるわけでは ありません。 また、変な名前をつけたからといって それだけの理由でプロジェクトが 失敗するというわけでもありません —もちろん、あまりにも マズい名前をつけてしまっ たら悪影響があるかもしれません。 しかし、わざわざプロジェクトを失敗に持っていく ようなことはしないだろう という前提の下で話を進めます。 ただ、変な名前をつけて しまうと、 真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、 その プロジェクトの利用が低下してしまうかもしれません。 よい名前とは、次のような条件を満たすものです。 ● そのプロジェクトのやることが多少なりとも分かること、 あるいは少なくとも明ら かな形でそれと関連があること。 そうすることで、名前とやることを知ってもらっ たあと、 その名前をすぐ思い出してもらえるようにするのです。 ● 覚えやすいこと。 ここで、インターネットのデフォルト言語が英語となっている という事実を無視することはできません。つまり「覚えやすい」 とは「英語が読め る人にとって覚えやすい」ということです。 英語のネイティブスピーカーの発音に 基づくだじゃれを用いた名前などは、 英語を母国語としない多くの人たちにとって はわかりにくいものとなるでしょう。 ただ、それが人の心をひきつけるほど印象的 なものならば だじゃれを使用する価値もあるでしょう。 英語を母国語としない人 たちからみると、 だじゃれを用いたプロジェクト名を見てもその読み方を想像しに くくなる ということを覚えておきましょう。 ● 既存の別のプロジェクト名と重複しない、 そして商標権を侵害しないものであるこ と。 これは、礼儀の問題であると同時に法的にもよい考えです。 別のプロジェク トと混同されてしまうようなことは望ましくないでしょう。 別々のものが同じ名前 を持っていなかったとしても、 ネットで手に入るものすべてを追跡するのは既に十 分困難なことなのです。 あなたが考えているのと同じ名前のプロジェクトが既に存在するかどうかを調べる には、 まずは周りを見渡すことから項 で示したリソースを使用するといいでしょ う。 登録商標に関する検索は 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 は「開発プロセスを 支配するようなつも りはない」ということを示しているわけです。 このように「問題が起こる可能性を認識 している」 ということを示すだけでも、問題の発生を回避するのに大いに効果があるの です。 一方、特定の企業の支援を受けているわけではないプロジェクトについては こ のような文言は不要でしょう。結局のところ、 普通はコミュニティーベースの開発にな るわけですから、 それをわざわざ示す必要はないわけです。 フリーであることを宣言する プロジェクトの目標についての説明 (ミッションステートメント) を読んで興味が残っ ているひとたちは、もっと詳細な情報を知りたくなることでしょう。 たとえばユーザー 向けドキュメントや開発者向けドキュメントなど。 そして、何かをダウンロードしたく なるでしょうね。 でもその前に、まずはそれがオープンソースなのかどうかを知る必要 があります。 プロジェクトのトップページで、 それがオープンソースであることを明記しておかなけ ればなりません。 当然のことだとお考えかもしれません。しかし、 世の中にはそれが できていないオープンソースプロジェクトが山ほどあります。 私がかつて見たとあるフ リーソフトウェアプロジェクトのウェブサイトのトップページでは、 そのソフトウェア の配布時にどのライセンスを適用するかが示されておらず、 さらにそのソフトウェアが フリーなのかどうかさえ書かれていませんでした。 また、このような重要な情報が ダ ウンロードページや開発者向けページなどにしか存在しないというページもよくありま す。 このような場合は、重要な情報を得るためにさらにマウスクリックが必要となって しまいます。 最もひどかった例では、ウェブサイト上のどこにもライセンスが示されて いなかったものもありました。 ソフトウェアをダウンロードしてその中身を見ない限り 、ライセンスの内容がわからなかったのです。 同じようなミスはしないでください。 そんなことをすると、せっかくの開発者候補やユ ーザー候補の多くを失うことになります。 トップページのミッションステートメント部 の次に、そのプロジェクトが 「フリーソフトウェア」あるいは「オープンソース」であ ることを示し、 さらに具体的なライセンスについても記しておきましょう。 どのライ センスを適用すればいいかについては ライセンスの選択と適用項で説明します。 また 、ライセンスに関するさまざまな問題については 第9章 で詳しく説明します。 ここまでの情報を見るのに、訪問者が要する時間は１分かそれ以下でしょう。 これらの 内容をもとに、彼/彼女 らがさらに次を読み進めるかどうかを決断するわけです。 次の セクションでは、最初の５分間で訪問者が見るであろう内容について扱います。 機能一覧・要件一覧 そのソフトウェアのちょっとした機能一覧 (まだ完成していない機能を一覧に含めても かまいません。しかしその場合は "予定" とか "開発中" などとはっきり示して置くよ うにしましょう)、 そしてそれを動かすために必要な要件についての説明が必要です。 機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに 答えるために まとめたものと考えるといいでしょう。 これは、単にミッションステートメントの内容 をより深く掘り下げたものと考えてもかまいません。 たとえば、ミッションステートメ ントで次のように説明したとすると、 豊富な API を備えた全文インデクサー・サーチエンジンを作成します。 大量のテ キストファイルに対する検索サービスを準備するプログラマーの利用を想定してい ます。 機能一覧、要件一覧でその詳細を説明することによって ミッションステートメントの範 囲を明確にします。 機能 ● プレーンテキスト、HTML および XML の検索 ● 単語あるいはフレーズによる検索 ● (予定) あいまい検索 ● (予定) インデックスの差分更新 ● (予定) リモートのウェブサイトのインデックス化 要件 ● Python 2.2 以降 ● インデックス作成用のディスク領域 (元のデータの約２倍の大きさ) これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうか を判断します。 また場合によっては開発者としてプロジェクトに参加することを検討し てくれるかもしれません。 開発の進捗状況 そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることで しょう。 特に新しいプロジェクトの場合は、 そのプロジェクトが掲げている目標のう ち 現在どれくらいが達成されているのかが気になるところです。 十分に成熟したプロ ジェクトの場合に気になるのは、 「そのプロジェクトが現在活発に保守されているのか 」 「どれくらいの頻度で新しいバージョンがリリースされているのか」 「バグレポー トに対する反応の速さはどれくらいか」 などとなります。 これらの質問に答えるために、開発状況を示すページを作らなければなりません。 ここ には、直近の目標とそれを達成するために必要なもの (たとえば「ある特定の分野に強 い開発者を募集しています」など) を表示します。また、過去のリリース履歴や機能一 覧などもここに掲載するといいでしょう。 そうすることで、そのプロジェクトが「進捗 」というものをどのように定義し、 その定義にしたがってどのくらい速く前進している のか、 ということが訪問者にわかるようにしておきます。 まだできあがっていないことを恐れる必要はありません。 できあがってもいないことを 変にごまかすこともやめましょう。 ソフトウェアの開発にはいくつかの段階があること を、みんな知っています。 "このソフトウェアはアルファ版です。既知のバグが存在し ます。 とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにして ください" と言ったところで、何も恥ずかしいことはありません。 そのような段階でプ ロジェクトが必要としている開発者は、 「アルファ版」という説明なんかではおびえた りしません。対エンドユーザーという面では、 まだできあがってもいないソフトウェア にユーザーが群がってしまうほどまずいことはありません。 いったん「不安定」だとか 「バグだらけだ」だとかいう評判が出てしまうと、 それを払拭するのは大変な話になり ます。 結局のところ、多少保守的なほうがうまくいきます。 そのソフトウェアが「ユ ーザーが期待しているよりも安定していた」 ほうが、期待はずれだった場合よりもずっ といいでしょう。 そしてそのほうが、口コミによる広がりが期待できます。 アルファ版/ベータ版 アルファ版 とは、通常は一番最初のリリースのことを指します。 とりあえずは動かす ことができ、ひととおりの機能はそろっていますが、 まだバグが残っている状態です。 アルファ版の主な目的は、 利用者からのフィードバックを得ることです。それによって 開発者は、 何に取り組むべきかを知ることができます。 その次の段階となるのがベー タ版です。 これは、致命的なバグはすべて修正済みとなっていますが、 まだリリース に向けての十分なテストが行われていない状態です。 ベータ版の目的には２種類ありま す。 １つには、バグが見つからない場合にそれをそのまま公式リリースとすることです 。 もう１つには、公式リリースを早く行うため、 開発者が詳細なフィードバックを受 け取れるようにすることです。 アルファ版とベータ版の差をどこにおくかは、あなたし だいです。 ダウンロード 標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要が あります。 プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージ はなくてもかまわないでしょう。 ただし、ビルド手順が面倒だったり依存性が複雑だっ たりして、 ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は 、 バイナリ版も必要です (でも、 そんなプロジェクトは開発者にとってはあまり魅力 的ではありません)。 配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。 あ なたがある病気の撲滅を狙っているなら、 薬を配る際に独自の注射器が必要となるよう な面倒な手段はとらないでしょう。 同様に、ソフトウェアについても標準的な手順で ビルド・インストールできるようにしておきましょう。 標準から外れれば外れるほど、 ユーザー候補や開発者候補は狼狽してそのプロジェクトから離れてしまいます。 当然のことだと思われるかもしれません。 しかし、多くのプロジェクトは本当に切羽詰 るまで インストール手順を標準化しようとはしないものです。 "ま、リリースに近づい たら そのときにやろうよ。そんなことはいつでもできるんだから。" といった言い訳を してしまいがちです。 彼らはわかっていないのですが、そういった作業を後回しにして しまうと、 結果的にリリースに近づくまで余計に時間がかかってしまうのです。 なぜ ならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでし まうからです。 もっとも悪いことに、彼らはそのような開発者を失いつつあることに気 づきません。 なぜならば、この過程は 「誰かがウェブサイトを訪れた→ソフトウェアを ダウンロードした →ビルドしようとした→失敗した→あきらめた」 という、イベントが発 生しなかったことの積み重ねだからです。 あきらめた本人以外には、そんなことがあっ たということはわかりません。 もともとあなたのプロジェクトに興味を持っていてくれ たはずの人が黙って立ち去ってしまった、 そしてそれをプロジェクトのメンバーは誰も 気づかないのです。 面倒だが見返りの大きい作業は、できるだけ早めに済ませてしまいましょう。 パッケー ジをきちんと作成すると、 プロジェクトへの参加障壁を劇的におろすことができ、 結 果として大きな見返りを得ることになります。 ダウンロード用のパッケージをリリースするときは、それに対して 一意なバージョン番 号を与えることが大切です。 それによって人は、２つのリリースのうちどちらが新しい のかを知ることになるのです。 バージョン番号のつけかたについては 第7章 の リリー スに番号を付ける項 で、 そしてビルド手順やインストール手順の標準化については同 じ章の パッケージング項 でそれぞれ詳しく説明します。 バージョン管理システムやバグ追跡システムへのアクセス 単にそのソフトをインストールして使いたいだけという人にとっては、 ソースパッケー ジで十分でしょう。しかし、デバッグをしたり 機能追加をしたりしたい人たちにとって はそれだけでは不十分です。 毎晩最新ソースのスナップショットを作成するという手も ありますが、 開発が活発に行われているコミュニティーではまだこれでも完璧だとはい えません。 常にその時点の最新のソースにアクセスしたいという人たちにその手段を提 供するのが、 バージョン管理システムです。 バージョン管理システム上のソースに匿 名でアクセスできるようにしておくと、 「このプロジェクトは、新しいメンバーの参加 を歓迎しています」 というメッセージをユーザーと開発者の両方に送ることになります 。 もし今すぐにバージョン管理システムを用意できない場合は、 近々公開予定である というメッセージを書いておくようにしましょう。 バージョン管理システムについては 第3章 の バージョン管理項 で詳しく説明します。 バグ追跡システムについても同じです。 バグ追跡システムの意義は、開発者に対する有 用性だけでなく、 それがプロジェクトの観察者に対して発している暗黙のメッセージに も存在します。 多くの人は、バグデータベースが公開されていると 「熱心に開発が進 められているようだ」と感じます。 さらに、バグデータベースにたくさんのバグが登録 されていればいるほど、 そのプロジェクトの見栄えはよくなります。 ちょっと直感に 反しているように思われるかもしれません。でも考えてもみてください。 バグデータベ ースに登録されたバグの数が実際何に依存しているかというと、 それは次の３つです。 まず、そのソフトウェアに存在するバグの絶対数。 次に、そのソフトウェアを使用して いるユーザー数。 そして最後に、ユーザーが新規のバグを登録できるための利便性です 。 このうち最初の１つよりも後ろの２つの方が重要な要素になります。 ある程度の規 模と複雑さを持つソフトウェアには、 基本的にバグが含まれているものです。本当の問 題は、 それらのバグをいかにして見つけ、どのように優先順位を設定するかというとこ ろにあります。 したがって、よく整備された (バグに対する対応がすばやく、 重複し たバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、 バグ データベースがなかったりほとんど機能していなかったりするプロジェクトより ずっと 印象がよくなります。 もちろん、そのプロジェクトが本当に始まったばかりなのなら バグデータベースに登録 される内容はほんのちょっとだけになるでしょう。 それについてはどうにもしようがあ りません。 しかし、プロジェクトが始まったばかりであることがどこかにきちんと書い てあり、 かつデータベースに登録されているのが最近登録されたバグばかりであったと すると、 プロジェクトのバグ登録が健全な比率を保っている、 ということを読み取る ことができます。 彼らはバグ登録の絶対数が小さいことを不当に警戒することはないで しょう。 バグ追跡システムに登録されるのはソフトウェアのバグだけではありません。 機能追加 の要望やドキュメントの変更、 とりあえず保留になっている作業などが登録されること も多々あります。 バグ追跡システムの運用方法については 第3章 の バグ追跡システム 項 で詳しく説明するので、 ここでは深く立ち入りません。プロジェクトの見栄えとい う観点から見て大切なのは、 まずバグ追跡システムが 存在する ということ。 そして それがプロジェクトのトップページからたどれる場所にあるということです。 連絡手段 プロジェクトの関係者の連絡先を知りたいという人もあらわれることでしょう。 関係者 と連絡を取れるように、メーリングリストのアドレスや チャットルーム、IRC チャンネ ル、掲示板などの場所を示しておきましょう。 あなた、あるいはその他のプロジェクト 関係者がこのメーリングリストに参加していることも明記しておきましょう。 そうする ことで、「そこに行けば開発者と話すことができる」ということが伝わります。 あなた がメーリングリストに参加しているからといって、 すべての質問に答えなければならな いとか すべての要望に答えなければならないとかいった義務が発生するわけではありま せん。 長い目で見れば、ユーザーのほとんどはこのようなメーリングリストや掲示板に は参加しません。 とはいえ、必要ならいつでも参加できるということを示すだけで、 安心感を与えることができます。 プロジェクトを立ち上げたばかりのころは、 エンドユーザー向けと開発者向けにフォー ラムを分ける必要はありません。 それよりも、プロジェクトにかかわる人たちが１つの 「部屋」 に集まってわいわいがやがや話をするほうがずっといいでしょう。 アーリー アダプター層においては、開発者とユーザーの区別はあいまいです。 あえて分類すると しても、プロジェクトの初期には開発者の比率がかなり高くなります。 アーリーアダプ ターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。 しかし 、少なくともそのプロジェクトの今後の方向性に関する議論には 興味を持っていること でしょう。 本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。 こ の段階では「とりあえずコミュニケーション用の場所が必要だ」というくらいで十分で しょう。 後で、第6章 の 巨大化への対応項 においてさらに詳しく説明します。 ここ では、掲示板の設置や管理の方法について扱います。 また、いつかユーザー向け会議室 と開発者向け会議室を分割することになったときに、 両者の間に溝を生じさせないため の方法も説明します。 開発者向けのガイドライン 開発者としてプロジェクトに参加しようと考えた人は、 まず開発者向けのガイドライン を探すことになるでしょう。 このガイドラインは、技術的なものというよりもむしろ社 会的なものとなります。 たとえば開発者同士のやりとりの方法、ユーザーとのやりとり の方法、 プロジェクトをうまく進めるためにどのようにしていくかなどです。 このトピックについては 第4章 の 全てを記録しておく項 で詳しく説明します。 ここ では、そこに含める基本的な内容だけをまとめておきます。 ● 他の開発者とのやり取りのためのフォーラムの場所 ● バグ報告やパッチの投稿の方法 ● 開発の基本方針— 「慈悲深い独裁者」式でいくのか「民主主義」式でいくのか、 あ るいはそれ以外の手法をとるのか ところで、「独裁者」という言い方には、特にそれを批判する意図はありません。 特定 の開発者だけがすべての変更に対する拒否権を行使できる というような専制政治を行っ てもまったく問題はありません。 実際、多くのプロジェクトはこの方式で成功していま す。 大事なのは、そのプロジェクトがそういう方針で運営されているとはっきり示して おくことです。 実際には独裁型なのに無理に民主主義っぽく見せようとすると、 人は 離れていってしまいます。きちんと独裁型であることを宣言しておけば、 少なくともそ の独裁者が有能で信頼できる人である限りはうまく進みます。 開発者向けガイドラインの実例は http://svn.collab.net/repos/svn/trunk/www/ hacking.html をご覧ください。また、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://svn.collab.net/repos/svn/trunk/www/hacking.html のように) が、そうしなければならないというわけではありません。 開発者ドキュメントがいかに有用なものであったとしても、 それが原因でリリースを遅 らせるようなことがあってはなりません。 そのプログラムの作者自身がコードに関する 質問に答えられる (そして答える気がある) のなら、当面はそれで十分です。 実際のと ころ、何度も何度も同じ質問に答える羽目になるっていうことが ドキュメント作成の動 機となることもあります。 しかし、ドキュメントを書き始める前であっても、 プロジ ェクトに協力することを決心した人たちは 何とかコードと格闘しようとするものです。 何が人をそこまでさせるのかといえば、 そのコードがきっと何か自分の役に立つだろう と考えているからです。 人がそれを信じていれば、自分自身で何とかしようとするでし ょう。 信じていなければ、大量の開発者向けドキュメントがあったとしてもあまり役立 たないでしょう。 なので、もしどちらか一方に向けたドキュメントしか書く時間がないのであれば、 まず ユーザー向けのドキュメントを作成しましょう。 ユーザー向けのドキュメントは、事実 上 開発者向けのドキュメントでもあります。 そのソフトウェアの開発に参加しようと しているプログラマーは、 まずそのソフトウェアの使い方を身に着けなければならない からです。 後になって他のプログラマーが同じような質問を 何度も何度も繰り返すよ うになったときに、 あらためて時間をとってドキュメントを作成すればいいでしょう。 プロジェクトによっては 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章 の ツールが一通り揃ったホスティングサ イト項 をご覧ください。 ライセンスの選択と適用 このセクションでは、ライセンスの選択方法について 手っ取り早く大雑把に説明します 。 個々のライセンスについての法的な意味合いや 他のフリーソフトウェアと組み合わ せて使用する際に出てくる影響などについての詳細は 第9章 をご覧ください。 世の中には、フリーソフトウェア用の優れたライセンスがたくさんあります。 ここでは 、そのほとんどについては取り上げません。 なぜならそれらは特定の人や組織の法的な 需要を満たすためだけに書かれたものだったり あなたのプロジェクトには適切でないも のだったりするからです。 ここで取り上げるのは、よく用いられているものに限定しま す。 ほとんどの場合は、ここで取り上げたものの中からライセンスを選択することにな るでしょう。 「何でもできる」ライセンス あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にならないの なら、 MIT/X スタイル のライセンスを使用しましょう。 これは必要最小限のことのみ を記したライセンスです。 このライセンスは、名目上の著作権 (実際には複製を制限し ません) と無保証であるということだけを明記するシンプルなものです。 詳細は MIT/X Window System ライセンス項 を参照してください。 GPL あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にいらないの なら、 GNU General Public License (http://www.gnu.org/licenses/gpl.html) を使用 しましょう。 GPL は、おそらく現在世界中でいちばんよく知られているフリーソフトウ ェアライセンスです。 これは最大の利点です。というのも、 プロジェクトに参加しよ うと考えているユーザーの多くはこのライセンスを知っており、 そのライセンスについ て学習する手間が省けるからです。 詳細は、第9章 の GPL項 を参照してください。 ユーザーがあなたのコードとネットワーク越しにやりとりする場合 — つまり、ソフトウ ェアがネットワーク上でホストされたサービスの一部である場合は — GNU Affero GPL の利用を検討してください。 詳しくは、第9章 の GNU Affero GPL: サーバサイドにあ るコード向けの GNU 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 この文面では、ライセンスの全文がプログラムに同梱されているファイル COPYING に存 在することは明記されていません。しかし、通常はこの名前のファイルを使用すること になります (上の文面を変更して、このファイル名を明記するようにしてもかまいませ ん)。 このテンプレートには、ライセンスのコピーを取得するための手紙の宛先も記載 されています。 これ以外の一般的な方法としては、ライセンスの本文を記載したウェブ ページへのリンクを用意するというものもあります。 あなたの自己判断で、ライセンス のコピーが最も恒常的に存在すると思われる場所を使用するようにしましょう。 たとえ ば、あなたのプロジェクトのウェブサイト上のどこかでもかまいません。 一般的には、 各ソースファイル中に含める注意書きは上のものと全く同じである必要はありません。 著作権保有者と日付、ライセンスの名前、そしてライセンスの全文がどこで取得できる のか といったことが含まれていればいいのです。 うまく引っ張っていく ここまで取り上げてきたのは、プロジェクトの立ち上げ時に一度だけ必要となる作業で した。 ライセンスの選択や最初のウェブサイトの作成などです。 しかし、プロジェク ト開始時に最も大切なのは、それ以外の動的な作業です。 メーリングリストのアドレス を決めるなんていうのは簡単なことです。 でも、そのメーリングリストでのやり取りを 有益で前向きなものに保つのは それとはまったく別の話となります。 これまで何年に もわたって社内の閉じた環境で開発が進められてきたものをオープンにすると、 その開 発プロセスはこれまでとはかわります。これまでの開発者たちに対して、 その変更に対 応できるように準備をさせなければなりません。 最も困難なのが、はじめの一歩です。なぜなら、今後の方向性に関する先例もなければ 今後どのようになっていくのかもまだはっきりわからないからです。 プロジェクトの安 定性は、形式張った方針からくるものではなく、 開発者の間で徐々にできあがっていく 集合知によってもたらされるものです。 そして、これはしっかりとらえにくいものです 。 明文化された規則があることもありますが、それはたいてい、 プロジェクトを本当 に動かしているこれらの無形の合意をまとめあげたものにすぎません。 明文化された方 針によってプロジェクトの文化を定義することはできませんし、 それに近づくことさえ できません。 このようになるには、いくつかの理由があります。 成長と変化の速さは、人が考えるほ どには文化の蓄積に影響を与えません。 変化の速度があまりにも高速にならない限り、 新入りさんがそれを学ぶ時間はあります。 そして学び終えた後は、自分自身でそのやり かたを補強してくれるでしょう。 童謡が、いったいどのようにして何百年も歌い継がれ るようになったのかを考えてみましょう。 現在の子どもたちが歌っている童謡は、基本 的には数百年前の子どもたちの歌っているものと同じです。 もちろん、昔の子どもたち が童謡を歌っていた頃には現在の子どもたちはまだ産まれていません。 子どもたちはそ の歌を年長者から聞いて覚えます。そして子どもたちが成長すると、 年少者の前でそれ を歌って聞かせるわけです。もちろん、 子どもたちは意識的にそうするよう指示されて いるわけではありません。 しかし、何百年も同じ歌が歌い継がれているという事実は、 このような伝承が常に繰り返し行われていることを示しています。 フリーソフトウェア プロジェクトの歴史が今後何百年も続くかどうかはわかりません (どうなるかはまだわ かりません) が、この仕組みは似たり寄ったりでしょう。 しかし、その回転率はより高 速になるので、 より活発かつ慎重に伝承を行うようにしなければなりません。 この動きは、人が基本的に社会規範を求めているという性質があるので成功しやすくな ります。 それこそが人が存在する理由なのですから。 一般的な方法でまとめあげられ た集団なら、そこに参加しようとする人々は 本能的にその集団の一員として振る舞うた めのやりかたを見つけようとするものです。 より早い時期に先例を確立するには、その プロジェクトに役立つ 「グループとしての」振る舞いを作ることです。いったんできあ がってしまえば、 あとは勝手にそれが広まっていきます。 以下に示すいくつかの例は、 よりよい先例を作るためにできる具体的なことをまとめた ものです。 これだけを行えば完全だというものではありません。単に、 「早いうちに 協力的なムードを作り上げておくとプロジェクトを運営しやすくなりますよ」 というこ とを説明するためだけのものです。 物理的には、個々の開発者がそれぞれ別の場所で作 業をしているのかもしれません。 しかし、まるで同じ部屋で一緒に開発しているかのよ うに 感じさせる ために、いろいろなことができます。 彼らがこのように感じてくれれ ばくれるほど、プロジェクトに対してより時間をさきたいと思うようになるでしょう。 以下の例は、Subversion プロジェクト (http://subversion.tigris.org/) から選びま した。私は、開始当時からこのプロジェクトに参加しています。 しかし、これらの例は 決して Subversion 独特のものではありません。 同様の状況は大半のオープンソースプ ロジェクトで起こりえるでしょう。 また、プロジェクトに片足を突っ込む際には意識し ておく必要があることばかりです。 個人的な議論を避ける プロジェクトを一般に向けて公開した後でも、難しい問題についての話し合いは 内輪の 関係者たちだけで行いたいと考えることもあるでしょう。 これは、プロジェクトが始ま ったばかりのときにはあり得ることです。 話し合うべきことは山ほどありますし、通常 は その話し合いに参加する資格のある外部の協力者はほとんどいないからです。 公開 されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことで しょう。 メールでのやりとりに特有ののんびりした速度、 合意を形成するのにかかる 時間、本当は何もわかっていないのに 「自分はすべてわかっている」と勘違いしている ボランティアへの対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人 かは将来すばらしい貢献をしてくれることになるでしょうが、 中にはずっと勘違いした ままの人だっています)、ある問題 X がより大きい問題 Y の一部であるときに、 なぜ 問題 Y ではなく問題 X だけを解決したいのかを理解してくれない人たち、 などなど。 こんなときに、密室の話し合いで決めた内容を "既成事実 (faits accomplis)"、 ある いは少なくとも有力な選択肢として提示できればどんなに楽なことでしょう。 でも、そんなことをしてはいけません。 たとえ公開の場での議論の進行が遅くて厄介だとしても、 長い目で見ればそれが一番望 ましい方法です。 重要な決定を内輪でこっそり行うのは、まるでそのプロジェクトに 「貢献者よけスプレー」を振りまくようなものです。 秘密の協議会がすべての重要な決 定を行うというような環境では、 やる気のあるボランティアは決してついてこないでし ょう。 さらに、公開の場での議論にはよい副作用もあります。 ● その議論が、新しく参加する開発者の訓練や教育に役立ちます。 その議論をいった いどれだけの人が注目しているかは決してわかりません。 大半の人たちは単なる傍 観者として見ているだけで、 黙ってそのソフトウェアについての情報を追いかけて いるのです。 ● その議論は、あなた自身 の訓練にもなります。 技術的な問題を、そのソフトウェ アにあまり詳しくない人たちにもわかるように説明するという技術を磨くことがで きます。 これは実際に必要となる技術であり、 すでにそのソフトウェアについて 熟知している人たちと話しているだけでは身につけることができません。 ● 議論の内容とその結論が公開されたアーカイブに残るようになります。 後に同じよ うな問題が発生したときに、同じ議論を繰り返す必要がなくなります。 詳細は 第6 章 の アーカイブを目に付きやすくする方法項 を参照してください。 最後に、メーリングリスト上の誰かがそのやり取りに対して真の貢献をしてくれるかも しれません。 つまり、あなたが思いもしなかった新たな考え方を示してくれるというこ とです。 これがどのくらいの頻度で起こるのかは断言できません。 そのコードの複雑 さがどれくらいか、そしてどの程度の専門知識を要するかによっても異なります。 ただ 、私のこれまでの経験上、その頻度はみなさんが思っているよりもかなり高くなります 。 Subversion プロジェクトで、私たち (プロジェクトを開始した当時のメンバー) は 深く複雑なさまざまな問題に直面していました。私たちは何ヶ月も悩み続けました。 そ して、率直に言って、当時できたてのメーリングリストにいるメンバーがこの手の議論 に貢献してくれるとは期待していませんでした。 そこで私たちは安易な方法をとること にしました。技術的なアイデアについての議論を個人的なメールのやりとりで行うよう にしだしたのです。 その様子を嗅ぎ付けた人 ^[14] から「議論は公開されたメーリン グリストでしてくれ」 と言われるまで、その状態が続きました。私たちはそれを受け入 れ、その話題をメーリングリストに移動しました。 そのとたん、数々の洞察に満ちた意 見や提案が寄せられるようになり、私たちは驚きました。 寄せられた意見の多くは、こ れまで私たちが考えもしなかったものでした。 メーリングリスト上には、非常に 優秀 な人間がいたのです。 彼らはただ、メーリングリスト上にネタが投下されるのを待ちわ びていたのです。 確かに、すべて密室の議論ですませるのに比べれば時間はかかりまし た。 しかし、時間をかけたのに十分見合うだけの成果が得られました。 "三人寄れば文殊の知恵" だとか "個人よりも集団のほうが常によい判断ができる" とか いうように一般化して逃げてしまうのではなく、 集団のほうがよい結果がでる活動とし てはどんなものがあるのかを知っておきましょう。 大規模なピア-レビューなどがその 例のひとつです。 あるいは、とにかくたくさんの案を手早く出していくといった作業も それにあたります。 もちろんアイデアの質はそれを考えた人たちの質に依存しますが、 困難な問題を皆にぶつけてみるまで、誰がどのような案を持っているかはわからないも のです。 当然、内容によっては個人的に議論しなければならないものもあります。 本書の中でも そのような例がいくつか登場します。 しかし、基本方針として、隠す必要がないものは 、すべて公開すべきである ということは常に心においておきましょう。 そのためには何らかのアクションが必要です。 あなた自身が常に公開のメーリングリス トに投稿しようと心がけるだけでは不十分です。 隠す必要がない内容のメールを他の人 から受け取ったら、 それをメーリングリストにも流すようにしなければなりません。 誰かが個人的に議論を始めようとしているとき、もしそれが個人的にする必要のないも のなら、 それを個人的に行うのか公開で行うのかに関する議論をすぐに始める責任があ ります。 首尾よくその議論を公開の場に持ち出すか、 あるいは個人的に話し合うのが 適切であることがわかるまで、 元の話題にはコメントしないでください。 常にこのよ うにすることを心がければ、 人はやがてデフォルトで公開の場を使用することになるで しょう。 炎上を阻止する プロジェクトを一般に公開したら、 フォーラムにおける失礼な振る舞いや侮辱的な発言 にはゼロトレランスで (情け容赦なく) 対処しなければなりません。「ゼロトレランス で」とは、 何か技術的に特別なことをしなければならないという意味ではありません。 別の参加者を罵倒した参加者をメーリングリストから強制退会させる必要はありません し、 人を傷つけるようなコメントをしたからといってその人のコミット権を剥奪する必 要もありません (理屈上は、結局のところそういった措置をとらざるを得ないことにな るかもしれません。 しかし、それはさまざまな対策がすべて失敗したときの最後の手段 とすべきです。 つまり、プロジェクトの開始当初にはそのようなことは起こりません) 。 ここで言うゼロトレランスとは、そんな振る舞いを決して見過ごさないということで す。 たとえば、技術的なコメントといっしょに プロジェクトの他の開発者に対する個 人攻撃 (ad hominem) を含むコメントが投稿されたとしましょう。そんな場合は、まず その個人攻撃に対する指摘をしたうえで、技術的な内容についてはそれとは分けて返答 するようにしましょう。 残念ながら、これは易しいことではありません。 そして、たいていは建設的な議論が不 毛な罵倒合戦に陥ってしまいます。 人は、面と向かっては決して言えないことでもメー ルでは平気で言ってしまうものです。 また、議論の内容もこの傾向に拍車をかけます。 技術的な問題に関して、多くの人は「ほとんどの質問には正解がひとつしかない」 と考 えがちです。そしてその答えに同意しない人のことを無知で愚かな人だと思ってしまう のです。 誰かの技術的な提案を否定すると、その人自身の人格を否定したように受け取 られることもあります。 実際、技術的な議論が人格攻撃に切り替わる瞬間を見極めるの は非常に難しいものです。 厳しめの返答や処罰がいい考えではないひとつの理由がここ にあります。 そのかわりに、ちょっと雰囲気が怪しくなってきたなと感じたら、 議論 を友好的に進めるように促す投稿をするようにしましょう。 その際に、特定の人物が意 図的にそんなことをしているように非難することは避けなければいけません。 しかし、 そのような "町のおまわりさん" 的な投稿は、 時として園児をしつける幼稚園の先生の ように見えてしまうという傾向があります。 まず最初にひとこと。個人攻撃につながる (あるいはその恐れのある) コメントは 控えてください。たとえば、J が設計したセキュリティ層について "コンピュータ のセキュリティに関する基礎知識に欠ける無能な設計だ" と語るようなことです。 それが正しいかどうかは別にして、 これは議論の進め方としては間違っています。 J は信念を持ってこの提案をしたわけです。 もし問題があるならその問題を指摘し ましょう。 そして皆でそれを修正するか、新しく設計をやりなおせばいいじゃない ですか。 M は決して J を個人攻撃するつもりがないことは知っています。 でも、 その言い方はちょっとまずかった。もっと建設的な議論を進めましょう。 さて、提案内容に話を戻しましょう。 私は、M の言うことはもっともだと思います …… ちょっと堅苦しく感じるかも知れませんが、これはかなりの効果があります。 何かあっ たら必ず口を出すが、決して攻撃側に謝罪を要求したり落ち度を認めさせたりしない。 そうではなく、そのまま放っておいて次回はよりおだやかに振舞うように促すのです。 そうすれば彼らはきっとそれに従ってくれます。 これをうまく行う秘訣のひとつは、ど っちが悪いかとかどうすべきかといった メタ議論を主題にしてしまわないことです。そ うではなく、 本題に入る前の前置き程度の扱いにしておくべきです。 「ここではそん な振る舞いはやめてください」と指摘した後はすぐに本題に移ります。 そうすることで 、相手側にも本題に返答する機会を与えることができるのです。 もしそれでも「あなた に非難されるいわれはない」といったことを言われたら、 もうそれ以上その話題を引き ずるのはやめましょう。 単にその話題に関する返信をやめておく (単に彼らは自分の主 張を振りかざしているだけであり、 返事を求めているわけではなさそうな場合) か、あ るいは 「出すぎたまねをしてしまってごめんなさい。メールではなかなかニュアンスが 伝わりにくいので」 と謝ったうえで本題に戻ればいいのです。 不適切な振る舞いをし た人たちの主張は、公開の場であるか否かにかかわらず 決して認めないでください。も しかれらの方から謝罪があればすばらしいことですが、 こちらから謝罪を要求しても相 手をさらに怒らせるだけでしょう。 最終的な目標は、その集団に「礼儀をわきまえる」という空気を作り上げることです。 これは、プロジェクトにとって大きな助けとなります。なぜなら、開発者が (自分が好 んでサポートしようとしている) プロジェクトで罵倒合戦に巻き込まれる心配がなくな るからです。 そんなことが原因で開発者候補がプロジェクトが離れていることに、あな たは気づかないかもしれません。 誰かがメーリングリストにひっそり参加してそのプロ ジェクトの状況を観察し、 参加するための障壁が厚いことがわかり、結局参加すること をあきらめるということがあるかもしれません。 フォーラムを友好的な雰囲気にしてお くことが、長期的に生き残るための作戦として有効です。 また、これはプロジェクトが 小さいうちから心がけておいたほうが実現しやすいことです。 いちどそんな文化ができ あがってしまえば、あなたひとりがいちいちそれを主張して回る必要もなくなるでしょ う。 皆がそういうふうに持って行ってくれるからです。 きちんとしたコードレビューの習慣 開発コミュニティーをうまく育てていくために最適な方法は、 開発者どうしがお互いの コードを見せ合うことです。 これを効率的に行うには、技術的な支援が効果的です。特 に便利なのが、コミット時のメール通知です。 これについては コミットメール項 で詳 しく説明します。 コミットメールとは、誰かがソースコードに加えた変更をコミットす るたびに そのログメッセージと変更内容をメールで送る機能のことです (バージョン管 理に関する用語集項 の 差分 を参照してください)。 コードレビュー とは、コミット メールがやってくるたびにその内容を確認し、 バグや改善点がないかどうかを探す作業 を指します。 ^[15] コードレビューは、さまざまな点で役立ちます。 オープンソースの世界におけるコード レビューの最大の効果は、 ソフトウェアの品質を一定に保つことです。 ソフトウェア にバグが含まれる原因は、 コミットされたコードをきちんとチェックしなかったことに あります。 コミットの内容を多くの目でチェックすることで、 バグを残したまま公開 してしまう危険性を減らすことになります。 しかし、コードレビューの目的はこのよう な直接的なものだけではありません。 コードレビューによって、自分たちの作業の内容 を確認させることができます。 コミットの内容をレビューするには、その作業について よく知っておく必要があるからです。 他の人が自分の作業を評価すると知っていれば、 人は最善を尽くして作業を行うようになります。 レビューは公開の場で行わなければなりません。 開発者同士が物理的に同じ部屋にいる 場合であっても、 誰かがコミットしたときにそのレビューを部屋の中だけで済ませてし まってはいけません。 面倒でも開発者用のメーリングリストに投稿するようにしましょ う。 そのレビューを見ることで、参加者全員が何かを得ることになります。 レビュー の結果、何らかのコメントをしたり、 場合によっては不具合を見つけたりすることもあ ります。 レビューは日常の作業のひとつととらえましょう。 そう。ちょうど皿洗いや 芝生の手入れと同じような感覚です。 Subversion プロジェクトの開始当初は、日常的なコードレビューの習慣はありませんで した。 すべてのコミットがレビューの対象になるという保証はありませんでしたが、 変更されたコードの内容に興味のある人がそれを眺めるということはありました。 当時 のコードに紛れ込んでいたバグは発見可能でしたし見つけられるべきでした。 当時の開 発者のひとりである Greg Stein は、 過去の経験からコードレビューが役立つことを知 っていました。 彼は、リポジトリへの すべてのコミット の１行１行の内容を詳細にま でわたってレビューするようになりました。 誰かがコミットするたびにそのコミットに ついての Greg からのメールが 開発者用メーリングリストに流れました。メールの内容 は、 コミットの内容を細かく切り刻んで分析し、起こりうる問題を指摘するといったも のです。 時には、優れたコードに対して賞賛を送ることもありました。 コミットがあ るたびに、バグを見つけたり 注意しないとつまづくく恐れのあるあまりよい書き方では ないコードを見つけたりしていたのです。 彼は、コミットの内容をレビューするのが自 分ひとりであることについて、 表立っては不平を述べることはありませんでした。 か なりの時間をレビューに費やしていたにもかかわらずです。 その代わりに、ことあるご とにコードレビューのすばらしさについて発言していました。 やがて、私を含めた他の メンバーもコミットの内容を定期的にレビューするようになりました。 何がそうさせた のでしょう? 決して Greg が私たちにそれを強制したわけではありません。 彼は「コー ドのレビューが時間をかけるだけの価値のあるものである」こと、そして 「他人のコー ドをレビューすることは新しいコードを書くのと同じくらいに重要である」 ことを自身 の行動をもって証明したのです。 いざそういう習慣が身につくと、自分のコミットに何 の反応もなければ逆に不安になります。 開発者用メーリングリストで「誰か私のコード をレビューしてくれないかな?」 と聞いてみたりなんかして。後に、Greg は別の仕事を 得ることになり、 Subversion にあまり時間をかけられないようになってしまいました 。 彼は定期的なレビューをあきらめざるを得なくなったのです。 しかし、そのときに はすでにレビューの習慣が私たちにも深く根付いていました。 まるで太古の昔からそれ が当たり前であったかのように。 コードのレビューは、最初のコミットの時点から始めましょう。 差分を見れば簡単に発 見できる問題としては次のようなものがあります。 たとえばセキュリティ上の脆弱性や メモリリーク、 コメントや API ドキュメントの不足、「ひとつずれちゃった (off-by-one) エラー」、呼び出し元と呼び出し先の規約の不一致などです。 また差分 の前後を確認することで発見できる問題もあります。 しかし、より規模の大きい問題、 たとえば繰り返し登場するパターンを一か所にまとめていないことなどは、 定期的なレ ビューをしていないと見つけにくいものです。 過去の更新の履歴の記憶を今回の差分と 組み合わせることで、 このようなの問題も見つけやすくなるのです。 何もコメントすべき点が見つからないんじゃないかとか、 すべてのコードについて熟知 しているわけじゃないとかいったことを気にしないでください。 あらゆるコミットには 何かしら言うべきことがあるはずです。 何も疑問点が見つからなかった場合は、何か賞 賛の言葉を贈ればいいだけのことです。 大事なのは、すべてのコミッターに対して 「 あなたの作業内容を見ているし、理解もしている」というメッセージを伝えることです 。 もちろん「後でほかの人にレビューしてもらえるから、コミット前のチェックやテス トは不要」 というわけではありません。本来自分自身で発見すべき問題を、 他人のレ ビューに頼ってはいけません。 もともと非公開だったプロジェクトをオープンにするときには、 変化の大きさに気をつ けよう 既存のプロジェクトをオープンにする場合は、 クローズド環境での開発に慣れきった既 存の開発者がいることに注意しましょう。 環境が大きく変わることを彼らに理解しても らうこと、 また、彼ら側の視点で考えた場合に何がどのように変わるのかを あなた自 身が理解することが大切です。 彼らにとってその状況がどのようなものかを想像してください。 これまでは、どのよう な設計でどのようなコードを書くのかを決めるのは 特定のプログラマーの集団でした。 また、彼らは同じ管理者のもとで働き、 同じような重圧を受けていました。 そしてお 互いのスキルや弱点もよくわかっていました。 今やそうではありません。自分の書いた コードをチェックしてもらうために どこの誰ともわからない人に向かって公開しなけれ ばならないのです。 彼らは純粋にコードの内容だけをもとにして判断を下します。 そ れ以外のビジネス上の問題などは考慮しません。 自分のコードについて、見知らぬ人か らさまざまな質問が寄せられることになります。 あんなに苦労して作ったドキュメント が、まだ 不十分であることが判明して (お決まりのパターンです) 衝撃を受ける瞬間で す。 新入りさんは、みんな誰も知らない得体の知れない人たちばかりです。 もし既存 の開発者の中に自分のスキルに不安のある人がいたとしましょう。 新入りさんが何も考 えずに彼のコードの問題を指摘したら、 彼にどのような悪影響を及ぼすでしょうか。特 に、 彼の同僚の目の前でそのようなことが起こったら、さらに状況は悪くなります。 完全無欠のプログラマーが集まったチームでもない限り、 このような問題が起こること は避けられません。 実際、すべてのメンバーが一度はこのような経験をすることになる でしょう。 これは、決して彼らがプログラマーとして劣っているからではありません。 ある程度以上のサイズのプログラムには、必ずバグが含まれるものです。 そして、コー ドのレビューによってそれが見つかることになります (本章の前半にある きちんとした コードレビューの習慣項 をご覧ください)。 と同時に、新入りさん自身は最初のうちは 自分のコードをレビューされることはないでしょう。 というのも、そのプロジェクトに ある程度なじむまではコードを書くことができないからです。 既存の開発者にとっては 「奴らからさんざん批判されるだけで、 こちらからは言い返すことができない」という 状況になるわけです。 そのため、古株の開発者たちに対する総攻撃状態になる危険性が あります。 これを避ける最良の方法は、これから何が起こるのかを彼らに説明することです。 最初 のうちは不快に感じるかもしれないがそれは当然の心理であること、 そしていつかはう まくいくようになることを説明しましょう。 これらの警告は、プロジェクトをオープン にする前に 閉じた場所で行わなければなりません。 また、公開されたメーリングリス ト上で 「プロジェクトの開発方式が新しくなった」「なれるには少々時間がかかる」 ということを知らせるのも効果的です。 一番いいのは、なにか例を示すことです。 既 存の開発者たちがあまり初心者の質問に答えていないようなら、 彼らに「もっと返事を 書いてあげてよ」といってもあまり意味がありません。 彼らは単に、どう答えればいい のかがわからないだけかもしれません。 あるいは、他人の質問に答えるよりも 実際に コードを書くほうが大切だと思っているのかも知れません。 彼らを質問に答えさせるよ うにするには、まずあなた自身がお手本を見せましょう。 公開されているメーリングリ スト上で、誰かの質問に対して答えてみましょう。 その質問をうまくさばくだけの専門 知識がない場合は、 それに対応できる開発者に明示的に対応を依頼するようにしましょ う。 そして、彼が確かに答えを返すこと、 あるいは少なくとも何らかの返事をするこ とを確認しましょう。 長年プロジェクトにかかわってきた開発者にとっては どうして も閉じた場での議論のほうがやりやすく感じられることでしょう。 これまではずっとそ うしてきたのですから。 そんなことが起こらないように内輪のメーリングリストの動き もチェックし、 必要な議論は公開の場で行うように彼らを誘導しましょう。 これまでは閉じた環境にあったプロジェクトをオープンにするにあたっては、 これら以 外にも長期的な懸案事項があります。 第5章 では、給料をもらって開発に参加している 人たちと 無償で開発に参加している人たちとをうまく共存させる方法を考えます。また 第9章 では、法的な努力の必要性について考えます。 他の団体が書いた、あるいは "所 有している" コードを含むかもしれないソフトウェアを公開する場合は、 それなりの注 意が必要となります。 広報 プロジェクトが人に見せられる状態 (完全なものではなく、 単にとりあえず見せられる という程度) になったら、 それを全世界に向けて公開しましょう。 これは、実際には 非常に簡単なことです。まず http://freshmeat.net/ に行ってナビゲーションバーの Submit をクリックし、 フォームに内容を入力しさえすれば新しいプロジェクトを宣伝 できるのです。 Freshmeat は、新しいプロジェクトが気になる数多くの人が見ていると ころです。 あなたのプロジェクトに関するニュースがその中の何人かの目にとまれば、 後は口コミでその情報が広まっていくでしょう。 あなたのプロジェクトに関するお知らせを投稿するのに適したメーリングリストや ニュ ーズグループがあるのなら、そこに投稿するのもいいでしょう。 しかし、投稿するのは それぞれの場所で一度ずつだけにしておきましょう。 その後の議論は、(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 プロジェクトも実際に動くものがない状 態から始まりました。 そして今や人気のあるウェブブラウザとして大成功を収めていま す。 これらの事例を前にして、私は「実際に動くコードこそがプロジェクトの立ち上げに必 要だ」 という主張を曲げざるを得なくなりました。 動くコードがあることは成功のひ とつの要素ではあります。そして、経験上は、 動くものができあがるまではプロジェク トの公開を控えたほうがよいと思います。 しかし、とりあえず先に公開してしまったほ うがいいこともあります。 最低限、しっかりした設計ドキュメントか何らかのコード基 盤は必要です —もちろん、これは公開後のフィードバックを受けて改版することになる でしょう。 しかし、それだけではなく何か具体的なもの、 実際に触って試せるものが 必要です。 プロジェクトを公開したからといって、大量のボランティアが すぐにプロジェクトに参 加したがるとは思わないでください。 普通は、公開した後の反応といえばもっとおとな しいものです。 何人かはたいしたことのない問い合わせをくれるでしょう。 何人かは メーリングリストに参加してくれるかもしれません。 しかし、それ以外の大半の人たち にとっては、 そのプロジェクトが公開されたことなんて気にもしていないでしょう。 しかし時間がたつにつれて、開発者として参加してくれる人や 実際にソフトウェアを利 用してくれる人が徐々に増えていくことに気づくでしょう。 公開の発表は、種まきのよ うなものです。 そのニュースが広まるには、長い時間がかかります。 プロジェクトに 参加した人たちが何らかの利益を得ることになると、 ニュースがより広まるようになり ます。自分が見つけたすばらしいものを、 周りにも知らせてあげようという気持ちが働 くからです。 すべてがうまくいけば、そのプロジェクトは指数関数的に大きくなり、 複雑なコミュニティーに成長するでしょう。 そこまで来れば、もはや個々のメンバーの 名前を知っている必要もなくなります。 また、メンバー間の会話の内容をすべて追いか けることも不可能となります。 次の章では、このような環境を運営する方法を説明しま す。 ━━━━━━━━━━━━━━ ^[13] hack と activation を組み合わせた造語？ おそらく http://www.gnu.org/ software/guile/docs/docs-1.6/guile-ref/Programming-Overview.html からの引用だと 思われます。 ^[14] ここまではまだ個人の名前を挙げることはありませんでしたが、 これ以降では必 要に応じて名前を挙げていきます。ここでいう「嗅ぎ付けた人」 とは Brian Behlendorf のことです。彼は、 プライバシーの侵害の恐れがない議論はすべて公開の 場で行うべきだという一般論を指摘してくれました。 ^[15] これは、オープンソースプロジェクトでごく一般的に行われているコードレビュ ーの方法を示したものです。 より中央集権的なプロジェクトでは、複数の人が集まって ソースコードのプリントアウトを見つめ、 特定の問題やパターンを探すことを称して " コードレビュー" という場合もあります。 第3章 技術的な問題 目次 プロジェクトに必要なもの メーリングリスト スパム対策 投稿のフィルタリング アーカイブでのメールアドレスの処理 識別しやすいヘッダ Reply-to はどうすべきか 私のふたつの夢 アーカイブ ソフトウェア バージョン管理 バージョン管理に関する用語集 バージョン管理システムの選択 バージョン管理システムの使用法 すべてをバージョン管理する ウェブで閲覧できるようにする コミットメール ブランチの活用 情報の一元管理 承認 バグ追跡システム 議論の場としてメーリングリストを使う バグ追跡システムをあらかじめフィルタする IRC / リアルタイムに行なわれるチャットシステム ボット IRCの会話を保存する RSS フィード Wiki ウェブサイト ツールが一通り揃ったホスティングサイト ホスティングサイトを選ぶ 匿名性とプロジェクト参加 フリーソフトウェアプロジェクトを運営していくには、 さまざまな情報を取捨選択する 技術が必要です。 これらの技術を使いこなせばこなすほど、また周りの人に使わせれば 使わせるほど、 プロジェクトがうまくいく可能性が高くなります。 プロジェクトの規 模が大きくなればなるほど、この傾向は強まります。 うまく情報を管理しないと、オー プンソースプロジェクトは ブルックスの法則 ^[16] (プロジェクトの終盤になってから 人を増やしたところで、 かえってプロジェクトの完成が遅れてしまう) の罠に陥ってし まいます。 Fred Brooks は、プロジェクトの複雑度はそれにかかわる関係者の数の ２ 乗に比例するとしています。 メンバーの数がほんの数人の時は、簡単にお互いの意思疎 通ができます。 しかしメンバーが数百人規模に膨れ上がると、 もはや他のメンバーが 何をしているのかをすべて把握することは不可能です。 フリーソフトウェアプロジェク トを管理する秘訣は、 お互いがまるでひとつの部屋に集まってともに働いているかのよ うに感じさせることだといいます。 では、もし混雑した部屋に詰め込まれたメンバーが みんないっせいに話し始めたら、 どんなことになるでしょう? これは、特に目新しい問題ではありません。 たとえ話ではない実際の混雑した部屋では 、このような場合の解決法は 議会制、つまり大人数の集団で議論を行う際の手順を決め ることです。 重要な異議が「異議なし!」の大合唱にかき消されてしまわないようにし たり、 いくつかの小委員会を構成したり、議決方法を定義したりといったことです。 この制度で重要なのは、その集団が情報管理システムをどのように利用するかというと ころです。 "正式に記録される" 情報もあれば、そうでないものもあります。 記録自体 は方向性を決めるためのものです。 「何が起こったのか」を単に書き記したものではな く、 その集団で何を 合意 しようとしているのかを表すものと考えます。 記録は、目 的によってさまざまな形式で行います。 個別の打ち合わせの議事録、すべての打ち合わ せの議事録をまとめたもの、 その概要、議題、コメント、委員会の報告書、 その場に いない通信員からの報告、宿題の一覧などが記録に含まれます。 インターネットは実際の部屋とは異なるので、 「誰かが発言しているときは他のメンバ ーは静かにそれを聴く」 というようなしきたりにこだわる必要はありません。情報管理 技術を駆使すると、 オープンソースプロジェクトにおける議論の手順はより効率的にな ります。 オープンソースプロジェクトでは、ほぼすべてのやりとりは文字によって行わ れます。 そこで、情報を振り分けたり適切なラベル付けをしたりするためのシステムが 発達してきました。 繰り返しを最小限に抑えて間違った方向に進みにくいようにしたり 、 データを保存して検索しやすくしたり、 間違った情報や古びた情報を訂正したり、 あちこちに散らばった情報をまとめてそれらのつながりを見出したりといった作業のた めのシステムです。 オープンソースプロジェクトに積極的にかかわっている人たちは、 これらのテクニックを自然に身に着けており、 情報が正しくいきわたるように複雑な手 作業を行っていることもあります。 しかし、プロジェクト全体で考えると、これらの作 業にはソフトウェアのサポートが必要です。 可能な限り、通信に使用するメディア自身 が 振り分けやラベル付け、内容の保存といった作業を行うべきです。 そして、その情 報は、人間が見やすい形式で利用可能にしておかなければなりません。 もちろん、現実 的にはまだそこまで全自動化されているわけではなく、 途中で何らかの人手が必要とな るでしょう。 しかし一般論として、人間側で振り分けやラベル付けのための情報を一度 提供したら、 あとはソフトウェア側でそのめたデータを最大限に活用できるようにすべ きです。 本章でのアドバイスは、実用的なものばかりです。 どれも特定のソフトウェアやその使 用例にもとづいたものです。 とはいえ、単に特定のテクニックを教えるだけというつも りはありません。 ちょっとした例をたくさんご覧いただくことで、 あなたのプロジェ クトにおける情報管理をよりよくするための 一般的な方法を身につけていただくつもり です。 これには、技術的なスキルだけでなく社会的なスキルも含まれます。 技術的な スキルは必要不可欠です。というのも、 情報管理用のソフトウェアは常に何らかの設定 が必要となるからです。 また、運用中にもある程度の保守作業が必要です (たとえば、 大きく成長したプロジェクトをどのように扱うかについて、 本章の後半 の バグ追跡シ ステムをあらかじめフィルタする項 で取り上げています)。 また、社会的なスキルも必 須です。なぜなら、 人間の集まりについても維持する必要があるからです。 さまざま なツールを使用して利益を受ける方法は、 すぐに明らかになるとは限りません。場合に よってはその使用法をめぐって争いが起こるかもしれません (例として、メーリングリ ストから配送されるメールの Reply-to ヘッダの設定についての議論を メーリングリス ト項 で取り上げています)。 プロジェクトに参加している人たちはみな、 そのプロジ ェクトの情報をうまく管理するための方法を必要としています。 プロジェクトに深くか かわればかかわるほど、 学ばねばならないテクニックは複雑で専門的なものになります 。 情報管理には、月並みな解決策はありません。 考慮すべき点があまりにも多すぎるので す。 最終的に望みどおりの手段が見つかるかもしれません。 コミュニティーの参加者 のほとんどもその方法を利用してくれるかもしれません。 しかし、プロジェクトがさら に成長したときに、 その方法がそのまま使えるとは限りません。 あるいは、プロジェ クトの成長が安定し、 開発者とユーザーの両方が現在の情報管理技術に慣れてきたとき に、 だれかがまったく新しい情報管理サービスを発明するかもしれません。 新しくプ ロジェクトに参加したメンバーはきっとこう言うでしょう。 「何であの便利なツールを 使わないの?」 Wiki (http://ja.wikipedia.org/wiki/Wiki を参照してください) が登 場しだした頃に、当時のプロジェクトの多くでまさにこれと同じことが起こりました。 どのような手段を使用するかを決めるには、さまざまな判断材料があります。 たとえば 、情報を提供する側と情報を利用する側のどちらの利便性を優先させるかも 判断材料の ひとつとなるでしょう。あるいは、 情報管理ソフトウェアの設定の難易度と、 それが プロジェクトにもたらす利益とのトレードオフについても考える必要があります。 あまりになんでもかんでも自動化しすぎないようにしましょう。 実際、人手がかかわる べきところまで自動化してしまってはいけません。 技術的な仕組みは重要ではあります が、 フリーソフトウェアプロジェクトをうまく運営するために重要なのは、 結局のと ころ人への気配り—決しておしつけがましくない気配りなのです。 技術的な仕組みとい うのは、この気配りをうまく行うための手段に過ぎません。 プロジェクトに必要なもの ほとんどのオープンソースプロジェクトは、 情報管理用のツールとして少なくとも以下 のようなものを用意しています。 ウェブサイト プロジェクトについての情報を、 管理者側から一般に向けて公開する場所です。 また、プロジェクトで使用するその他のツールについての 管理用インターフェイス もここで提供します。 メーリングリスト 通常は、そのプロジェクトにおける最も活発な議論の場となります。 また、議論の 「記録媒体」としての意味合いもあります。 バージョン管理システム 開発者が、コードの変更点を追いかけやすくするものです。 変更内容を元に戻した り、他に移植したりすることもできます。 これを見ると、コードに何が起こってい るのかを誰もが知ることができます。 バグ追跡システム 開発者が自分の作業内容を確認したり、 他の開発者と作業を調整したり、リリース 時期の予定をたてたりするために用います。 特定のバグの状況や関連情報 (再現手 順など) について、誰もが調べられるようになります。 バグだけに限らず、やるべ き作業やリリース時期、 新機能の追加などについてもここで扱うことがあります。 リアルタイムチャット ちょっとした議論や質問のやり取りのための場です。 議論の内容がアーカイブされ ないこともあります。 ここであげたツールはどれも異なるニーズを満たすものではありますが、 その機能には 相関性があります。また、 各種ツール群は協調して動作させなければなりません。これ 以降では、 その方法について考えます。また、より重要なこととして、 メンバーにそ れを使ってもらうためにはどうすればいいのかも説明します。 ウェブサイトについての 議論は後回しにします。というのもウェブサイトは、 独立したツールというよりは 他 のツールを組み合わせるための接着剤のようなものだからです。 どんなツールを選択しようかといった問題に悩まされたくないという場合は、 出来合い の ホスティング サイトを使用するといいでしょう。 たいていはパッケージ化されたウ ェブサイトのテンプレートが用意されており、 フリーソフトウェアプロジェクトの運営 に必要なツールもひととおりそろっているはずです。 本章の後半の ツールが一通り揃 ったホスティングサイト項 で、 ホスティングサイトの利点と欠点を取り上げます。 メーリングリスト メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです 。 ウェブページ以外にユーザーに見せるものがあるとすれば、 まず最初はそのプロジ ェクトのメーリングリストとなるでしょう。 しかし、メーリングリストに参加する前に 、 ユーザーはまずそのメーリングリストのインターフェイス (たとえば "メーリングリ ストに参加する" など) に出会うことになります。 ここから、次の「メーリングリスト 第一法則」が得られます。 メーリングリストの管理は、手作業で行うのではなく、 専用のソフトウェアを使用 すること。 いきなりそんなことを言われても驚きますよね。 メーリングリストの管理用にわざわざ ソフトウェアをセットアップするなんて、 ちょっとやりすぎのように感じられるかもし れません。 小規模で流量の少ないメーリングリストは手動で管理するほうが楽に見えま す。 参加申し込み用のアドレスをひとつ作成してそれをあなた宛てに転送されるように しておき、 届いたメールの内容を見て、アドレス一覧 (おそらく単なるテキストファイ ル) に追加したり削除したりするだけです。 これ以上にシンプルなやりかたなんてない でしょう? みんなが満足するレベルでメーリングリストの管理を行うということは、 思っているほ ど簡単なことではありません。 メーリングリストの管理というのは、 単にユーザーを 登録したり削除したりするだけの話ではありません。 スパムよけのために投稿内容をモ デレートするようにしたり、 複数の投稿をひとまとめにした形式でメールを配信するよ うにしたり、 メーリングリストやプロジェクトに関する情報を自動返信するようにした り といったさまざまな内容があります。 参加用のアドレスを人手でチェックするとい うだけでは、 最小限の機能しか提供することができません。 そしてその最小限の機能 でさえ、ソフトウェアに任せるのに比べると 信頼性や即時性に欠けるものとなるでしょ う。 いまどきのメーリングリスト管理用ソフトウェアなら、 少なくとも次のような機能が搭 載されているはずです。 メールおよびウェブの両方からの参加受付 ユーザーがメーリングリストへの参加を申し込むと、 すぐに自動返信のメッセージ を受け取ります。 そこには、参加しようとしているメーリングリストの情報や メ ーリングリストソフトウェアへの指示の出し方、そして (最も重要な項目として) リストからの退会のしかたなどが書かれています。 この自動返信の内容はカスタマ イズすることが可能です。 ここにはプロジェクトのウェブサイトや FAQ の場所と いった情報を含めることができます。 一通ごとの配信かまとめての配信かの選択 ダイジェストモード (「まとめて配信」モード) にすると、参加者が受け取るメー ルは１日に１通となります。 その日に投稿されたすべてのメールの内容が１通にま とめて送信されるわけです。 積極的に参加するわけではないが、 大まかな話の流 れは追いかけておきたいといった人たちには ダイジェストモードがお勧めです。 これを使用すると、頻繁にやってくるメールに気を散らされることなく その日のメ ールの内容をゆっくり見渡せるからです。 モデレート機能 「モデレート」とは、 投稿の内容をいったんチェックし、 a) スパムでないこと、 そして b) メーリングリストで扱うのにふさわしい内容であること を確認してから 一般向けに配信する作業のことです。 モデレート処理は、必ずしも人間が行わなけ ればならないというものではありません。 ソフトウェアに任せることで、より簡単 に行えるようになります。 モデレートについては、後でもういちど取り上げます。 管理者用インターフェイス これは特に、使われなくなったアドレスを簡単に削除するために有用です。 メーリ ングリストの参加者のアドレスから 「このアドレスはもう存在しません」といった 自動返信メッセージが毎回届くようになったら、 即刻対応しなければなりません (メーリングリストソフトウェアによっては、 これを自動検出して該当者を自動的 にメンバーから外すようにできるものもあります)。 ヘッダの操作 多くの人は、メールソフトの仕分け機能などを活用していることでしょう。 メーリ ングリストソフトウェアを使用すると、 特定のヘッダをメールに付加することで これらの機能を使いやすいようにします (詳細は後で説明します)。 アーカイブ処理 メーリングリストへのすべての投稿は、 保存されたうえでウェブから閲覧可能にな ります。 あるいは、メーリングリストソフトウェアによっては MHonArc (http:// www.mhonarc.org/) のような外部のアーカイブツールへのプラグインインターフェ イスを持っているものもあります。 第6章 の アーカイブを目に付きやすくする方 法項 で説明するように、 アーカイブは重要な作業です。 このようにひとつひとつ挙げてみると、 メーリングリストの管理というものが思いのほ か複雑な作業であることがお分かりでしょう。 そして、それらの作業の多くがソフトウ ェアで自動化できることもわかります。 決してこれらのソフトウェアのエキスパートに なる必要はありません。 しかし、まだまだ常に学ぶ余地があるということ、 そしてフ リーソフトウェアプロジェクトを運営するにあたって メーリングリストの管理作業は避 けて通れないものであることは心においておきましょう。 これ以降では、メーリングリ ストの設定に関するよくある問題についてみていきます。 スパム対策 今、この文章を書いている時点と実際に本書が出版された時点を比べても、 スパムに関 する問題の深刻度は倍増していることでしょう。 少なくとも、そう感じるくらいのレベ ルにはなっているはずです。 つい最近までは、スパム対策をまったく行わなくても メ ーリングリストを普通に運営できていました。 ごくまれに変な投稿が行われることもあ りましたが、気になるほどのものではなかったのです。 しかし、そんな時代はとっくに 終わってしまいました。 現在では、スパム対策をまったくしていないメーリングリスト は あっという間にゴミメールの山となってしまいます。 そんなメーリングリストは使 い物にならないでしょう。 スパムは決して野放しにしてはいけません。 本書では、スパム対策を２種類に分けて考えます。 ひとつはメーリングリストにスパム が配信されないようにすること。 もうひとつは、メーリングリストの参加者のメールア ドレスを スパム業者に収集されないようにすることです。 前者の方がより大事なので 、まずはそちらから考えていきましょう。 投稿のフィルタリング スパム投稿を防ぐ基本的な方法は、次の３つです。 ほとんどのメーリングリストソフト ウェアは、これらの機能をすべて提供しています。 また、これらの方法は、どれかひと つだけを使うのではなく 組み合わせて使うと有効です。 1. メーリングリストのメンバーからの投稿のみを自動配信する これはある程度は有効で、管理者にはほとんど負担がかかりません。というのも、 これを行うには単にメーリングリストソフトウェアの設定を変更するだけだからで す。 しかし、自動承認されなかった投稿を単に捨ててしまってはいけません。 そ うではなく、自動承認されなかった投稿は管理者がいったんチェックするようにし ましょう。 そうする理由は次の２つです。まず第一に、 メーリングリストのメン バー以外からの投稿も受け付けたいからです。 ちょっとした質問や提案がある人が 、 いちいちメーリングリストに参加しなければメールを投稿できないというのは不 便です。 もうひとつ、メーリングリストのメンバーであっても、 登録しているア ドレス以外のメールアドレスから投稿することがあるかもしれません。 メールアド レスは、人を識別する手段としてはあまり信頼できるものではありません。 メール アドレスにあまり頼りすぎないようにしましょう。 2. 投稿を、いったんスパムフィルタリングソフトウェアにかける メーリングリストソフトウェアが対応していれば (ほとんどは対応しています)、 投稿内容をスパムフィルタリングソフトウェアに渡すことができます。 自動スパム フィルタリングは完璧なものではありません。 また、今後も決して完璧なものには ならないでしょう。 スパムの送信者とフィルタの作者との戦いは永遠に続くのです 。 しかし、フィルタリングソフトを使用することで、 管理者が手作業で処理すべ きスパムを激減させることができます。 人手で処理すべき内容が多くなればなるほ ど、 自動フィルタリングは有用です。 ここでは、スパムフィルタの設定方法については説明しません。 ご利用のメーリン グリストソフトウェアのドキュメントを参照してください (本章の後半の ソフトウ ェア項 で詳しく説明します)。 メーリングリストソフトウェアにはたいてい、 自 前のスパム対策機能が組み込まれています。 しかし、サードパーティのフィルタを 使いたいこともあるでしょう。 私がよく利用しているのは、SpamAssassin (http:/ /spamassassin.apache.org/) と SpamProbe (http://spamprobe.sourceforge.net/) です。もちろんこれら以外にも オープンソースのスパムフィルタはたくさんありま すし、 その中にはすばらしいものもあるでしょう。 私はたまたまこの２つで満足 しているので、 他のものをあまり調べていないというだけのことです。 3. モデレートする 登録されているメールアドレスからの投稿ではないので 自動配信はされませんでし た。 また、スパムフィルタを通した結果、スパムではないと判断されました。 そ のような投稿に対する最後の手段は モデレート です。 メールの内容が特別なアド レスに送られ、 人間がその内容をチェックしたうえで承認するか却下するかを決め るのです。 投稿を承認する場合は、「その投稿だけを承認する」 あるいは「その投稿を承認し 、 今後同じアドレスからの投稿があった場合は自動的に配信する」 のいずれかの 方式となります。 ほとんどの場合は後者の方式をとることになるでしょう。 そう すれば、将来のモデレートの負荷を下げることができます。 投稿の承認方法は、シ ステムによってことなります。 よくある方式は、特別なアドレスに対してコマンド を返信することです。 たとえば "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: Subject による仕分けができるメールソフトなら、 まず間違いなく To による仕分けも できるはずです。 これ以外にも必須ではないけれどメーリングリストではよく使われているヘッダがいく つかあります。 これらのヘッダをもとにして仕分けをしたほうが、"To" や "Cc" に頼 るよりも確実です。以下のようなヘッダは メーリングリスト管理ソフトウェアが直接追 加するので、 これを使用した仕分けをしている人もいることでしょう。 list-help: list-unsubscribe: list-post: 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 というメー ルソフトはこの機能を持っています ^[17] )。 よりよい対応法は、Reply-to を変更するかしないかを 各メンバーが個別に設定できる ようにすることでしょう。 メーリングリスト宛ての投稿は (自分の投稿も他人の投稿も 含めて) Reply-to をメーリングリストのアドレスにしてほしいという人はそのオプショ ンを指定し、 Reply-to をそのままにしておいてほしい人はそのように指定します。 残 念ながら現時点では、 これを各参加者ごとに設定できるメーリングリスト管理ソフトは 存在しないようです。 現状は、全員共通の設定で我慢するしかありません。 ^[18] アーカイブ メーリングリストのアーカイブを設定する技術的な方法は、 使用するメーリングリスト 管理ソフトによって異なるので、 本書では詳しくは取り上げません。 アーカイブツー ルを選択したり設定したりする際には、 以下のような点に注意しましょう。 迅速な更新 少なくとも、実際に投稿があってから１時間後くらいには その投稿がアーカイブさ れていてほしいものです。 可能なら、実際に投稿があった瞬間にアーカイブ処理も 同時に行なうべきです。 そうすれば、その投稿がメンバーに配信されたときには既 に アーカイブにも同じ内容が存在するということになります。 それが無理だとし ても、少なくとも１時間おきくらいの頻度でアーカイブの更新を行ないましょう (アーカイブソフトによっては、デフォルトでは １日に１回しかアーカイブを行な わないものもあります。 しかし、メーリングリストのアーカイブ処理としては、 事実上これでは使い物にならないでしょう)。 参照の永続性 メッセージがいったんある URL にアーカイブされたら、 その後ずっと同じ URL で そのアーカイブにアクセスできるようにすべきです。 アーカイブを再構築したりバ ックアップから復旧したり、 あるいはその他何らかの修正を加えたときにも、 い ったん公開した URL はそのまま変わらないことが望ましいでしょう。 同じ URL を 保つようにしておけば、サーチエンジンに捕捉されやすくなります。 これは、利用 者にとって大きな利点となるでしょう。 URL を保ち続けるよう心がけるもうひとつ の理由としては、 メーリングリストの投稿やスレッドがバグ追跡システム (本章の 後半の バグ追跡システム項 を参照してください) や他のプロジェクトのドキュメ ントからリンクされることが多いということもあります。 理想を言えば、メールをメンバーに配信する際に、 そのメッセージがアーカイブさ れている URL をヘッダに含められるようになっていればなおよいでしょう。 そう すれば、そのメールを受け取った人は わざわざアーカイブサイトを訪れなくても そのメッセージがアーカイブされている場所を知ることができます。 ブラウザを開 いて何らかの操作をするというのは時間のかかる作業なので、 それが省けるだけで も非常に便利です。 このような機能を持つメーリングリスト管理ソフトウェアがあ るかどうかは、 私は知りません。残念ながら、 私が今使っているソフトウェアに はそのような機能はないようです。 しかし、どこかにそんなソフトウェアがあるの ではと期待しています (もしあなたが新たにメーリングリスト管理ソフトウェアを 開発するのなら、 ぜひこの機能を実装してください。お願いします)。 バックアップ 当然、アーカイブのバックアップとバックアップからの復旧の方法は 簡単なほうが よいでしょう。いいかえれば、 アーカイブソフトがブラックボックス化してしまっ てはいけないということです。 あなた (もしくはプロジェクト内の誰か) はメッセ ージが実際にどのように保存されているかを知っている必要があり、また、 必要に なったときにはそこからアーカイブを復元できるようにしておかなければなりませ ん。 プロジェクトにとって、アーカイブの内容は宝物です。 万一アーカイブを失 ってしまうことがあれば、 貴重な記録を失ってしまうことになります。 スレッドのサポート 個々のメッセージから、そのメッセージが属する スレッド (関連するメッセージの まとまり) へ移動できるようにしておく必要があります。 また、各メッセージ個別 の URL とは別に、 スレッドを表す URL もあるとよいでしょう。 検索機能 メッセージの本文や送信者、件名などによる検索機能を サポートしていないアーカ イブソフトなんて、使い物にならないといっていいでしょう。 アーカイブソフトの 中には、単に Google などの外部のサーチエンジンに処理をまかせているだけのも のもあります。 機能がないよりはましですが、検索機能を自前で実装しているほう が よりきめ細やかな処理ができます。 たとえば、タイトルだけを対象に検索した り、 本文も含めて検索したりといったこともできるでしょう。 上にあげたのは、アーカイブソフトを選択する際に注意する点として 技術的な面にしぼ った一覧です。 実際にみんなにアーカイブソフトを利用 してもらうことにどのような 利点があるのかについては、 アーカイブを目に付きやすくする方法項でとりあげます。 ソフトウェア メーリングリストの管理やアーカイブの作成用に、 さまざまなツールがオープンソース で公開されています。 あなたのプロジェクトを公開しているサイトで何かのツールが用 意されているのなら、 それを使えばいいでしょう。しかし、もし自分で新たにインスト ールする必要があるのなら、 いくつかの選択肢があります。私が実際に使用したことが あるのは Mailman、Ezmlm、MHonArc、そして Hypermail です。 しかし、それ以外のソ フトウェアが劣っているというわけではありません (また、当然のことですが、私が知 っているソフトウェアだけがすべてではありません。 それ以外にもさまざまなものがあ るはずなので、 これを完全なリストとはとらえないでください)。 メーリングリスト管理ソフトウェア ● Mailman — http://www.list.org/ (独自のアーカイバが組み込まれていますが、 プラグイン形式で外部のアーカイバ を使用することもできます) ● 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 を採用するこ とが多くなってきました ^[19]。 これから新たにプロジェクトを立ち上げるのなら、 Subversion をお勧めします。 一方、私が Subversion プロジェクトにかかわっていることもあり、 私の意見の客観性 に疑問を持たれる方もいるかもしれません。 ここ数年、新たなオープンソースのバージ ョン管理システムがいくつか登場しています。 付録 A. フリーなバージョン管理システ ム に、 私が知っているものを挙げておきます。 このリストを見てもわかるように、バ ージョン管理システムにどれを採用するかを決めるには、 下手したら一生かかってしま うかも知れません。 もしかしたら、あなたには選択の余地がないかも知れません。 と いうのは、ホスティングサイトを使用する場合は ホスティングサイト側でバージョン管 理システムが設定されているかもしれないからです。 もしあなたが自分で選択しなけれ ばならない立場になったのなら、 まず周りの意見をよく聞いてからどれかひとつを選択 し、 そして動かしてみましょう。 最近のバージョン管理システムは、どれもそれなり に機能します。 どれを選んだとしても、致命的な被害を受けることはないでしょう。 もしまだ迷っているのなら、Subversion を使ってみましょう。 これは簡単に習得でき 、少なくとも今後数年は標準的に使われることでしょう。 バージョン管理システムの使用法 この章で説明する内容は、特定のバージョン管理システムに固有のものではありません 。 どのシステムを選択した場合にも適用できるはずです。 詳細は、各システムのドキ ュメントを調べるようにしましょう。 すべてをバージョン管理する ソースコードだけでなく、ウェブページやドキュメント、FAQ、設計メモなどなど、 編 集する可能性のあるものはすべてバージョン管理下におくようにしましょう。 これらは 、同一リポジトリツリー内でソースコードの隣に置いておきます。 書き残した情報は、 すべてバージョン管理する価値があります。 つまり、あらゆる情報は変化する可能性が あるということです。 今後変わりようのない内容については、 バージョン管理ではな くアーカイブしなければなりません。 たとえば、メーリングリストに投稿されたメール の内容は、変わることがありません。 このようなものをバージョン管理しても無意味で す (もちろん、それが巨大な文書の一部となる場合などは別ですが)。 すべてを同じ場所でバージョン管理する理由は、 そうしておけば作業に参加する人がひ とつのことを覚えるだけですむようになるからです。 たとえば、最初はウェブページや ドキュメントの修正から参加しはじめたメンバーが、 後にコードそのものの修正にも参 加するようになるといったことがあります。 すべてを同じ仕組みでバージョン管理して おけば、 このような場合に新たにその使用法を学ぶ必要がなくなるのです。 また、新 機能を追加すると同時にドキュメントも更新したり、 コードのブランチを作成すると同 時にドキュメントのブランチも作成したり といった際にも便利です。 自動生成されるファイル はバージョン管理する必要がありません。 これらのファイル は純粋に編集可能なデータではなく、 別のファイルの内容をもとにして自動生成される ものだからです。 たとえば、ビルドシステムでよく用いられるファイル configure は 、テンプレート configure.in の内容をもとにして自動生成されるものです。もし configure を変更したいのなら、configure.in を編集してから再生成するということに なります。つまり、この場合で言う 「真に編集可能なファイル」は、テンプレートであ る configure.in だけということになります。バージョン管理するのはテンプレートだ けにします。 生成した結果までバージョン管理してしまうと、 テンプレートを修正し た際にファイルを再生成することを忘れてしまうかも知れません。 そうすると、ファイ ルの整合性が取れなくなってしまって混乱の元となります。 ^[20] 「編集可能なデータはすべてバージョン管理下におかなければならない」 という規則に は、残念ながらひとつだけ例外があります。 それが バグ追跡システム です。 バグデ ータベースは編集可能なデータを大量に保持していますが、 技術的な理由により、この データをバージョン管理することはできません (バグ追跡システムの中には、ちょっと したバージョン管理機能を独自に実装しているものもあります。 しかし、これはプロジ ェクトのメインリポジトリとは独立したものとなります)。 ウェブで閲覧できるようにする プロジェクトのリポジトリは、ウェブ上からも閲覧できるようにしなければなりません 。 これは、ただ単に最新のリビジョンが見られればいいというレベルのものではありま せん。 前のリビジョンにさかのぼったりリビジョン間の差分を見たり、 変更時のログ メッセージを見たりといった機能も含みます。 これは、そのプロジェクトのデータに関する便利な入り口となるので、 ブラウザビリテ ィ（閲覧のしやすさ）が重要となります。 もしウェブブラウザ経由での閲覧ができなけ れば、 そのプロジェクトの特定のファイルを調べたい人 （あのバグ修正はどんな風に 行われたのかな？など）はまず バージョン管理システムのクライアントソフトウェアを インストールするところから始めなければならなくなってしまいます。 ウェブで見られ れば２分ですむことなのに、 それがないために30分がかりの作業になってしまうという ことになります。 ブラウザビリティの中には、特定のファイルの特定のリビジョンが特定の URL で見られ ること、そして特定のファイルの（その時点での） 最新リビジョンも特定の URL で見 られることといった内容も含まれます。 こうしておくと、技術的な議論の際にその場所 を示しやすくなるので便利です。 たとえば「サーバをデバッグするためのヒントは、作 業コピーにある www/hacking.html をご覧ください」という代わりに 「サーバをデバッ グするためのヒントは http://svn.collab.net/repos/svn/trunk/www/hacking.html を ご覧ください」と言えるのです。 これは、常に hacking.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） と言うようです。 コミットがあるたび に自動で特定の作業をさせる際に使用するのが コミット後フックです。これは各コミッ トの直後に呼び出され、 そのコミットに関する情報を受け取って任意の作業を行うこと ができます。 そう。たとえばメールを送信したりなど。 用意されているメール送信の仕組みを使用していると、 そのデフォルトの動作をちょっ と変更したくなってくるかもしれません。 1. コミットメールシステムの中には、実際の差分そのものは本文に含めず、 それをウ ェブで見るための URL だけを記載するというものがあります。 もちろん URL は大 事です。後から変更内容を確認するのにも便利ですしね。 でも、差分の内容そのも のをメールの本文に含めておくことも 非常に 重要です。多くの人にとって、 メー ルを読むという作業は日常のルーチンワークとして組み込まれているでしょう。 変 更の内容が直接メールに書かれていれば、 一連の流れの中で自然にコミットをレビ ューすることができます。 いちいちメールソフトを終了してブラウザに切り替える 必要がなくなるのです。 変更を確認するには URL をクリックする必要があるとな れば、 ほとんどの人はクリックなどしてくれないでしょう。 だって、これまでず っとメールを読んでいたのに、 いきなり別の操作が必要となるのですから。 さら に、変更点をレビューした人がその内容について質問をしたいときに、 そのメール に「返信」すれば自動的に変更内容が得られるので便利です。 さもないと、ウェブ ページを開いて変更点を カット＆ペーストするという大変な手間がかかってしまい ます。 (もちろん、新たにリポジトリにコードを追加したなどで変更点が大量にある場合は 、 差分を省略して URL だけにするというのもわかります。 コミットメールのシス テムの多くは、 何らかの制限値を設定してこの処理を自動化してくれるようになっ ています。 もしそんな機能がついていなかったとしましょう。そんな場合でも、 差分をまったく記載しないよりは常に差分を含めるようにするほうがずっとマシで す。 たまに巨大なメールが送信されることになりますが、許容範囲です。 共同開 発においては、みんなが他人の変更をレビューしたりコメントしたりすることが重 要です。 そのための努力は、いくらしてもしすぎることはありません) 2. コミットメールの Reply-to ヘッダは、コミットメール用のメーリングリストでは なく 開発者向けのメーリングリストにしておきましょう。 そうすると、コミット メールの内容をレビューして何らかのコメントをしたくなった人が 「返信」すると 、それが自動的に開発者向けメーリングリストに流れることになります。 こうして おくべき理由はいくつかあります。 まず、技術的な議論はひとつの場所に集約する ということ。 技術的な議論を行う場として最適なのは、開発者向けメーリングリス トです。 次に、コミットメール用のメーリングリストに参加していないメンバーに も 議論の内容を伝えるということ。 ３つ目に、コミットメール用のメーリングリ ストはあくまでも コミットの内容をチェックするだけのものであり、 決して「コ ミットの内容のチェックがメインだけど、 たまに技術的な議論もある」というもの であってはいけないからです。 コミットメール用のメーリングリストに登録する人 たちは、 コミット内容のメールだけが送られてくることを期待しています。 それ 以外の内容が送られると、暗黙の了解を裏切ってしまうことになります。 最後に、 コミットメールの内容を処理して（ウェブページなどに） 結果を出力するプログラ ムを作成するような人のことを考えるということ。 この種のプログラムは、 コミ ットメールのようなお決まりのパターンのメールに関してはうまく動作します。 し かし、人間が書いたメールを処理させると変な結果になってしまうでしょう。 ここでお勧めした Reply-to の設定は、決して 本章の前半で述べた Reply-to はど うすべきか項 の内容と矛盾するものではないことに注意しましょう。 先ほども、 メッセージの 送信者 自身が Reply-to を設定するぶんには特に問題はないとして います。今回の場合、 メッセージの送信者はバージョン管理システムです。 バー ジョン管理システム自身で Reply-to を指定して開発者向けメーリングリスト向け に返信させようとしているのですから、 さきほどの説明とは矛盾しません。 CIA: 変更点を公開するためのもうひとつの方法 変更点を公開する方法は、コミットメールだけではありません。 最近、CIA (http:// cia.navi.cx/) と呼ばれる別の仕組みが開発されました。 CIA は、コミットの状況をリ アルタイムで収集し、配信するものです。 CIA の最も一般的な使用法は、コミットの通 知を IRC チャンネルに送信するというものです。 そのチャンネルに参加していれば、 コミットがあるたびに即時にそれを知ることができます。 メールに比べたら、技術的に 劣っているかもしれません。 だって、IRC にコミット通知を送ったとしても それを見 ている人がいるかどうかがわからないわけですから。 それでも、この仕組みは 社会的 な面で 面白いものです。参加している人たちは そこで何かが起こっていることが感じ られ、 開発の進行状況をまさに目の前で見られるというわけです。 この仕組みを使用するには、コミット後のフックで CIA の通知用プログラム (CIA notifier) を実行します。 このプログラムは、コミットに関する情報を XML 形式に変 換して中央サーバ (通常は cia.navi.cx) に送ります。するとサーバがその情報を別の フォーラムに配信するのです。 CIA を設定することで、 RSS フィードを送信させることもできます。詳細は http:// cia.navi.cx/ のドキュメントをご確認ください。 CIA が実際に動作している例を見るには、IRC クライアントで irc.freenode.net のチ ャンネル #commits に行ってみましょう。 ブランチの活用 バージョン管理システムにあまり慣れていないユーザーは、 ブランチの作成やマージ作 業を怖がる傾向があるようです。 おそらく、これは 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章 の 誰が投票するのか?項 で 詳しく説明します。 バグ追跡システム バグ追跡 が扱う範囲は多岐にわたります。 この本ではバグ追跡についての様々な側面 を議論しています。 ここでは バグ追跡システムをセットアップすることと、 その作業 に関する技術的な考察に集中しようと思います。 その話題に入る前に、バグ追跡の方針 に関する質問から始めましょう。 具体的にどの情報をバグ追跡システムに保存すべきな のでしょうか? バグ追跡システム は、誤解を招きやすい用語です。 バグ追跡システムは、新しい機能 要望や、一度限りのタスク、 送られてきたパッチ — はじまりと終わりの状態があるす べてのもの、 存在している間に情報が発生するすべてのものを追跡するためによく使わ れます。 このため、バグ追跡システムは、 問題追跡システム、 不具合追跡システム、 影響追跡システム、 要望追跡システム、 チケットシステム などとも呼ばれています。 バグ追跡システムのソフトウェアの一覧は、付録 B. フリーなバグ追跡システム を参照 してください。 この本では "バグ追跡システム" という用語を、 バグを追跡するソフトウェアを指すも のとします。 なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。 しかし 、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、 問 題 という用語を使います。 これによってユーザーが遭遇するソフトウェアの変な振る 舞い（つまり、バグです）と、 バグの発見、診断、解決の 記録 を区別できるからです 。 殆どの問題は実際に起こったバグに関するものですが、 他のタスクに関することで も問題という用語が使えるということを覚えておいてください。 問題の典型的なライフサイクルは次のようなものです。 1. 誰かが問題をバグデータベースに記録します。 この記録には、問題の要点、問題の 説明(もしあれば、 問題を再現させるための手順も。 ユーザーに優れたバグ報告を させる方法については、 第8章 の すべてのユーザーの協力を得るために項 を参照 してください) 、バグ追跡システムが求めているその他の情報が全て含まれていま す。 問題を報告した人は、プロジェクトについて全く知らないかもしれません。— ユーザーのコミュニティーと開発者達から、同じくらいの割合でバグ報告や機能要 望があがってきます。 いったん問題が報告されると、その問題は 保留中 の状態にあるといいます。 なぜ なら、それに対して何らアクションがとられていないからです。 システムによって は、 未確認 とか 未着手 といったラベルを付与するものもあります。 まだ誰もこ の問題を担当していません。システムによっては、 担当が決まっていないことを表 すためにダミーの担当者を割り当てるものもあります。 この時点では、問題は一時 的な領域に置かれています。つまり、 システムに記録されてはいるが、プロジェク トがまだ関心を持っていないということです。 2. 誰か他の人が問題を読み、コメントを付けます。 おそらく問題を報告した人に、不 明な点について説明を求めるでしょう。 3. 問題はやがて 再現済み という状態になります。 これは問題のライフサイクルの中 で最も重要かもしれません。これは、 まだ解決されたわけではないが、 報告した 人以外の誰かが問題を再現でき、 この問題が本物だと証明したことをいいます。 そして同じくらい重要なことですが、 報告した人が本物のバグを報告することで、 プロジェクトに貢献したと確認することでもあります。 4. そして 診断済み という状態になります。 問題の原因が特定され、可能なら解決に 必要な労力が見積もられます。 これらのことは必ず追跡システムに記録するように しましょう。 原因を調べた人が突然しばらくプロジェクトを離れなければならない （これはボランティアの開発者にはよくあることです）場合に、 誰かが穴を埋めら れるようにしておくべきだからです。 この段階か、もうひとつ前の段階で、 開発者が問題を "自分が解決することにして "、 自分自身を 担当者にする するかもしれません。 (担当者を決める手続きをさ らに詳細に調べるには 第8章 の 、 作業依頼と担当者の決定を明確に区別する項 を参照してください) この段階で、問題に優先度 も割り当てられるかもしれません 。 たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、 そ の事実は早い段階で確認する必要があります。 よって、追跡システムはそれを記録 する何らかの方法を備えるべきということになります。 5. 問題をいつ解決するかという予定が立てられます。 予定を決めるということは、 いつまでに直すという日程を決めることとは限りません。 将来のどのリリース（次 のバージョンとは限りません）で直すかを決めるだけのこともありますし、 特定の リリースで直すと決めない場合もあります。 バグが素早く直せる場合には、予定を 立てないこともあります。 6. 問題が解決されます。（タスクが終了したり、 パッチが適用されたりとか、そうい ったものです） 行った変更は、問題の 処理が済んだ り、 解決済み とマークされ たあとに、 コメントとして記録するようにしましょう。 問題のライフサイクルには共通のバリエーションがいくつかあります。 問題によっては 、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることが あります。 プロジェクトが多くのユーザーを獲得するにつれ、 バグではない問題が報 告される回数も増えていき、 開発者は次第にぶっきらぼうな返事をして問題を処理済み とするようになります。 こういう風潮にならないよう努力しましょう。 ぶっきらぼう に問題を処理済みにしてもいいことは何もありません。 バグではない問題を報告したユ ーザ－は、以前報告された問題には何の責任もないのですから。 それに報告される問題 が統計的にどういった傾向にあるかは、 開発者のみわかることで、ユーザーにはわから ないことです。 (この章の後半の バグ追跡システムをあらかじめフィルタする項 で、 バグではない問題の数を減らすテクニックについて見ていきます) また、異なったユー ザーが繰り返し同じような誤解をする場合は、 誤解を生む部分を再設計する必要がある ということかもしれません。 この手のパターンはバグデータベースを監視する問題管理 システムがあれば簡単に見つかります。 第8章 の、 バグマネージャー項 を参照してく ださい。 別のバリエーションとして、 1. のすぐ後で問題が 重複している として処理済みにさ れる場合があります。 重複した問題は、プロジェクトが既に認識している問題を誰かが また報告すると発生します。 重複した状態は 保留中 の問題で発生するとは限りません 。 解決したあとで再び報告される(この状態を リグレッション（回帰） と呼びます)こ ともあります。 こういう場合は、重複の元となった問題を 再度保留中の状態にして、 重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。 バグ追跡システム は、 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 問題同士の関連を追跡しているはずです。 開発者が問題を処理済みにする3つ目のバリエーションは、 問題を解決したと思い込ん で処理済みにするパターンです。 これは結局、問題を報告した人がそれを拒んで再度保 留中にする結果になります。 これは開発者が単にバグを再現するのに必要な環境にアク セスできないか、 問題を再現する手順に正確に従ってテストをしなかったために発生し ます。 これらのバリエーションのほかにも、 バグ追跡システムによって細かい部分が変わる場 合はありますが、 基本的なパターンは同じです。 問題のライフサイクルそのものもオ ープンソースソフトウェアに特有のものではありませんが、 オープンソースプロジェク トのバグ追跡システムの使い方に影響を与えています。 1. が暗に示すとおり、 バグ追跡システムはメーリングリストやウェブページと同様プ ロジェクトの顔です。 誰でも問題を報告し、調べることができますし、現在保留中とさ れている問題の一覧を見ることができます。 よって、報告されている問題の進捗を何人 の人が知りたがっているのかが、 開発者にはわからないということになります。 問題 が解決される割合は開発者コミュニティーの規模やスキルに左右されますが、 プロジェ クトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。 たとえ問 題が解決されずにしばらく残り続けても、 開発者が返答すると、問題を報告した人は引 き続き参加したいと考えます。 なぜなら、自分がやったことが認められたと感じるから です。(問題を報告することは、 たとえば電子メールを送ること以上に労力がいること を思い出してください) それ以上に、問題をいったん開発者が見れば、 報告された問題 の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、 プロジェクト が問題を認識したことになります。 適切なタイミングで問題に応答するには、次の二つが必要です。 ● バグ追跡システムをメーリングリストと接続しなければいけません。 これは、問題 を報告することを含めた、問題の状態を変更するあらゆる行動が、 メールで投稿さ れるようにするためです。 このメーリングリストは通常使う開発用のものとは違う のが普通です。 なぜなら、開発者全員が自動送信されるバグ報告メールを受け取り たいとは限らないからです。 しかし、(コミットメールと同様に) Reply-to ヘッダ は開発用のメーリングリストのアドレスに設定しておきましょう。 ● 問題を報告するときの記入フォームは、 報告する人の電子メールアドレスの欄にフ ォーカスを当てておくべきです。 (しかし、匿名で報告したいと思う人もいるので 、 電子メールアドレスを 必須 にすべきではありません。 匿名の重要性について は、 この章の後半にある 匿名性とプロジェクト参加項 を参照してください。 議論の場としてメーリングリストを使う バグ追跡システムがディスカッションフォーラムにならないようにしましょう。 バグ追 跡システムに人間が顔を出し続けることは大事ですが、 それがリアルタイムに議論する のに適しているわけではありません。 バグ追跡システムは、起こった事実や他の議論に 対する参照、 メーリングリストで起きた議論をまとめるアーカイバと考えるようにしま しょう。 こうした区別をするのはふたつの理由があります。 ひとつめは、バグ追跡システムがメ ーリングリストに比べて（ついでにいうと、リアルタイムに会話ができるチャットシス テムと比べても）使いにくいからです。 これはバグ追跡システムのインターフェイス設 計が悪いからではなく、 単にメーリングリストやチャットシステムが、連続していない 状態、つまり自由に流れていく議論を取り込めるように設計されているからです。 ふた つめは、ある議論に参加している人が、 バグ追跡システムを見ているとは限らないから です。 よい問題管理のやり方(第8章 の、 技術的な作業だけでなく管理作業もみんなで 項 を参照してください)は、 開発者全員に起こっている問題全部を追いかけさせるので はなく、 適切な人の注意をひくようにすることです。 第6章 の バグ追跡システムでは 議論しない項では、 適切なフォーラム以外に偶然議論が波及しないようにする方法や、 バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。 バグ追跡システムによっては、メーリングリストをモニタし、 既知の問題に関する電子 メールを全て自動的に記録するものがあります。 通常、こうしたシステムはメールの件 名の行にある問題の番号を、 特別な文字列として認識することでこれを行います。 開 発者達は、バグ追跡システムの注意を引くために、 電子メールにこうした文字列を含め ることができるようになります。 バグ追跡システムに電子メール全体を記録させてもい いですし、 (よりよいのは)通常のメーリングリストのアーカイブにあるメールへのリン クを記録させてもよいでしょう。 どちらの方法でも、これはとても役に立つ機能です。 あなたが使っているバグ追跡システムにこの機能があるなら、 それを有効にして人々が 利用するように知らせておきましょう。 バグ追跡システムをあらかじめフィルタする ほとんどのバグ追跡システムは結局同じ課題に悩まされます。 バグを報告した経験が少 なかったり、 肝心な部分を知らない善意のユーザーが、 既に報告されている問題やバ グではない問題を大量に報告してくるのです。 この傾向に対処するはじめのステップと して、 バグ追跡システムのトップページに目立つように注意書きを置いておく方法があ ります。 そこで本当にバグかどうかを区別する方法や、 既に報告されている問題かど うかを検索する方法、 そして最後に、本当に新規のバグであった場合に効果的に報告す る方法を説明しておくのです。 こうすることでしばらくは報告されてくる問題のノイズは下げられますが、 ユーザーが 増えてくるにつれてこの課題は結局再燃します。 このことでユーザーを責めることはで きません。 ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようと しているだけですし、 たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 あなたは彼らにひき続きプロジェクトに参加してもらって、 将来はよりよいバグ報告を して欲しいと思うでしょう。 しばらくの間は、バグ追跡システムに自由にバグを報告さ せ続ける必要があります。 この課題を避けるために何より実行すべきことがふたつあります。 バグではない問題や 、 重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある 人にバグ報告システムを見張ってもらうこと。 そしてバグ報告システムにバグを報告す る前に、 他の人とバグかどうかを確認するようユーザーに求める（または強く勧める） ことです。 はじめのテクニックはあらゆるところで使われているようです。 巨大なバグデータベー スを持つ（たとえば http://bugs.debian.org/ にある Debian のバグ追跡システムは、 執筆時点で 315,929個 のバグ情報があります）プロジェクトでも、バグが報告されるた びに 誰かが 見張るようにシステムを改造しています。 問題のカテゴリによって見張る 人は違うかもしれません。 たとえばDebianプロジェクトはソフトウェアパッケージの集 合体なので、 自動的にそれぞれの問題を適切なパッケージメンテナーに転送しています 。 もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。 そう いう場合は、そのバグははじめは間違った人に転送されるので、 転送された人が再度転 送し直さなければなりません。 しかし重要なのは、その負担が共有されているというこ とです — ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすま いが、 報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。 よ って問題が報告されるたびに、適切なタイミングで応答できるのです。 ふたつめのテクニックは広く使われているわけではありませんが、 これはおそらく自動 化が難しいからでしょう。 アイディアの要点は、新しく報告されてくる問題をデータベ ースに登録する前に、 "仲間を" 巻き込むことです。 ユーザーが問題を見つけたと思っ たときは、 メーリングリストかIRCで説明するように求めます。 そうすることで、誰か が本当にバグかどうかを確認するのです。 別の人の目に早めに晒すことで、たくさんの 間違った報告を避けることができます。 別の人がその振る舞いはバグではないとわかっ たり、 最近のリリースで解決済みだとわかる場合があります。 または、別の人が以前 報告された問題から報告されるバグの兆候に精通しているので、 古い問題であるとユー ザーに指摘することで重複した報告を防ぐことができる場合もあります。 "既に報告さ れた問題かどうかをバグ追跡システムで検索したかい?" とユーザーに聞くだけで十分な こともあります。 多くの人はそんなことを考えてもいませんが、 誰かがそうすること を 期待している とわかれば、 喜んで検索するものです。 仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、 欠点もいくつか あります。 多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を 見ないか、 軽視するかして、結局ひとりでバグ報告をしてしまうことです。 よって、 ボランティアにはやはりバグデータベースを見張ってもらう必要があります。 さらに、 ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らな いので、 ガイドラインを無視しているからといって厳しく注意するのはフェアではあり ません。 よってボランティアは、 誰にも見てもらっていないバグ報告を報告者にどう 差し戻すのかについては、 用心深く、なおかつ慎重でなければなりません。 これは、 問題をフィルタする仕組みを理解する人々を増やせるように、 ゆくゆくは仲間を巻き込 んでバグ報告をしてもらうことが目的です。 誰にも見てもらっていないバグ報告を見つ けたら、 とるべき理想的な対処のステップは次のようなものです。 1. すぐにバグ報告に応答し、 ユーザーがバグ報告をしてくれたことに丁寧にお礼を言 います。 しかし、バグかどうかを誰かに見てもらうガイドラインがあることを指摘 します。（これはもちろん、ウェブサイトに目立つように投稿すべきです） 2. 報告された問題が明らかに正しいもので重複していない場合は、 とりあえずそれを 受け入れて通常のライフサイクルを開始します。 結局、報告した人はバグかどうか を誰かに見てもらうべきだと言われているので、 正しいバグ報告を処理済みにする まで労力を無駄にする点はありません。 3. そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークし ましょう。 しかし、報告した人には誰かにバグであるかを確認した上で報告したの なら、再度保留中にして欲しいと伝えます。 この場合、報告した人は確認をとった スレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するは ずです。 この方法はいずれバグ追跡システムの S/N比を改善してくれるでしょう。 しかし、間違 ったバグ報告は決してなくならないことを覚えておいてください。 間違ったバグ報告を 根絶する唯一の方法は、 開発者以外の人にはバグ追跡システムを使わせないことです — しかし、この方法でよい結果が出ることはほとんどありません。 間違ったバグ報告を取 り除くことがプロジェクトのルーチンワークであることを受け入れ、 できるだけ多くの 人達の助けを得ようとした方がよいでしょう。 第8章 の バグマネージャー項 も参照してください。 IRC / リアルタイムに行なわれるチャットシステム 多くのプロジェクトでは、Internet Relay Chat (IRC) を使ったリアルタイムのチャッ トルームを提供しています。 そこではユーザーと開発者が質問を出し合い、すぐに返事 を貰うことができます。 自前のIRCサーバを動かすことも 可能です が、 普通はそこま で頑張る必要はありません。むしろみんながやっていることを真似てみましょう。 つま り、Freenode (http://freenode.net/) で自分のIRCチャンネルを開設するのです。 Freenodeは、IRCサーバを自分で管理する苦労からあなたを解放すると同時に、 ^[21] プロジェクトのIRCチャンネルを管理するために必要な規制を行っています。 まずやるべきことはチャンネルの名前を決めることです。 もっともわかりやすいのはプ ロジェクトの名前です。 — Freenode で使える名前なら使ってください。 もし使えない のなら、 プロジェクトの名前に近い名前で、 できるだけ覚えやすい名前を選ぶように してみてください。 質問に素早く答えて欲しいユーザーがすぐにわかるように、 プロ ジェクトのウェブサイトでIRCチャンネルが利用できることを知らせましょう。 たとえ ばSubversion のホームページでは、 ページ上部の目立つボックス部分に次のような情 報を表示しています。 Subversionをお使いなら、メーリングリスト users@subversion.tigris.org を購読 し、 Subversionによるバージョン管理 と FAQ を読むことを勧めます。 IRCの irc.freenode.net 上のチャンネル  #svn  でも質問することができます。 プロジェクトによっては複数のチャンネルを持つものもあり、 ひとつひとつが副次的な トピックを扱っています。 たとえばあるチャンネルはインストール時の問題を扱い、 別のチャンネルでは使い方の問題、開発に関するチャット、等です。 (第6章 の 巨大化 への対応項 では、チャンネルを複数に分割する方法について議論しています。) プロジ ェクトが始まって間もないなら、皆が一緒にお喋りできるようにチャンネルの数はひと つにすべきでしょう。 後に開発者ひとりに対するユーザーの数が増えるのに応じて、 チャンネルの分割が必要になるかもしれません。 どのチャンネルで喋ればよいかは言うまでもなく、 利用できる全てのチャンネルを知ら せるにはどうしたらよいでしょうか? そしてチャットをするとき、 プロジェクトに特有 の決まりごとを知らせるにはどうすればよいでしょうか? 答えは チャンネルトピック ^[22] を設定して知らせることです。 チャンネルトピック は、初めてチャンネルに入ったときにユーザーが見るメッセージです。 これは新顔のユ ーザーに簡単な案内をすると同時に、 さらに詳しい情報へのポインタを提供します。 たとえば以下のようなものです。: あなたは #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チャンネルには、 いわゆる ボット と呼ばれる人間でないメンバ ーがいます。 これは特定のコマンドに反応して情報を保存したり、 表示したりできま す。 通常は、ボットはチャンネルにいる他のメンバーと同じように扱います。 つまり 、コマンドはボットに "話しかける" ことで伝えます。 たとえば次のようなものです : ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd Thanks! これはボット(ayita としてチャンネルにログインしています)に "diff-cmd" という問 い合わせの答えとしてあるURLを覚えておくように伝えています。 では、ayita に話し かけて、他のユーザーに diff-cmd に関する情報を伝えるように頼んでみましょう : ayita: tell jrandom about diff-cmd jrandom: http://subversion.tigris.org/faq.html#diff-cmd 便利な短縮コマンドを使っても同じことが実現できます。 !a jrandom diff-cmd 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 についての技術的な詳細を説明することは控えます ^[23]が、次のふた つはしっかり覚えておきましょう。 まず、購読者がフィードリーダーを使用すると、購 読しているフィードを 同じように 扱えるようになります。 これが RSS のセールスポ イントのひとつです。 何かひとつのインターフェイスを選択すれば、 すべてのフィー ドが同じインターフェイスで使用でき、 配信される内容に集中することができるという わけです。 次に、RSS は今やあらゆるところで利用されており、 ほとんどの人は知ら ず知らずのうちにそれを使用しているということです。 世間一般の人たちにとっては、 RSS というのはウェブページ上の "このサイトを購読" とか "ニュースフィード" とか 言うちっちゃなボタンのことです。 そのボタンをクリックすれば、フィードリーダー (ホームページに埋め込まれているアプレットかもしれません) は自動的にそのサイトの ニュースの更新情報を取得してくれます。 これらを踏まえると、あなたが運営するオープンソースプロジェクトでもおそらく RSS フィードを提供しなければならなくなるでしょう (あらかじめ用意されているホスティ ングサイト  — ツールが一通り揃ったホスティングサイト項 を参照ください — の多く は、この機能を持っています)。 一日になんどもニュースを投稿してしまわないように 注意しましょう。 そんなことをしたら、購読者たちは どれが本当に大切なニュースな のかを判断できなくなってしまいます。 あまりにも大量のニュースが投稿されると、 そのフィードを無視されてしまったり、 あるいは腹が立ってそのフィードの購読をやめ てしまうかもしれません。 理想を言えば、用途に応じて個別のフィードを提供するのが いいでしょう。 大事な告知用のフィード、たとえばバグ追跡システム用のフィード、 メーリングリストの投稿用のフィードなとといった具合です。 とは言え、実際にこれを するのは大変です。 プロジェクトのウェブサイトを訪れる人たちにとっても、 プロジ ェクトの管理者にとっても、 何をどうしたらいいのか混乱してしまうことでしょう。 しかし、少なくともプロジェクトのトップページには RSS フィードを提供するようにし ましょう。 このフィードでは、リリース情報やセキュリティ警告といった重要な告知を 配信します。 ^[24] 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は変えないように確実に準備をしておくよう にしましょう。 ホスティングサイトを選ぶ 最も規模が大きく、有名なホスティングサイトは SourceForge です。 他には、 savannah.gnu.org と BerliOS.de の二つが SourceForge と同様または類似のサービス を提供しています。 Apache Software Foundation や Tigris.org^[25] のような組織は 、自分達の任務と既にあるプロジェクトのコミュニティーにうまく合っているオープン ソースプロジェクトを無料でホスティングしています。 匿名性とプロジェクト参加 厳密にはホスティングサイトに限った問題ではないのですが、 ホスティングサイトで最 もよく見られるのが、ユーザーログインの機能に関する苦情です。 ログイン機能自体は 十分単純です。 ウェブサイトでは、訪問者が自分のユーザー名とパスワードを登録する ことができるのです。 登録するとユーザーのプロフィールが保存され、 プロジェクト の管理者は、ユーザーにリポジトリへのコミット権限のような特定の権限を与えること ができます。 この機能は非常に有用で、ホスティングサイトの主な利点のひとつです。 問題は、未登 録のユーザーにも許可されるべきタスク、 特にバグ追跡システム内のファイルアップロ ードや、既存の問題にコメントをつけるときに、 往々にしてログインが必要になってし まっている点にあります。 こうしたタスクにログインを必要としてしまうと、 本来迅 速で便利であるべきタスクに参加する敷居が高くなってしまいます。 勿論、バグ追跡シ ステムにデータを登録した人に連絡を取りたい人もいますが、 その場合は(本人が望ん だ場合に)電子メールアドレスを入力できるフィールドを設けておけば十分です。 新し いユーザーがバグを発見して報告したいと思ったとして、 バグ追跡システムに入力する 前にアカウント作成フォームを入力しないといけないとわかればうんざりするでしょう 。 そのユーザーは結局バグを登録しないかもしれません。 ユーザーを管理する利点は、通常は欠点に勝るものです。 しかしユーザーを匿名で行動 させる選択肢があるなら、 全ての 読み取り専用のアクションだけでなく、 特にバグ追 跡システムや、持っているならwikiページのデータ入力についても、 ログインしていな いユーザーに許可するようにしましょう。 ━━━━━━━━━━━━━━ ^[16] 1975 年に出版された彼の著書 The Mythical Man Month (邦題:「人月の神話」) に登場した法則。 http://en.wikipedia.org/wiki/The_Mythical_Man-Month および http://en.wikipedia.org/wiki/Brooks_Law ( 日本語) を参照してください。 ^[17] 本書の出版直後に Michael Bernstein が教えてくれました。"Mutt 以外にも、 reply-to-list 機能を実装しているメールソフトがあります。 たとえば Evolution で は、キーボードショートカット (Ctrl+L) でこの機能を使用できます。でもボタンはあ りません。" ^[18] その後、この機能をサポートするメーリングリスト管理ソフトがあることを知り ました。 Siesta というものです。 http://www.perl.com/pub/a/2004/02/05/ siesta.html の記事も参考になるでしょう。 ^[19] その証拠としては http://cia.vc/stats/vcs や http://subversion.tigris.org/ svn-dav-securityspace-survey.html があります。 ^[20] configure ファイルをバージョン管理するか否かについては、 別の見方もありま す。Alexey Makhotkin の記事 "configure.in and version control" が、次の URL で 見られます。 http://versioncontrolblog.com/2007/01/08/ configurein-and-version-control/ ^[21] Freenode への寄付を要求されたり、 期待されたりすることはありませんが、 あ なた個人やプロジェクトに余裕があるなら寄付することを考えてみてください。 アメリ カ国内からだと税金が控除される寄付金として扱われますし、 寄付されたお金を使って 価値のあるサービスが提供されるのです。 ^[22] チャンネルトピックを設定するには /topic コマンドを使います。 IRCコマンド は全て "/" で始まります。 IRCの使い方やチャンネルの管理に慣れていないのであれば 、 http://www.irchelp.org/ を参照してください。: 特に http://www.irchelp.org/ irchelp/irctutorial.html は優れたチュートリアルです。 ^[23] 詳細は http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html をご覧くだ さい。 ^[24] このセクションは、書籍として出版された初版には存在しません。 Brian Aker のブログのエントリ "Release Criteria, Open Source, Thoughts On..." を読んで、オ ープンソースプロジェクトにおける RSS フィードの有用性に気づいたので追記しました 。 ^[25] 注意: 筆者は Tigris.org に出資している CollabNet で働いており、普段 Tigrisを使っています。 第4章 プロジェクトの政治構造と社会構造 目次 優しい独裁者 誰がよき「優しい独裁者」になれるか？ 合意に基づく民主主義 バージョン管理を行なうと堅くならずに済む 合意に至らなければ投票する いつ投票を行なうべきか? 誰が投票するのか? 世論調査 v.s 投票 拒否権 全てを記録しておく フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう 仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？" と いったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコー ド、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のと ころ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコ ードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているか について殆ど説明していませんし、 プロジェクト内で起こる衝突をどうやって解決する のかについては何も触れていません。 この章では、成功しているオープンソースプロジェクトに共通している、 基本的な仕組 みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、 プ ロジェクトが健全に運営されており、生き残る力が強いことを言います。 新しいコード や開発者を受け入れたり、 バグレポートに素早く反応することを継続できていれば、 プロジェクトは健全に運営されているといえます。 特定の個人やスポンサーに依存しな くてもプロジェクトを続けられれば、 生き残る力が強いといえます。— プロジェクトを 立ち上げたメンバー全員が他に移ったとしても、 プロジェクトが生き残る可能性がある かを考えてみてください。 技術的に成功することは難しくありません。 しかし開発者 の層が薄かったり、社会的な基盤が弱かったりすると、 プロジェクトが初期段階で成功 して膨張したり、 カリスマ的な人がいなくなったときに、対応できないかもしれません 。 オープンソースプロジェクトを成功させる方法はたくさんあります。 議論をまとめたり 、新しい開発者を勧誘したり（時には追い出したり）、 新しい機能を企画するなどの、 型にはまった統治の仕組みもあれば、 形になって表れないものとして、 メンバーが信 頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、 より意識的に自 制することも含まれます。 プロジェクトは、 参加する人達がよく理解している習慣や 手続きに支えられて存続するという意味で、 どちらも行き着くところは同じです。 こ れらの方法は、中央集権的なプロジェクトより、 自発的に成長するプロジェクトで重要 になります。 自発的に成長するプロジェクトでは、少なくともしばらくは、 よくない ことが全体に影響することを参加する人が意識しているからです。 プロジェクトが分裂する可能性 開発者をフリーソフトウェアプロジェクトに繋ぎ止め、 必要な時に妥協してもらうのに 不可欠な要素は、 コードが 派生する ことです。つまり、 誰かがソースコードのコピ ーを使って、 新しい競合プロジェクトを立ち上げることです。これは フォーク という 用語でも知られています。 逆説的なのは、プロジェクトが分裂する 可能性 の方が、 まれながら実際に分裂することよりも、 フリーソフトウェアプロジェクトにとって大き な力になるということです。 プロジェクトが分裂することは万人にとってよくないこと なので、 (詳細な理由は、第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://svn.collab.net /repos/svn/trunk/www/hacking.html にある、Subversion の hacking.html ファイルが あります。 もうひとつは、http://www.apache.org/foundation/how-it-works.html と http://www.apache.org/foundation/voting.html にある、Apache Software Foundation の統治に関する文書です。 Apache Software Foundation は実際はソフトウェアプロジ ェクトの集合体ですが、 非営利組織として合法的に組織されています。 よって彼らの 文書には、開発する際の規約よりも、 プロジェクトを統治する際の手続きについて多く 記述されています。 ですが、まだ読む価値は大いにあります。 なぜなら、それはたく さんのオープンソースプロジェクトの経験を集積した文書だからです。 第5章 カネに関する問題 目次 プロジェクトへの関わり方 開発者を長期に渡って雇用する 企業の人間としてではなく、個人として振る舞う 動機を隠し立てしない カネで愛は買えない 契約する レビューを行い、変更をソースコードに取り入れる ケーススタディ: CVS パスワード認証プロトコルの場合 プログラミング以外の活動を支援する 品質保証 (テストの専門家など) 法律上の助言、権利の保護 ドキュメントやユーザビリティの改善 ホスティングサイトや接続回線を提供する マーケティング 見られていることを意識する 競合するオープンソースプロジェクトを攻撃しない この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきま す。 ここでは、フリーソフトウェアプロジェクトでお金を貰って雇われる開発者だけで なく、 開発する環境が置かれる社会力学を理解する必要があるプロジェクト管理者も対 象にします。 以下のセクションでは、読者(あなたです！) はお金を貰って雇われる開 発者か、 開発者を管理する人であることを想定します。 この章でのアドバイスは、両 者に当てはまることもありますし、そうでないこともありますが、 対象となる人は文脈 の中で明らかにしていきます。 フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。 多く の開発が、いつも非公式に奨励金の対象になってきました。 システム管理者が業務の遂 行を助けるためにネットワーク分析ツールを書き、 オンラインにそれを投稿し、 バグ 修正や機能追加の貢献を他のシステム管理者から受けた場合、 非公式に団体が設立され ていきました。 団体を維持するための資金は、システム管理者達の給料から出ており、 オフィススペースやネットワークの帯域は寄付によって賄われました。 こうした組織は 、はじめのうちは制度的に認知されることはありませんでしたが、 もちろん投資するこ とで利益を得ていたのです。 当時と今の違いは、こうした努力の多くが公に認められるようになったということです 。 企業はオープンソースソフトウェアから得られる利益に関心を示すようになり、 そ の開発に直接関わりはじめました。 開発者達も、本当に重要なプロジェクトには少なく とも寄付や、 可能であれば長期のスポンサーを期待するようになっています。 お金が あるからといって、 フリーソフトウェアの基本的な開発力学が変わるものではありませ んが、 開発者の数や、開発者ひとり当たりの作業量の規模は劇的に変わりました。 お 金は、プロジェクトが組織化される方法や、 関係者のプロジェクトでのやりとりの仕方 にも影響を与えました。 問題は、単にお金がどう使われるのかとか、 投資に対する見 返りをどのように測るか、ということにとどまらず、 プロジェクトの管理やそのプロセ スにも及びます。 つまり、企業の階層的な命令系統と、 緩やかに分散したフリーソフ トウェアプロジェクトのコミュニティーが、 お互いに生産的に動くにはどうしたらいい でしょう？ そもそも "生産的に" という言葉がどういう意味なのか、 について企業と コミュニティーは一致するのでしょうか？ 金銭的な支援を受けることは、 オープンソース開発コミュニティーでは一般的に歓迎さ れています。 支援を受けることで、 軌道に乗る前に多くのプロジェクトを潰してきた コミュニティーの弱点を無秩序の力に変えることができます。 それゆえに、人々はソフ トウェアを世に送り出したいと強く願うようになります。 — つまり、これから向こう6 ヵ月間は自分の時間をそこらへんに転がっている何かに使おう、 と人々は考えるのです 。結局、何かを信じる心は、ある程度までは他の人に伝染しやすいものです。 たとえば 、IBM がオープンソースプロジェクトを支援したとき、 このプロジェクトに失敗は許さ れないと人々は強く思いましたし、 失敗しないようプロジェクトに注力しようと思う心 が、 プロジェクトが実際に失敗しない状況を作ったのです。 しかし、お金を出すことは、人を支配する感覚を生むものでもあります。 注意深く扱わ ないと、お金はプロジェクトを、仲間内の開発者とそうでない開発者に分裂させてしま うかもしれません。 ボランティアの開発者が、一番お金を出している人が機能追加や設 計上の決定を行えるんだと思ってしまうと、 実力志向が強く、それでいて他人の利益の ために無給で働くことを好まないプロジェクトに移ってしまうでしょう。 彼らは、決し てメーリングリスト上で大声で不平を言ったりはしません。 そのかわり、ボランティア 達が真剣に取り組むことをやめてしまうため、 外から口を出す人がどんどん少なくなっ ていくだけです。 バグ報告や小規模な修正をたまに行う形で活動は続きますが、 大規 模なコードの貢献や、設計上の議論に外部から人が参加するといったことはなくなって しまいます。 人々は自分に何が期待されているのかを感じ取り、期待に応えようと動い たり、 それを裏切ったりするのです。 お金は注意深く扱う必要がありますが、 そうしたからといってプロジェクトへの影響力 を買えるわけではありません。 ほとんどの場合は、買えるのですが、 プロジェクトに 直接影響力を行使できるわけではない、というのがミソです。 単純な商取引では、欲し いものとお金を交換します。あなたが追加して欲しい機能があれば、 契約にサインし、 お金を払い、作業をしてもらいます。 オープンソースプロジェクトでは、事はそう簡単 ではありません。 あなたは開発者達と契約することが出来ます。しかし、彼らがもし、 お金を払うだけで開発コミュニティーにその有償の成果を取り込んでもらえると保証し たのなら、 彼らは — そしてあなたも — 勘違いをしています。 コミュニティーは、成 果物そのものの利点と、 それがどの程度ソフトウェアのビジョンに合っているかに応じ てそれを受け入れるのです。 あなたはソフトウェアのビジョンについて口を出す権利は ありますが、 あなたの意見が唯一の声というわけではないのです。 よって、お金でプロジェクトへの影響力を買うことはできません。しかし、 影響力に 繋がるもの を買うことはできます。 もっとも明快な例はプログラマーを買うことです 。 優れたプログラマー達を雇えば、彼らはソフトウェアに関する経験を積み、 コミュ ニティーで信頼を得るまでプロジェクトに張り付きます。 そうすれば、他のメンバーと 同じ手段でプロジェクトに影響を与えることができます。 彼らはそれぞれが投票権を持 つ場合もあれば、人数が多い場合にはブロック投票権を持つこともあります。 彼らがプ ロジェクトで尊敬を得れば、投票権以上の影響力を持つことになるでしょう。 雇われて いる開発者は自分の動機を偽る必要はありません。 結局、ソフトウェアに変更を加えた い人は誰でも、それぞれに理由があるものです。 企業がソフトウェアを変更したい理由 が、他より正しくない、ということはありません。 企業の目標がプロジェクトで重視さ れるかどうかは、 企業規模や予算、もしくはビジネスプランによって決まるのではなく 、 企業を代表している人たちのプロジェクト内での地位によって決まるのです。 プロジェクトへの関わり方 オープンソースプロジェクトがお金を出してもらう理由は様々なものがあります。 以下 に示す理由は、相互に排他的なものではありません。 つまり、支援を受ける理由は以下 の複数、または全てが当てはまる場合があります。 コスト負担を共有する 関連があるソフトウェアを必要とする組織は、 似たようなコードを社内で書いたり 、 商用ベンダから似たような商品を購入したりすることで、 同じ目標に向かって 重複した努力をしていることがよくあります。 彼らはそれを知ると、 自分たちの 需要を調整するため、 オープンソースプロジェクトを作る(または既存プロジェク トに参加する)かもしれません。 その利点は明らかです。 開発コストを分散しつつ 、利益は参加したすべての組織が得ることができるからです。 このシナリオは、非 営利な組織の場合もっともわかりやすいのですが、 競合関係にある営利組織であっ ても、戦略的には有意義なものです。 例: http://www.openadapter.org/, http://www.koha.org/ サービスを拡大する 企業が販売している複数のサービスが特定のオープンソースソフトウェアに依存し ていたり、 それによってサービスの魅力を高めている場合、 そのソフトウェアを 活発に維持していくことがその企業の関心事になるのは自然の流れです。 例: CollabNet が http://subversion.tigris.org/ をサポートしていること(お断 り: これは筆者のルーチンワークですが、これがこのモデルの最良の例です) ハードウェアの営業をサポートする コンピューターとその部品の価値は、 それが利用できるソフトウェアの量に直接左 右されます。 ハードウェアベンダー — 完成したマシンのベンダーだけでなく、 周 辺機器デバイスやマイクロチップのベンダーも含みます — は、自分たちのハードウ ェアを動かせる高品質なフリーソフトウェアが存在していることが、 顧客にとって 重要であることに気付いているのです。 競争相手を弱体化させる 企業によっては、 競合しているソフトウェアの力を弱めることを狙ってオープンソ ースプロジェクトをサポートするところもあります。 競合するソフトは、オープン ソースであってもそうでなくても構いません。 競争相手の市場シェアを減らすこと が、 オープンソースプロジェクトに参加する唯一の理由ではないものの、 そのひ とつだったりすることはあり得ます。 例: http://www.openoffice.org/ (競争相手を弱体化させることが OpenOffice の 唯一の存在理由ではありませんが、 このソフトウェアは、少なくとも Microsoft Office に対する答えのひとつです) マーケティング 人気のあるオープンソースソフトウェアに関わっている企業は、 それだけでブラン ド管理をうまく行うことができます。 デュアルライセンス デュアルライセンス とは、 自分のソフトウェアに商用のソフトウェアを組み込ん で売りたい顧客向けの伝統的な商用ライセンスと、 ソースを公開して使いたい人向 けのフリーなライセンスを同時に共存させてソフトウェアを提供するための手法で す。 (第9章 の デュアルライセンスの仕組み項 を参照してください) オープンソ ース開発者のコミュニティーが活発なら、 デュアルライセンスされたソフトウェア は、 広く多くの人から開発作業やデバッグをしてもらえるという利益を得られる上 、 企業はフルタイムで働くプログラマーを支援することで、 ロイヤリティの収入 を得ることができるのです。 このモデルの例として、よく知られているものがふたつあります。 同じ名前のデー タベースソフトウェアを作っている 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 と私は契約を結び、新しい認証機構を設計する作業に腰を据えて取り組みました。 私たちが思いついたのはとても単純なもの (アメリカ合衆国は、当時暗号化に関するプ ログラムに輸出規制をかけていました。よって、暗号化の強度が高い認証機構を実装で きなかったのですが、このことは顧客も理解してくれていました) でしたが、この手の プロトコルは設計したことがなかったので、専門家から見れば明らかな間違いが残って いました。この手の間違いは、設計を提案する文書を書いて、他の開発者にレビューし て貰えば容易に発見できるものでした。しかし、当時の私たちには開発用のメーリング リストをリソースとして使うという考えがなかったため、そうしませんでした。コミュ ニティーの人たちは私たちが何をコミットしても受け入れることがわかっていましたし 、それに — 自分たちが無知であることがわからなかったので — 自分たちがやっている ことを他人が見える形にはしなかったのです。たとえば、修正プログラムを頻繁に投稿 したり、小さな理解しやすい単位で特別なブランチにコミットしたりするなど、です。 結果としてできた認証プロトコルは、あまり出来がよくありませんでしたし、一度作っ てしまったら、互換性の問題を考えると改良も難しいものだったのです。 問題の根本は、経験不足でした。私たちは知るべきことを容易に学ぶことができたはず なのに、学ぼうとしなかったのです。開発コミュニティーに対する態度にも問題があり ました。私たちは、レビューをして貰った上で変更を取り入れてもらうことを変更の質 を上げるためのプロセスというよりは、障害だと考えていたのです。自分たちがやるこ とはほとんど全て受け入れてもらえると(当時は)思い込んでいたので、他の人を巻き込 もうとする努力をしなかったのです。 契約する相手を選ぶときは、適切な技術スキルと経験を持った人を選びたいのは明らか ですが、コミュニティーにいる他の開発者と建設的なやりとりをした実績がある人を選 ぶことも重要です。そうすれば、実質的にひとり分以上の成果を得ることができます。 つまり、堅固で維持しやすいやり方で仕事をしてくれる、専門家のネットワークと繋が りを持ったエージェントを雇うことになるのです。 プログラミング以外の活動を支援する プログラミングはオープンソースプロジェクトで行われる活動の一部に過ぎません。プ ロジェクトのボランティアから見ると、プログラミングはもっとも目立つ、華やかな部 分です。このことは、ドキュメントやテストなどのプログラミング以外の活動が、少な くとも独占的なソフトウェアと比較すると残念ながら無視されることがある、というこ とを意味しています。企業は、自らが持つソフトウェア開発の内部インフラをオープン ソースプロジェクトに与えることで、こうした無視されがちな活動を埋め合わせること ができます。 内部インフラをオープンソースプロジェクトにうまく与えるための鍵は、企業の内部プ ロセスをオープンソースプロジェクトのそれに変換することです。この変換にはそれな りの努力が必要です。企業の内部プロセスとオープンソースプロジェクトのそれは一致 しないことが多いですし、そうした違いは人間が介入しないと埋められないものだから です。たとえば、企業とオープンソースプロジェクトは異なるバグ追跡システムを使っ ているかもしれません。たとえ同じものを使っていたとしても、蓄積したデータが全く 違うかもしれません。なぜなら、企業のバグ追跡の対象がオープンソースプロジェクト のそれとは全く違うからです。一方のシステムにある情報の断片は、もう片方のシステ ムに反映させるべきかもしれませんし、企業秘密に関わるものだから削除すべきかもし れませんし、一方にないものをもう片方に追加しなければいけないかもしれません。 ここでは、企業とオープンソースプロジェクトをそうした点で橋渡しする方法を説明し ます。うまく橋渡しすれば、オープンソースプロジェクトがより順調に動き、コミュニ ティーは与えられたリソースを理解するはずです。また、企業が自分のエゴのために物 事を不適切に進めているのではないかと疑わなくなるはずです。 品質保証 (テストの専門家など) 独占的なソフトウェアの開発では、バグ探しやパフォーマンス、 スケーラビリティのテ スト、インターフェイスやドキュメントの確認、 などの品質保証専門チームを置くこと が普通です。 フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、 品質保証に関する活動は積極的に行われないのが一般的です。 これはテストのような地 味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、 ユーザー数が 多いプロジェクトのコミュニティーでは、 テストの網羅率が高くなると人々が考えると いうこともあります。 また、パフォーマンスやスケーラビリティのテストの場合は、 ボランティアは必要なハードウェアリソースを得られないから、 ということもあります 。 多くのユーザーを抱えているプロダクトには多くのテスターがいる、 という考えは全く 根拠がないものではありません。一般的な環境で、 基礎的な機能にテスターを割り当て るのはあまり意味がないのは確かです。 なぜなら、そういう状況ではバグがすぐに見つ かるのが自然の流れだからです。 しかし、ユーザーはただ仕事をこなそうとするだけな ので、 プログラムの動作の限界を意図的に探そうとはしません。 よってある程度のバ グが残る可能性があります。 さらに、容易に回避する方法があるバグの場合、 ユーザ ーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。 もっとも油断 ならないのは、あなたの顧客 (あなたが 関心がある人たちです) のソフトウェアの使い 方が、 そこら辺にいる平均的なユーザーの使い方と違う場合があることです。 テスト専門のチームは、 こうした手合いのバグをフリーソフトウェアでも発見してくれ ます。 難しいのは、テストチームが行った作業の結果を、 わかりやすい方法で皆に伝 えることです。 組織内のテスト専門部署は、 テスト結果を報告する独自のやり方をそ れぞれ持っています。 たとえば企業独自の方言や、 特定の顧客や彼ら向けのデータに 関する特定の知識などです。 こういった独自の情報は、書式や秘密保持の観点から、 公開されているバグ追跡システムに載せるのは不適切です。 たとえあなたの企業で使っ ているバグ追跡システムが、 フリーソフトウェアプロジェクトのそれと同じだったとし ても、 特定の企業向けのコメントやバグに関するメタデータ (たとえば、バグに対する 内部的な優先度や、 特定の顧客向けに解決するスケジュール) を作る必要があるでしょ う。 こうした情報は外部には漏らさないのが普通です— 場合によっては、顧客にすらみ せてはいけないものです。 しかし、たとえ秘密でなくても、 それらはフリーソフトウ ェアプロジェクトにとっては関心がないものです。 よって、そうした情報に気を取られ てはいけません。 しかしながら、バグ報告そのもの はフリーソフトウェアプロジェクトにとって重要なも のです。 実際、テスト専門のチームからあがってきたバグ報告は、 多くのユーザーか ら受け取るそれよりもある意味価値があるものです。 なぜなら、彼らはユーザーが調べ てくれないことを調べてくれるからです。 テストチームからしかあがってこないバグ報 告がある場合、 確実に保存してフリーソフトウェアプロジェクトが利用できるようにし ておきます。 確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、 彼らとの仲介 役 (通常は開発者のひとり) が、 内部向けのバグ報告を新しいものに「翻訳」してバグ 追跡システムに登録するようにします。 ここでいう「翻訳」とは、単に顧客特有のデー タ (バグの再現手順には、 勿論顧客の同意を得た上で顧客のデータを使う場合がありま す) を参照せずにバグについて説明することです。 テストチームが直接問題を登録する方がどちらかといえば望ましいです。 こうすること で、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。 役に立つバグ報告をすると、 技術的な貢献をすることと同じくらいあなたの組織への信 頼は高まります。 これは開発者にとっては、 テストチームと直接話をする機会に繋が ります。 たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれて いる場合、 開発者はスケーラビリティに関するバグ (これをテストするリソースを彼ら は持たない場合があります) を修正する作業に注力でき、 その修正が望ましい結果を出 しているか検証するよう、 バグ追跡システム上にコメントすることでテストチームに頼 むことができます。 開発者から多少の抵抗があることは覚悟しておいてください。 プ ログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。 テ ストチームが重要なバグを発見し、 理解しやすいバグ報告を行えば、こうした抵抗を振 り払うのは簡単です。 一方、彼らのバグ報告の質がユーザーからあがってくるそれと大 差ない場合は、 開発者と彼らが直接話をする意味はありません。 どちらにせよ、組織内部のバグ報告が、 外部のバグ追跡システムにいったん登録された ら、 組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。 組織の 管理者や雇われている開発者は、 必要に応じて顧客に特有の情報について注釈を付けて も構いませんが、 みんなが使えるようにするために、外部の情報を利用するようにしま しょう。 こうした作業の過程で、あなたには余計な負担が掛かるはずです。 ひとつしかバグがな いのに二重にバグ報告を管理するのは、 ひとつを管理するのに比べて仕事が多くなるの は当然です。 ただ、こうすることで多くのプログラマーがバグ報告の情報を利用でき、 問題の解決に貢献できるようになるのです。 法律上の助言、権利の保護 営利企業であれ、非営利な組織であれ、 法人はフリーソフトウェアに潜む複雑な法律問 題に注意を払う機会があるほぼ唯一の組織です。 開発者個人は、オープンソースライセ ンスの微妙な違いを理解している人もいますが、 著作権、商標、そして特許に関する法 律の詳細を理解するためのリソースも時間もないのが普通です。 あなたの組織に法務部 がある場合、 プログラムについている著作権の状態を調査したり、 実際に起こりうる 特許や商標の問題について開発者に具体的に助言することができます。 こうした点で開 発者を助ける正しいやり方は、 第9章 で議論しています。 もっとも重要なのは、法務 部と開発者コミュニティーがコミュニケーションを取る必要がある場合、 それぞれが全 く違う世界にいることを認識した上で話をすることです。 お互いが過去に話したことが ある場合もあれば、 一方が全く知らない専門領域に関する知識を持っているものとめい めいが思い込んでいる場合もあります。 一番よいのは、仲介役となる人 (開発者か、技 術的な専門知識をもった弁護士) を必要な限り間に置くことです。 ドキュメントやユーザビリティの改善 ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として 有名ですが、 私は少なくともドキュメントについては、独占的なソフトウェアとの違い が誇張されていると思っています。 とは言っても経験上は、素晴らしいドキュメントや ユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。 あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、 プロジェクトの開発 者ではなく、 彼らと建設的に話ができる人を雇うとよいでしょう。 プロジェクトの開 発者を雇わない方がよい理由はふたつあります。 ひとつは、プロジェクトから離れてし まうと開発する時間がとれなくなること。 もうひとつは、対象となるソフトウェアにあ まりにも距離が近い人は、 第3者の視点からそれを眺めるのが難しいために、 ドキュメ ントを書いたりユーザビリティを調べるのに普通向いていないからです。 しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。 彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておら ず、 普通のユーザーに感情移入できる人を探しましょう。 中級者レベルのユーザーが、ドキュメントを書くのに多分向いているでしょう。 実際、 この本の第1版が世に出たあと、 私は Dirk Reiner というオープンソースソフトウェア の開発者から次のようなメールを受け取っています。 「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。 もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか を覚えていましたし、問題を乗り越えてきていたので、どう人に説明すればいいかを 分かっていました。このため、彼が書いたドキュメントは、彼自身が理解できなかっ た部分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」 ものとして見逃していた部分も網羅できていたのです。 もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は 自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま うまくできたこと、をうまく組み合わせることができました。 よって、彼が書いたドキュメントはさらに素晴らしいものになっていたのです。 ホスティングサイトや接続回線を提供する 一通りのツールが揃ったホスティングサイト ( 第3章 の ツールが一通り揃ったホステ ィングサイト項 を参照してください) を使っていないプロジェクトに対して、 サーバ やネットワーク接続を提供— もっとも重要なのはシステム管理を手助けすることですが— すると、 プロジェクトが大いに助かる可能性があります。 たとえそれがあなたの組織 ができる全てであったとしても、 世間的に良い評価を得るためにそれなりの手段になる ことでしょう。 但し、プロジェクト全体の方向性に影響を与えることはできません。 ホスティングサイトを提供していることに感謝の意を表すために、 プロジェクトのホー ムページにお礼の言葉を載せてもらったり、 バナー広告を貼らせてもらえることが期待 できます。 ホスティングの設定にあたって、プロジェクトのURLをあなたの企業のドメ イン内に設定した場合、 URLだけでプロジェクトとあなたの企業が関係があることを理 解してもらえるでしょう。 これによって、あなたの企業が開発に全く貢献していなくて も、 ほとんどのユーザーが 何かしらの 関係があると看做すようになります。 問題は 、ユーザーがそう考えることに開発者も気づくため、 ホスティングサイトやネットワー ク回線以外の開発リソースを提供しなければ、 あなたのドメイン内にプロジェクトを置 くことにあまりいい感情を持たない可能性があることです。 何だかんだ言っても、最近 はたくさんのホスティングサイトがあります。 コミュニティーは結局、実態に見合わな いクレジットを与えるのは、 ホスティングを提供してもらう利点に見合わないと感じて 、 プロジェクトを他に移してしまうでしょう。 よって、あなたがホスティングサイト を提供したいなら、そうすると良いでしょう— 但し、すぐにもっと積極的にプロジェク トに関わるプランを示すか、 自分の主張がどれくらいプロジェクトに影響を与えられる かについて、 よく考える必要があります。 マーケティング ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、 マーケ ティングは役に立つものです。マーケティング活動をうまくやれば、 頭の固いプログラ マーが理由もよくわからないのに、 そのソフトウェアに対して良い印象を持つくらいに まで、 オープンソース界隈の評判を作り出すことができます。 ここでは、マーケティ ングにおける競争力学を一般的に分析するわけではありません。 フリーソフトウェアの 世界に関わっている企業は結局、企業自体や、ソフトウェア、 そしてソフトウェアと企 業の関係をどうやって売り込んでいくか、を考えるようになります。 以下では、こうし た努力をするにあたって陥りがちな一般的な落とし穴について解説します。 第6章 の 宣伝・広報項 も参照してください。 見られていることを意識する ボランティアの開発者コミュニティーをあなたの味方に付けるには、 はっきりしていな い事柄は喋らないことが とても 重要です。 すべての主張を公にする前に注意深く調べ 、その主張自体をチェックする手段も公にしておきます。 独自に事実を検証できるのは 、オープンソースの重要な部分です。 それはコード以外の部分にも当てはまります。 当然のことながら、検証できない主張をするなと企業にアドバイスする人などいません 。 しかし、ことオープンソースの活動においては、 主張を検証する経験に長けた人が 非常に多くいます— なぜなら、広い帯域のインターネット接続回線を持ち、 物事を中傷 するために社会的接触を持つ可能性がある人が大勢いるからです。 化学工業の巨大企業 が川を汚染している場合、それは検証可能ですが、 検証できるのは訓練を受けた科学者 のみです。 彼らは巨大企業の科学者から反論され、 頭をかきむしってどう考えたらよ いのか困惑するかもしれません。 一方で、オープンソースの世界であなたがすることは 、 目に見える形で記録されるだけではありません。多くの人が独立してチェックし、 独自の結論を下し、それらを口コミで広めていくのです。 この口コミのネットワークは 既に定着しているものです。つまり、 オープンソースがどのように影響するかを決める 要素であり、 あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにし ても、 特に人々が言っていることが事実である場合は、普通難しいものです。 たとえば、"プロジェクトXを作った" とあなたの組織が言うのは、 実際にそうしたので あれば問題ありません。しかし、 実際にコードを書いたのが外部の人間である場合、 "Xというソフトウェアを作った" と言ってはいけません。 逆に、誰かがリポジトリの中 身を覗いてみて、 あなたの組織以外の人が変更を加えた跡が殆どまたは全くない場合は 、 ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。 それほど昔のことではありませんが、 とてもよく知られているコンピューター会社が、 重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、 というア ナウンスを見ました。はじめのアナウンスが出た後、 私は公開されているバージョン管 理システムのリポジトリを見てみましたが、 そこには3つのリビジョンしか存在してい ませんでした。 言い換えれば、彼らはソースコードのインポートを終えたこと以外は何 もしていなかったのです。 それ自体は変な事ではありませんでした。— だって結局彼ら はアナウンスしただけですから。 しかし、すぐに活発な開発が行われると期待する理由 は何もなかったのです。 しばらくたってから、別のアナウンスがありました。以下にそれを示しますが、 リリー スナンバーとソフトウェアの名前は別のものに置き換えてあります。 Singer コミュニティーによって厳密にテストされた後、 Singer 5の Linux 版と Windows 版が、 製品としての使用に耐える品質になったことを発表します。 "厳密なテスト" によってコミュニティーが明らかにしたことを知りたいと思い、 私は リポジトリを再度見に行って最近の変更履歴を覗いてみました。 プロジェクト自体のリ ビジョンは3のままでした。明らかに、 コミュニティーはリリース前に修正すべきバグ を ひとつも 見つけていなかったのです！ コミュニティーによるテスト結果がどこかに 記録されているはずだと考えて、 私は次にバグ追跡システムを調べてみました。そこに は確かに6つの問題が記録されていましたが、 そのうちの4つは数ヶ月の間保留状態のま まだったのです。 これは勿論信じがたいことです。 テスターが巨大かつ複雑なソフトウェアをそれなりの 時間使えば、 彼らはバグを見つけるものです。 たとえそうしたバグが次回のリリース に取り込まれなかったとしても、 テストの結果としてバージョン管理システム上での活 動か、 新しい問題がバグ追跡システムに登録されていると期待されるはずです。 しか しながら、どこを見ても、はじめのアナウンスと、 その次のアナウンスとの間に活動の 跡はみられなかったのです。 問題は、コミュニティーがテストしたことについて、企業が嘘をついたことではありま せん。 コミュニティーがテストしたかどうかは私には分からないからです。 しかし、 彼らが言っていることがどれくらい嘘っぽいかは明らかでした。 バージョン管理システ ムだけでなく、バグ追跡システムにも、 厳密なテストが行われたことを示す痕跡はなか ったので、 企業はコミュニティーがテストしたという主張をしないか、 目に見える形 のテスト結果へのリンク ("278個のバグが発見されました。 詳細はここをクリックして ください") を提供すべきでした。 後者は誰でもコミュニティーの活動レベルを素早く 把握できるようにするものです。 実際は、コミュニティーがテストしたことを探すのに 2、3分しかかかりませんでしたし、 普通なら記録される場所に、テストの痕跡が全く残 っていなかったのです。 検証するのに大した手間はかかりませんでしたが、 手間をか けたのは私だけではないはずです。 透明性と検証可能性は、正確なクレジットを与えるときも勿論重要です。 詳しくは、第 8章 の クレジット項 を参照してください。 競合するオープンソースプロジェクトを攻撃しない 競合するオープンソースプロジェクトについて、否定的な意見を述べるのはやめましょ う。 否定的な 事実 については一向に構いません。 — 容易に裏が取れる主張は、比較 の要素としてよく見られるものだからです。 しかし、あいまいな事柄に対して否定的な 評価を行うことは避けた方が良いでしょう。 理由はふたつあります。 まず、それがき っかけで建設的でないフレームウォーが起こりがちだからです。 ふたつめは、もっと重 要なことですが、 あなたの プロジェクトにいるボランティアの開発者の中からも、 競 合プロジェクトで働く人が出る可能性があるからです。 前者より、後者の方が多く発生 する可能性が高いです。 なぜなら、それぞれのプロジェクトは既に同じ専門領域に属し ていて(それゆえに競合関係にあります)、 その領域で専門知識を持っている開発者は、 それを生かせる場所であればどのプロジェクトでも貢献してよいからです。 直接的には 開発者が重複していない状況でも、あなたのプロジェクトにいる開発者が、 関連するプ ロジェクトの開発者を知っている可能性があります。 彼らの建設的な人間関係を維持す る能力が、 否定的なマーケティングのメッセージによって全て壊れてしまう可能性だっ てあるのです。 ソースコードが公開されていない競合プロジェクトを攻撃することは、 特にその製品が マイクロソフト製である場合は、 オープンソースの世界では広く受け入れられています 。 個人的には、この傾向は (単刀直入に事実を比較するのであれば一向に構わないので すが) 残念に思っています。 なぜなら、これは相手に失礼であるからというだけでなく 、 プロジェクトが自ら作っているものの誇大広告を信じ、 それゆえに競合相手が実際 に優れている点を無視し始めるのが危険でもあるからです。 一般的には、マーケティン グのメッセージが、 自分たちの開発コミュニティーにも影響を与えるものかどうかを注 意しておくとよいでしょう。 マーケティングにお金が使われると、 開発者は自分達の ソフトウェアが持っている本当の強みや弱点を、 客観的な眼で見なくなってしまいます 。 このため、企業の開発者はマーケティング上のメッセージに対して、 公のフォーラ ム上でさえある種無関心な態度を示すのが普通ですし、 むしろそれが期待されています 。 はっきりしているのは、企業の開発者はマーケティングによるメッセージに対して、 公の場で矛盾した態度を直接示してはいけない (但し、 それが実際に間違っているとい うのなら別ですが、 その手の事実は早い段階からわかることでしょう) ということです 。 企業の開発者はそうしたメッセージをネタとして扱い、 コミュニティーをマーケテ ィングのメッセージから現実に引き戻す手段にしているのです。 第6章 コミュニケーション 目次 書いたことがすべて 構成や体裁 中身 口調 何が失礼にあたるのか 顔 陥りがちな罠 目的のない投稿をしない 生産的なスレッドとそうでないスレッド 簡単な議題ほど長引く 宗教論争を回避する "口やかましい少数派" について 扱いにくい人たち 扱いにくい人たちへの対応 実例 巨大化への対応 アーカイブを目に付きやすくする方法 全リソースをアーカイブと同様に扱う しきたりの成文化 バグ追跡システムでは議論しない 宣伝・広報 セキュリティ脆弱性の告知 バグ報告を受ける 大至急それを修正する CAN/CVE 番号 事前通知 修正を一般に公開する 明瞭に、わかりやすく書くという技術は、 オープンソース界で暮らす上で最も重要なも ののひとつといえるでしょう。 ある意味ではプログラミング技術よりも重要かもしれま せん。 プログラミングの技術は優れているがコミュニケーションスキルに欠ける人は、 一度にひとつずつのことしかこなせません。 また、周りの人の気を引くことにも苦労す るかもしれません。 逆に、プログラマーとしては二流だがコミュニケーションスキルが 優れている人は、 周りの人をうまく巻き込んでさまざまな作業をこなすことができます 。 そして、結果としてプロジェクトをよい方向に引っ張っていってくれるのです。 コードを書く能力のある人が、 必ずしも他人とうまくやっていくためのコミュニケーシ ョン能力があるとは限りません。 よいプログラムを書く能力と技術的な問題をうまく説 明する能力とには それなりの相関関係はあるかもしれませんが、 「技術的な問題を説 明する」ということは プロジェクト内でのコミュニケーションにおけるほんの一部のこ とに過ぎません。 それよりもずっと大事なことは、次の３つ。 まず聞き手の気持ちに なって考えること、 自分の投稿やコメントを客観的に見るようにすること、 そして他 人にも自分自身の投稿やコメントを客観的に見させるようにすることです。 ……といったことを口で言うのは簡単ですが、実際にやってみると これは非常に難しいこ とです。というのも、フリーソフトウェアの開発には さまざまな人たちが参加しており 、彼らのコミュニケーション方法もそれぞれ異なるからです。 何か意見を述べたいとき はどうすればいいのでしょう？ メーリングリストへ投稿する？ バグ追跡システムに登 録する？ それともコードのコメントとして記述する？ 掲示板での質問に回答するとき 、相手がどれくらいの知識を持っていると想定したらいいのでしょう？ 当然、ここでい う「相手」とは、質問の当事者だけでなく 後であなたの回答を読むであろう第三者も含 まれます。 開発者と利用者の関係を良好な状態に保つにはどうしたらいいのでしょう？ 利用者からの機能追加要求や勘違いのバグ報告、 その他の雑談などに開発者たちが悩ま されないようにするには？ コミュニケーションの手段が尽きたら相手にどう伝えたらい いでしょうか？ また、どう対処したらいいのでしょうか？ これらの問題に対する解決策は、通常は一時的なものとなります。というのも、 どんな 解決策であっても、プロジェクトの規模が大きくなったり プロジェクトの体制が変わっ たりすれば意味がなくなってしまうからです。 また、これらの解決策はたいていその場 しのぎのものになります。 刻々と変化する状況にあわせて即興で対応しなければならな いからです。 すべてのメンバーは、コミュニケーション不全に陥っていないかどうかを 常に気にかけ、 それに対応する必要があります。このような行動を支援することも、 オープンソースプロジェクトの運営の大事な一部です。 以下のセクションでは、あなた 自身がうまくコミュニケーションを行う方法を扱います。 また、プロジェクト内での円 滑なコミュニケーションを維持するための方法についても説明します。 ^[26] 書いたことがすべて 考えてもみてください。インターネット上では、あなたが何者であるかを判断する基準 は 「あなたが何を書いたか」「他人があなたのことをどのように書いたか」 しかあり ません。たとえあなたが頭脳明晰で洞察力に優れ、 カリスマ性のある人物だったとして も、 あなたの書いたメールが中身のない乱雑なものだったら 他の人たちはあなたのこ とを「中身のない乱雑な人」とみなすことでしょう。 逆に、実際のあなたが中身のない 乱雑な人だったとしても、 あなたの投稿する内容が明快で有益なものなら、 他の人た ちは実際のあなたがどうであるかなんて気にしません。 自分が何かを書くときには十分注意を払うようにしましょう。 決して損はしません。フ リーソフトウェアのハッカーとして長年の経験を持つ 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" 実際のところ、この例には 2 つの内容が存在します。 先ほど説明したように、スクリ ーンネームは実名と直感的に対応します。 しかし、実名は 実際の名前です。 つまり、 これは次のような何らかの作り上げた名称とは異なります。 From: "Wonder Hacker" 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 などで取得できます。 陥りがちな罠 目的のない投稿をしない オンラインのプロジェクトに参加するひとたちが陥りがちな罠のひとつに 「すべてのメ ッセージに返信しなければ！」というものがあります。 そんなことはありません。 第 一、数ヶ月を経てある程度の規模になったプロジェクトについて、 すべてのスレッドの 議論を追いかけるなんて不可能です。 また、自分が注目しているスレッドについても、 その投稿の多くは別に返信を要求しているものではないでしょう。 開発系のフォーラム では特に、次のようなメッセージが多くなる傾向があります。 1. 見過ごせない問題についての意見 2. 誰かが言ったことに関する賛成意見あるいは反対意見 3. これまでの議論のまとめ これらのいずれについても、本質的には 返信は不要です。注意深くスレッドを観察して いれば、 あなたが言いたいことはきっと他のだれかが言ってくれるでしょう (みんなが 同じように考えていたら、結局だれも発言しなくなってしまうんじゃないの？ と思われ るかもしれませんが、そんなことはありません。 たいていの場合、何か言わずにはいら れない人が 誰かしら 存在するものです)。 明確な目的がある場合にのみ返信を行うよ うにしましょう。 まずは自分に問いかけることです。 「その返信で何を達成したいの か、きちんとわかっているのか？」 「その目的は、自分が返信しない限り達成できない ものなのか？」 あなたがスレッドに口出しをするのに適切な場面は次のふたつです。 a) 提案内容の不 備に気づいたが、おそらく他の誰もそれに気づいていないと思われるとき、 そして b) 誰かと誰かの間の意思疎通がうまくいっていないときに、 投稿内容を整理して二人の関 係を修復してあげられそうなとき。 あとは、誰かが何かをしてくれたことに対する感謝 のメッセージや ただ単に "私もそう思います！" というだけのメッセージなどを送信し てもよいでしょう。 というのも、そういった投稿をすればそのメールに対する返信が不 要であることがはっきりするからです。 そして、そのスレッドで最後にメールを投稿し た人に対して 「スレッドがきれいにまとまった」という安心感を与えることもできます 。 しかし、そんな投稿の際にも、投稿の前によく考えるようにしましょう。 「ちょっ と投稿しすぎじゃない？」と思われるより 「もうちょっと発言してほしいな」と思われ るほうがずっとマシです (活発なメーリングリスト上でどのように振舞えばいいのかに ついての意見は、 付録 C. なんで自転車置場の色まで気にしなきゃならないの？ の後 半をご覧ください)。 生産的なスレッドとそうでないスレッド 活発なメーリングリストで欠かせないのは、次の 2 点です。 まず明らかなのは、注目 すべきものとどうでもいいものを見分けること、 もうひとつは、できるだけノイズの 原因 となることを避けることです。自分自身の投稿の S/N 比を高く保つだけでなく、 他の参加者のメッセージの S/N 比も同様に高くしたい。 それができないならいっその こと投稿しないでほしい。 どうすればいいのかを考えるために、まずは状況を考えてみましょう。 この中で、生産 的でないスレッドといえるのはどれでしょうか？ ● すでに行われている議論をもう一度繰り返す。 まるで、最初に投稿した内容を 誰 も読んでいないのではないかと思われるような状態。 ● 話がどんどん誇張されていき、 その議論にかかわる人がどんどん減っていく状態。 ● 実際には何もしない人たちばかりが大騒ぎし、 実際に動くことになる人が黙り込ん だままの状態。 ● はっきりとした提案を出さないまま、 多くのアイデアが議論されている状態 (もち ろん、どんな興味深いアイデアだって 最初はぼんやりとした想像から始まるもので す。 ここで大事なのは、そこからどう膨らませるかです。 そのスレッドは、ぼん やりとした空想レベルのアイデアを 具体的にまとめあげる流れになっていますか？ それとも、別の想像や関係のない想像などの どうでもいいことに振り回されていま すか？) うまく機能していないスレッドがすべて無駄なものであるとは限りません。 中には重要 な話題が含まれているかもしれません。 そんな場合は、そのスレッドが盛り上がってい ないということ自体が問題です。 あまり押し付けがましくならないようにスレッドの流れをよい方向に持っていくのは、 ある種の芸術といえます。単に「無駄な話をするのはやめよう」とか 「もっと前向きな ことを投稿するようにしようよ」とか言うだけではうまくいきません。 もちろんこれら を個人的に行うことはできるでしょうが、 ちょっと強く言ってしまうと攻撃的になって しまいます。 そうではなく、前に進むためには次に何をすべきなのかを提案しなければ なりません。 あなたが望む結果が得られるような道筋を (無理やり指示しているような 流れになるのを避けつつ) 示してあげるのです。 提案のよしあしを区別するのは、主に 口調の問題となります。 たとえば、こんなやり方はよくありません。 これ以上議論しても、収束しないでしょう。 とりあえず、だれかがこの提案を実現 するパッチを書くまでこの話題はやめることにしませんか？ 同じ議論を何度も繰り 返すなんて無意味です。 ごちゃごちゃ言うより、結局はコードでしょ？ それよりは、こちらのほうがいいでしょう。 いくつかの提案はありましたが、結局どれもうまく膨らませることができず、 多数 決をとる段階まではいきませんでした。 また、今や新しい意見も出てこなくなって います。 単にこれまでの議論を繰り返しているだけです。 今私たちに必要なのは 、この提案に関する完全な仕様か あるいはパッチを含む投稿でしょうね。そうすれ ば、 少なくともなんらかのアクション (その仕様について合意をとったりパッチを テストしたり) ができるでしょう。 後者のアプローチを最初のものと比べてみましょう。 最初のほうは「私」と「その他の メンバー」の間に一線が引かれていましたが、 後のほうは違います。みんなをうまく議 論に巻き込んでいます。 あなたがそのスレッドの議論に最初からかかわっていたかどう かに関係なく、 主語を「私たち」とすることが重要です。これによって、 それまでス レッドをみているだけで何も発言しなかった人たちに対しても 「みんなにかかわる話な んだ」ということを確認させることができるからです。 スレッドが煮詰まってしまった 原因については説明していますが、 誰かをののしったり自分の意見を押し付けたりはし ていません。 淡々と事実を述べているだけです。 最も重要なのは、前向きに進めるた めに次に行うべきことを示している点です。 これにより、ただ単に議論を打ち切らせる (そんな制限をしても、だれも守ってくれないでしょう) のではなくより建設的な方向に 会話を持っていこうとしているのです。 そのスレッドをもっと膨らませたいといった状況ばかりであるとは限りません。 時には 、こんなスレッドはさっさと打ち切ってしまいたいと思うこともあるでしょう。 この場 合には、スレッドを終了させるための投稿をします。 もしそのスレッドが既にみんなに 忘れ去られてしまっているものなら、 あなたが投稿するだけでそのスレッドは事実上終 了するでしょう。 もちろん、スレッドを打ち切るための完璧な方法なんてありません。 もしそんなのがあったとしても、使いたいとは思わないでしょう。 しかし「何か目に見 える成果を出してください。 でなければこのフレッドを終了します」とお願いすると、 うまくいくことでしょう。 ただ、スレッドを終了させるのは十分に考えた後にしてくだ さい。 話題によっては、雑談の中から生産的な内容に発展することがあるかもしれませ ん。 あまりに拙速に打ち切ってしまうと、あなたはせっかちな人と思われてしまいます 。 どんなスレッドであっても、すぐに終了するとは期待しないでください。 あなたが投稿 した後にも、おそらくいくつかの投稿があるでしょう。 あなたのメールがまだ届いてい なかったり、あるいはいわゆる 「最後にひとこと」が言いたかったりといった人たちに よるものです。 心配することはないですし、先ほどの投稿を繰り返す必要もありません 。 スレッドが収束する (あるいはさらに膨らんでいく) のを黙って見守っていればいい のです。 完全にスレッドをコントロールすることなんてできません。 ただ、あなたは 多くのスレッドに何らかの効果を及ぼせるはずです。 簡単な議題ほど長引く どんな議題であっても議論は紆余曲折するものですが、 技術的な難度が低い話題になれ ばなるほど 議論が発散する可能性があがります。 結局のところ、技術的な難度が高い 話題になればなるほど その話題についていける人の数が少なくなるということです。 そんな話題についていける人というのは、たいていは長年経験を積んだ開発者です。 彼 らはこれまでに何度となくそのような議論に参加しており、 全員が納得のいく合意を得 るにはどうしたらいいのかを知っているのです。 というわけで、合意を得ることが最も難しいのは、 誰にでもわかる (誰でも意見が言え る) レベルの技術的な問題となります。 また同様に、組織論や広報活動、資金調達など の "やわらかめ" な話題も合意を得にくいものです。 これらの話題については、人はい つでも気の済むまで議論に参加することができます。 議論に参加するための前提条件も なければ 何が正しくて何が間違っているのかを (後になっても) 決めることもできない 、 そして、他人の意見を聞いてから「後出し」で議論に参加することもできるからです 。 議論の量と話題の複雑さが反比例するという原則はよく知られており、俗に Bikeshed Effect (自転車置場効果) と呼ばれています。 ここで、Poul-Henning Kamp による説明 を見てみましょう。 もともとは BSD 開発者向けに投稿されたものですが、今や超有名 になっています。 話せば長くなる昔話だけど、実際のところは単純な話だ。C・ノースコート・ パー キンソンが 1960 年代初期に書いた「パーキンソンの法則」という本があって、 そ こにはものごとの管理に関するさまざまな洞察が書かれていたんだ。 [...] 自転車置場の例にでてくるもう一方の役者が、原子炉だ。なんだか、 いかにも時代 を感じさせるなぁ。 パーキンソンは、委員会に乗り込んで数百万から数億ドルもの原子炉建設計画を承 認させる方法を説明している。 しかし、 原子炉ではなく自転車置場を作りたいと 思ったら終わりのない議論に巻き込まれることになるだろうとも言っている。 パーキンソンによると、原子炉はあまりに巨大で高価そして複雑であるために みん ながその内容を把握できなくなるということだ。考えようともせずに思考停止して しまい、 「まぁここまで来る前に誰か他の人が一部始終をチェックしただろう」 ということになってしまう。リチャート・P・ファインマンの著書には、 これに関 連するロス・アラモスでの興味深い事例がいくつか紹介されている。 さぁ一方自転車置場だ。週末をつぶせばだれでも作ることができ、 余った時間にテ レビで試合を見て楽しむことさえできるだろう。 どんなに用意周到であったとして も、どんなに妥当な提案だったとしても、だれかが機会をとらえては、 自分もなに かやっていることを示したり、自分もそれに注目してることを示したり、 「俺を忘 れるな」と言ったりするだろう。 デンマークでは、こういったことを「指紋をつける」って言うんだ。 個人的なプラ イドや見栄のために何かをして、あとからその証拠を見せられるようにする。 「ほ ら見ろよ。これ、俺がやったんだ」てな具合にね。 政治家どものよくやりそうなこ とでもあるが、一般人だって機会があればやりそうだよ。ほら、 よく生乾きのセメ ントに足跡がついてたりするだろう？ (彼の投稿の完全版はかなり長くなりますが、一読の価値はあります。 付録 C. なんで 自転車置場の色まで気にしなきゃならないの？ でご確認ください。また http:// bikeshed.com も参照ください) これまでにグループでの議論に参加したことがある人なら誰でも Kamp の言っているこ とがよくわかるでしょう。 しかし、自転車置場に色を塗るようなことを避けるよう 全 員 を説得するのは不可能です。 できることといえば、そんな状況を見つけたときに 「 こういう状態になっているんじゃない？」と指摘するくらいです。 そして、影響力の強 い開発者たちに対して 「早めに筆をおろしてくれませんか？」とお願いするのです。 そうすれば、少なくとも彼らはノイズの原因とはならなくなります。 自転車置場の塗装 大会を完全にやめさせることはできないでしょうが、 プロジェクトの文化をうまく育て ていけばそんな羽目になる頻度を下げる (そして発生したときも早く収束できるように する) ことができます。 宗教論争を回避する 宗教論争 (holy war: 聖戦) とはある種の論争のことです。 ただ、時には話し合いで解 決できないほど大きな問題になることもあります。 お互い、相手側を打ちのめすまで議 論を続けようとします。 これは、先ほどのいわゆる「自転車置場問題」とは多少異なる ものです。 自転車置場の議論に加わっている人たちは、先を競って自分の意見を表明し ます (だって簡単に意見を言えるから)。 でも、彼らは必ずしもそれを強く主張するわ けではありません。 時には相手の意見に理解を示すこともあります。 しかし「宗教論 争」においては、相手の意見に耳を傾けた時点で負けです。 みんな「正解はたったひと つである」という点では合意しているのですが、 ただ「正解がどれか」という点で争っ ているのです。 いったん宗教論争が始まってしまったら、 みんなが満足するようなかたちでそれを収束 させることは不可能です。 炎上している真っ只中で「これって宗教論争じゃない？」 と指摘したところで無意味です。 そんなこと、みんなとっくに知っているわけなんだか ら。 残念なことに、宗教論争の多くは 「この問題は話し合いを続ければ解決できるの か」 という点に対しても意見の対立が発生するものなのです。 第三者からみれば、ど ちら側も相手を説得できそうにないのは明らかです。 当事者たちは「相手側は何もわか っちゃいない。 うまく説得すればきっと私たちの考えをわかってくれるだろう」とお互 い考えています。 私は「こんな争いには正解なんてない」とは 言いません。 時には正 解があることもあるのです。 私も過去に何度か宗教論争に巻き込まれましたが、 その ときはいつも私たちのほうが正論でした。 とはいえ、そんなのはどうでもいいことです 。 どちらが正しいのかを納得いくように説明する方法なんてないのですから。 宗教論争を解決しようとしてやりがちなことは 「こんなことをいつまでも続けていても 時間のムダじゃないか！ もういい加減やめてしまわない？」 と言うことですが、これ では不十分です。 このやりかたには 2 つの問題があります。 まず、これまで議論に費 やしてきた時間や気力は取り戻せないということです。 いま大事なのは「あとどれだけ 議論しなければならないのか？」です。 もし「もうちょっと話をすれば解決できそうだ 」と感じている人が何人かいるのなら、 (少なくとも彼らの視点からは) 議論を続ける のは理にかなっています。 もうひとつの問題は、 そこで議論をやめてしまう (現状維持とする) ことが、 どちら か一方に事実上の勝利宣言をするのに等しいことがあるということです。 また時には「 とにかく現状をどうにかしなければならない」という点では合意しているが 「どのよう に変えるのか」で争っているということもあります。 こんな場合は、議論を打ち切って しまったら誰の得にもなりません。 そのことはみんなわかっているので、この場合は議 論を続けることも可能でしょう。 じゃあ、いったいどのように処理したらいいのでしょう？ まず言えることは、そんな議論が起こりえないようにするということです。 これは、皆 さんが思っているほど難しいことではありません。 宗教論争になりがちなネタは、だいたい予想がつきます。 プログラミング言語について だったりライセンスについてだったり (第9章 の 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 にあります。 "口やかましい少数派" について メーリングリストでの議論においては、 少数派の意見がいかにも大きな異議であるよう に見せることは簡単です。 長々としたメールをメーリングリストに大量に投稿すればい いのです。 これは議事進行妨害と似ていますが、 反対意見が大きくなっていると思い 込ませることにはより強力な意味があります。 というのも、あまりにたくさんの意見が 行きかうと 「誰がいつ何を言ったのか」を追いかけるのが面倒になってしまうからです 。 「よくわからないけど、何だか重要なことを議論しているんだな」 と本能的に感じ 、騒ぎがおさまるまでしばらくおとなしくしている人が多くなるのです。 このような効果をうち消す最もよい方法は、何らかの証拠をもって 「異議を申し立てて いる人がどれだけ少数であるかということ」 「他の大半の人たちが合意しているという こと」 を明確に指摘することです。より状況を明確にするために、 明確に意見は表明 していないがおそらく多数派に合意するであろうと思われる人たちに 個別に意見を聞い てみてもいいでしょう。 反対している人たちが自分の意見を故意に膨らませようとして いるといったことを 指摘するのはやめましょう。多分彼らはそんな気持ちはないでしょ う。 たとえ意図的にしているのだとしても、 それを指摘したところで戦略上なんの利 点もありません。 あなたがすべきことは、単に実数を比較して示すこと。 そうすれば 、他の人たちは自分の実感とずれていることをわかってくれるでしょう。 この手法は、賛成か反対かがはっきりするような議論に関しては適用できません。 この 方法がうまくいくのは、誰かが大騒ぎしているものの 大半の人にとってはそれが議論す べき問題なのかどうか判断できないといった場合です。 議論をしばらく見ていて、それ が (メールの数のわりには) あまり人々の気を引いていないものであって どうでもいい 議論であると判断したら、それをはっきりと示してあげましょう。 いわゆる "口うるさ い少数派" が目立っているときには、あなたの投稿が一服の清涼剤となるでしょう。 こ んな場合、たいていの人はちょっと落ち込んでいます。「なんてこった。 大量の投稿が あるので多分重要なことを話しているんだろうけど、 いったい何がどうなっているのか ちっともわかりゃしない」といった気分です。 実際の議論が必要以上に大げさになりす ぎていたことを説明すれば、 彼らはそれまでの流れを見直して 何が起こっていたのか を理解してくれるでしょう。 扱いにくい人たち 扱いにくい人たちに対して電子会議室上で対応するのは、 面と向かって対応することに 比べて多少難しくなります。 ここで言う "扱いにくい" とは "失礼な" という意味では ありません。 確かに失礼な人たちは不快なものですが、彼らが必ずしも扱いにくいとい うわけではありません。 本書では、すでに失礼な人たちへの対処法は説明済みです。 とりあえず一言指摘したあとは、そのまま無視してしまうか、 何事もなかったかのよう に他の人たちと同じよう接すればいいのです。 それでも彼らが失礼な振る舞いを続ける ようなら、 彼らはきっとそのプロジェクトの誰にも見向きもされなくなるでしょう。 自業自得です。 本当にやっかいなのは、あからさまに失礼な態度であるとはいえないが プロジェクトの 進み具合に悪影響を与えている人たちです。 彼らは他の人たちの時間や労力を余計に費 やさせるだけで プロジェクトに何の利益ももたらしません。 そういった人たちは、プ ロジェクトを進めるにあたって要となる箇所を探しては そこで自分の影響力を誇示しよ うとします。 このような行いは、単に失礼であるだけの人よりよっぽど油断なりません 。 なぜなら、その振る舞いだけでなくそれによる被害も明白だからです。 このような 行いの典型的な例は、いわゆる議事進行妨害です。 進行中の議題について、誰かが (い かにももっともらしく聞こえるように) 「まだ結論は見えていない。もっと別の解決策 も検討してみるべきだ。 違う視点から見直してみるのもいい」といった意見を述べるが 、 実際のところは既にほぼ合意がとれているかあるいは採決をとる準備ができていると いった状況です。 別の例を考えてみましょう。なかなか合意が得られない議論において 、 「まずはお互いの意見の不一致を確認してこれまでの議論のまとめを作成しよう」 という流れになることがあります。 そのまとめを作成した結果、自分が気に入らない方 向に進むかもしれないと考えている人は、 まとめの作成作業さえも邪魔しようとするか も知れません。 妥当な提案に対していちいち反対したり、 誰も喜ばないような新たな 話題を持ち出したりなどといった手段で粘着してくるわけです。 扱いにくい人たちへの対応 こんな振る舞いに対抗するには、 何が彼らをそうさせるのかを理解することが助けにな ります。 たいていの人は、意識してそのように振舞っているわけではありません。 毎 朝起きたときに「さあ、今日も斜に構えて議論をかき乱し、 みんなをいらいらさせてや ろう」と考える人なんていませんよね。 そんな行動に彼らを導くのは、たいていの場合 は 「自分はこのグループでの議論や意思決定の際に仲間はずれにされているのではない か」 という被害妄想です。彼らは自分がないがしろにされていると感じています。 あ るいは (もっと深刻な場合は) 自分だけをのけものにして 他のメンバーだけで何かをし ようとたくらんでいると感じることもあります。 そう感じている彼にとって、プロジェ クトの進行に口をはさんで 何とか 自分のほうに目を向けてもらえるようにすることは 完全に正当な振る舞いです。極端な場合は、彼は 「自分が戦わなきゃこのプロジェクト はダメになってしまう」と思い込んでいるかもしれません。 こういった攻撃は、その性質上みんなが一斉に気づくものではありません。 人によって は、明白な証拠があらわれるまでそれを認めないかもしれません。 つまり、このような 攻撃を何とか収めるのはそれなりの作業になるということです。 何かが起こっていると 自分が気づくだけでは不十分で、 他のメンバーを納得させるだけの証拠を用意する必要 があるのです。 その証拠を示す際には十分な注意が必要です。 戦うだけの余力がない場合、とりあえずはしばらく見過ごしておくのが得策です。 ちょ っとした感染性の病気と同じようにとらえらばいいのです。 プロジェクトが極端に衰弱 していない限り、 病気に感染してもなんとかなります。 下手に薬に頼ると、何らかの 副作用があるかもしれません。 しかし、無視できない程度の被害が出始めたら、それが 動き出すときです。 まず、目にしている状況をしっかり書き留めてください。 公開し ているアーカイブを参照するようにしましょう。 このような場合のためにも、プロジェ クトの活動をアーカイブしておくことが大切になります。 よい手がかりが見つかったら 、 次にプロジェクトの他のメンバーと個人的な話し合いをします。 このときに「こん な風に感じるんだけど……」と話すのではなく、まず 「最近何か感じることはない？」と いうように問いかけるようにします。 トラブルメーカーの行いについて他人がどう思っ ているのかについて聞けるのは、 これが最後のチャンスになるかもしれません。 あな たがいったんトラブルのことについて話し始めると どうしても相手の意見は変化してし まい、 もともとどう考えていたのかを思い出せなくなってしまうでしょう。 個人的な話し合いの結果、 同じような問題を感じている人が少なからずいるとわかった としましょう。 そろそろ何か行動をおこすときです。 このときは ほんとうに 用心深 くならなければなりません。 この手のトラブルメーカーは、しばしば「自分が不当にい じめられている」 と思い込んでしまいがちだからです。何をするにしても、 「プロジ ェクトの動きを故意に妨害している」「被害妄想に陥っている」 あるいはその他あなた が疑っていることが事実であると決め付けて責めたりしてはいけません。 あなたの最終 的な目標は、もっと妥当なもので かつプロジェクト全体の利益のためになるものでなけ ればなりません。 彼らの振る舞いを改めさせるか、あるいは追い出してしまうか。 最 終的にはどちらかになるでしょう。 あなたと他の開発者たちとの関係によっては、 事 前に個別に手を組んで共同で責めていくことも有効かもしれません。 ただ、それが裏目 に出ることもあります。 裏でこそこそと何かをして中傷しているようにとられたら、 あまりよく思われないかもしれません。 たとえまずい行動をしたのが手を組んだ相手のほうだったとしても、 言い出したのがあ なたである以上、周りから見ればまずい行動をしたのは あなた だということになりま す。 自分のいいたいことを示す例をできるだけ多く集めるようにしましょう。 そして 、できるだけやさしく紳士的に説得するようにするのです。 もしかしたら問題の当事者 を説得しきれないかもしれません。 しかし、その他大勢の人たちを説得できればそれで 十分です。 実例 私がフリーソフトウェアにかかわりだしてから 10 年以上たちますが、 私が覚えている 限り、これまでにこのようなことが起こったのは一度だけです。 そのときは、実際に投 稿をやめてもらうよう働きかけるはめになりました。 このような場合によくありがちな ことですが、 実際のところ彼はまったく悪気はなく、良かれと思ってやっていただけで した。 彼は単に、投稿すべきときと控えるべきときの区別ができなかったのです。 私 たちのメーリングリストは一般に公開されており、 彼は非常に頻繁にそこに投稿してい ました。 さまざまな内容について質問を繰り返すこともあり、 コミュニティーの間で 徐々に目障りに感じられるようになってきました。 質問を投稿する前に少しは自分で調 べるようにやさしくお願いしてはみたのですが、 彼には何の効果もありませんでした。 最終的に有効だったのは、完全に中立で定量的なデータを示すことでした。 開発者のひ とりがアーカイブを調べ、 以下のようなメッセージを何人かの開発者に個別に送ったの です。 問題の人 (以下の一覧における 3 番目の人。ここでは仮に "J. Random" としま す) がプロジェクトにかかわり始めてから日がまだ浅いこと、 そしてコードやドキュメ ントに一切貢献していないこと。 なのにメーリングリストの投稿ランキングでは 3 番 目になっていることがわかります。 From: "Brian W. Fitzpatrick" 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" 220 "J. Random" 176 Branko Čibej 130 Philip Martin 126 Ben Collins-Sussman この中の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. 全体としては巨大化の悪影響が出てきつつあるようだが、 特定の分野の話題につい てはまだその影響を受けていない というところを見つけたら、その分野の話題だけ に特化した会議室を新たに作成する (つまり、被害が及ばないうちに他の場所に避 難させる)。 2. 情報を自動的に取得できる場所を多く確保し、 それをきちんと系統立てて管理する 。 また、常に最新の情報を反映させ、人が見つけやすいようにする。 作戦 (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 をどのように使うのでしょう? 1. 適当な単語やフレーズを入力して検索できればいいですね。 2. 単に特定の質問に対する答えを探すというだけでなく、 全体をざっと眺めたいこと もあるでしょう。 3. Google のようなサーチエンジンでも FAQ の内容を見つけられるようにしてほしい と思うことでしょう。 4. FAQ の特定の項目を直接指し示せるようにもしたいものです。 5. FAQ に新たな内容を追加できるようにもしたいでしょう。 しかし、注意すべきなの は、FAQ への新たな内容の追加は FAQ の検索よりもはるかに頻度の低いものである ということです。 FAQ は、書き込むよりも読まれるほうが圧倒的に多いものです。 1. は、つまり FAQ が何らかのテキスト形式でなければならないということです。 2. と 3. が言わんとしていることは、FAQ が HTML ページとして存在しなければならない ということです。 2. はさらに、HTML が読みやすい形式であること (つまり、その見栄 えを変更できること) や目次を持っていることも要求しています。 4. を満たすには、 FAQ の各項目に HTML の 名前付きアンカー を指定しておく必要があります。 それによ って、ページ内の特定の場所に直接到達できるようになります。 5. が意味するところ は、FAQ のソースファイルの取得が容易であり (第3章 の すべてをバージョン管理する 項 をご覧ください)、 また編集しやすいものでなければならないということです。 名前付きアンカーと ID 属性 ウェブページ内の特定の場所に直接移動させるには、 名前付きアンカーを使う方法と id 属性を使う方法の二通りがあります。 名前付きアンカー は単なる HTML の アンカー要素 (...) と同じで、そこに "name" 属性を追加したものです。 ... 最近のバージョンの HTML では、より汎用的な id 属性 をサポートしており、 だけ でなく任意の HTML 要素で使用することができます。 たとえば次のように使用します。 ...

名前付きアンカーと id 属性の使用法は、どちらも同じです。 URL の最後にハッシュマ ーク (#) に続けてラベルを指定すると、 ブラウザはページ内のその場所に直接移動す るようになります。 http://myproject.example.com/faq.html#mylabel 名前付きアンカーは事実上すべてのブラウザがサポートしており、 最近のブラウザのほ とんどは id 属性にも対応しています。 万全を期すなら、名前付きアンカーだけを用い るか 名前付きアンカーと id 属性を 併用 する (もちろん、そのときは両者に同じラベ ルを指定する) ことをおすすめします。名前付きアンカーについては、 開始要素と終了 要素をひとつにまとめることはできません。 たとえ要素内のテキストが存在しない場合 でも、 以下のように開始要素と終了要素を別々に書かなければなりません。 ……とはいえ、普通はここには (セクションのタイトルなど) 何らかのテキストが入るも のです。 名前付きアンカーを使うにしても id 属性を使うにしても、 ラベルを指定してアクセス しない限りはブラウザ上でそのラベルは見えないことに注意しましょう。 しかし、たと えば FAQ の特定の回答をメールで示したい場合など、 その場所のラベルが何なのかを 知りたいこともあるでしょう。 このような場合のために、"name" や "id" 属性を指定 した場合は title 属性 も同じ要素に指定しておくとよいでしょう。 たとえば次のよう にします。 ... 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 からのパッチを採用した * 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 通りくらいになることもありま す。 そして各方面へのアナウンスはほぼ同時に行わなければなりません。 1. プロジェクトのトップページは、おそらく最も多くの人たちが目にする場所でしょ う。 重大なアナウンスに関しては、トップページにも掲載するようにしましょう。 ここに掲載するのは概要だけとし、詳細な情報を知りたい人のためには プレスリリ ース (以下で説明します) へのリンクを用意しておきます。 2. また、ウェブサイト上には「ニュース」や「プレスリリース」 と題した場所を設け 、アナウンスの詳細はそこに書くようにします。 プレスリリースの目的のひとつは 、 他のサイトからのリンクの際に使用する、正規の 「アナウンスオブジェクト」 を用意することにあります。 したがって、プレスリリースは適切な構造にしておく 必要があります。 プレスリリースごとに個別のウェブページを用意するにしても、 ひとつのblogの個別のエントリとするにしても、 あるいはその他の形式にするとし ても、 他のサイトからリンクする際に 別のプレスリリースと区別できるようにし ておかなければなりません。 3. そのプロジェクトが RSS フィードを提供しているのなら (RSS フィード項 をご覧 ください)、 そこにもアナウンスを含めなければなりません。 サイトの構築方法に よっては、 プレスリリースを作成したら自動的にフィードも更新されるようになっ ているかもしれません。 4. 新たなリリースが公開されたというアナウンスの場合は、 http://freshmeat.net/ 上のそのプロジェクトについてのエントリも更新しましょう (Freshmeat のエント リを作成する方法については 広報項 をご覧ください)。 Freshmeat のエントリを 更新すると、 Freshmeat の変更履歴を扱うメーリングリストにそのエントリの内容 が投稿されます。 このメーリングリストに投稿されるのは Freshmeat の更新情報 だけではありません。 それ以外にも、多数の人が注目しているポータルサイト ( http://slashdot.org など) の更新情報も投稿されます。 Freshmeat は、これらの データを RSS フィードでも提供しています。 つまり、あなたのプロジェクトの RSS フィードを購読していない人たちにも Freshmeat 経由で情報を伝えることがで きるのです。 5. あなたのプロジェクトのアナウンス用メーリングリストにメールを送信します。 ア ナウンス用メーリングリストの名前は "announce" とします。 つまり announce@yourprojectdomain.org のようになるというわけです。 これは事実上の 標準として使われている名前であり、 この名前のメーリングリストに流されるメー ルは 重要なアナウンスのみに限定しなければなりません。 流れるメールのほとん どは そのソフトウェアの新たなリリースに関するものとなるでしょうが、 それ以 外にも資金集めのお知らせやセキュリティ上の脆弱性の発見 (本章で後ほどとりあ げる セキュリティ脆弱性の告知項 をご覧ください) に関するメールも送信されま す。 あるいは、プロジェクトが大きく方向転換する際のお知らせなども投稿される でしょう。 announce メーリングリストの流量はあまり多くなく、 また重要な内容 のみに使用するものです。 そのプロジェクトの各種メーリングリストの中でも 購 読者の管理に最も力を入れる必要があります (あまり乱用するのではなく、熟考し てから投稿するようにしましょう)。 誰もが好き勝手にアナウンスを作成したり ス パムだらけになってしまうことを避けるため、 announce メーリングリストは 必ず モデレートしなければなりません。 これらの各所に出すアナウンスは、できるだけ同時になるようにしましょう。 メーリン グリストに流されたアナウンスが プロジェクトのホームページやプレスリリースに反映 されていなければ、 それを見た人は混乱してしまいます。 さまざまな変更 (メールの 送信、ウェブページの編集など) を事前に準備しておいて同時に実行すると、 情報の一 貫性が失われることが少なくなります。 それほど重要でもない出来事の場合は、 上であげた手法のうちいくつか (あるいはすべ て) を省略してもかまいません。 出来事の重要性に応じて、それでもプロジェクトの外 部には自然に伝わっていくでしょう。 たとえば「新しいリリースが公開されました」と いうのは重要な出来事ですが、 ただ単に「次のリリースの公開予定日が決まりました」 というのは、実際のリリースに比べてそれほど重要ではありません。 リリース予定日が 決まったという程度の情報なら (アナウンス専用ではなく) 通常のメーリングリストに 投稿し、 あとはウェブページ上のタイムラインを更新しておくくらいで十分でしょう。 しかし、あなたのプロジェクトに関心を持っている人たちは、 リリース予定日が決まっ たという話題をインターネット上の他の場所で持ち出すかもしれません。 メーリングリ ストに参加しているけれども ただ話を聞いているだけで自分は一切発言しないという人 たちが、 必ずしも他の場所でも同じように黙っているとは限りません。 口コミの影響 は侮れません。ちょっとしたアナウンスであっても、 それが正しい内容で周りに広まる よう心がける必要があります。 具体的に言うと、他の人に引用されることを想定した投 稿では、 どの部分を引用してもらいたいのかを明確にし、 その部分は公式のプレスリ リースと変わらないレベルで書くようにするということです。 たとえば次のようにしま す。 開発の最新状況をお知らせします。Scanley のバージョン 2.0 を、 2005 年 8 月 中旬にリリース予定です。詳細な情報は http://www.scanley.org/status.html で もご覧いただけます。 このバージョンで追加される主要な機能は、正規表現による 検索です。 その他の新機能は、 ... また、 次のようなバグの修正も含まれます ... 最初のパラグラフでは、ふたつの重要な情報 (リリース予定日と新機能) を簡潔に説明 し、 さらに詳細な情報を知るための URL を示しています。 この部分だけしか読まなか ったとしても、内容が伝わるようにしておきましょう。 メールの残りの部分は、他に伝 わる際には無視される可能性があります。 もちろん、中にはメール全体へリンクする人 もいるかもしれません。 しかし、ほとんどの人はメールの一部を引用するのみとなりま す。 そうである以上、一部を引用する人が引用しやすいようにすることを心がけましょ う。 うまく引用してもらえば、情報を広く伝えることができます。 セキュリティ脆弱性の告知 セキュリティ脆弱性の処理のしかたは、 他のバグ報告の場合とは異なります。 通常、 フリーソフトウェアの世界では、 物事をオープンにして誰にでも見えるようにすること が当たり前のことです。 一般的なバグ報告の対応状況は、興味のある人なら誰にでも見 えるようになっています。 いつバグが報告されたのか、どのような議論がなされたのか 、 そして最終的にどのように修正されたのか。 これらはすべて、知りたければ誰でも 知ることができるわけです。 セキュリティに関するバグの場合は、これとは異なります。 セキュリティに関するバグ が原因でユーザーのデータが漏洩してしまう可能性もありますし、 場合によってはコン ピュータを破壊してしまうことになるかもしれません。 このような問題をオープンな場 で議論してしまうと、 問題があることを全世界に知らしめてしまうことになります。 当然その中には、そのバグを悪用しようという人たちもいることでしょう。 単に淡々と バグを修正してコミットしただけでも、バグの存在を世にさらしてしまうことになりま す (攻撃者の中には、公開されているプロジェクトのコミットログをチェックしている 人もいます。 変更内容を調べれば、変更前のコードにセキュリティ上の問題があること がわかるでしょう)。 ほとんどのオープンソースプロジェクトでは、 この開放性と秘密 主義の対立に折り合いをつけるために 同じような方針をとっています。その方針は、以 下のようなものとなります。 1. 修正が完了するまではバグのことを口外しない。 そして、バグがあったことをアナ ウンスすると同時に修正プログラムを公開する。 2. 修正プログラムは、可能な限り迅速に提供する。 そのバグが外部からの報告で発覚 したものである場合は特に急ぐ必要があります。 というのも、プロジェクトの外部 の人間の中に少なくとも 1 人はその脆弱性を突く攻撃ができる人がいるということ がはっきりしているからです。 実際のところ、この規則は標準化した手順としてまとめることができます。 これらの手 順について、以下のセクションで解説します。 バグ報告を受ける 当然のことながら、各プロジェクトには セキュリティバグの報告を一般から受け付ける ための窓口が必要です。 しかし、これは通常のバグ報告を受け付けるアドレスと一緒に はできません。 というのも、通常のバグは誰にでも見えるようになっているからです。 そこで、セキュリティ関連のバグ報告を受け取るためのメーリングリストを別途用意し ます。 このメーリングリストのアーカイブは一般に公開してはいけません。 また、参 加資格は厳しく制限するべきです。そのプロジェクトに長くかかわっていて 信頼できる 開発者たちのみをメンバーに加えるようにしましょう。 もし "信頼できる" の具体的な 定義が必要な場合は、たとえば "コミット権を得てから 2 年以上経過している" などと いった条件を使用するといいでしょう。 そうすれば、参加資格に関して "えこひいきし ているのでは?" といった批判を避けることができます。 このメーリングリストに参加 しているメンバーが、 セキュリティバグに対応するメンバーとなります。 セキュリティ関連のメーリングリストについては、 スパム対策やモデレートは行わない のが理想です。 というのも、重要な報告がスパム扱いされてしまうと困りますし、 た またまその週末にすべてのモデレータがメールをチェックしなかったなどという理由で 重要な報告に気づくのが遅れるというのも困ります。 何らかのスパム対策ソフトウェア を使用するのなら、 可能な限り緩やか目の設定にしておきましょう。 重要な報告をフ ィルタリングしてしまうくらいなら、 多少のスパムが混ざってしまうほうがずっとまし です。 作成したメーリングリストをうまく活用するためには、 そのアドレスを周知さ せる必要があります。 しかし、このメーリングリストはモデレートされておらず、 ま たスパム対策も甘いものです。したがって、 そのアドレスを宣伝するときには、アドレ スを隠すために何らかの細工が必須となります。 詳細は 第3章 の アーカイブでのメー ルアドレスの処理項 で説明します。 幸いにも、アドレスを読みにくいものになどしな くてもアドレスを隠すことは可能です。 http://subversion.tigris.org/security.html をご覧になったうえで、 そのページの HTML ソースを確認してみてください。 大至急それを修正する セキュリティメーリングリストに報告が来たら、次は何をすればいいのでしょう? まず 最初にすべきことは、その問題の重大度 (severity) と緊急性 (urgency) を評価するこ とです。 1. その脆弱性はどれくらい深刻なものでしょう? 悪意のある攻撃者が、 そのソフトウ ェアを使用しているコンピュータを乗っ取ってしまえるほどのものですか? それと も、ただ単に何らかのファイルのサイズが漏洩してしまうというだけのものですか? 2. その脆弱性を突く攻撃の難易度はどの程度ですか? スクリプトを使って誰でも攻撃 できる程度のもの? あるいはその場の状況を熟知している人が 高度に頭を働かせて も、ごくまれにしか成功しないもの? 3. 誰が その問題を報告してきたのですか? この問いへの答えによって脆弱性そのもの の性質が変わるわけではありませんが、 他にどれくらいの人がその問題に気づいて いる可能性があるかを推測することができます。 もしそのプロジェクトの開発者自 身から報告されたのなら、ちょっとだけ (本当にちょっとだけ) 安心できます。 お そらく、その報告者は他人にその問題を漏らしていないでしょうから。 一方、もし 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 メーリングリストにメールを送ったりプレスリリースを作 成したり Freshmeat のエントリを更新したりといったことです。 そのプロジェクトの 評判を気にしてセキュリティバグの存在を甘く見るなんてことは論外ですが、 セキュリ ティに関するアナウンスの影響と実際の問題の重大度との兼ね合いには注意しましょう 。 そのセキュリティホールが単に些細な情報が漏洩するというだけのものであって コ ンピュータ全体がのっとられてしまうほどのものではないという場合は、 あまり大騒ぎ しないほうがいいこともあります。場合によっては announce メーリングリストへの投 稿も控えるということもありえます。 ささいなことで毎回大騒ぎしていると、ユーザー はどう思うでしょう? 実際にはそれほどではないのに「このソフトウェアはあまり安全 ではない」 と思われてしまうかもしれません。また、本当に深刻な問題が発生したとき にそれをアナウンスしても、 「またいつものやつだろう」と無視されてしまう可能性も あります。 重要度の判断方法については、 http://cve.mitre.org/about/ terminology.html にすばらしい入門文書があるので、ぜひご覧ください。 セキュリティ問題の対処方法がよくわからない場合は、 経験がありそうな人を探して相 談するようにしましょう。 脆弱性の評価やその処理の技術は、経験を積まないとなかな か得られないもので、 最初のうちは失敗することが多いものです。 ━━━━━━━━━━━━━━ ^[26] これらの問題については、いくつか興味深い研究があります。たとえば Gutwin、 Penner および Schneider による Group Awareness in Distributed Software Development もそのひとつです。この論文はオンラインで公開されていましたが、 一時 しばらく見えなくなっていました。その後、改めて http://www.st.cs.uni-sb.de/edu/ empirical-se/2006/PDFs/gutwin04.pdf で公開されました。もしこの URL で見つからな い場合は、 また別の場所に移動した可能性があります。サーチエンジンを使って探して みてください。 第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 を参照してください。 1. マイクロ番号だけに影響する（つまり、 同じマイナーライン上で行う）変更は、 前方互換性と後方互換性の両方がなければなりません。 つまり、変更はバグ修正の みか、 既にある機能に対するわずかな改善にとどめるべきです。 新機能は、マイ クロ番号を変更するリリースに取り込んではいけません。 2. マイナー番号に影響する（つまり、 同じメジャーラインで行う）変更には、 後方 互換性がなければなりませんが、前方互換性は必ずしも必要ありません。 マイナー 番号を変更するリリースでは、 新機能を取り込むのが普通ですが、 一度にたくさ ん取り込んだりはしません。 3. 互換性を維持するには限度があり、 メジャー番号に影響する変更がその境目となり ます。 新しいメジャーリリースには前方互換性も後方互換性もありません。 メジ ャーリリースには新機能が含まれているはずですが、 全ての機能が新しくなってい る場合さえあります。 後方互換性 と 前方互換性 の正確な意味は、 ソフトウェアが実現することに依存しま すが、解釈の余地がないのが普通です。 たとえば、あなたのプロジェクトがクライアン ト/サーバ アプリケーションを作っているとすると、 "後方互換性" とは、サーバを 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章 ボランティアの管理 目次 ボランティアを最大限に活用する 委任 作業依頼と担当者の決定を明確に区別する 委任したあとのフォロー みんなの好みを知る 賞賛と批判 縄張り意識の回避 自動化の割合 自動テスト すべてのユーザーの協力を得るために 技術的な作業だけでなく管理作業もみんなで パッチマネージャー 翻訳マネージャー ドキュメントマネージャー バグマネージャー 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 # 現在の保守担当者: The Scanley Project # そして 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 プロジェクトにおけるバグ報告の説明は、まさにこの形式のよい例といえま す (付録 D. バグ報告のやり方を説明した例 をご覧ください)。 最後のほうに、バグを 修正するためのパッチの提供を促している箇所があることに注目しましょう。 そうした からといって、バグ報告におけるパッチの添付率が上がるわけではありません (バグを 修正できるくらいのレベルの人なら、 いちいち言われなくてもパッチが有用であること を知っているはずですから)。 真の目的は、すべての読者 (特にそのプロジェクトに初 めて参加する人たち、 あるいはフリーソフトウェアの世界に初めて足を踏み入れる人た ち) に対して「このプロジェクトは多くのボランティアの貢献によって成り立っている 」 ということを示すことです。プロジェクトの開発メンバーだからといって、 バグ修 正に対する責任がバグの報告者より重いということはありません。 新入りさんにはあま りなじめない考え方でしょうが、これは重要です。 それをみんなに理解してもらえれば 、 バグ修正のための手助けをより多く得られるようになるでしょう。 コードが書けな い人であっても、バグの再現手順を詳細に説明したり だれかのバグ修正の内容を検証し たりといった支援は可能です。 最終的な目標は、みんなに「自分とプロジェクトのコア メンバーの間には 本質的な 違いはない」ということを理解してもらうことです。 失礼なユーザーに対しては、多少きつく対応しても許されるでしょう。 たまに、バグ報 告や苦情を書く際に 状況を考えずにプロジェクトをバカにした態度をとる人がいます。 このような人は、バカにしたかと思えば急にこびへつらってきたり、 態度をコロコロ変 えることがよくあります。かつて Subversion のメーリングリストにこんな投稿をした 人がいました。 6 日もたったのに、いまだに Windows 版のバイナリがないってどういうこと?!? 毎 回こんなことが続くんで、もういらいらしっぱなしだよ。 そんなの自動化しちゃえ ばいいだけのことでしょ?? "RC" 版を出したってことはそれをみんなに使ってほし いんでしょ? なのにこんな状態だと使うこともできないじゃないか。 試しようがな いのなら、テスト期間なんて無駄じゃない?? この煽り気味の投稿に対する返信は、どれも驚くほど落ち着いたものでした。 このプロ ジェクトではバイナリ版をリリースしない方針になっていることを指摘し、 そんなにバ イナリが大事なのなら自分でそれを作って提供するべきだと返信したのです。 驚くなか れ、彼の次の投稿はこんな一文から始まっていました。 まず最初に一言。Subversion は最高のツールだし、 プロジェクトのすべての参加 者には本当に感謝してるんだよ。[...] ...といった舌の根も乾かぬうちに、また バイナリを提供しないことに対するプロジェ クトへの批判を続けたのです。 彼は自分では何もしようとしませんでした。それに対し て、 50 人ほどが彼を批判する返信をしました。 私はそれを見ても、とくに気に病むこ とはありませんでした。 第2章 の 炎上を阻止する項 で説明した、 失礼な人に対する 「ゼロトレランス (情け容赦なく)」という考え方は、 そのプロジェクトに対して継続 的にかかわり続ける人たちに対するものです。 しかし、相手がただ単に不満をぶちまけ ているだけなんだということがわかってしまえば、 彼に対して気配りをしても無意味で す。 幸いなことに、こんな状況になることはほとんどありません。 初心者に対してもより建 設的な対応を心がけているプロジェクトでは、 まずこのようなことはありえないでしょ う。 技術的な作業だけでなく管理作業もみんなで プロジェクトを運営していくにあたっては、 技術的な作業だけでなく管理作業も大切で す。 プロジェクトが複雑になればなるほど、 メンバーや情報の流れの管理作業が多く なります。 管理作業だってみんなで協力してやるようにしましょう。 別にトップダウ ンの階層がなくたってそれは可能です。 実際のところ、行う作業というのは軍隊式の命 令系統ではなく ピアツーピアのネットワークトポロジーに近いものだからです。 「○○管理者」を正式に任命することもあれば、 その場のノリで決めてしまうこともあり ます。 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 " のような書き方はせず、 "バグ報告と再現手順を教えてくれた J. Random 、 ありがとう" と記すようにします。 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章 ライセンス、著作権、特許 目次 使用する用語 ライセンスの特徴 GPL とライセンスの互換性 ライセンスを選ぶ 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 とライセン スの互換性項 で議論しています。 クレジットの強制 フリーなライセンスの中には、 それが適用されたソースコードを使ういかなるコー ドにも、 注意書きを記すことを強制するものがあります。 注意書きの位置や内容 も決まっているのが普通です。 内容はコードの作者や著作権を持つ人へのクレジッ トです。 こうしたライセンスでも、 独占的なライセンスと互換性があるものがあ ります。 なぜなら、派生物がフリーであることを要求するのではなく、 フリーな コードに対してクレジットを与えることだけを要求しているからです。 商標の保護 クレジットを強制するやり方の変形として、 商標で保護されたライセンスは、 オ リジナルのソフトウェア (またはその著作権を持つ人や組織など) の名前を、事前 の書面での許可なく派生物で使っては いけない と定めています。 クレジットを強 制するやり方は、 ある名前をどこかで使うことを求めますし、 商標で保護するや り方は、使わないことを求めますが、 どちらも同じ要求を表しています。 つまり 、オリジナルのソースコードへの敬意を払い、 それを伝播させたいけれども、 ど こからもそうした敬意を傷つけられたくないのです。 「ソースコードの完全性」を保護する ライセンス (たとえば、プログラミング言語 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 を参照して ください) は以下の二つです。 1. すべての派生物 — つまり、GPL が適用されたコードを含んだあらゆるプログラム — は、それ自体も GPL で配布しなければならない。 2. オリジナルでも、派生物であっても、 それを再配布する場合には制限を追加しては いけない。 (原文の該当箇所を以下に引用します: 「あなたは、 このライセンスが 与えた、または認めた権利を行使することに関して、 これ以上他のいかなる制限も 課してはならない。」) これらの条件によって、GPL は自由を伝播させることに成功しています。 いったんプロ グラムが GPL で保護されると、 再配布の条件が 伝染する のです — つまり、取り込ん だコード以外のあらゆる部分にその条件を適用させ、 かつ GPL を採用したコードをク ローズドソースなプログラムで使うのを不可能にしているのです。 しかしながら、 こ れらの条項は他のフリーなライセンスと GPL を非互換にするものでもあります。 通常 は、他のライセンスが追加の条件を課したときに非互換が起きます — たとえば、何らか の方法でオリジナルの作者へのクレジットを要求する場合です — これは、GPL の 「あ なたは、これ以上他のいかなる制限も課してはならない ...」 という文言に反していま す。こうした二次的な結果は、望ましいものか、少なくとも悪いことではない、という のが FSF の見解です。 GPL は あなたのソフトウェアをフリーな状態に保つだけでなく 、 他の ソフトウェアにも自由を強制する媒体にもするのです。 この手法がフリーソフトウェアを広める優れた手段なのかどうかは、 インターネット上 でずっと続いている宗教論争 (第6章 の 宗教論争を回避する項 を参照してください) のひとつであり、 ここでは深く触れません。重要なのは、 GPL と互換性があるかどう かがライセンスを選ぶ際に重大な問題になるということです。GPL は非常に重要なオー プンソースライセンスです。 http://freshmeat.net/stats/#license では、 GPL が 68% を占めており、次に高いのは 6% です。 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) 以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うこと を無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提 供する相手に同じことを許可する権利も無制限に含まれます。 上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。 ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、およ び権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフト ウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとし ます。 (原文は 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) と呼ばれるライセンスをリリースしました ^[38]。 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 は電子メール で送ることができるのも優れています。 三つめは、プロジェクト (通常は非営利な法的 主体) が全ての著作権を保持するために、貢献する人から著作権を実際に譲ってもらう ことです。 これがもっとも法的には隙のない方法ですが、貢献する人にとってはもっと も厄介です。 よって、この方法を求めてくるプロジェクトはわずかです。 著作権を一ヶ所に集めたとしても、 コード^[39] はフリーのままであることに注意して ください。 なぜなら、オープンソースライセンスは、 著作権を持つ人にコードのコピ ーを過去に遡って独占的なコードにする権利を認めていないからです。 よって、たとえ 法的な主体としてのプロジェクトが突然方針を転換し、 すべてのコードを制限が強いラ イセンスで配布し始めたとしても、 そんなことはコミュニティーにとって決して問題に なりません。 他の開発者は単に最新のフリーなコードをコピーして新しいプロジェクト を始め、 何事もなかったかのように開発は続くでしょう。そうできることを知っている からこそ、 貢献する人達のほとんどは 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)は、全く逆の立場をとっています。 彼らは著作権を譲渡する正式な声明文が書かれた一枚の紙切れに直接サインし、 郵送す ることを求めてきます。 たった一度貢献しただけでも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という企業は、 オープンソースの世界に留まるか、 そうでないかは問題視してい ないようです。 特許 ソフトウェア特許は、フリーソフトウェアの世界で現在注目されている問題です。なぜ なら、 フリーソフトウェアのコミュニティーが防ぐことができない、 現実的な唯一の 脅威となっているからです。 著作権と商標の問題はいつでも回避することができます。 仮にあなたのコードが他の人のコードと似ていて、誰かの著作権を侵害していたとして も、 あなたはその部分を書き直せばよいのです。 また、誰かがあなたのプロジェクト の名前に対して商標権を持っていたとしても、 最悪プロジェクトの名前を変えれば済み ます。 プロジェクト名の変更は一時的には不便かもしれませんが、 長い目で見れば問 題にならないでしょう。なぜなら、コードそれ自体はいつも通り動くからです。 しかし、特許はあるアイディアを実装することに対して一律に適用されるものです。 誰 がコードを書くかは関係ありませんし、 どのプログラミング言語を使うかさえ関係ない のです。 誰かが特許を侵害していると主張してフリーソフトウェアプロジェクトを訴え た途端、 プロジェクトは特定の機能の実装をやめるか、カネと時間がかかる裁判をしな ければなりません。 このような裁判を起こすのは、十分な資力がある企業なのが普通で す — つまり、はじめから特許を買収する資金があり、そうする傾向がある組織です — ほとんどのフリーソフトウェアプロジェクトは特許を買い取る余裕はありませんし、 対 象となる特許が法廷で拘束力がないと強く思っていたとしても、 すぐに降伏しなければ ならないのです。 こういう状況をはじめから防ぐには、 フリーソフトウェアプロジェ クトがコードを用心深く書いて、 たとえ最良かつ唯一の解決策であったとしても、 特 許になっているアルゴリズムをあらかじめ使わないようにすることです ^[40]。 調査や事例が示す通り、これは大多数のオープンソースプログラマーだけでなく、 すべ ての プログラマーの多くが、 ソフトウェア特許を全面的に廃止すべきだと考えていま す ^[41]。 オープンソースプログラマーは、特に強くそう感じており、 ソフトウェア 特許を集めたり、 強制することに強く関係しすぎているプロジェクトで働くのを拒否す るかもしれません。 あなたの組織がソフトウェア特許を集めているのなら、 オープン ソースプロジェクトに特許を適用しないこと、 そして別の組織が特許違反の裁判を起こ した場合の、 防御の手段としてのみ特許を使っていることを取り消せないやり方で明確 にしておきましょう。 これが唯一の正しい手段ではありません。 オープンソースプロ ジェクト同士が連携することもよいことです。 ^[42] 不幸なことですが、法的な防御を目的として特許を集めるのは合理的な行動です。 現在 の特許の仕組みはその本質上、少なくともアメリカでは軍拡競争です。 つまり、競争相 手がたくさんの特許を取得した場合、 最良の防御方法は、特許違反で訴えられたときに 逆に訴え返せるように、 多くの特許を取得することです — こうしておけば、 お互いが お金を払わないで済むよう、 双方が机についてクロスライセンスの取引をするのが普通 です。 もちろん知的財産権専門の法律家には払わないといけませんが。 しかし、ソフトウェア特許がフリーソフトウェアに及ぼす害は、 コードの開発に及ぼす ものよりも陰湿なものです。 ソフトウェア特許はファームウェアの設計者達に秘密主義 の雰囲気を助長しています。 彼らは自分たちが設計したインターフェイスの詳細を公に すると、 特許違反で訴えるためにあら探しをしている競争相手を技術的に助けてしまう のではないかと心配しているのです。 これは単なる机上の空論ではありません。 たと えばビデオカード業界で明らかに起きてきたことなのです。 多くのビデオカードメーカ ーは、 高速に動くオープンソースなデバイスドライバを作るのに必要なプログラミング 仕様を公にしてきませんでした。 よって、そうしたカードの機能を完全にサポートする フリーなオペレーティングシステムを作るのが不可能になっているのです。 なぜメーカ ーはそんなことをするのでしょうか？ ソフトウェアをサポートすることに 反対するこ と は理にかなっていません。 なぜなら、多くのオペレーティングシステムで動くこと が、 ビデオカードの売り上げにつながるからです。しかし、 あるときは故意に、ある ときは偶然、 こうしたメーカーすべてがデザインルームの裏で互いに特許を侵害してい ることが明らかになってきています。よって、メーカーは敢えて完全なインターフェイ ス仕様を公開しないのです。 公開することで、特許を侵害していることが競争相手にわ かりやすくなってしまうからです。 (もちろん、こういった性質のことは一次情報源か ら許可を得て書けることではありません。 私はこのことを個人的なやりとりで知りまし た。) フリーソフトウェアライセンスの中には、ソフトウェア特許と戦ったり、 もしくは拒絶 するための特別な文言を入れているものがあります。 たとえば、GNU GPL は次のような 文言を含めています。 7. 特許侵害あるいはその他の理由(特許関係に限らない)から、裁判所の判決あるいは 申し立ての結果としてあなたに(裁判所命令や契約などにより)このライセンスの条 件と矛盾する制約が課された場合でも、あなたがこの契約書の条件を免除されるわ けではない。もしこの契約書の下であなたに課せられた責任と他の関連する責任を 同時に満たすような形で頒布できないならば、結果としてあなたは『プログラム』 を頒布することが全くできないということである。例えば特許ライセンスが、あな たから直接間接を問わずコピーを受け取った人が誰でも『プログラム』を使用料無 料で再頒布することを認めていない場合、あなたがその制約とこの契約書を両方と も満たすには『プログラム』の頒布を完全に中止するしかないだろう。 [...] 特許やその他の財産権を侵害したり、そのような権利の主張の効力に異議を唱えた りするようあなたを誘惑することがこの節の目的ではない。この節には、人々によ ってライセンス慣行として実現されてきた、フリーソフトウェア頒布のシステムの 完全性を護るという目的しかない。多くの人々が、フリーソフトウェアの頒布シス テムが首尾一貫して適用されているという信頼に基づき、このシステムを通じて頒 布される多様なソフトウェアに寛大な貢献をしてきたのは事実であるが、人がどの ようなシステムを通じてソフトウェアを頒布したいと思うかはあくまでも作者/寄与 者次第であり、あなたが選択を押しつけることはできない。 ^[43] Apache License バージョン 2.0 (http://www.apache.org/licenses/LICENSE-2.0) も特 許に反対する条件を含めています。 まず第一に、このライセンスでコードを配布する人 は、 自分が保有している特許で、配布するコードに適用できるものについては、 ロイ ヤリティーがかからない特許ライセンスを与えなければなりません。 二つめに、 配布 したコードを根拠に特許侵害の訴えを起こした時点でその特許ライセンスを自動的に終 了させることで、 そうした人を巧みに排除しています。 3. 特許ライセンスの付与 本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物 を作成したり、使用したり、販売したり、販売用に提供したり、インポートし たり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料 無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与 します。ただし、このようなライセンスは、コントリビューターによってライ センス可能な特許申請のうち、当該コントリビューターのコントリビューショ ンを単独または該当する成果物と組み合わせて用いることで必然的に侵害され るものにのみ適用されます。あなたが誰かに対し、交差請求や反訴を含めて、 成果物あるいは成果物に組み込まれたコントリビューションが直接または間接 的な特許侵害に当たるとして特許訴訟を起こした場合、本ライセンスに基づい てあなたに付与された特許ライセンスは、そうした訴訟が正式に起こされた時 点で終了するものとします。 ^[44] このように、フリーソフトウェアライセンスに特許から防御するための仕掛けをしてお くのは、 法的にも政治的にも役に立つものです。しかし最終的には、 フリーソフトウ ェアに対する特許違反裁判の脅威がもたらす、 萎縮的効果を払拭するには不十分です。 それができる唯一の手段は、国際的な特許法の本質や解釈を変更することです。 この問 題について、そしてこの問題と人々がどう戦ってきたのかをさらに知るには、 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] このライセンスと名前の歴史はちょっと複雑です。 このライセンスのはじめのバ ージョンは Affero, Inc. によってリリースされ、 GPL バージョン2 (GPLv2) を基にし たものでした。これは通常 AGPL と呼ばれていました。 のちに FSF はこのライセンス の考え方を採用することを決めましたが、 それより前に GPL のバージョン3 (GPLv3) をリリースしていたのです。 よって、FSF は AGPL に基づいて自分たちのライセンスを 作り、それを "GNU AGPL" と呼んだのです。現在、Affero, Inc. が作った古いライセン スは事実上推奨されていません。 もしあなたが Affero のような条件を望むなら、GNU AGPL を使うべきです。 曖昧にならないように、このライセンスを "AGPLv3" とか、 "GNU AGPL"、 もしくは最大限正確を期すために "GNU AGPLv3" と呼びます。 ^[39] ここから私は、「コード」という言葉を「プログラムとドキュメント両方」 とい う意味で使います。 ^[40] サン・マイクロシステムズ と IBM は、 この問題に対して少なくとも別の方向性 を打ち出しています。 彼らは大量のソフトウェア特許 — それぞれ 1600 と 500 個 — をオープンソースコミュニティーが使えるようにフリーにしました。 私は法律家ではな いので、 これらの特許が付与されたことがどれくらい有用なのかを評価できません。 しかしたとえこれらがすべて重要な特許であり、 特許を付与する条件をオープンソース プロジェクトが使うために本当にフリーなものにしたとしても、 それは氷山の一角に過 ぎないでしょう。 ^[41] 調査の一例として、以下を参照してください。 http://groups.csail.mit.edu/ mac/projects/lpf/Whatsnew/survey.html ^[42] たとえば RedHat は、 オープンソースプロジェクトは特許に違反しないことを約 束しています。 http://www.redhat.com/legal/patent_policy.html を参照してくださ い。 ^[43] GNU General Public License バージョン 2 のもの。 http://www.opensource.jp /gpl/gpl.ja.html.euc-jp より引用。 ^[44] オープンソースグループ・ジャパン wiki より引用。 http://sourceforge.jp/ projects/opensource/wiki/licenses%2FApache_License_2.0 付録 A. フリーなバージョン管理システム 2007 年半ばの時点で私が把握しているオープンソースのバージョン管理システムは、 これらがすべてです。このうち、私が常用しているのは Subversion のみです。 Subverion と CVS 以外の大半のシステムについては、 使用経験がないに等しいものば かりです。 ここにあげた情報は、それぞれのシステムのウェブサイトを参考にしたもの です。 http://en.wikipedia.org/wiki/List_of_revision_control_software もご覧く ださい。 CVS — http://www.nongnu.org/cvs/ CVS は長い歴史を持っており、多くの開発者にとっておなじみのものです。 公開された 当時は革命的な存在でした。 オープンソースのバージョン管理システムとしては初めて (少なくとも私の知る限り) 離れた場所にいる開発者達によるネットワーク経由のアクセ スに対応し、 また初めて匿名での読み込み専用チェックアウトに対応しました。 これ により、新しい開発者が容易にプロジェクトに参加できるようになったのです。 CVS が バージョン管理するのはファイルのみであり、 ディレクトリのバージョンは管理しませ ん。 ブランチやタグの機能を持っており、 クライアント側でも高速に動作しますが、 巨大なファイルやバイナリファイルはうまく扱うことができません。 また、アトミック なコミットにも対応していません。 [注: 私はかつて、約 5 年にわたって精力的に CVS の開発に携わってきました。 その後、CVS にかわるシステムとしての Subversion プロ ジェクトの立ち上げにかかわりました。] Subversion — http://subversion.tigris.org/ Subversion が書かれた最大の目的は、CVS にとってかわるシステムを作ることです。 CVS とほぼ同じような方法でバージョン管理を行いますが、 CVS ユーザーがしばしば悩 まされていた問題点や機能不備などを解消するようにしています。 Subversion の目標 のひとつは、CVS になじみのある人たちが 比較的スムーズに Subversion に移行できる ようにすることです。 Subverion の機能についてここで事細かに語ることは控えます。 詳細はウェブサイトをご覧ください。 [注: 私は Subversion の開発に参加しています 。 また、この一覧の中で私が常用しているシステムは Subversion だけです。] SVK — http://svk.elixus.org/ Subversion 上で構築されているシステムではあるものの、SVK はおそらく Subversion よりも以下にあげる分散管理型のシステムに似ています。 SVK は、分散型の開発やロー カルでのコミットをサポートしています。 また変更点のマージ機能も洗練されており、 SVK 以外のバージョン管理システムのツリーを複製する機能もあります。 詳細はウェブ サイトをご覧ください。 Mercurial — http://www.selenic.com/mercurial/ Mercurial は分散型のバージョン管理システムで、 "ファイルやチェンジセットの完全 なクロスインデクシング、 ネットワーク帯域や CPU に優しい同期プロトコル (HTTP お よび SSH)、 任意の開発ブランチ間でのマージ、単体で動作するウェブインターフェイ スの同梱、 UNIX でも MacOS X でも Windows でも同じように動作する" といった機能 を持っています (この機能一覧は、Mercurial のウェブサイトの内容をまとめたもので す)。 GIT — http://git.or.cz/ GIT は、Linus Torvalds が Linux カーネルのソースツリーを管理するためにはじめた プロジェクトです。 最初のうちはカーネルの開発で必要となる機能に特化したものでし たが、 今では機能も増え、Linux カーネル以外のプロジェクトでも用いられるようにな っています。 ホームページでの説明によると、GIT は 「……巨大なプロジェクトを高速 かつ効率的に管理するように設計されており、 主に各種オープンソースプロジェクトで 使用されています。 中でも有名なのは Linux カーネルです。 Git は分散型ソースコー ド管理ツールの一種で、GNU Arch や Monotone (あるいは独占的ソフトウェア界での BitKeeper) と似ています。 Git のすべての作業ディレクトリは、 それ単体で完全なリ ビジョン追跡機能を持つリポジトリであり、 ネットワークアクセスや中央サーバがなく ても機能します」。 Bazaar — http://bazaar-vcs.org/ Bazaar (bzr) は 使いやすさと柔軟なデータモデルを追及した分散型のバージョン管理 システムです。 これは GNU の公式プロジェクトであり、フリーソフトウェアプロジェ クトをホスティングしている Launchpad.net で採用されています。Bazaar は完全に分 散したバージョン管理を実現します。つまり、 すべての仕事をブランチでこなします。 開発者は通常ブランチの変更履歴のコピーを持ちます。 それぞれのブランチは、分散型 のやり方で互いをマージできますが、Bazaar は中央管理型のやり方も使えるように設定 できます。 Bazaar は GNU Arch の派生プロジェクトとして出発しましたが、 のちに1 から書き直され、GNU Arch とは直接の関連がなくなっています。 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 の開発が始まった当初から最も重視してきたものです」 付録 B. フリーなバグ追跡システム プロジェクトでどのバグ追跡システムを採用していても、 文句を言う開発者は必ずいま す。 この傾向は他の標準的な開発ツールよりも強いようです。 私は、バグ追跡システ ムが使う人の目に見えることと、 ユーザーと開発者がやりとりを双方向に行うツールで あることから、 (時間があれば)改善したいと思う点が想像しやすいこと、 そしてそれ を口に出して説明しやすいのが理由だと思っています。 こうした不平不満は話半分に聞 いておきましょう — 以下に示すバグ追跡システムの多くはとても優れたソフトウェアで す。 以下の一覧では、バグ追跡システムが追跡するものとして「問題」という用語を使いま す。 しかし、それぞれのシステムは、 これに対応するものとして「欠陥」や「バグ」 などの独自の用語を使うこともあることに注意してください。 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 と統合されています。 (付録 A. フリーなバージョン管理シス テム も参照してください) 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件のバグが登録されています^[45]。 やりとりは普通の電子メールクライアントで行います。つまり、 ほとんどの人に馴染み があり、簡単に使える環境で行うということです。 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 を管理する仕組みもあります。 ━━━━━━━━━━━━━━ ^[45] この数は原著出版当時(2005年)のものと思われる。2009年3月現在では、登録され ているバグの数は51万件を超えている 付録 C. なんで自転車置場の色まで気にしなきゃならないの？ 別にそんな必要はありません。 だって、そんなのどうでもいいことじゃないですか。 それに、もっとマシな時間の使い方もあるでしょ？ 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 です。 Subject: A bike shed (any colour will do) on greener grass... From: Poul-Henning Kamp 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 付録 D. バグ報告のやり方を説明した例 以下に示すのは、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://svn.collab.net/repos/svn/trunk/www/hacking.html#patches で見てください。 これら全ての情報を dev@subversion.tigris.org に投稿しましょう。もしあなたが既にそうしているか、バ グ追跡システムに登録するように頼まれたのなら、バグ追跡システムのページに行き、そこの指示に従ってく ださい。 ここまで読んでくれてありがとう。優れたバグ報告を行うには、たくさんの努力が必要なのはわかっています。 しかし、優れた報告は開発者の時間を多く節約でき、バグが修正される確率を一層高めるものなのです。 付録 E. 訳者あとがき 高岡 芳成 [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月のこと。あるオープンソースコミュニティのメーリングリスト が荒れているのを見かねた人が「みんなこれを読むといいよ」と紹介していらしたのが きっかけでした ^[46]。彼が紹介していた部分を読んで深く感銘を受けた私は、さっそ くその日本語訳の作成に取り組むことを決めたのです。その頃には、まさか2年後に日本 語版が出版されることになるとは思ってもいませんでした。 オープンソースソフトウェアのコミュニティを運営していくには、よいソフトウェアを 書くこと以外にもさまざまなことを考えなければなりません。メーリングリスト上での 争いのしずめかたなどもそのひとつです。これまで口伝で受け継がれていくことが多か ったこれらの事柄を１冊の書籍としてまとめあげた本書は、オープンソースソフトウェ アにかかわるすべての方にとって有用なものとなることでしょう。 日本語訳を進めていく上で、多くの方にお世話になりました。原著者のKarlFogelさんは 、すばらしい内容の文章をオープンソースで提供してくださっただけでなく、私たちの 翻訳作業を力強くフォローしてくださりました。彼からいただいたアドバイスや励まし のおかげで、翻訳作業をスムーズに進めることができました。翻訳作業の中盤以降は、 共同翻訳者の高岡さんのパワーに助けられっぱなしでした。彼がいなければ、この翻訳 が完成することもなかったでしょう。原著と同様、日本語版の原稿もまたオープンソー スで公開されています ^[47]。そのおかげで、多くの方から翻訳へのフィードバックを いただきました。IRCやメールなどで何度となく細かい指摘をしてくださった方もいらっ しゃいましたし、スラッシュドットジャパンにパッチを投稿してくださった方もいらっ しゃいました。ここで全員のお名前をあげることはできませんが、みなさんの指摘はと ても役立ちました。 そして最後に。全文がウェブ上で公開されている本書の書籍化を決断してくださったオ ライリー・ジャパン、出版にあたって数多くの手助けをいただいた編集の毛利さんのお かげで、みなさんのお手元に本書をお届けできるようになりました。私が原著から影響 を受けたのと同様、みなさんが本書から何かを得ていただくことがあれば幸いです。 ━━━━━━━━━━━━━━ ^[46] http://blog.thepimp.net/archives/ Good-reading-for-Mailing-list-members.html ^[47] http://producingoss.com/ja/index.html 付録 F. 著作権表示 この本の内容は、クリエイティブコモンズ Attribution-ShareAlike (表示-継承) ライセンス によってライセンスされています。 このライセンスのコピーを見るには、http://creativecommons.org/licenses/by-sa/2.1/ を 見るか、以下の住所に郵便を送ってください^[48]。 Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. 以下でははじめにこのライセンスの要約を示し、完全な条文がその後に続きます。あなた がこの本の全部または一部を別の条件で再配布したい場合は、作者に連絡をとってください。 Karl Fogel -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- あなたは以下の条件に従う場合に限り、自由に: * 本作品を複製、頒布、展示、実演することができます。 * 二次的著作物を作成することができます。 あなたの従うべき条件は以下の通りです。: * 表示. あなたは原著作者のクレジットを表示しなければなりません。 * 継承. もしあなたがこの作品を改変、変形または加工した場合、あなた はその結果生じた作品をこの作品と同一の許諾条件の下でのみ頒布する ことができます。 * 再利用や頒布にあたっては、この作品の使用許諾条件を他の人々に明ら かにしなければなりません。 * 著作[権]者から許可を得ると、これらの条件は適用されません。 * この許諾条件は、原著作者の著作者人格権を損ねたり、制限するもので はありません。 -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- 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/から連絡すること ができます。 ━━━━━━━━━━━━━━ ^[48] 元々本書は クリエイティブコモンズ Attribution ShareAlike 3.0 に基づいてラ イセンスされていたが、2009年2月17日現在 日本で最新とされていた 2.1 でも OK との 許可を著者から頂いた。よって、ここでは バージョン 2.1 の日本語版を掲載している 。http://creativecommons.org/licenses/by-sa/2.1/jp/ も参照すること。