Previous Next Contents


4。はやめのリリース、しょっちゅうリリース

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Previous Next Contents