はやめにしょっちゅうリリースするのは、Linux 開発モデルの重要な部分だ。 ほとんどの開発者（含ぼく）は、プロジェクトがちょっとでも大きくなったら こいつはまずいやり方だと考えていた。初期バージョンはその定義からいって バグだらけだし、ユーザの我慢にも限度があるだろうから。

　この信念のおかげで、伽藍建設式の開発への関与も深まった。もし最優先課題が、 できるだけ少ないバグしかユーザにお目にかけないということだったら、 うん、それならリリースは半年に一度とかにして（あるいはもっと間をおいて）、 リリースの間は犬みたいにひたすらバグ取りに専念するだろう。Emacs の C の核部分はこういう形で開発された。Lisp ライブラリは、事実上ちがっていた。 FSF のコントロールのきかない活発な Lisp アーカイブがあって、そこにいけば Emacs のリリースサイクルとはまったく関係ない、新しい開発コードが 手に入ったから。[QR]

　こういうアーカイブのいちばん重要なものの一つは、オハイオ州立大の elisp アーカイブでここは今日の大きな Linux アーカイブの精神や特徴の多くを 先取りしたところだった。でも、自分たちがなにをしているのかしっかり 考えてみた者はほとんどいなかったし、このアーカイブの存在自体が、FSF 式の伽藍建設型開発モデルの問題点についてなにを示唆しているのかについても あまり考えなかった。1992 年頃、ぼくはオハイオのコードの相当部分を正式に 公式 Emacs Lisp ライブラリに組み込もうとして、かなりまじめに取り組んだ。 でも政治的な問題にぶちあたって、ほとんどうまくいかなかった。

　でもそれから一年たたないうちに、Linux がかなり目に見えて広まってくると、 なにかちがった、ずっと健全なことが起こっているのははっきりしてきた。 リーヌスのオープンな開発方針は、伽藍建設の正反対のものだった。Sunsite （現metalab）や tsx-11 のアーカイブは はちきれそうで、パッケージもどんどん登場してきた。そしてそのすべてが、 前代未聞の頻度でリリースされるコアシステムに動かされていた。

　リーヌスはいちばん効果的なやりかたで、ユーザたちを共同開発者として 扱っていたことになる：

7. はやめのリリース、ひんぱんなリリース。 そして顧客の話をきくこと

　リーヌスの革新は、これをやったということじゃない（似たようなことは、 もうながいこと UNIX の世界の伝統になっていた）。それをスケールアップして、 開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていった ということだった。開発初期のあの頃だと、リーヌスが新しいカーネルを 一日に何回もリリースすることだって、そんなに珍しくはなかった。 そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく 共同作業をする点で、ほかのだれよりも上をいっていた。 それでうまくいったわけだ。

　でも、具体的にどういうふうにうまくいってるんだろう。 そしてそれはぼくでもまねできるものなんだろうか、それとも リーヌスだけにしか ない独特な才能に依存したものなんだろうか？

　そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ （完全な製品レベルの OS カーネルをつくりあげられる人間が、ぼくたちのなかで どれだけいるね？）。でも、Linux はとんでもないソフトウェア思想上の進歩を 取り込んだりはしていない。 リーヌスは、たとえばリチャード・ストールマンとか ジェームズ・ゴスリング（NeWSとJavaで有名）のような、設計面での革新的天才では ないんだ（少なくともいまのところは）。むしろリーヌスはエンジニアリングの 天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、A 地点から B 地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。Linux の設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で 単純化するような設計アプローチが反映されている。

　じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが 偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の 天才的洞察の不可欠な部分だったんなら、かれが最大化しているのは 何だったんだろう。 この仕組みからかれがひねりだしているのはなんだったんだろう。

　こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、 ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。 刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、 ごほうびは、自分たちの仕事がたえず（まさに毎日のように） 進歩している様子だ。

　リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり 狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグが どうしようもなくなったら、ユーザ基盤に見放されるかもしれないという 危険をおかしてまでそれをやっていた。リーヌスの行動を見ていると、 次のような信念を持っていたんじゃないかと思える：

8. ベータテスタと共同開発者の基盤さえ十分大きければ、 ほとんどすべての問題はすぐに見つけだされて、 その直し方もだれかにはすぐわかるはず。

　あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、 どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。

　はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」 という書き方をしていた。リーヌスはこれに異議を唱えて、 問題を理解してそれをなおす人物は、必ずしもどころかふつうは、 その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。 そしてそれを理解するのはだれか別の人だよ。 そして問題を見つけることのほうがむずかしいとぼくが述べたことは 記録しておいてね」。でも肝心なのは、見つけるのもなおすのも、 だいたいすごく短期間で起きるってことだ。

　ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。 伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、 潜伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、 少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も 開いてくるし、長く待たされたリリースが完璧じゃないときには、 どうしても失望も大きくなる。

　一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという 前提にたつことになる —— 少なくとも、リリースを一つ残らず、 千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、 どんなバグも早々に浮上してくると考える。よって、 たくさんなおしてもらうためにリリースも増やすし、 有益な副作用としては、ときどきヘマが出回っちゃっても、 あんまり失うものは大きくないってわけ。

　そして、これがすべてだ。これだけで必要十分。 もしリーヌスの法則がまちがってるなら、Linux カーネルほど複雑なシステム、 Linux カーネルくらいみんながよってたかってハッキングしてるようなシステムは、 どこかの時点でまずい相互作用や、発見できない「深い」バグのせいで 崩壊してたはずなんだ。一方、もしリーヌスの法則が正しければ、 これで Linux が相対的にバグが少ないことを十分説明できる。

　そしてこれは、そんなに驚くべきことでもなかったのかもしれない。 社会学者たちは何年も前に、同じくらいの専門家（あるいは同じくらい無知な人たち） の意見の平均は、そういう観察者の一人をランダムに選んで意見をきくよりも、 予測精度がかなり高いことを発見している。これをかれらは「デルファイ効果」 と呼んだ。どうやらリーヌスが示したのは、これが OS のデバッグにも適用できるってことみたいだ。つまりデルファイ効果は、OS カーネル級の複雑なものでも、開発上の複雑さをおさめることができるんだ。

　Linux の場合の特別な性格で、デルファイ効果的な形でとても役にたっているのは、 どんなプロジェクトでもその貢献者は自薦だということだ。 初期にコメントをくれた人が指摘してくれたことだけれど、貢献は、 ランダムなサンプルから出てくる訳じゃなくて、そのソフトを使うだけの興味を 持って、その仕組みを学び、出くわした問題への解決を探そうとして、 まあまともそうな解決策を作るだけのことをした人から寄せられる。 これだけのフィルタを全部突破してくる人は、貢献できるだけのものは持っている 可能性がかなり高い。

　Jeff Dutky <dutky@wam.umd.edu> は、リーヌスの法則は 「デバッグは並列処理可能だ」と言い換えることもできると指摘してくれた。 感謝したい。Jeff の知見では、デバッグするにはデバッガは開発コーディネータと 多少のやりとりは必要だけれど、デバッガ同士では大した調整は必要ない。 だから、開発者を加えることで発生する、幾何級数的な複雑性と 管理コスト増大という問題には直面しないですむというわけだ。

　実際問題として、デバッガたちの作業重複によって生じる理論的な無駄は、Linux の世界ではほとんど問題にされないようだ。「はやめしょっちゅうのリリース」 の効果の一つとして、すでにフィードバック済みのバグフィックスをすばやく 広めることでそういう重複をなくせるということがある。 [JH]

　ブルックスは、すでに Jeff の見解に関連したような観察をなにげなく述べてる。 「広範に使われるプログラムをメンテナンスするコストは、 おおむねその開発コストの 40 ％だ。驚いたことに、このコストはユーザ数に 大きく左右される。ユーザが増えると見つかるバグも増えるのだ」 （強調筆者）。

　ユーザが増えると見つかるバグも増えるのは、ユーザを追加することで、 プログラムをもっといろんな方法で叩いてみることができるからだ。この効果は、 そのユーザたちが共同開発者でもある場合にはさらに増幅される。各人が、 ちょっとずつちがったものの見方と分析用ツールキットをもって、その任に当たる。 「デルファイ効果」はまさにこの多様性のためにうまく機能するらしい。 デバッグという分野に限った話をすると、この多様性のおかげで試みが 重複する機会も減るらしい。

　だからベータテスタの数を増やしても、開発者側の立場からすれば 目下の「一番深い」バグの複雑さが減るわけではないけれど、 でもだれかのツールキットがその問題にうまくマッチして、 その人にとってはそのバグが深刻ではないという可能性を 増してくれるわけだ。

　リーヌスも、そこらへんは抜け目なくやってる。 万が一本当に深刻なバグがあったときのために、Linux カーネルのバージョンのナンバリングには工夫がある。ユーザ候補は、 「安定」とされたカーネル最新版を使うか、最先端にいって、 新しい機能を使うかわりにバグの危険をおかすか、という選択が できるようになってる。この戦術は、ほかの Linux ハッカーたちはまだ正式に 採用していないけれど、でも採用されるべきかもしれない。 選択肢があるというのは、魅力を増すから。