Programing Pearlsで、 有名なコンピュータ科学の警句屋ジョン・ベントレーは、ブルックスの観察について こうコメントしている。「もし一つ捨てることを予定して置いたら、 二つ捨てる結果になるだろう」。かれはほとんど確実にただしい。 ブルックスの見解と、べントレーのコメントというのは、 単に最初の試みはまちがえやすいから覚悟しろ、ということではない。 めちゃくちゃになったのを救うよりは、正しいアイデアで一からやり直すほうが、 有効な場合が多い、ということを言いたいのだ。

　インターネットに先立つ、成功したオープンソースのバザール形式開発で、 しかも UNIX やインターネットの伝統とは関係ないものも存在している。 1990-92 年の info-Zip 圧縮ユーティリティの開発（主に DOS マシン用）はその一例だ。 もう一つあるのが、RBBS BBS ソフトだ（これまた DOS 用）。 これは 1983 年に始まって、なかなか強力なコミュニティが形成され、 インターネットの電子メールやファイル共有のほうがローカルの BBS よりもずっと技術的なメリットが高くなった今（ 1999 年半ば）にいたるまで、 定期的なリリースを繰り返している。info-ZIP コミュニティはある程度まで インターネットの電子メールに頼っていたけれど、RBBS 開発者の文化は、RBBS 自身を使って相当なオンラインコミュニティを擁し、完全に TCP/IP インフラとは独立していた。

　John Haslerは、ある作業が重複してやられたところで、 オープンソースの開発にとっては差し引きであまり足をひっぱる結果には ならないと示唆してくれた。かれが提案したものを「ハスラーの法則」と呼ぼう。 重複作業のコストは、そのチームのサイズの二乗より少ない —— つまり、 そういう重複を避けるために必要な、計画やマネジメントのオーバーヘッドに比べて 増え方が遅いのだ。

　この主張は、実はブルックスの法則に反するものではない。 複雑なオーバーヘッド総額と、バグへの弱さがチームサイズの二乗に比例するのは 事実かもしれないけれど、でも重複作業からくるコストは、 もっとゆっくりスケールする特殊な例でしかない。これにもっともらしい理由を つけるのは、そんなにむずかしくない。まずは、ほとんどのバグの原因となっている、 計画外のよからぬ相互作用を防ぐのに比べれば、開発者のコード同士で 機能の仕分けについて話あうのはずっと簡単だという、 まちがいのない事実からも説明できる。

　バザール方式でゼロからプロジェクトを立ち上げられるかという問題は、 バザール方式が真に革新的なものをサポートできるのか、という問題と関係している。 ある人に言わせると、強いリーダーシップのないバザールは、 エンジニアリングの最先端にすでに存在しているアイデアをまねしたり、 改良したりできるだけで、その最先端を先に進めることはできないそうだ。 この議論を提出したいちばん悪名高い例が、ハロウィーン文書 （原文、 翻訳）だろう。 オープンソース現象について書かれた、マイクロソフトの恥ずかしい社内メモだ。 この著者たちは、Linux が UNIX に似た OS を開発するのを 「テールライトを追いかける」と例えてくれて、 「（そのプロジェクトがひとたび技術の最先端の「飽和点」に達してしまえば） 、新たなフロンティアに向けてみんなを押し進めるために必要となる マネジメントのレベルはとてつもないものとなる」と論じている。

　この議論には、深刻な事実関係のまちがいが含まれている。その一つは、 ハロウィーン文書の著者たち自らが次のように洞察しているところで はっきり表明されている：「具体的にはこれは、新しい研究上のアイデアは まず Linux 上で実装されて入手可能となり、その後でほかのプラットホームで 提供されたり組み込まれたりするようになる、ということだ」

　ここで Linux を「オープンソース」と読み替えれば、これがまるで 目新しい現象でないことはわかるだろう。歴史的に、オープンソース・コミュニティが Emacs や World Wide Web やインターネットを発明したのは、 テールライトを追っかけたり、とてつもないレベルのマネジメントがあったり したためではない —— そしていまでも、オープンソースではとても多くの 独創的な仕事が続いていて、選ぶのに目移りするほどだ。あえて一つ選ぶとすると、 GNOME プロジェクトは GUI とオブジェクト技術の最先端を押し広げていて、 Linux とはかけ離れたコンピュータ業界紙からも大いに注目されている。 その他の例も目白押しで、これはいつでもいいから Freshmeatを訪ねてみればすぐに証明される。

　でも、伽藍方式が（あるいはバザール方式でも、その他どんなマネジメント方式 でもいい）、なにやら技術革新を信頼できるかたちで生じさせられるという、 暗黙の仮定にはもっと根本的なまちがいがある。だって、そんなのナンセンス だからだ。群衆は、突破口となるような洞察なんか持てない —— バザール方式のアナキストたちによるボランティア集団でさえ、 まともなオリジナリティは発揮できないし、ましてやなにか現状に生存が 係っているような人々からなる、企業委員会なんかからそんなものは 絶対に出てきやしない。洞察は個人からくる。 それをとりまく社会機構としてせいぜい期待できるのは、 その突破口となる思いつきに対して敏感に反応することくらいだ —— それをつぶすのではなく、ちゃんと育てて報酬を与え、 きちんとテストしてやることだ。

　これをロマンチックな見方だと決めつける人もいるだろう。 孤独な発明家というステロタイプに逆戻りしている、と。ちがうね。 ぼくは別に、いったん生まれた突破口となる洞察をグループが 育てられないなんて言ってるわけではない。 それどころか、ピアレビューのプロセスから学ぶのは、 こうした開発グループこそが高品質の結果を生み出すために不可欠だということだ。 むしろぼくが指摘しているのは、そういうグループ開発もすべて出発点は —— つまり、それに火をつけるのは必ず —— だれか一人が思いついた、 いいアイデア一つなんだ、ということだ。伽藍やバザールなんかの社会的な機構は、 その火花をつかまえて洗練させることができるけれど、 でもその機構が命令して着想を生み出したりはできないんだ。

　だから、技術革新の根本問題（これはソフトウェアに限らずあらゆるところで） というのは、そのアイデアをどうやってつぶさずにおくか、ということだ —— でも、もっと根本的には、そもそも洞察を持てるような人たちを たくさん育てるにはどうしたらいいか、ということだ。

　伽藍方式の開発がこいつを実現できて、参入障壁が低い、 プロセスの流動的なバザールではこれができないと仮定するのはバカげている。 もしたった一人のたった一つのアイデアでいいなら、 一人の人間がそのいいアイデアで、何百、何千という人々の協力をすぐに 集められる社会方式のほうが、クビになる心配なしにそのアイデアに基づく 作業ができるようになるために、階級機構に対して政治的な売り込みを しなくてはならないようなシステムに比べて、革新は早いに決まっている。

　そして実際に、伽藍方式を使った組織によるソフトの技術革新の歴史を見てみると、 あまり数がないことがすぐにわかる。巨大企業は新しいアイデアの源として 大学の研究に頼っている（だからこそハロウィーン文書の著者たちは、Linux がその研究成果をずっとはやく取り入れられるということに危機意識を見せている）。 あるいは、革新者の頭脳を中心に生まれた小企業を買収するだろう。 いずれの場合にも、伽藍文化には技術革新は根付いていない。それどころか、 そうやって輸入された技術革新の多くは、ハロウィーン文書の著者たちが あんなに持ち上げる「とてつもないレベルのマネジメント」によって、 静かに窒息させられてしまう結果となる。

　これはでも、否定的なポイントだ。読者のみんなは、 もっと肯定的な論点のほうが役にたつだろう。試しに、 以下のような実験をしてみたらどうだろう。

1. 一貫性を持って適用できると思うような、オリジナリティをはかる尺度を選ぶこと。 きみの定義が「オリジナリティなんて見りゃわかる」というものであっても、 このテストでは問題にはならない。
2. Linux と競合しているクローズドソースの OS をどれでもいいから選んで、 その OS 上で進行中の開発作業を記述した最高の情報源を選ぶこと。
3. その情報源と Freshmeat を一ヶ月眺めること。毎日、「オリジナル」 な仕事だと思われるリリースの発表の数を数えること。 「オリジナル」の定義をその別の OS にも適用して、その数を数える。
4. 30 日たったら、両方の数字をそれぞれ合計。

　これを書いた日だと、Freshmeat はリリースのアナウンス 22 つがあって、 そのうち 3 つは何らかの形で最先端をさらに先へ進めるようなものだった。 この日の Freshmeat は低調だったけれど、でもクローズドソースの どんなプロジェクトでも、ものになりそうな技術革新が一月 3 つもあったら 驚嘆しちゃうね。

　いまや、いくつかの意味で fetchmail よりもバザール方式の実例として 好都合なプロジェクトの歴史が手に入った。それが EGCS、gcc の高速版である Experimental GNU Compiler System だ。

　このプロジェクトは 1997 年半ばに、この「伽藍とバザール」初期公開版に 登場したアイデアを意識的に適用してみようという試みとしてはじまった。 プロジェクトの創始者たちは、GCC（GNU C コンパイラ）の開発が停滞していると 感じていた。そしてそれ以降 20 ヶ月にわたり、GCC と EGCS は並行した プロジェクトとして続いていた —— どちらも同じインターネット開発人口から 人材を集め、どちらも同じ GCC のソースべースから出発してるし、 どちらもだいたい同じ UNIX ツールセットと開発環境から始めている。 両プロジェクトの唯一のちがいは、EGCS が意識的に、ぼくがこれまでに記述してきた バザール戦術を用い、それに対して GCC のほうは、閉じた開発者グループと めったにないリリースとでもっと伽藍的な開発方式を続けたということだった。

　これは、対照実験にいちばん近いものといっていい。そして結果は劇的だった。 数ヶ月のうちに、EGCS のバージョンは、機能面ではるかに GCC を引き離した。 最適化も向上していて、FORTRAN と C++ のサポートも優れていた。 多くの人は、EGCS の開発途上スナップショットのほうが、GCC の最新安定版より 信頼性が高いと判断しており、主要 Linux ディストリビューションも EGCS に移行しはじめた。

　1999 年 4 月には、フリーソフト財団（GCC の公式スポンサー）はもとの GCC 開発チームを解散して、プロジェクトのコントロールを公式に EGCS ステアリング・グループに譲りわたした。

　もちろん、クロポトキンの批判とリーヌスの法則は、 社会機構のサイバネティクスについてもっと大きな問題を提起している。 ソフト工学についての別の口伝理論が、その一つを示している。 これはコンウェイの法則と言われる —— ふつうの言われ方では、 「もしコンパイラをつくるのに 4 つのグループが作業していたら、 できあがるのは 4 パスコンパイラになる」となる。 もとの表現はもっと一般的だった。「システムを設計する組織は、 その組織のコミュニケーション構造の複製であるような設計を生み出すように 縛られる」というものだ。これをもっと平たくして「手段が目的を決定する」 と言ってもいいだろう。あるいは「プロセスこそが成果物となる」とでも。

　したがって、オープンソース・コミュニティでは、 組織形態と機能がいろんなレベルで一致していることは頭にいれておいていいだろう。 ネットワークがすべてで、いたるところにある。インターネットだけじゃない。 みんな分散した、ゆるい結びつきの、ピア・ツー・ピアのネットワークで 作業を進めて、それがいくつもの冗長性を生んで、退行のしかたもとても緩やかだ。 いずれのネットワークでも、各ノードはほかのノードがそれと協力したがる度合いに 応じてのみ重要となる。

　オープンソース・コミュニティのすさまじい生産性には、このピア・ツー・ピアの 部分が本当にだいじだ。クロポトキンが力関係について言おうとしていたことは、 「SNAFU 原理」によってさらに展開されている。その原理とは、 「真のコミュニケーションは対等な者同士の間でしか成立しない。 なぜなら、劣る者は上位者に耳障りのいいウソを語ったほうが、 真実を語るよりも報酬を得る見込みが高いからだ。」創造的なチームワークは、 まさに真のコミュニケーションに依存していて、だからそこに権力関係が入り込むと、 かなり深刻に足を引っ張られる。オープンソース・コミュニティは、 こういう力関係からは実質的に自由で、しかもそういう力関係がバグや 機会損失という面でどんなに高いコストを支払うことになるのか、 ということを反面教師的に教えてくれているわけだ。

　さらに、SNAFU 原理は権威主義的な組織において、意志決定者たちと 現実の間がだんだん乖離していくと預言している。というのも、 意志決定者の耳に入る入力は、ますます耳障りのいいウソばかりになってくるからだ。 これが従来のソフト開発でどう効いてくるかというのは、すぐにわかる。 下位の者たちには、問題を隠し、無視して、過小評価する強いインセンティブがある。 このプロセスが製品となったら、ソフトウェアは悲惨なことになる。