伽藍方式とバザール方式

・UNIX時代の開発は中央集権的で少数の精鋭により伽藍のごとく作られる必要があると考えることが多かった

・LINUXはこれとは違いリリース速度、分散型のアプローチで開発されていた（バザールのよう）

・バザール型の開発は安定したシステムの構築を果たせるとは到底思われていなかった
→ むしろ今は分散型やアジャイル開発などが重視される傾向がある

・SLIP接続：シリアル・ライン・インターネット・プロトコルの略、ホストとの接続がなく電話回線とモデムを経由してインターネットに接続する企業向けのインターネット接続プロトコルのこと、現在ではPPPに代替される

・PPP接続：Point-to-Point Protocolの略、2点間を接続してデータ通信を行うための通信プロトコル

「よいソフトはすべて、開発者の個人的な悩み解決から始まる。」

・LINUXはお金ではなく自信が欲しいと思えるものを作る意志を持った集団によりつくられた

「何をかけばいいか分かっているのが良いプログラマ。何を書き直せば（そして使いまわせば）いいか分かっているのがすごいプログラマ」

・DRYの原則

・すごいプログラマの大事な特徴の一つが建設的な面倒くさがり

・評価は努力ではなく結果でのみということをわかっている

・LINUXも真っ白からのスタートではなくMinixのコードを再利用するところからスタートしている

・結局再利用部分は書き直されることとなっても地盤となっている

・再利用性はLINUXの場合とても高い（OSS精神の高いコミュニティ）

「捨てることをあらかじめ予定しておけ。どうせいやでも捨てることとなるんだから」

・1回解決策を実装してみるまでは問題を完全には理解し切れない

・やり直す覚悟を持たないとダメ

・コンポーネント作成も同じ意識で取り組むべきと再認識

「まともな行動をとってれば、おもしろい問題のほうからこっちを見つけ出してくれる」

・とりあえず手を動かして見ようぜ的なことと自己解釈

「あるソフトに興味を失ったら、最後の仕事としてそれを有能な後継者に引き渡すこと」

・よく聞く後継者問題だなといった感じ

・いつの時代も悩みの種なのか、、

ユーザーは大事な財産

・きちんとソフトを育て上げればユーザーは共同開発者となっていく

・そうなれば一人でやるよりも早く適切なアプローチが出来るようになる

「ユーザーを共同開発者として扱うのは、コードの高速改良と効率よいデバックの一番楽ちんな方法」

・ユーザー数が増えるごとにこの効果は上昇する

・リーナスの特出すべきはLINUXカーネルの構築ではなくLINUX開発モデルの構築である

・思想を作って動くのは周囲（怠惰）

・社内でも共同作業の有益性はやはり高そう（ペアプロ）

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

・LINUX開発モデルの重要部分

・伽藍方式は慎重なリリース

・バグだらけだとユーザーが困るでしょ

・バザール方式はユーザーが機能すれば高い更新頻度でブラッシュアップされていく

「はやめのリリース、ひんぱんなリリース。そして顧客の声を聴くこと」

・バグや開発上の袋小路を避ける第六感とA 地点からB 地点にたどりつく一番楽な道を見つけだす真の直感

・この思想がLINUXコミュニティの中に根付いている

・ユーザーを盛り立てる仕組みもある
→ コミュニティの一員であることの誇り、改善が進歩に役立っている
→ ユーザーによる貢献を最大化させた

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

・問題を見つけるのも直すのもかなり短期間のサイクルで起きる

・伽藍式とバザール式の違いはここにあるしバザール式の肝がある

・伽藍式はバグや開発上の問題は根深いこと
→ 全ての問題を解決したと確信できるのは多くの時間がかかる
→ リリース間隔も大きくなる、

・バザール式はバグありきで短期的なリリースを主眼に置く
→ バグはコミュニティの中で早々に発見され、修正とリリースのサイクルができる

・デルファイ効果が働く
→ 観察者の一人の意見より同じくらいのレベルの専門家複数人の意見の平均の方が予測精度が高い

・デバックは並列処理可能である
→ バグフィックスの速度が早ければ重複の問題が起こる可能性を抑えられる

・ユーザーが増えれば見つかるバグの数も増える

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし

「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。データ構造さえ見せてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから」

・大事なのは思想やモデルの部分であり、コードなどではない

・ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる

自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある

・古い機能や既存の機能は捨て去る可能性があるもしくは捨てるべきであることを頭の片隅に置いておく

・自分の実装が正しいかどうかはあまり自己認識できないから意見をもらったりする上で、もっと良くなる方法がないか探求する気持ちを持つようにしたい

「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき

・結構ハッとした部分

・無駄のないものが完成品という意識は持っていなかった

・おそらく自分のコードはここが甘い

・シンプルかつ無駄のない構成、コードになっているか？