伽藍とバザール

http://cruel.org/freeware/cathedral.html
を読み返してみましった〜www
19項目中★マークつけた10個ぐらいは心に刻めてきている気がしまっす〜www

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

みんなはどすか？