TITLE : Cathdral & Bazar: Japanese 伽藍とバザール (The Cathedral and the Bazar) ------------------------------------------------------------------------------- Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳 1998/08/11版、1998/10/17訳 原文の最新版はhttp://www.tuxedo.org/~esr/writings/cathedral-bazaar/にて各種フォーマットで入手可能。 翻訳の pdf 版は http://www.post1.com/~hiyori13/freeware/cathedral.pdf にある。 翻訳の PostScript 版 (tar&gzip圧縮）は http://www.post1.com/~hiyori13/freeware/cathedral.tgz にある。 続編 「ノウアスフィアの開墾」 (Homesteading the Noosphere) も是非参照されたし。 原文はhttp://www.tuxedo.org/~esr/writings/homesteading/にて各種フォーマットで、 翻訳は http://www.post1.com/~hiyori13/freeware/noosphere.html にて入手可能。 パロディ版 The Circus Midget and the Dinosour Turd （翻訳『サーカス小人と恐竜うんち化石』も一興かと。 　 概要 　この論文ではまず、大成功したフリーソフト/オープンソース プロジェクト fetchmail を分析する。このソフトは、 Linux の歴史から導かれる、ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。本論ではその理論を、二種類の根本的にちがった開発スタイルという形で論じている。一つは FSF やそのまねっ子たちの「伽藍」モデルで、それに対するのが Linux 界の「バザール」モデルだ。この2つのモデルが、ソフトのデバッグ作業の性質に関する、正反対の前提からそれぞれ生じていることを示す。続いて Linux 体験に基づき、「目玉の数さえ十分あれば、どんなバグも深刻ではない」という仮説を支持する議論を展開し、利己的エージェントによる自己修正システムとの有益な対比をしてみる。そしてこの洞察がソフトウェアの未来に対して持つ意味について、いくつか考察を行って結論としている。 ------------------------------------------------------------------------------- 目次 1 伽藍方式とバザール方式<#1> 2 なにはともあれメールは通せ<#2> 3. ユーザは大事な財産<#3> 4 はやめのリリース、しょっちゅうリリース<#4> 5 バラがバラでないのは？<#5> 6 Popclient から Fetchmail へ<#6> 7 Fetchmail の成長<#7> 8 続・Fetchmail の教訓<#8> 9 バザール方式の前提条件とは<#9> 10 フリーソフトの社会的な意義<#10> 謝辞<#11> もっと考えたい人のための文献リスト<#12> エピローグ：Netscapeもバザール方式を受け入れる<#epilogue> バージョンと変更履歴<#version> ------------------------------------------------------------------------------- 　 1 伽藍方式とバザール方式 　Linux は破壊的存在なり。インターネットのかぼそい糸だけで結ばれた、地球全体に散らばった数千人の開発者たちが片手間にハッキングするだけで、超一流の OS が魔法みたいに編み出されてしまうなんて、ほんの 5 年前でさえだれも想像すらできなかったんだから。 　ぼくもできなかった。Linux がぼくのレーダー画面に泳ぎ着いたのは 1993 年の頭だったけれど、その頃ぼくはすでに Unix やフリーソフト開発に10年以上も関わってきていた。1980 年代半ば、ぼくは最初期の GNU 協力者の一人だったし、ネット上にかなりのフリーソフトもリリースして、いまでも広く使われているようなプログラムをいくつか（nethack、Emacs VC モードと GUD モード、xlife など）単独または共同で開発してきた。だから、もうやり方はわかってるもんだと思いこんでいた。 　Linux は、ぼくがわかっているつもりでいたものを、大幅にひっくりかえしてくれた。それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといったUnix の福音は説き続けてはいた。でももっと上のレベルでは何かどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。一番だいじなソフト（OS や、Emacs みたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメで、一人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげるべきもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。 　だから リーヌス・トーヴァルズの開発スタイル――はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――にはまったく驚かされた。静かで荘厳な伽藍づくりなんかない―― Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった（これをまさに象徴しているのが Linux のアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう）。そしてそこから一貫した安定なシステムが出てくる なんて、奇跡がいくつも続かなければ不可能に思えた。 　このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。この世界の様子を学ぶにあたって、ぼくは個別のプロジェクトだけでなく、なぜ Linux 界が混乱のうちに崩壊しないのか、それどころかなぜ、伽藍建設者たちの想像を絶するスピードで、続々と強みを発揮し続けられるのかを理解しようとしてきた。 　1996 年半ばには、答がわかりかけてきたような気がした。そしてその頃まったくの偶然から、自分の理論を試してみる完璧な機会がやってきた。意識的にバザール方式で運営できるようなフリーソフトプロジェクトという形で。そこでバザール方式を試してみた――大成功。 　というわけでこれから、そのプロジェクトの話をしようではないの。そしてそれを使って、上手なフリーソフト開発についていくつかアフォリズムを提案してみよう。全部が全部、Linux の世界で学んだことばかりではないけれど、そういうものでも Linux 界がすごくいい例になってることがわかるはず。ぼくが正しければ、なぜ Linux コミュニティがこんなにいいソフトを続々と生み出せるのか、みんなにもずばりわかるはず――そしてみんなももっと生産的になれるはずなんだ。 ------------------------------------------------------------------------------- 2 なにはともあれメールは通せ 　1993年以来、ぼくはペンシルバニア州ウェストチェスターにある、Chester County InterLink (CCIL) という小さなフリーアクセス ISP の技術面を担当してた (ぼくは CCIL の共同創設者で、ぼくたちが使ってるユニークなマルチユーザ BBS ソフトを書いた。興味があれば、locke.ccil.orgに telnet してみてほしい。いまでは 19 回線で 3,000 人弱のユーザをサポートしてる) 。この仕事のおかげで、CCIL の 56K 回線を通じて 1 日 24 時間ネットにアクセスし続けられるようになった――というより、仕事柄そうせざるをえなかったというのが実状かな！ 　そういうわけで、インターネットの電子メールがすぐに手放せなく なった。なんかややこしい理由で自宅のマシン (snark.thyrsus.com)と CCIL とで SLIP 接続するのに手間取って、それがうまくいくと、今度はしょっちゅうlockeに telnet してメールをチェックするのがえらく面倒になってきた。メールを snarkに配信してもらって、新しいメールがきたら biff(1) が報せてくれるようにしたかったわけ。 　Sendmail の転送機能は使えない。snark はネットにつないでないときもあって、IP アドレスも固定されてないからね。SLIP 接続経由で手をのばして、メールをローカルマシンに引っ張ってきてくれるようなソフトがほしかったわけだ。そういうソフトがあるのは知ってたし、そのほとんどが POP (Post Office Protocol) っていう簡単なアプリケーション・プロトコルを使ってるのも知ってた。そして、確かに locke の BSD/OS には、ちゃんと POP3 サーバソフトが含まれているではないの。 　あとは POP3 のクライアントがあればいい。そこでネットで探してみると、3つか4つ見つかった。しばらくは pop-perl を使ってたけれど、これには当然あるべき（と思われる）機能が欠けていた。とってきたメールのアドレスをいじくって、返信がうまくいくようにするのができなかったんだ。 　つまりこういうことだ。locke 上の「joe」という人が、ぼくにメールを出したとする。このメールを snark にとってきて、それに返信したら、メールソフトは snark 上の「joe」にそれを送って悦に入っちゃうわけ。そんな人物はいないのに。返信アドレスを手でなおして、@ccil.orgを最後にくっつけてたんだけれど、これはすぐにえらい手間になってきた。 　こんなのどう見ても、コンピュータがやるべきことだよね (実は RFC1123 のセクション 5.2.18 によれば、これは sendmail が処理しなきゃいけないんだけど）。でも、既存の POP クライアントはどれ一つとしてこいつがこなせなかった！　というわけで、教訓その1: * 1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。 　これは自明のことかもしれない（昔から「必要は発明の母」って言うし）。でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし好きでもないようなソフトを一日中シコシコ書いてることがあまりに多いんだ。でも、Linux の世界ではちがう―― Linux 界出身ソフトの質が、平均してすごく高いのはこのせいかもしれないね。 　そこでぼくは、既存のものとタメを張るようなまっさらの POP3 クライアントを書き上げるべく、即座にコード書きの渦中へ猛然ととびこんだ――かな？　ご冗談を！　ぼくはまず、手元にある POP ユーティリティをじっくりながめてこう考えた。「ぼくの欲しいものにいちばん近いのはどれかな？」　というのも： * 2. 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。 　――だからね。すごいプログラマを気取るつもりはないけど、でもそのまねくらいはしたい。すごいプログラマの大事な特徴の一つが、建設的な面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、そのための努力じゃないってのがわかってるってこと。そして白紙から始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。 　たとえば リーヌスは、Linux をゼロから書き始めたわけじゃない。386 マシン用の、小さな UNIX っぽい OS だった Minix のコードやアイデアを再利用するところから始めてる。やがて Minix のコードは全部落とされたか、あるいは完全に書き直された――でも最初のうちは、やがて Linux となるべき赤ん坊のための簡単な囲いを提供してくれてたんだ。 　同じ精神から、ぼくは既存の POP ユーティリティを探しに出た。そこそこ上手にコーディングされてて、開発のベースに使えるようなヤツを。 　Unix 界では、ソース共有の伝統のおかげでコードの再利用が昔からとってもやりやすかった（このせいで GNU プロジェクトは、Unix という OSそのものついては、かなり不満を持ってたんだけれど、ベース OS には Unix を選んだ）。Linux 界は、この伝統を技術的な極限にまでつきつめてる。だれにでも使えるオープンなソースコードが、何テラバイトもある。だからだれかほかの人の、ほとんど使いものになりそうなコードを探すのは、Linux の世界ではほかのどこよりもすごくいい結果をうみやすい。 　ぼくの場合もそうだった。もう一度探しに出た結果、最初に見つけたのとあわせて候補が9個あがってきた―― fetchpop、PopTart、get-mail、 gwpop、pimp、pop-perl、popc、popmail、upop。最初に落ち着いた先は Seung-Hong Oh の fetchpop だった。ぼくは自前のヘッダ変更機能をそれに加えて、その他いろいろ改良を入れた。作者はそれを受け入れて、1.9 リリースに含めてくれた。 　でも数週間たって、Carl Harris の popclient のコードに出くわして、困ったなと思った。fetchpop はなかなかいい独創的なアイデア（たとえば daemon モードとか）が入ってたんだけれど、POP3 しか扱えないし、コードもいささか素人くさかった（Seung-Hongはプログラマとして才能はあるけれどまだ駆け出しで、その両方の特徴が fetchpop には出ていた）。Carl のコードのほうが優れていて、プロ級のしっかりしたものだったけれど、大事なのに実装が面倒な fetchpop の機能がいくつか欠けていた（ぼくがコーディングした機能も含め）。 　このままいくか、乗り換えるか？　乗り換えたら、開発ベースはよくなるけれど、かわりにこれまでのコーディングは全部捨てることになる。 　実際問題として、乗り換える理由の一つに複数のプロトコルが扱える点があった。POP3 は post-office サーバプロトコルで一番普及はしているけれど、唯一無二ってわけじゃない。Fetchpop をはじめとする競合ソフトは POP2 も RPOP も APOP も扱えなかったし、ぼくのほうでは IMAP (Internet Message Access Protocol、一番最近に設計された、最強の post-office プロトコル) のサポートを入れたらいいかもしれないな、なんてことをすでにおもしろ半分で考え始めていた。 　でも、乗り換えたほうがいいかもしれない理論的な根拠もあった。これはぼくが、Linux よりずっと前に学んだことでもある。こういうことだ： * 3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章） 　あるいは言い換えると、1 回とりあえず解決策を実装してみるまでは、問題を完全には理解しきれないってこと。2 回目くらいになってやっと、正しい解決法がわかるくらいの理解が得られるかもしれない。だからちゃんとした問題解決をしたいなら、少なくとも 1 回くらいはやりなおす覚悟はしておくこと。 　ま、（と独り言）fetchpop の改良が 1 回目だったわけだ。というわけで、ぼくは乗り換えた。 　最初の popclient 用パッチを 1996 年 6 月 25 日に Carl Harris に送ったんだけれど、実はかれはしばらくまえに、popclient に興味をなくしていることがわかった。コードもほこりをかぶってる状態で、ちょっとしたバグも残ったままだったし。こっちとしては、いろいろ変えたいところもあった。だから、ぼくがこのプログラムを任されるのがいちばん理にかなってるということで、両者はすぐに合意した。 　自分でも気がつかないうちに、プロジェクトは拡大したわけだ。もはやぼくは、既存の POP クライアントにちょっとパッチをあてるような話をしてるわけじゃない。プログラムをまるごとメンテする作業を引き受けてたんだ。そして頭の中ではいろいろアイデアも湧いてきていて、これをやったら大幅な変更が必要になるな、というのもはっきりしてた。 　コード共有を奨励するソフト文化にあって、これはプロジェクト発展の自然な道筋ではある。ぼくは次の原理を実践していたことになる： * 4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。 　でも Carl Harris の行動のほうがもっと大事だ。かれが理解していたこと： * 5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。 　なにも相談なんかしなくても、カールもぼくも、自分たちがこの世で最高の問題解決方法を実現するという共通の目標を持っていることがわかっていた。二人にとって唯一の問題は、ぼくがこれを安心して任せられる人物だってことを証明できるかということだけだった。それを実証してみせたら、かれはすぐさま優雅なふるまいを見せて、ソフトをゆだねてくれた。ぼくの順番がきたときにも、Carl と同じくらいの鷹揚さを示したいなと思う。 ------------------------------------------------------------------------------- 3. ユーザは大事な財産 　というわけで、ぼくは popclient をひきついだ。そして同じくらい大事なことだけれど、ぼくは popclient のユーザベースもひきついだわけだ。ユーザを持つのはすばらしいことで、それは単に、自分が何かニーズに対応してるんだな、なにか役に立つことをしたんだな、ということを実証してくれるからというだけじゃない。きちんと育てれば、ユーザは共同開発者になってくれるんだ。 　これまた Unix の伝統の強みで、これまた Linux がみごとに極限までおしすすめる強みでもあるんだけれど、ユーザの中にもハッカーがたくさんいるわけだ。そしてソースコードが公開されてるから、かれらは同じハッカーでも役に立つハッカーになってくれる。これはデバッグ時間短縮にはすごく役に立つ。ちょっと励ますだけで、ユーザが問題を診断し、直し方を提案してくれて、一人でやるよりずっとはやくコードを改善できるようにしてくれる。 * 6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。 　この効果の力はすごく見落としがち。はっきり言って、ぼくらフリーソフト界のほとんどだれもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そしてそれがシステムの複雑さに対してどれほど有効に機能するかについて、まったく見えてなかった。リーヌスが目を開いてくれるまでは。 　はっきり言って、ぼくは リーヌスのいちばん賢い、影響力あるハッキングというのは、Linux のカーネル構築そのものではないと思う。むしろ Linux 開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。あるいはロバート・ハインラインなら「失敗するには怠惰すぎる」とでも言っただろうね。 　ふりかえってみると、Linux の手法や成功の前例は GNU Emacs の Lisp ライブラリと Lisp コードアーカイブの開発にみることができる。Emacs の C のコア部分やその他 FSF ツールみたいな、伽藍建築方式にくらべると、Lisp コードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで 3 回も 4 回も書き直されるのがしょっちゅうだった。そして Linux と同じく、インターネットが可能にしたゆるい協力体制もしばしばとられていた。 　確かに、ぼく自身でも fetchmail 以前でいちばんうまくいったハッキングは、Emacs の VC モードだと思う。これは Linux みたいに、電子メールで 3 人と共同作業して開発した。今日にいたるまで、その中で実際に顔をあわせたことがあるのは一人（Richard Stallman）だけだ。これは SCCS、RCS、そして後には CVS となったもののフロントエンドで、ワンタッチのバージョンコントロール機能を Emacs の中から使えるようにするものだった。もとにしたのは、だれかが書いた、いい加減でちっちゃな sccs.el モード。そしてVCの開発が成功したのは、Emacs 本体とはちがって、Emacs Lisp のコードはリリース/テスト/改良のサイクルをすごくはやく回せるからだった。 ------------------------------------------------------------------------------- 4 はやめのリリース、しょっちゅうリリース 　はやめにしょっちゅうリリースするのは、Linux 開発モデルの重要な部分だ。ほとんどの開発者（含ぼく）は、プロジェクトがちょっとでも大きくなったらこいつはまずいやり方だと考えていた。初期バージョンはその定義からいってバグだらけだし、ユーザの我慢にも限度があるだろうから。 　この信念のおかげで、伽藍建設式の開発への関与も深まった。もし最優先課題が、できるだけ少ないバグしかユーザにお目にかけないということだったら、うん、それならリリースは半年に一度とかにして（あるいはもっと間をおいて）、リリースの間は犬みたいにひたすらバグ取りに専念するだろう。Emacs の C の核部分はこういう形で開発された。Lisp ライブラリは、事実上ちがっていた。FSF のコントロールのきかない活発なLispアーカイブがあって、そこにいけば Emacs のリリースサイクルとはまったく関係ない、新しい開発コードが手に入ったから。 　こういうアーカイブのいちばん重要なものの一つは、オハイオ州立大の elisp アーカイブでここは今日の大きな Linux アーカイブの精神や特徴の多くを先取りしたところだった。でも、自分たちがなにをしているのかしっかり考えてみた者はほとんどいなかったし、このアーカイブの存在自体が、FSF 式の伽藍建設型開発モデルの問題点についてなにを示唆しているのかについてもあまり考えなかった。1992 年頃、ぼくはオハイオのコードの相当部分を正式に公式 Emacs Lisp ライブラリに組み込もうとして、かなりまじめに取り組んだ。でも政治的な問題にぶちあたって、ほとんどうまくいかなかった。 　でもそれから一年たたないうちに、Linux がかなり目に見えて広まってくると、なにかちがった、ずっと健全なことが起こっているのははっきりしてきた。リーヌスのオープンな開発方針は、伽藍建設の正反対のものだった。Sunsite や tsx-11 のアーカイブははちきれそうで、パッケージもどんどん登場してきた。そしてそのすべてが、前代未聞の頻度でリリースされるコアシステムに動かされていた。 　リーヌスはいちばん効果的なやりかたで、ユーザたちを共同開発者として扱っていたことになる： * 7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと 　リーヌスの革新は、これをやったということじゃない（似たようなことは、もうながいこと Unix の世界の伝統になっていた）。それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。開発初期のあの頃だと、リーヌスが新しいカーネルを一日に何回もリリースすることだって、そんなに珍しくはなかった。そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく共同作業をする点で、ほかのだれよりも上をいっていた。それでうまくいったわけだ。 　でも、具体的にどういうふうにうまくいってるんだろう。そしてそれはぼくでもまねできるものなんだろうか、それとも リーヌスだけにしかない独特な才能に依存したものなんだろうか？ 　そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ（完全な製品レベルの OS カーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね？）。でも、Linux はとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。 リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリングのような、設計面での革新的天才ではないんだ（少なくともいまのところは）。むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、A 地点から B 地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。Linux の設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。 　じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。 　こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。 　リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザ基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。リーヌスの行動を見ていると、次のような信念を持っていたんじゃないかと思える： * 8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。 　あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。 　はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。リーヌスはこれに異議を唱えて、問題を理解してそれをなおす人物は、必ずしもどころかふつうは、その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。そしてそれを理解するのはだれか別の人だよ。そしてぼくは、問題を見つけることのほうがむずかしいと述べたことは記録しておいてね」。でも肝心なのは、見つけるのもなおすのも、だいたいすごく短期間で起きるってことだ。 　ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、潜伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。 　一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを一つ残らず、千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。よって、たくさんなおしてもらうためにリリースも増やすし、有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。 　そして、これがすべてだ。これだけで必要十分。もしリーヌスの法則がまちがってるなら、Linux カーネルほど複雑なシステム、Linux カーネルくらいみんながよってたかってハッキングしてるようなシステムは、どこかの時点でまずい相互作用や、発見できない「深い」バグのせいで崩壊してたはずなんだ。一方、もしリーヌスの法則が正しければ、これで Linux が相対的にバグが少ないことを十分説明できる。 　そしてこれは、そんなに驚くべきことでもなかったのかもしれない。社会学者たちは何年も前に、同じくらいの専門家（あるいは同じくらい無知な人たち）の意見の平均は、そういう観察者の一人をランダムに選んで意見をきくよりも、予測精度がかなり高いことを発見している。これをかれらは「デルファイ効果」と呼んだ。どうやらリーヌスが示したのは、これが OS のデバッグにも適用できるってことみたいだ。つまりデルファイ効果は、OS カーネル級の複雑なものでも、開発上の複雑さをおさめることができるんだ。 　Jeff Dutky は、リーヌスの法則は「デバッグは並列処理可能だ」と言い換えることもできると指摘してくれた。感謝したい。Jeff の知見では、デバッグするにはデバッガは開発コーディネータと多少のやりとりは必要だけれど、デバッガ同士では大した調整は必要ない。だから、開発者を加えることで発生する、幾何級数的な複雑性と管理コスト増大という問題には直面しないですむというわけだ。 　実際問題として、デバッガたちの作業重複によって生じる理論的な無駄は、Linux の世界ではほとんど問題にされないようだ。「はやめしょっちゅうのリリース」の効果の一つとして、すでにフィードバック済みのバグフィックスをすばやく広めることでそういう重複をなくせるということがある。 　ブルックスは、すでに Jeff の見解に関連したような観察をなにげなく述べてる。「広範に使われるプログラムをメンテナンスするコストは、おおむねその開発コストの 40％だ。驚いたことに、このコストはユーザ数に大きく左右される。ユーザが増えると見つかるバグも増えるのだ」（強調筆者）。 　ユーザが増えると見つかるバグも増えるのは、ユーザを追加することで、プログラムをもっといろんな方法で叩いてみることができるからだ。この効果は、そのユーザたちが共同開発者でもある場合にはさらに増幅される。各人が、ちょっとずつちがったものの見方と分析用ツールキットをもって、その任に当たる。「デルファイ効果」はまさにこの多様性のためにうまく機能するらしい。デバッグという分野に限った話をすると、この多様性のおかげで試みが重複する機会も減るらしい。 　だからベータテスタの数を増やしても、開発者側の立場からすれば目下の「一番深い」バグの複雑さが減るわけではないけれど、でもだれかのツールキットがその問題にうまくマッチして、その人にとってはそのバグが深刻ではないという可能性を増してくれるわけだ。 　リーヌスも、そこらへんは抜け目なくやってる。万が一本当に深刻なバグがあったときのために、Linux カーネルのバージョンのナンバリングには工夫がある。ユーザ候補は、「安定」とされたカーネル最新版を使うか、最先端にいって、新しい機能を使うかわりにバグの危険をおかすか、という選択ができるようになってる。この戦術は、ほかの Linux ハッカーたちはまだ正式に採用していないけれど、でも採用されるべきかもしれない。選択肢があるというのは、魅力を増すから。 ------------------------------------------------------------------------------- 5 バラがバラでないのは？ 　リーヌスの行動を研究して、それが成功している理由について理論ができたので、この理論を自分の（確かにずっと単純で小規模な）プロジェクトで試してみようとぼくは意識的に決めた。 　でも、まずやったのは popclient を再構成してすごく単純化することだった。Carl Harris の実装はすごくしっかりしていたけれど、C のプログラマにありがちな、無用な複雑さが見られた。かれはコードを中心に考えていて、データ構造はコードのサポートとして扱っていた。結果として、コードは美しかったけれど、データ構造のデザインはいきあたりばったりで、いささか醜かった（少なくともこの老いぼれ LISP ハッカーの高い基準で見れば）。 　でも、書き直しをやったのは、コードやデータ構造の設計を改善する以外にも目的があった。それは、このソフトを進歩させて、自分が完全に理解してるものにすることだった。自分でもわかってないプログラムのバグをなおす責任をしょいこむなんて、おもしろくもないからね。 　そして最初の1ヶ月かそこらは、単に Carl の基本的な設計の考え方を追いかけてただけだった。ぼくが加えた最初の大きな変更は、IMAP のサポートを加えることだった。これは、プロトコルマシンを、汎用ドライバとメソッドテーブル 3 つ（POP2、POP3、IMAP 用）に再構成することで実現した。これと、その前の変更は、プログラマとして頭にいれておくといい一般原則を示すものだ。特に、ダイナミックなタイプ処理をしない C みたいな言語では： * 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。 　またもやフレッド・ブルックス本の第 11 章から。「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。データ構造さえみせてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから」 　ほんとはかれが言ったのは「フローチャート」に「テーブル」だった。でも30年にわたる用語面・文化面での推移を考慮すれば、ほとんど同じことを言ってる。 　この時点（1996 年 9 月頭、ゼロ時点から約 6 週間後）で、ぼくはそろそろ名前の変え時かな、と考え出した。なんといっても、もう POP クライアントだけじゃなくなってたんだし。でも、ためらった。いまのところ、まだこのソフトにはまったく新しい部分が何もなかったからだ。ぼく版の popclient は、まだ独自のアイデンティティを確立するにいたってなかった。 　これが派手に変わったのは、fetchmail がとってきたメールを SMTP ポートに転送する方法を身につけたときだった。この話はまたあとで。それよりまず：上で、このプロジェクトを使って、リーヌス・トーヴァルズがうまくやった点についての自分の理論を試すことにした、と書いた。試すって、どういうふうに？（という疑問は当然起こるだろう）。それは以下の通り： * はやめしょっちゅうのリリースを心がけた（間が 10 日以上開いたことはほとんどない。集中して開発しているときは、1 日 1 回）。 　 * だれかが fetchmail の件で連絡してきたら、その人をベータリストに加えてリストを増やした。 　 * リリースごとに騒々しいアナウンスをベータリストに送りつけて、みんなに参加をうながした。 　 * そしてベータテスタたちの言うことをきいて、設計上の判断について意見を求め、パッチやフィードバックを送ってくれたら必ずほめた。 　こういう単純な方法の見返りはすぐにやってきた。プロジェクトの始めから、ぼくは他の開発者なら死んでもいいと思うような質の高いバグレポートをもらったし、しかもそれになかなかいいフィックスまでついてきた。よく考えられたコメントももらったし、ファンレターもきたし、賢い機能の提案ももらった。これでわかるのが： * 10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。 　Fetchmail の成功をはかるおもしろい指標としては、このプロジェクトのベータリスト―― fetchmail 友の会――のサイズを見るといい。執筆時点では 249 人で、毎週2、3人追加されている。 　実は、1997 年 5 月に改訂している時点だと、このリストは人数が減りはじめてる。その理由がおもしろい。何人かがリストから外してくれといってきたんだけれど、それは fetchmail がかれらにはまったく文句なしに機能しているので、メーリングリストのトラフィックを見る必要がないと言うんだ。成熟したバザール形式のライフサイクルでは、これが自然なのかも知れない。 ------------------------------------------------------------------------------- 6 Popclient から Fetchmail へ 　このプロジェクトの真のターニングポイントは、Harry Hochheiser がクライアント機の SMTP ポートにメールを転送するための書きかけのコードを送ってきてくれたときだった。ぼくはほとんど即座に、この機能を信頼できる形で実装できたら、ほかの配信モードはほとんど時代遅れ同然になるなと気がついた。 　何週間にもわたって、ぼくは fetchmail にいろいろ追加する形でいじってきていた。でもその間、インターフェースのデザインが使えなくはないけれど、ちょっと野暮ったいなと感じだしていた――エレガントじゃないし、貧弱なオプションがそこらじゅうにぶらさがってるし。とってきたメールをメールボックスファイルや標準出力にダンプするオプションがことさら気に入らなかったけれど、その理由が自分でもわからなかった。 　SMTP 転送について考えてみたときに気がついたのは、popclient はいろいろやろうとしすぎてるということだった。これはメール配送エージェント（MTA）とローカル配信エージェント（MDA）の両方をこなすよう設計されていた。SMTP 転送があれば、MDA の仕事からは足を洗って、メールのローカル配信はほかのソフトにまかせればいい。ちょうど sendmail がやってるように。 　メール配信エージェントのややこしい設定なんか、しなくたっていいじゃないか。メールボックスをロックして追加なんて、しなくていいじゃないか。ポート 25 は、TCP/IP サポートのあるプラットホームなら、まずまちがいなくそこにあるんだから。特にこうすれば、とってきたメールは確実に、ふつうの送り手から送られてきた SMTP メールのように見えるはずなんだ。それがもともとぼくたちの求めているものだろう。 　ここにはいくつか教訓がある。まず、この SMTP 転送のアイデアは、ぼくがリーヌスのやりかたを意識的に真似ようとした最大の見返りだった。あるユーザがすばらしいアイデアを提供してくれた――ぼくは単に、その意義を理解すればよかっただけ。 * 11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。 　おもしろいことに、もし自分が他人に負うところがいかに大きいかについて、完全かつ謙虚なくらいに正直でいたら、世の中はその発明が全部あなた自身のもので、単に自分の天才ぶりについて謙遜しているだけだと見なしてくれる。これがリーヌスの場合にどんなにうまくいってるか、みんなもごらんの通り！ 　（1997 年 8 月にこの論文を Perl の会議で発表したとき、最前列に Larry Wall がいた。ぼくがこの直前のくだりにさしかかるとかれが野次をとばした。キリスト復活論者スタイルで、「そうだそうだ、言ってやれ、兄弟！」と。全聴衆が笑った。みんなこれが、Perl 発明者にとってもうまくいったのを知っていたからだ。） 　そしてその同じ精神でプロジェクトを運営してほんの数週間もしないうちに、ユーザたちからだけでなく、それを伝え聞いたほかの人たちからも、同じような賞賛のメールが届くようになった。そういうメールはいくつかとってある。いつか、自分の人生なんて何の価値もなかったんじゃないかと思うようになったら、またそれを読みかえそうっと:-)。 　でもここには、もっと本質的で政治的でない教訓があと 2 つある。これはあらゆるデザインに一般化して言えることだ。 * 12. もっとも衝撃的で革新的な解決策が、自分の問題のとらえかたがそもそも間違っていたという認識からくるということはよくある。 　ぼくは popclient を、MTA/MDA の複合物として開発し、いろんな気の利いたローカル配信モードをくっつけたものにしようとし続けていた。これは解決すべき問題をまちがえていたんだ。Fetchmail の設計は、純粋なMTAとして最初から考え直す必要があった。通常の SMTP を話すインターネットメールパスの一部として。 　開発で壁にぶちあたったとき――次のパッチ以降何をしたらいいか、すごく悩んでしまうとき――というのは、自分が最終的な回答にたどりついたのかな、と考えるべきときではなく、むしろ自分が正しい質問をしているのかな、と考え直してみるべきときであることが多い。ひょっとして、問題をとらえなおしてみる必要があるのかもしれない。 　というわけで、問題をとらえなおした。明らかに、やるべき正しいことというのは： * 汎用ドライバに SMTP 転送サポートをハックして入れ込む * それをデフォルトモードにする * やがてはその他の配信モードをすべてうっちゃる。特にファイルへの配信と標準出力への配信は始末する ということだった。 　この 3 番目については、しばらくためらった。ながいこと popclient を使ってきて、他の配信メカニズムに頼っている古参ユーザたちを怒らせるんじゃないかと思ったからだ。理論的には、かれらは即座に .forward ファイルか、sendmail 以外でもそれに相当する仕組みを使うことで、同じ結果を得ることができる。でも実際問題としては、この移行はえらく手間がかかることになるかもしれない。 　でも実際にやってみたら、利点のほうが大きく出てきた。ドライバのコードのいちばんいやらしい部分が消えた。設定もむちゃくちゃに簡単になった――システム MDA やユーザのメールボックスを探し回ったりして悩むこともなくなったし、下敷きになってる OS がファイルのロッキングをサポートしているか心配する必要もない。 　さらに、メールをなくす唯一の方法も消え失せた。もしファイルへの配信を指定してディスクがいっぱいになったら、メールは消えてしまう。これは SMTP 転送では絶対に起きない。SMTP のリスナーは、メッセージが配信できるか、少なくとも後の配信用にスプールできる場合にしか OK を返してよこさないからだ。 　さらに、速度も向上（もっともこれは一回走らせたくらいではわからないけれど）。もうひとつバカにできないメリットとして、man ページがすごくシンプルになった。 　あとで、ダイナミック SLIP がらみの珍しい状況を処理できるようにするため、ユーザ指定のローカル MDA 経由の配信は復活させなきゃならなかった。でも、これももっと簡単にこなす方法を見つけた。 　教訓は？　古びてきた機能は迷わず捨てること――有効性を下げずに捨てられる場合には。アントワーヌ・サンテグジュペリ（かれは児童書の古典を書いていないときには、飛行家で航空機設計家だった）曰く： * 13. 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。 　コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に自分が正しいのがわかる。そしてこの過程で、fetchmail のデザインは、先祖の popclient とは別の独自のアイデンティティを獲得してきた。 　そろそろ名前を変える頃だった。新しいデザインは、以前の popclient よりずっと sendmail の双子みたいな感じになってきていた。どっちも MTA だけれど、sendmail がプッシュして配信するのに対して、新しいpopclientはプルして配信する。だから引き継いで2ヶ月したところで、ぼくはこれを fetchmail と改名した。 ------------------------------------------------------------------------------- 7 Fetchmail の成長 　そういうわけで、きれいで革新的なデザインを手に入れ、毎日自分で使ってるから確実に動くのもわかってるコードもできたし、さらにベータリストは拡大する一方。だんだんわかってきたのは、自分がやっているのが、ほんの数人にたまたま便利に使えるような、自分だけのちょっとしたハッキングなんかではなくなってきた、ということだった。ぼくがいじっているのは、Unix マシンと SLIP/PPP メール接続を持ってるハッカーみんなが本当に必要としているプログラムだったんだ。 　SMTP 転送機能のおかげで、このソフトは競合ソフトからぬきんでて、「カテゴリーキラー」になる可能性まで出てきた。カテゴリーキラーというのは、ニッチをあまりに見事に満たしているので、それ以外の選択肢は単に放棄されるどころか、ほとんど忘れ去られてしまうようなソフトのことだ。 　こういう結果は、狙ってできるものではないし、計画して得られるものでもないと思う。ものすごく強力なデザイン上のアイデア、あとから考えると、その結果が当然きわまりなく、自然で、事前に約束されていたようにさえ思えるようなアイデアによって、そういう結果に引き込まれなくてはならないんだと思う。そんなアイデアを狙うには、たくさんアイデアを思いつくしかない――または、ほかのひとのいいアイデアをもらって、それをもとの発案者が思ってもみなかったところまでつきつめるというエンジニアリング上の判断を持つという方法か。 　Andrew Tanenbaum は、386 用に簡単なネイティブのUnixをつくるというアイデアを最初におもいついた。これは教育用ツールとしてだった。リーヌス・トーヴァルズは Minix のコンセプトを、Andrew が予想もしなかったくらいはるか遠くにまで拡張した――そしてそれが、すばらしいものへと成長した。同じように（もっともスケールは小さいけれど）ぼくは Carl Harris と Harry Hochheiser のアイデアをもとにして、それをつきつめた。ぼくらのいずれも、みんなが天才というものを考えるロマンチックな意味では「独創的」じゃなかった。でも、科学も工学もソフト開発も、ほとんどは独創的な天才の手になるものではないんだ。ハッカー神話がなんと言おうとも。 　でも結果はそれでもなかなか大した代物だった――それどころか、あらゆるハッカーが死んでもいいと思うような大成功！　そしてこれはつまり、ぼくは自分のねらいをさらに高く設定しなきゃいけないということを意味する。fetchmail を、いまの自分に見える可能性くらいにまで優れたものにするためには、自分のニーズのためだけにコードを書くのではなく、自分の守備範囲ははずれていても他人が必要としているような機能を加え、サポートしなくてはならなくなった。そして同時に、プログラムをシンプルで堅牢にしておく必要もあった。 　これを認識してから書いた初の、そして圧倒的にいちばん重要な機能は、マルチドロップのサポートだった。これはつまり、複数ユーザ宛のメールが全部たまっているメールボックスからメールをとってきて、それぞれのメールを個別受信者に選り分ける機能だ。 　マルチドロップのサポートを足すことにしたのは、一つには一部のユーザがしつこくせがんだこともある。でも最大の理由は、アドレッシングを最大限に一般化して対応せざるを得なくなることで、シングルドロップのコードのバグを全部ひねりつぶせるだろうと思ったからだ。そしてそれは立派に実証された。RFC822 の解析をきちんと実装するには、えらく長い時間がかかった。これは個別部分が特にむずかしかったからではなく、相互に依存しあった面倒な細部を山ほど片づけなきゃならなかったからだ。 　でもマルチドロップアドレッシングは、ふたをあけてみたらこれまたすばらしい設計上の決定だった。なぜそう思ったかというと： * 14. ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。 　――からだ。マルチドロップ fetchmail の予想もしない利用法は、メーリングリストを運用する際に、リストの管理や alias の展開を、SLIP/PPP 接続のクライアント側でできちゃえることだった。これはつまり、ISP のアカウント経由で個人マシンを走らせてる人でも、ISP の alias ファイルに絶えずアクセスすることなしにメーリングリストを運用できるってことだ。 　もう一つ、ベータテスタたちが要求してきた重要な変更は、8 ビット MIME のサポートだった。これはすごく楽だった。ぼくは自分のコードを 8 ビットクリーンにするように心がけてきたからだ。これは、こういう機能への要望を予想してたからではない。こんな別のルールに従ったまでのことだった： * 15. ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！ 　この規則を守っていなかったら、8 ビット MIME サポートはむずかしくてバグだらけになっただろう。でも、ぼくは守っていたので、RFC1652 を読んで、ほんのちょっとしたヘッダ生成のロジックを加えるだけですんだ。 　ヨーロッパのユーザの一部は、セッションあたりにとってこられるメッセージ数を制限するオプションをつけるようにしつこくせがんだ（電話代が高いので、それを抑えるためだ）。ぼくは長いことこれを拒否してきたし、いまでも完全に満足しているとはいいがたい。でも、世界のために書いているんなら、顧客には耳を傾けなきゃ――かれらがお金で支払ってるんじゃなくても、これは変わらない。 ------------------------------------------------------------------------------- 8 続・Fetchmail の教訓 　一般的なソフトウェア工学の問題に戻る前に、fetchmail の経験からもう少し教訓を引っぱり出して考察しておこう。 　rcファイルの構文は、オプションの「ノイズ」キーワードを持っていて、これはパーサーに完全に無視される。このキーワードのおかげで英語に似た構文が使えるようになるので、それを全部はぎとってできるような、従来の無味乾燥なキーワードと値の対応表よりはずっと読みやすくなっている。 　これはそもそも、ある晩遅くにちょっと始めた実験が発端だった。rc ファイルの宣言が、命令形のミニ言語にずいぶん似てきたのに気がついたのだ（そしてこのせいで、もとの popclient のキーワード「サーバ（server）」を「チェックせよ（poll）」に変えた）。 　この命令形のミニ言語をもっと英語風にしてみたら、使いやすくなりそうだと思った。さて、ぼくは Emacs や HTML や各種データベースエンジンに代表される「なんでも言語化せよ」式デザイン派閥の意識的な急進派ではあるけれど、通常は「英語っぽい」構文はふつう、あまり好きじゃない。 　伝統的にプログラマは、厳密でコンパクトで冗長性のまったくない制御構文を好む傾向にあった。これはコンピュータ資源が高価だった時代の文化的な名残だ。当時は構文解析段階は、できる限り安く単純でなきゃならなかったから。英語は 50％くらい冗長性を持っているので、当時はすごく不適切なモデルに見えた。 　英語っぽい構文を避けるべき理由としてぼくが挙げたいのはこういうことではない。ここでこれを挙げたのは、単にそれを却下するためだ。サイクルやコアが安くなってきたら、無味乾燥がそれ自体で目的化してはならない。いまでは、言語はコンピュータにとって安あがりになるよりも、人間にとって便利なほうが大事なのだ。 　でも、慎重になるべきまともな理由はある。一つは複雑さと、構文解析段階のコストだ――あんまり複雑にすると、それ自体がバグのもとになったりユーザの混乱を招いたりしかねない。別の理由として、言語の構文を英語っぽくしようとすると、しばしばその言語の使う「英語」はとんでもなく歪んだ代物になってしまい、これが高じると、そういうわざとらしい自然言語との類似は伝統的な構文と同じくらい混乱をまねくことになる（これはいろんな 4GL や商業データベースキュエリー言語で見かける）。 　Fetchmail の制御構文は、どうやらこういう問題を免れている。それは、言語ドメインがすごく制限されているからだ。汎用言語にはほど遠い。それが表現していることは、とにかく大して複雑ではないので、英語の小さなサブセットと実際の制御言語の間を行き来するのに、精神的な混乱を起こす可能性があまりない。ここにはもっと広い教訓があるかもしれない。 * 16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。 　別の教訓は、隠すことでセキュリティを高めるという点についてのものだった。Fetchmail ユーザの一部は、ソフトの仕様を変えて、パスワードを暗号化して rc ファイルに保存するようにしてくれと要求してきた。のぞき屋たちが気軽にそれをのぞいたりできないようにしてほしいから、と言って。 　これはやらなかった。これでは実は、セキュリティはぜんぜん高まらないからだ。rc ファイルを読む許可を与えられている人間なら、だれでも fetchmail をどのみちあなたと同じように好き勝手に動かせてしまうんだから――そしてそいつがあなたのパスワード目当てなら、fetchmail のコードそのものから必要なデコーダをぬきだして、ファイルを解読して盗むことができてしまう。 　だから .fetchmailrc パスワード暗号化なんかしても、ものごとをつきつめて考えない人たちに、セキュリティが高まったかのようなまちがった幻想を与えるだけだ。ここでの一般原則は以下の通り： * 17. セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。 ------------------------------------------------------------------------------- 9 バザール方式の前提条件とは 　この論文の初期レビューアーや、試験読者たちがたえず返してきた質問というのは、上手なバザール形式の開発に必要な条件は何か、というものだった。これはプロジェクトリーダーの資質と、共同開発者コミュニティをつくろうとしてコードを公開する時点での、コードの状態についての条件の両方についてのものだった。 　バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしているだろう。バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのはすごくむずかしいだろう。リーヌスはそんなことはしなかったし、ぼくもしなかった。あなたが生み出そうとしてる開発者コミュニティは、いじるために何か動いてテストできるものを必要としているんだ。 　コミュニティ形成を始めるときには、まずなによりも実現できそうな見込みを示せなきゃならない。別にそのソフトは特によく書けてなくてもいい。雑で、バグだらけで、不完全で、ドキュメント皆無でもいい。でも絶対不可欠なのが、開発者候補たちに、それが目に見える将来にはなにか本当に使える代物に発展させられると説得できることだ。 　Linux と fetchmail は、どちらも強力で魅力的な基本デザインをもって公開された。ぼくが提出したバザールモデルについて考えてきた人の多くは、これがきわめて重要だということを正しく認識し、そこからいきなり、だったらプロジェクトリーダーには高度なデザイン上の直感と才能が必要にちがいないという結論に一足飛びにとびついてしまった。 　でもリーヌスはデザインを Unix からもらってる。ぼくはもともと先祖の popmail からアイデアを得てる（もっともそれは後に大きく変わった。割合から言えば Linux よりはずっと大きな変化だ）。ということは、バザール形式のリーダー/コーディネーターはずばぬけたデザインの才能が本当にいるんだろうか、それとも他人のデザインの才能をうまく生かすだけでやっていけるんだろうか。 　コーディネーターが、とてつもないデザイン上のひらめきを自分で得る必要性は必ずしもないと思う。でも、絶対に必要なのは、その人物がほかの人たちのよいデザイン上のアイデアを認識できるということだ。 　Linux も fetchmail も、この証拠を示している。リーヌスは（すでに述べた通り）、驚異的に独創的な設計者ではないけれど、よいデザインを認識してそれを Linux カーネルに組み込む強力な第六感を示した。そしてすでに述べたように、fetchmail 最大の強力なデザインアイデア（SMTP 転送）は他人にもらったものだった。 　この論文を早い時期に読んだ人たちは、おまえはバザールプロジェクトでのデザイン上の独創性を過小評価している、自分にはいろいろアイデアがあるもんだから、それが当然のことだと思ってるんだろう、と誉めてくれた。確かにこれは一理ある。ぼくの最大の強みは確かに、コーディングやデバッグではなく、デザイン能力にある。 　でもソフトの設計で、小利口で独創的になることの問題点は、それが習慣になってしまうことだ。ソフトは堅牢でシンプルにしておかなきゃダメなのに、反射的にそれを媚びた複雑なものにしてしまいがちになる。このまちがいのおかげでつぶれたプロジェクトもいくつかある。でも、fetchmail ではそういうことにならずにすんだ。 　だから fetchmail プロジェクトが成功したのは、一部はぼくが小利口になりがちな自分の性格を抑えたからだと思う。これは（少なくとも）バザールプロジェクトの成功にデザイン上の独創性が不可欠という議論の反証になっている。そして Linux もそうだ。もしリーヌス・トーヴァルズが開発途上で根本的なOSデザインの革新をやってのけようとしていたら、その結果のカーネルがいまのものほど安定してうまくいっていたかどうか？ 　一定レベルのデザインとコード書き能力は必要だけれど、でもバザール式のプロジェクトを始めようかと真剣に考えている人なら、ほとんどだれでもそんな最低限以上の能力はあるだろう。フリーソフト/オープンソースコミュニティ内における評判の市場は、最後まで面倒を見られないような開発プロジェクトを始めないように、みんなに微妙な圧力をかける。いまのところ、これはなかなかうまく機能してきたようだ。 　別の才能で、ソフト開発とはふつうは関連づけられないけれど、でもバザールプロジェクトではデザイン上の才覚に匹敵するほど――あるいはそれ以上――重要なものがあると思う。バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。 　これは説明するまでもないだろう。開発コミュニティをつくるには、人を引きつける必要がある。自分のやっていることに興味を持たせて、各人のやっている仕事量についてみんなが満足しているように気を配る必要がある。技術的な先進性は、これを実現する役にはおおいに立つけれど、でもそれだけではぜんぜん足りない。その人が発する個性も大事だ。 　リーヌスがナイスガイで、みんなかれを気に入って手伝いたくなってしまうのは、偶然ではない。ぼくがエネルギッシュで外向的で、大人数を動かすのが好きで、コメディアンの話術や本能をちょっと備えているのも偶然じゃない。バザールモデルが機能するためには、人を魅了する能力が少しくらいでもあると、きわめて役に立つのだ。 ------------------------------------------------------------------------------- 10 フリーソフトの社会的な意義 　これはもう不動の真実だ。最高のハックは、作者の日常的な問題に対する個人的な解決策として始まる。そしてその問題が、実は多数のユーザにも典型的なものであるために広まる。これでルールその 1 の話に戻ってきた。ただしもう少し便利な形で言い直してみよう。 * 18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。 　 Carl Harris とかれのかつての popclient もそうだったし、ぼくの fetchmail もそうだ。でもこれは長いこと理解されてきた。おもしろい点、つまり Linux と fetchmail の歴史がぼくたちの目をいやでも向ける点は、次の段階だ――ユーザと共同開発者たちの巨大で活発なコミュニティがある中で、ソフトがどう発展するかという話。 　『人月の神話』でフレッド・ブルックスはプログラマの時間が代替不能だと看破している。遅れているソフト開発に開発者を加えても、開発はかえって遅れる。プロジェクトの複雑さとコミュニケーションコストは、開発者数の2乗で増大するのに対し、終わる作業は直線的にしか増加しないというのがかれの議論だった。この論はそれ以来「ブルックスの法則」と呼ばれるに至り、真実をついているものとだれもが考えている。でもブルックスの法則が唯一無二の真理なら、Linux はあり得なかっただろう。 　数年後、ジェラルド・ワインバーグの古典『プログラミングの心理学』が、いまにして思えばブルックスに対する重要な訂正だったものを提供してくれた。「エゴのないプログラミング」を論じるなかでワインバーグが述べたのは、開発者たちが自分のコードを私物化せず、ほかのみんなにバグを探したり改良点を見つけたりするよう奨励するようなところでは、ソフトの改善がほかよりも劇的にはやく生じる、ということだった。 　ワインバーグの分析がしかるべき評価を得なかったのは、用語のせいかもしれない――インターネットのハッカーたちを「エゴがない」と呼ぶなんて、つい笑ってしまうではないの。でも、かれの議論は今やかつてない説得力を持っている。 　Unix の歴史を見れば、Linux から学びつつあるもの（そしてぼくが意図的にリーヌスの手法を真似ることで、実験的に小規模に確認したもの）は見えていたはずなんだ。コーディングは基本的に孤独な活動だけれど、真に偉大なハックはコミュニティ全体の関心と能力を動員することで実現されるってこと。閉ざされたプロジェクトの中で、自分の脳味噌だけを使う開発者は、オープンで発展的な文脈をつくりだしてバグつぶしや改善を何百人もで行えるようにできる開発者に負けてしまうんだ。 　でも従来の Unix の世界は、このアプローチをとことんまでつきつめることができなかった。要因はいくつかある。一つはいろいろなライセンスや商売上の秘密、商業的な利害からくる法律上の制約。そしてもう一つは（いまにして思えば）インターネットがまだ発達しきってなかったことだ。 　安いインターネット以前には、いくつかの地理的に集中したコミュニティではワインバーグの「エゴのない」プログラミングが奨励されていた。そこでは開発者は、有能なチェック屋や共同開発者を楽にたくさん集めることができた。ベル研、MIT AI 研、UC バークレー――こういうところは伝説的な技術革新を生み出したし、いまでも強力だ。 　Linux は、意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。Linux 形成期が、World Wide Web の誕生と同時期なのは偶然ではないと思うし、Linux が幼年期を脱したのが 1993-1994 年という、ISP 産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。リーヌスは、拡大するインターネットが可能にした新しいルールにしたがって活動する方法を見いだした、最初の人間だったわけだ。 　安いインターネットは、Linux モデルの発展にとっての必要条件ではあったけれど、でもそれだけでは十分条件ではなかったと思う。もう一つの重要な要素は、開発者が共同開発者を集めて、インターネットというメディアを最大限に活かすためのリーダーシップのスタイルと、協力のための慣行が開発されたことだろう。 　でもこのリーダーシップのスタイルとはなんで、その慣行ってのはどういうものだったんだろう。これは権力関係に基づくものではあり得ない――あり得たとしても、脅しによるリーダーシップは、いまぼくたちが目にするような結果を生み出しはしない。ワインバーグは、19世紀ロシアのアナキストであるクロポトキンの『ある革命家の回想』を引用して、この点についていい議論を展開している。 「農奴を所有する一家に育ったわたしは、当時の若者たちみんなと同じように、命令したり指令したり、叱りつけたり罰したりといった行動の必要性について、まったく疑うことを知らぬままに成年に達した。しかしかなりはやい時期に、わたしは大がかりな企業を経営することになり、自由な人々と交渉することになった。そしてまちがい一つが重大な結果を招くような状況で、わたしは命令と規律という原理にしたがって活動するのと、共通の理解という原理に基づいて行動するのとの差をだんだん理解するに至った。前者は軍隊のパレードでは見事に機能するが、実生活において、目標が多くの重なり合う意志の真剣な努力によってしか達成できないような状況では何の価値もない」 　この「多くの重なり合う意志による真剣な努力」は、まさに Linux のようなプロジェクトには必須――そして「命令という原理」は、ぼくたちがインターネットと呼ぶアナキスト天国のボランティアたちに対しては、実質的に適用不可能だ。効果的に活動して競争するには、共同プロジェクトを仕切りたいハッカーは、クロポトキンが「理解の原理」で漠然と示唆しているモードを使い、有益なコミュニティをリクルートしてやる気を起こさせる方法を学ばなくてはならない。つまり、リーヌスの法則を学ばなくてはならないんだ。 　まえにリーヌスの法則の説明として「デルファイ効果」が考えられると述べた。でも、生物学や経済学に見られる適応型システムも、アナロジーとして強力だし魅力もある。Linux の世界はいろんな意味で、自由市場や生態系のような動きを見せる。自己中心的なエージェントがそれぞれ効用を最大化しようとして、その過程で自己調整的な自律的秩序を生み出し、それはどんな中央集権計画の何倍も複雑で効率が高くなる。だからこここそが「理解の原理」を探すべき場所だ。 　Linux ハッカーたちが最大化している「効用関数」は、古典経済的なものではなく、自分のエゴの満足とハッカー社会での評判という無形のものだ（かれらの動機を「愛他精神」と呼ぶ人もいるけれど、でもそれは、愛他家にとっての愛他活動はそれ自体が一種のエゴの満足だという事実を見落としている）。こういう形で機能するボランタリー文化は、実はそんなに珍しいものじゃない。ぼくが長いこと参加してきたもう一つの例は、SF ファンダムで、ここはハッカー界とちがってボランティア活動の基本的な動機をはっきり「エゴブー」（他のファンたちの間で自分の評判を高めること）だと認識している。 　リーヌスは、開発そのものはほとんど他人にやらせつつ、うまいこと自分はプロジェクトの門番におさまった。そしてプロジェクトへの関心を育てて、それが自立するようにしてきた。これはクロポトキンの「共通の理解という原理」の鋭い把握を示している。このように Linux の世界を準経済学的に見てやると、その理解がどのように適用されているか見て取れるだろう。 　リーヌスのやり方は、「エゴブー」の効率的な市場をつくりだす方法として見るといいかもしれない。個々のハッカーたちの利己性を、協力体制を維持しないと実現不可能なむずかしい目標に、できるだけしっかり結びつける方法だ。Fetchmail プロジェクトで、ぼくは（もっと小規模にではあるけれど）かれの手法が再現できるものだということを示した。ぼくのほうが、リーヌスよりもそれをちょっと意識的かつ体系的に行ったとはいえるかもしれない。 　多くの人（特に政治的な理由で自由市場を信用しない人たち）は、自己中心的なエゴイストの文化なんか断片的で、領土争いばかりで、無駄が多く、秘密主義的で、攻撃的にちがいないと考える。でもこの予想ははっきりと反証できる。数多い例の一つをあげると、Linux 関連文書の驚くべき多様性と品質と詳細さがある。プログラマたちはドキュメント作成が大嫌いというのは、ほとんど神聖化された周知の事実とされている。だったら、なぜ Linux ハッカーたちはこんなにもたくさんの文書を生み出すんだろう。明らかに Linux のエゴブー自由市場は、商業ソフト屋さんのものすごい予算をもらった文書作成業者たちよりも、気高さに満ちた他者をいたわる行動を生み出すうえでうまく機能するわけだ。 　Fetchmail と Linux カーネルプロジェクトがどちらも示しているのは、ほかの多くのハッカーたちのエゴにきちんとごほうびをあげれば、強力な開発者/コーディネータはインターネットを使って、共同開発者がたくさんいるメリットを享受しつつ、プロジェクトが混乱しきった修羅場に陥って崩壊するのは避けられる、ということだ。というわけで、以下はブルックスの法則に対するぼくの反対提案： * 19. 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。 　フリーソフト（オープンソース・ソフト）の未来は、ますますリーヌスのやりかたを身につけた人たちのものになっていくと思う。つまり、伽藍を後にしてバザール方式を受け入れる人たちのものだ。これは別に、個人のビジョンと才能がもはやどうでもいいということではない。むしろ、フリーソフト/オープンソースの最先端は、個人のビジョンと才能を出発点としつつも、それをボランタリーな利害/興味コミュニティの構築によって増幅する人々のものだと思う。 　そしてこれは、単に「フリー」ソフト（オープンソース・ソフト）だけの未来像ではないのかも知れない。問題解決にあたって、Linux コミュニティが動員できるほどの才能プールに太刀打ちできる商業デベロッパは存在しない。Fetchmail に貢献してくれた200人以上を雇える財力を持つようなデベロッパですら、ごくわずかしかいない！ 　もしかすると、最終的にフリーソフト/オープンソース文化が勝利するのは、協力が道徳的に正しいとかソフト「隠匿」が道徳的にまちがってるとかいう理由のためではなく（ちなみに後者については、リーヌスもぼくもそうは思わない）、単に商業ソフトの世界が、ある問題に有能な人々の時間を幾桁も多くそそぎ込めるフリーソフト/オープンソース界と、進化上の軍事競争で張り合えなくなるからかもしれない。 ------------------------------------------------------------------------------- 謝辞 　この論文は、デバッグを手伝ってくれた多数の人々との会話によって改善されてきた。とくに感謝したいのが Jeff Dutky 。かれは「デバッグは並列処理可能である」という言い方を提案して、そこから生まれる分析の形成を助けてくれた。Nancy Lebovitz は、クロポトキンを引用 してワインバーグをまねしたらどうかと示唆を与えてくれた。ほかに有益なコメントをくれた人としては、General Technics リストの Joan Eslinger と Marty Franz 。PLUG（フィラデルフィア Linux ユーザグループ）のメンバーたちにも感謝する。かれらはこの論文の初の公開版について、最初のテスト読者になってくれた。最後になったが、リーヌス。トーヴァルズのコメントは有益だったし、かれがはやいうちから賛同してくれたので、ぼくとしてもやりやすかった。 ------------------------------------------------------------------------------- もっと考えたい人のための文献リスト 　Frederick P. Brooks の古典The Mythical Man-Month （邦訳　フレデリック・P・ブルックス『人月の神話――狼人間を撃つ銀の弾はない』 アジソン・ウェスレイパブリッシャーズ・ジャパン、1996 年）からはあちこち 引用させてもらった。というのも、かれの洞察はいろいろな意味で、まだまだそのまま通用するものだからだ。Addison-Wesley から出ている刊行25周年記念版 (ISBN 0-201-83595-9）を是非ともお奨めする。これにはかれの 1986 年論文 No Silver Bullet （前掲書第 16 章所収。邦題「銀の弾などない」）も収められている。 　この新版の巻末には、非常に有益なブルックスの20年後の回想記がついていて、このなかでブルックスはもとの文章において結果的にまちがっていた部分について、すなおに認めている。ぼくはこの論文をほとんど書き上げたときにこの回想記を読んだのだけれど、ブルックスがバザール式のやり方の例としてマイクロソフトを挙げていたと知ったときにはたまげたね！ 　 Gerald M. WeinbergのThe Psychology of Computer Programming (New York, Van Nostrand Reinhold 1971)（邦訳　G. M. ワインバーグ『プログラミングの心理学　または、ハイテクノロジーの人間学』木村泉他訳、技術評論社、1994年）は、「エゴのないプログラミング」という考え方を導入していて、これは名前のつけかたがまずかったと思う。「命令主義」の不毛さについて認識したのは、かれが最初でもなんでもないけれど、でもそれを特にソフト開発に結びつけて論じたのはたぶんかれが最初だと思う。 　 Richard P. Gabriel は Linux 以前の時代の Unix 文化を考察し、1989 年の論文 "Lisp: Good News, Bad News, and How To Win Big" のなかで、初期のバザール状モデルの優位性を論じている。古びたところもあるけれど、この文章はいまでも Lispファン（ぼくを含め）の間では当然ながら珍重されている。ある人がぼくに、この文のなかの「劣るほうが優秀」という章は、まるで Linux を予見しているかのように読めることを指摘してくれた。この論文は World Wide Web のhttp://alpha-bits.ai.mit.edu/articles/good-news/good-news.htmlで入手可能。 　 De Marco と Lister の Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6) (邦訳『ピープルウェア』日立SK訳、日経BP社、1989年) は知られざる名著で、フレッド・ブルックスが回想記の中で触れているのを見たときは嬉しかった。著者たちの議論のなかで、直接 Linux やフリーソフト（オープンソース）界に適用できるものはあまりないけれど、創造的な作業に必要な条件に関する著者たちの洞察は正確で、バザールモデルの長所をもっと商業的な場に導入したいと試みる人には一読の価値がある。 　最後に、ぼくはこの論文を寸前まで「伽藍とアゴラ」と呼ぶところだったのを白状しておこう。アゴラというのは、ギリシャ語で自由市場や公共集会場所をさすことばだ。Mark Miller と Eric Drexler の先駆的な論文 "The Agoric System"「アゴラ的システム」 は、市場状のコンピュータ生態学にあらわれつつある性質を記述していて、5 年後に Linux がぼくをフリーソフト（オープンソース・ソフト）での類似現象に直面させたときも、これを読んでいたおかげで明確にものを考える準備ができていた。この論文はWeb上のhttp://www.agorics.com/agorpapers.html で入手可能。 ------------------------------------------------------------------------------- エピローグ：Netscapeもバザール方式を受け入れる 　自分が歴史の変化に手を貸したと気がつくのは、なんとも奇妙な感じだ…… 　1998年1月22日、ぼくがこの論文を初めて発表してからおよそ 7 ヶ月後、Netscape Communications, Inc. がNetscape Communicator のソースを無料でばらまく計画を発表した< http://www.netscape.com/newsref/pr/newsrelease558.html>。この発表の前日でさえ、こんなことが起こるとはつゆほども知らなかった。 　Netscape の専務副社長兼技術担当重役の Eric Hahn が、発表のすぐ後にぼくにメールをくれた。こんな文面だ。「Netscape 全社員を代表して、そもそもこのポイント把握を助けてくれたことに感謝します。あなたの考え方と論文が、われわれの決断にあたって根本的なひらめきを与えてくれました」 　翌週、ぼくは Netscape 社の招きでシリコンバレーに飛び、かれらの重役や技術陣との丸一日にわたる戦略会議（1998 年 2 月 4 日）に出席した。ぼくたちは Netscape のソース公開戦略とライセンスをつくり、その他、いずれフリーソフト（オープンソース）コミュニティに重大で前向きな影響をもたらすはずの計画をつくりあげた。この執筆時点では、これ以上の詳しい話はまだできないけれど、でも数週間以内に追って詳細が発表されるはずだ。 　Netscape は大規模な現実世界におけるバザールモデルのテスト機会を提供してくれようとしている。フリーソフト/オープンソース文化は、いま一つの危険に直面していることになる。もし Netscape のやりくちがうまくいかなければ、フリーソフト/オープンソースの考え方自体がダメなせいだと思われてしまい、商業ソフトの世界はまた 10 年ほどは手を出そうとしなくなるかもしれない。 　一方、これはまたとてつもないチャンスでもある。この動きに対するウォール街などでの初期の反応は、慎重ながらも肯定的だった。ぼくたちは自らの力を証明する機会を与えられているのだ。この動きを通じて Netscape が再び圧倒的な市場シェアを取り戻せば、それをきっかけにもうとっくに起こっていてしかるべきだったコンピュータ産業の革命が動き出すかも知れない。 　この先一年は、非常に示唆的でおもしろい時期になるだろう。 ------------------------------------------------------------------------------- バージョンと変更履歴 　 $Id: cathedral-bazaar.sgml,v 1.40 1998/08/11 20:27:29 esr Exp $ 　バージョン1.16: 1997 年 5 月 21 日、Linux Kongress にて発表。 　バージョン1.20: 1997 年 7 月 7 日、文献リストを追加。 　バージョン1.27: 1997 年 11 月 18 日、Perl 会議での逸話を追加。 　バージョン1.29: 1998 年 2 月 9 日、「フリーソフト」を「オープンソース」に変更（「オープンソース」という用語はまだ日本語として普及していないと判断して、翻訳では併記している）。 　バージョン1.31: 1998 年 2 月 10 日、「エピローグ：Netscape もバザール 方式を受け入れる」の章を追加。 　バージョン1.4: 1998年7月28日にRMSから強力な意見をもらったのを受けて、Paul EggartによるGPL vs バザール方式に関する見解を削除。 　これ以外の変更は、細かい編集上の変更やマークアップの変更を反映 したもの。 （翻訳上のミスについて、高瀬 俊朗、山根 信二、白田秀彰、井上友一の各氏からご指摘をいただいた。伏して感謝する――訳者記す） ------------------------------------------------------------------------------- YAMAGATA Hiroo