[本] 伽藍とバザールを読む

伽藍とバザールを読んでみた。　重要そうな点をついでに要約してみました(ﾉ∀｀)

Linuxは、ぼくがわかっているつもりでいたものを、大幅にひっくりかえしてくれた。それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといったUnixの福音は説き続けてはいた。でももっと上のレベルでは何かどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。一番だいじなソフト（OSや、Emacsみたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメで、一人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげるべきもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。
だからLinus Torvaldsの開発スタイル――はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――にはまったく驚かされた。静かで荘厳な伽藍づくりなんかない――Linuxコミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった（これをまさに象徴しているのがLinuxのアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう）。そしてそこから一貫した安定なシステムが出てくるなんて、奇跡がいくつも続かなければ不可能に思えた。

1。よいソフトはすべて、開発者の個人的な悩み解決から始まる。
これは自明のことかもしれない（昔から「必要は発明の母」って言うし）。でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし好きでもないようなソフトを一日中シコシコ書いてることがあまりに多いんだ。でも、Linuxの世界ではちがう ――Linux界出身ソフトの質が、平均してすごく高いのはこのせいかもしれないね。

2。何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
――だからね。すごいプログラマを気取るつもりはないけど、でもそのまねくらいはしたい。すごいプログラマの大事な特徴の一つが、建設的な面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、そのための努力じゃないってのがわかってるってこと。そして白紙から始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。

3。捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（Fred Brooks『人月の神話』 1）

4。まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
でも Carl Harrisの行動のほうがもっと大事だ。かれが理解していたこと：
5。あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。

3。ユーザは大事な財産
これまたUnixの伝統の強みで、これまたLinuxがみごとに極限までおしすすめる強みでもあるんだけれど、ユーザの中にもハッカーがたくさんいるわけだ。そしてソースコードが公開されてるから、かれらは同じハッカーでも役に立つハッカーになってくれる。これはデバッグ時間短縮にはすごく役に立つ。ちょっと励ますだけで、ユーザが問題を診断し、直し方を提案してくれて、一人でやるよりずっとはやくコードを改善できるようにしてくれる。
6。ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
この効果の力はすごく見落としがち。はっきり言って、ぼくらフリーソフト界のほとんどだれもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そしてそれがシステムの複雑さに対してどれほど有効に機能するかについて、まったく見えてなかった。Linusが目を開いてくれるまでは。

はっきり言って、ぼくはLinusのいちばん賢い、影響力あるハッキングというのは、Linuxのカーネル構築そのものではないと思う。むしろ Linux開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。あるいはロバート・ハインラインなら「失敗するには怠惰すきる」とでも言っただろうね。
ふりかえってみると、Linuxの手法や成功の前例はGNU Emacsの Lisp ライブラリとLispコードアーカイブの開発にみることができる。Emacs のCのコア部分やその他FSFツールみたいな、伽藍建築方式にくらべると、Lispコードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで 3回も4回も書き直されるのがしょっちゅうだった。そしてLinuxと同じく、インターネットが可能にしたゆるい協力体制もしばしばとられていた。

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

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

9。賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
またもやFred Brooks本の第11章から。「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。データ構造さえみせてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから」

11。いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
おもしろいことに、もし自分が他人に負うところがいかに大きいかについて、完全かつ謙虚なくらいに正直でいたら、世の中はその発明が全部あなた自身のもので、単に自分の天才ぶりについて謙遜しているだけだと見なしてくれる。

12。もっとも衝撃的で革新的な解決策が、自分の問題のとらえかたがそもそも間違っていたという認識からくるということはよくある。
13。「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
14。ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
15。ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
16。自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。

18。おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
Linusは、開発そのものはほとんど他人にやらせつつ、うまいこと自分はプロジェクトの門番におさまった。そしてプロジェクトへの関心を育てて、それが自立するようにしてきた。これはクロポトキンの「共通の理解という原理」の鋭い把握を示している。このように Linuxの世界を準経済学的に見てやると、その理解がどのように適用されているか見て取れるだろう
多くの人（特に政治的な理由で自由市場を信用しない人たち）は、自己中心的なエゴイストの文化なんか断片的で、領土争いばかりで、無駄が多く、秘密主義的で、攻撃的にちがいないと考える。でもこの予想ははっきりと反証できる。数多い例の一つをあげると、 Linux関連文書の驚くべき多様性と品質と詳細さがある。プログラマたちはドキュメント作成が大嫌いというのは、ほとんど神聖化された周知の事実とされている。だったら、なぜLinux ハッカーたちはこんなにもたくさんの文書を生み出すんだろう。明らかに Linuxのエゴブー自由市場は、商業ソフト屋さんのものすごい予算をもらった文書作成業者たちよりも、気高さに満ちた他者をいたわる行動を生み出すうえでうまく機能するわけだ。