ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方も誰かにはすぐわかるはず。もっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。
「だれかが問題を見つける。そしてそれを理解するのは誰か別の人だよ。そして問題を見つけることのほうが難しいとぼくが述べたことは記録しておいてね」。でも肝心なのは、見つけるのも直すのも、だいたいすごく短期間で起きるってことだ。
ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。
伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、潜伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。
一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを一つ残らず、千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。よって、たくさんなおしてもらうためにリリースも増やすし、有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。