書評というか，インターネット状で読める論文ですす．

伽藍とバザール(The Cathedral and the Bazaar)
http://cruel.org/freeware/cathedral.html

　存在は知っていましたが，今回初めて読んでみました．
　ソフトウェア開発に関する論文で，著者自身がオープンソースのソフトウェアの開発者で，この論文を元に当時のNetscape Communications社がNetscape Naviatorのオープンソース化を決めた切っ掛けを作ったものと言われています．

　伽藍（がらん）とは，「僧が集まり住んで、仏道を修行する、清浄閑静な場所。」の意味ですが，この論文の中では「これまでの開発手法」として挙げられています．　限られた者だけで開発が行われ，完成するまでは公開されないという意味です．

　対してバザールとは，複数の者で開発される手法とされており，この論文ではLinuxのとった開発手法をその成功例として記してあります．　一言で言うと「早めのリリース。しょっちゅうリリース」となります．

　翻訳文書に出てくる，教訓的な部分だけ，ピックアップしてみました．　振り返ると，納得する部分が多いなぁと，思います．．．

1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。
2. 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから
4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
12. 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
13. 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
14. ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
15. ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
17. セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
19. 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。