オープンソースソフトウェアの育て方 フリーソフトウェアプロジェクトを成功させるコツ 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 に 渡すための法的手続きをしてもらうことになっています。 見知らぬ誰かさんからも らったコードをそのまま取り込むことは、 破滅への第一歩だからです。 そこで私は、彼にメールで書類を送りました。 「ちょっとした事務手続きが必要な んだ。内容はここに説明してあるので、 まず君がここに署名してほしい。そしても うひとつの書類に君の雇用主の署名をもらってほしい。 そうしたら君のバグフィッ クスを取り込めるだろう。いつもありがとう。感謝してるよ。」 こんな内容でした 。 彼から返ってきた返事は「私には雇用主はいません」というものでした。 で、私は言いました。 「ああ、そうかい。それなら、代わりに君の通う大学に署名 をもらって送り返してくれないかな？