はやめにしょっちゅうリリースするのは、Ｌｉｎｕｘ開発モデルの重要な部分だ。ほとんどの開発者（含ぼく）は、プロジェクトがちょっとでも大きくなったら、こいつはまずいやり方だと考えていた。初期バージョンはその定義からいってバグだらけだし、ユーザーの我慢にも限度があるだろうから。
　この信念のおかげで、伽藍建設式の開発への関与も深まった。もし最優先課題が、できるだけ少ないバグしかユーザーにお目にかけないということだったら、うん、それならリリースは半年に一度とかにして（あるいはもっと間をおいて）、リリースの間は犬みたいにひたすらバグ取りに専念するだろう。
　（中略）

　７、はやめのりリース、ひんぱんなりリース。そして顧客の話をきくこと
　
　リーヌスの革新は、これをやったということじゃない（似たようなことは、もうながいことＵＮＩＸの世界の伝統になっていた）。それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。開発初期のあの頃だと、リーヌスが新しいカーネルを一日に何回もリリースすることだって、そんなに珍しくはなかった。そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく共同作業をする点で、ほかのだれよりも上をいっていた。それで、うまくいったわけだ。
　でも、具体的にどういうふうにうまくいってるんだろう。そしてそれはぼくでもまねできるものなんだろうか、それともリーヌスだけにしかない独特な才能に依存したものなんだろうか？
　そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ（完全な製品レベルのＯＳカーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね？）。でも、Ｌｉｎｕｘはとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリングのような、設計面での革新的天才ではないんだ（少なくともいまのところは）。むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、Ａ地点からＢ地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。Ｌｉｎｕｘの設計はすべて、この特徴が息づいているし、リーヌスの本賞的に地道で単純化するような設計アプローチが反映されている。
　じゃあ、もし急速リリースと、インターネットの徹底的な使い回しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的洞察の不可欠な的分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。
　こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー／ユーザーたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうぴは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。
　リーヌスは、デバッグと開発に投入される人・時間を最大化することを、ずばり狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザー基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。リーヌスの行動を見ていると、次のような信念を持っていたんじゃないかと思える。

　８、べー夕・テスターと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
　
　あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。
　はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。リーヌスはこれに異議を唱えて、問題を理解してそれをなおす人物は、必ずしもどころかふつうは、その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。そしてそれを理解するのはだれか別の人だよ。そして問題を見つけることのほうがむずかしいとぼくが述べたことは記録しておいてね）でも肝心なのは、見つけるのもなおすのも、だいたいすごく短期間で起きるってことだ。
　
　「オープンソースワールド」（川崎和哉著・翔泳社）の「伽藍とバザール」（エリック・Ｓ・レイモンド著）より
　原文は「The Cathedral and the Bazaar」
　http://www.tuxedo.org/~esr/writings/cathedral-bazaar/