開発プロセスとしての伽藍とバザール
わかりやすく、21世紀現在の言葉で、伽藍とバザールという対比を現実社会に当てはめると、もっとも近いものは、ウォーターフォールvsアジャイル だ。
artonさんが述べているように、伽藍とバザールは、OSSのアジテーション文書とかハッカー賛美の書ではなく、実際にはESRがFetchMailの開発をすることによって得たバザール方式開発プロセス*1のプラクティスを紹介するエッセイです。
コードをオープンにすることは必要条件であって十分条件ではない。コードをオープンにすることは、それ自体が目的じゃなくて素敵なソフトウェアを自然につくるための手段にすぎない*2。一般的な開発者の数百倍の生産性をたたき出すハッカー賛美などはどこにも無い。
いくつか興味深い部分をピックアップしてみましょう。
6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
これは、XPなどの開発プロセスのオンサイト顧客とほぼ同等です。
11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
これも、XPやScramにおける顧客の考え方とそんなに変わらない。
7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
これも当然というかソフトウェアをつくる上ではもっとも自然な発想ですね*3。
また、UNIX哲学に基づいた設計に関する記述も多く、そういう視点で文章をピックアップしても興味ぶかいです。
Linux の手法や成功の前例は GNU Emacs の Lisp ライブラリと Lisp コードアーカイブの開発にみることができる。Emacs の C のコア部分やその他 FSF ツールみたいな、伽藍建築方式にくらべると、Lisp コードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで 3 回も 4 回も書き直されるのがしょっちゅうだった。そして Linux と同じく、インターネットが可能にしたゆるい協力体制もしばしばとられていた。
動的な言語が、開発の進化をもたらす理由について述べている、と思います。またコア部分はC言語で伽藍方式で手堅くつくって、スクリプト言語でコミュニティで拡張機能をつくるという、多言語プログラミング(polyglot programming)の考え方の片鱗も見ることができます。
これはそもそも、ある晩遅くにちょっと始めた実験が発端だった。rc ファイルの宣言が、命令形のミニ言語にずいぶん似てきたのに気がついたのだ（そしてこのせいで、もとの popclient のキーワード「サーバ（server）」を「チェックせよ（poll）」に変えた）。
この命令形のミニ言語をもっと英語風にしてみたら、使いやすくなりそうだと思った。さて、ぼくは Emacs や HTML や各種データベースエンジンに代表される「なんでも言語化せよ」式デザイン派閥の意識的な急進派ではあるけれど、通常は「英語っぽい」構文はふつう、あまり好きじゃない。
今っぽくいえば、DSLに関する記述です。*4
9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
ここらへんも興味深いです。
以下は伽藍とバザールで紹介している開発プロセスと他の開発プロセスとの違いを強調する部分だと思います。
18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
プラクティスや原則に先立つ価値を「おもしろさ」に置くというのは、すごくおもしろいです。
伽藍とバザールが単なる開発プロセスの紹介ではなく面白いエッセイなのは、ESRがfetchmailというソフトウェアの開発を意図的にバザール方式で行い、そこで得た知見を生き生きと楽しそうに(自慢を交えながら)語っているところでしょう。
