パーティの場で「フリーソフトウェアを書いているんです」と言っても、 以前のように怪しげな目を向けられることはなくなりました。 「あぁ、オープンソースね。Linuxみたいなものでしょ？」とみんなすぐにわかってくれます。 「そうそう！　そうなんだ」。もはや完全な辺境でなくなったのは嬉しいことです。 次にくる質問は、ちょっと前までは「それで、どうやってお金を稼いでいるの？」に決まっていました。 答えとして、私はオープンソースの経済学について手短に述べたでしょう。 すなわち、あるソフトウェアが存在することで利益を得る組織があるのですが、 その組織はそのソフトウェアを販売する必要はなく、 ただそのソフトウェアが利用可能であり保守されているということを確かめたいのです、商品ではなく道具として。 しかし、最近は「オープンソースでどうやって儲けるの？」的な質問は少なくなってきました。 いまやオープンソースソフトウェア ここでは「オープンソース」と「フリー」をほぼ同じ意味で使用しています。 詳細は、 の で説明します。 でお金を稼ぐことは不思議でも何でもなくなったのです。オープンソースを仕事にしている人たちがいるということを、 開発者以外でも多くの人が理解しています—あるいは少なくとも驚かないようになってきています。 最近は、こんな質問に変わってきました。「オープンソースって、いったいどういう仕組みになっているんですか？」 当時の私は、その質問にうまく答えることができませんでした。考えれば考えるほど、 その話題が複雑なものであるように思えてきたのです。 フリーソフトウェアのプロジェクトを運営するというのは普通の商売とはちょっと違います （たとえば、会ったこともないボランティアのグループを相手にして自社の製品についての交渉を毎日のように行うなんてことは普通はありませんよね？）。 また、ごく一般的な非営利組織を運営したり政府を運営したりというのとも少々異なります。 　 まぁそれぞれ似ている点もあるのですが、徐々にわかってきたのは、 フリーソフトウェアは独特 （sui generis） だということです。 比較対象となるものはいくらでもありますが、その中のどれとも違うのです。 実際のところ、フリーソフトウェアプロジェクトを「運営することができる」という仮定さえも確かではありません。 フリーソフトウェアプロジェクトを「始める」ことはできます。 また、さまざまな人たちがそのプロジェクトに影響を与えることができます。中には強烈に影響を及ぼす人もいるでしょう。 しかし、そのプロジェクト自体は特定の個人の所有物とすることはできません。 そのプロジェクトに興味を持つ人がどこかにひとりでもいる限り、一方的にそのプロジェクトを終了することもできません。 誰もが限りない力を持っています。と同時に、誰もが無力だという一面もあります。興味深い話です。 といったわけで、私は本書を執筆することになったのです。 フリーソフトウェアプロジェクトは独特の文化を発展させてきました。 ソフトウェアに思い通りの仕事をさせる自由が主要な信条となる気風です。それでなおその自由の結果、 個々人がばらばらにコードとともに我が道を行くのではなく、熱狂的な共同作業が行われているのです。 実際、協調性というのはフリーソフトウェア界で最も評価されるスキルのひとつです。 プロジェクトを運営していくということは、ある種の肥大化した共同作業に従事するということです。 そこでは他人と作業をする能力だけではなく、共同作業を進めるための新たな手法を創り出す能力により、 ソフトウェアに具体的な利益をもたらすことができるのです。 本書では、このようにプロジェクトをうまく進めていくための秘訣を説明します。 決して完璧なものではありませんが、初めの一歩としては十分だと思います。 よいフリーソフトウェアを作ることは、本質的に価値のある目標です。 その方法を模索している読者のみなさんが、本書で何かのヒントを得てくだされば幸いです。 またそれだけでなく、実際にオープンソース開発者たちのチームに参加して、 一緒に作業を進めていただけるようになることも望んでいます。 志の高いメンバーとともに作業を進め、ユーザーと直接対話するのは非常に楽しいことです。 うまく動いているフリーソフトウェアプロジェクトでの作業はほんとうに 「楽しい」 ものです。 そして結局のところ、その楽しさがあるからこそプロジェクトがうまく進むのです。 本書が対象としている読者は、これからオープンソースプロジェクトを始めようと思っている、 あるいは始めてはみたもののどうすればいいのかわからないというソフトウェア開発者や管理者たちです。 「オープンソースのプロジェクトに参加したいんだけれど、どうしたらいいんだろう？」 という人たちにとっても役立つことでしょう。 プログラミングに関する知識は必須ではありません。ただ、ソースコードやコンパイラ、 パッチといったソフトウェア工学の概念の基本は知っておく必要があります。 オープンソースソフトウェアを開発したり使用したりといった経験の有無は問いません。 過去にフリーソフトウェアプロジェクトに参加した経験がある人にとっては、 本書の内容の中に「そんなの当たり前じゃん」と思われる箇所がいくつも見つかることでしょう。 そのように読者の経験に大きな差があるので、 各セクションのタイトルはできるだけわかりやすいものにすることを心がけています。 また、既によく知っている場合に読み飛ばしてもかまわない箇所についてはそれを明記しています。 本書で取り上げているネタの大半は、 5年にわたる Subversionプロジェクト（）での経験です。 Subversion はオープンソースのバージョン管理システムで、何もないところから作り上げたものです。 オープンソースコミュニティーにおけるバージョン管理システムの デファクトスタンダードの座を、CVSから奪い取ることを目標としています。 もともとこのプロジェクトは、私の雇用主であるCollabNet （）が2000年の初めに開始したものでした 日本語版注：Karl Fogel氏のウェブサイト（）などによると、 2009年7月現在は CollabNet ではなく、Ubuntuプロジェクトのコマーシャルスポンサーでもある Canonical社 （）で、ソフトウェアプロジェクトのホスティングサービス Launchpad （）などに関係しているようです。本書の本文では、 氏とCollabNetの雇用関係に基づいた記述がいくつかありますが、すべて執筆時点のものとしてお読みください。 。 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）のオンライン版を底本にして日本語訳が行われました。 原文は で公開されています。