伽藍とバザール

オープンソースのソフトウェア開発に関するエッセイないしは書籍

で、バザールの方が優れてるよって論調

どんな優れたソフトウェアも、開発者の個人的な痒いところに手が届くところから始まります。

優れたプログラマーは、何を書くべきかを知っています。優れたプログラマは何を書き直すべきか(そして再利用すべきか)を知っている。

1つのバージョンを捨てるつもりで、とにかく捨てるのだ(フレデリック・ブルックスの「神話上の人月」からのコピー)。

正しい姿勢でいれば、面白い問題は必ず見つかる。

プログラムに興味がなくなったら、有能な後継者に譲ることがプログラムに対する最後の義務である。

ユーザを共同開発者として扱うことは、迅速なコードの改善と効果的なデバッグのための最も手間のかからない方法です。

早くリリースする。頻繁にリリースする。そして、顧客の声に耳を傾けることです。

十分な数のベータテスターや共同開発者がいれば、ほとんどすべての問題は迅速に特定され、その修正方法は誰かにとって明白なものとなるでしょう。

賢いデータ構造と馬鹿なコードの組み合わせは、その逆よりもずっとうまくいくのです。

もしあなたがベータテスターを最も貴重な資源であるかのように扱えば、彼らはあなたの最も貴重な資源となり、応えてくれるでしょう。

良いアイデアを持つことの次に良いことは、ユーザーからの良いアイデアを認めることです。時には後者の方が良い場合もあります。

多くの場合、最も印象的で革新的な解決策は、問題に対する自分のコンセプトが間違っていたことに気づくことから生まれます。

デザインにおける完璧さとは、これ以上加えるべきものがないときではなく、これ以上取り去るべきものがないときに達成される。(アントワーヌ・ド・サン＝テグジュペリの言葉）

どんな道具でも、期待通りの使い方ができるはずだ。しかし、本当に優れた道具は、予想外の使い方をするものである。

逆説的に、予想外の使い方がされる余地が多い方がいい

どんな種類のゲートウェイソフトウェアを書くときでも、データの流れをできるだけ乱さないように苦心し、受信者が強制しない限り情報を捨てないようにしましょう

言語がチューリング完全でない場合、構文解析があなたの味方になります。

「言語」は何をさしている？

開発者が使うプログラミング言語？

開発者が製品に入れようとしているスクリプト機構とかの話？

セキュリティシステムは、その秘密が安全である限りにおいてのみ安全である。擬似的な秘密には気をつけよう。

面白い問題を解くには、まず自分にとって面白い問題を見つけることから始めましょう。

開発コーディネーターが少なくともインターネットと同程度の通信媒体を持ち、強制せずに導く方法を知っていれば、必然的に頭は1つよりも多い方が良い。

Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

provideは仮定法だよな

andも仮定法に繋がってる

要するに「非同期と自律」で働ける手段があるなら、マネージャ的ポジションは1人じゃない方がいいぞってこと？

---

昔なのにすげえ本質突いてるよな

今でいうアジャイルの原則（素早くつくって回せ

顧客大事

結局は面白さや興味駆動なのよ的な点