これはもう不動の真実だ。最高のハックは、作者の日常的な問題に対する 個人的な解決策として始まる。そしてその問題が、実は多数のユーザにも 典型的なものであるために広まる。これでルールその 1 の話に戻ってきた。 ただしもう少し便利な形で言い直してみよう。

18. おもしろい問題を解決するには、 まず自分にとっておもしろい問題を見つけることから始めよう。

　 Carl Harris とかれのかつての popclient もそうだったし、ぼくの fetchmail もそうだ。でもこれは長いこと理解されてきた。おもしろい点、つまり Linux と fetchmail の歴史がぼくたちの目をいやでも向ける点は、次の段階だ —— ユーザと共同開発者たちの巨大で活発なコミュニティがある中で、 ソフトがどう発展するかという話。

　『人月の神話』でフレッド・ブルックスはプログラマの時間が代替不能だと 看破している。遅れているソフト開発に開発者を加えても、開発はかえって遅れる。 プロジェクトの複雑さとコミュニケーションコストは、開発者数の 2 乗で増大するのに対し、終わる作業は直線的にしか増加しないというのが かれの議論だった。この論はそれ以来「ブルックスの法則」と呼ばれるに至り、 真実をついているものとだれもが考えている。 でもブルックスの法則が唯一無二の真理なら、Linux はあり得なかっただろう。

　数年後、ジェラルド・ワインバーグの古典『プログラミングの心理学』が、 いまにして思えばブルックスに対する重要な訂正だったものを提供してくれた。 「エゴのないプログラミング」を論じるなかでワインバーグが述べたのは、 開発者たちが自分のコードを私物化せず、ほかのみんなにバグを探したり改良点を 見つけたりするよう奨励するようなところでは、 ソフトの改善がほかよりも劇的にはやく生じる、ということだった。

　ワインバーグの分析がしかるべき評価を得なかったのは、 用語のせいかもしれない —— インターネットのハッカーたちを「エゴがない」 と呼ぶなんて、つい笑ってしまうではないの。 でも、かれの議論は今やかつてない説得力を持っている。

　UNIX の歴史を見れば、Linux から学びつつあるもの（そしてぼくが意図的に リーヌスの手法を真似ることで、実験的に小規模に確認したもの [EGCS]）は 見えていたはずなんだ。コーディングは基本的に孤独な活動だけれど、 真に偉大なハックはコミュニティ全体の関心と能力を動員することで 実現されるってこと。閉ざされたプロジェクトの中で、 自分の脳味噌だけを使う開発者は、オープンで発展的な文脈をつくりだして、 デザイン空間の探索やコードの貢献、バグつぶしなどの改善をもたらす フィードバックが何百人も（あるいは何千人も）から戻ってくるようにできる 開発者に負けてしまうんだ。

　でも従来の UNIX の世界は、このアプローチをとことんまでつきつめることが できなかった。要因はいくつかある。一つはいろいろなライセンスや商売上の秘密、 商業的な利害からくる法律上の制約。そしてもう一つは（いまにして思えば） インターネットがまだ発達しきってなかったことだ。

　安いインターネット以前には、いくつかの地理的に集中したコミュニティでは ワインバーグの「エゴのない」プログラミングが奨励されていた。そこでは開発者は、 有能なチェック屋や共同開発者を楽にたくさん集めることができた。 ベル研、MIT AI 研、UC バークレー —— こういうところは伝説的な技術革新を生み出したし、いまでも強力だ。

　Linux は、意識的かつ成功裏に全世界を才能プールとして 使おうとした最初のプロジェクトだった。Linux 形成期が、World Wide Web の誕生と同時期なのは偶然ではないと思うし、Linux が幼年期を脱したのが 1993-1994 年という、ISP 産業がテイクオフしてインターネットへの一般の関心が 爆発的に高まった時期と同じなのも偶然ではないだろう。 リーヌスは、拡大するインターネットが可能にした新しいルールにしたがって 活動する方法を見いだした、最初の人間だったわけだ。

　安いインターネットは、Linux モデルの発展にとっての必要条件ではあったけれど、 でもそれだけでは十分条件ではなかったと思う。もう一つの重要な要素は、 開発者が共同開発者を集めて、インターネットというメディアを 最大限に活かすためのリーダーシップのスタイルと、協力のための慣行が 開発されたことだろう。

　でもこのリーダーシップのスタイルとはなんで、その慣行ってのは どういうものだったんだろう。これは権力関係に基づくものではあり得ない —— あり得たとしても、脅しによるリーダーシップは、 いまぼくたちが目にするような結果を生み出しはしない。ワインバーグは、 19 世紀ロシアのアナキストであるクロポトキンの『ある革命家の回想』を引用して、 この点についていい議論を展開している。

「農奴を所有する一家に育ったわたしは、当時の若者たちみんなと同じように、 命令したり指令したり、叱りつけたり罰したりといった行動の必要性について、 まったく疑うことを知らぬままに成年に達した。しかしかなりはやい時期に、 わたしは大がかりな企業を経営することになり、自由な人々と交渉することになった。 そしてまちがい一つが重大な結果を招くような状況で、わたしは命令と規律という 原理にしたがって活動するのと、共通の理解という原理に基づいて行動するのとの差を だんだん理解するに至った。前者は軍隊のパレードでは見事に機能するが、 実生活において、目標が多くの重なり合う意志の真剣な努力によってしか 達成できないような状況では何の価値もない」

　この「多くの重なり合う意志による真剣な努力」は、まさに Linux のようなプロジェクトには必須 —— そして「命令という原理」は、 ぼくたちがインターネットと呼ぶアナキスト天国のボランティアたちに対しては、 実質的に適用不可能だ。効果的に活動して競争するには、共同プロジェクトを 仕切りたいハッカーは、クロポトキンが「理解の原理」で漠然と示唆しているモードを 使い、有益なコミュニティをリクルートしてやる気を起こさせる方法を 学ばなくてはならない。つまり、リーヌスの法則を学ばなくてはならないんだ。 [SP]

　まえにリーヌスの法則の説明として「デルファイ効果」が考えられると述べた。 でも、生物学や経済学に見られる適応型システムも、アナロジーとして強力だし 魅力もある。Linux の世界はいろんな意味で、自由市場や生態系のような動きを 見せる。自己中心的なエージェントがそれぞれ効用を最大化しようとして、 その過程で自己調整的な自律的秩序を生み出し、それはどんな中央集権計画の 何倍も複雑で効率が高くなる。だからこここそが「理解の原理」 を探すべき場所だ。

　Linux ハッカーたちが最大化している「効用関数」は、古典経済的なものではなく、 自分のエゴの満足とハッカー社会での評判という無形のものだ （かれらの動機を「愛他精神」と呼ぶ人もいるけれど、でもそれは、 愛他家にとっての愛他活動はそれ自体が一種のエゴの満足だという事実を 見落としている）。こういう形で機能するボランタリー文化は、実はそんなに 珍しいものじゃない。ぼくが長いこと参加してきたもう一つの例は、SF ファンダムで、ここはハッカー界とちがってボランティア活動の基本的な動機を はっきり「エゴブー」（他のファンたちの間で自分の評判を高めること） だと認識している。

　リーヌスは、開発そのものはほとんど他人にやらせつつ、うまいこと自分は プロジェクトの門番におさまった。そしてプロジェクトへの関心を育てて、 それが自立するようにしてきた。これはクロポトキンの「共通の理解という原理」 の鋭い把握を示している。このように Linux の世界を準経済学的に見てやると、 その理解がどのように適用されているか見て取れるだろう。

　リーヌスのやり方は、「エゴブー」の効率的な市場をつくりだす方法として見ると いいかもしれない。個々のハッカーたちの利己性を、協力体制を維持しないと 実現不可能なむずかしい目標に、できるだけしっかり結びつける方法だ。 Fetchmail プロジェクトで、ぼくは（もっと小規模にではあるけれど） かれの手法が再現できるものだということを示した。ぼくのほうが、 リーヌスよりもそれをちょっと意識的かつ体系的に行ったとは いえるかもしれない。

　多くの人（特に政治的な理由で自由市場を信用しない人たち）は、 自己中心的なエゴイストの文化なんか断片的で、領土争いばかりで、無駄が多く、 秘密主義的で、攻撃的にちがいないと考える。でもこの予想ははっきりと反証できる。 数多い例の一つをあげると、Linux 関連文書の驚くべき多様性と品質と詳細さがある。 プログラマたちはドキュメント作成が大嫌いというのは、 ほとんど神聖化された周知の事実とされている。だったら、なぜ Linux ハッカーたちはこんなにもたくさんの文書を生み出すんだろう。明らかに Linux のエゴブー自由市場は、商業ソフト屋さんのものすごい予算をもらった 文書作成業者たちよりも、気高さに満ちた他者をいたわる行動を生み出すうえで うまく機能するわけだ。

　Fetchmail と Linux カーネルプロジェクトがどちらも示しているのは、 ほかの多くのハッカーたちのエゴにきちんとごほうびをあげれば、 強力な開発者/コーディネータはインターネットを使って、 共同開発者がたくさんいるメリットを享受しつつ、プロジェクトが混乱しきった 修羅場に陥って崩壊するのは避けられる、ということだ。というわけで、 以下はブルックスの法則に対するぼくの反対提案：

19. 開発コーディネーターが、最低でもインターネットくらい 使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、 頭数は一つよりは多いほうが絶対にいい。

　フリーソフト（オープンソース・ソフト）の未来は、ますますリーヌスの やりかたを身につけた人たちのものになっていくと思う。つまり、 伽藍を後にしてバザール方式を受け入れる人たちのものだ。これは別に、 個人のビジョンと才能がもはやどうでもいいということではない。むしろ、 フリーソフト/オープンソースの最先端は、個人のビジョンと才能を出発点としつつも、 それをボランタリーな利害/興味コミュニティの構築によって増幅する 人々のものだと思う。

　そしてこれは、単に「フリー」ソフト（オープンソース・ソフト）だけの 未来像ではないのかも知れない。問題解決にあたって、Linux コミュニティが 動員できるほどの才能プールに太刀打ちできる商業デベロッパは存在しない。 Fetchmail に貢献してくれた 200 人以上を雇える財力を持つような デベロッパですら、ごくわずかしかいない！

　もしかすると、最終的にフリーソフト/オープンソース文化が勝利するのは、 協力が道徳的に正しいとかソフト「隠匿」が道徳的にまちがってるとかいう 理由のためではなく（ちなみに後者については、リーヌスもぼくもそうは思わない）、 単に商業ソフトの世界が、ある問題に有能な人々の時間を幾桁も多くそそぎ込める フリーソフト/オープンソース界と、進化上の軍事競争で張り合えなくなるから かもしれない。