従来の「伽藍」方式から見ると、カオスな「バザール」方式の客観的観察。「はやめにしょっちゅうリリース」「乱交まがいになんでもオープン」「でかい騒がしいバザールに似ている」。市場のように開かれている、誰でも参加可能。文中の教訓を抜粋よいソフトはすべて、開発者の個人的な悩み解決から始まる。何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。捨てることをあらかじめ予定しておけ。いやでも捨てることになるんだから(フレッド・ブルックス『人月の神話』第11章)まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。はやめのリリース、ひんぱんなリリース。顧客の話をきくことベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。「完成」(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと!自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。カーネル構築そのものではないと思う。開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。登場人物の一人について書いた有名な表現にならえば、「失敗するには怠惰すぎる」。カーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね?)。ないソフトウェア思想上の進歩を取り込んだりはしていない。なくともいまのところは)。リーヌスはエンジニアリングの天才なんじゃないかと思う。地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。いう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず(まさに毎日のように)進歩している様子だ。意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。した新しいルールにしたがって活動する方法を見いだした、最初の人間だったわけだ。オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。いうのがあり、意味が分からなかった。contributors「はじめての貢献に良い問題です。」という「プロジェクトへ参加するなら。これが適しているよ」のラベルだった。デフォルトのラベルを一覧しておく。