伽藍とバザール
The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary
著者Eric S. Raymond
訳者山形浩生
イラストLiubov S. Popova
発行日1999
発行元O'Reilly Media
ジャンル
ノンフィクション、随筆 オープンソース、ソフトウェアリリースライフサイクル、トップダウン設計とボトムアップ設計
国アメリカ合衆国
言語英語
形態著作物
ページ数241
次作ノウアスフィアの開墾
公式サイト ⇒www.catb.org
コードISBN 978-1565927247
ISBN 978-4904807026(日本語訳版)
『伽藍とバザール』(がらんとバザール、英: The Cathedral and the Bazaar、カテドラルとバザール)は、エリック・レイモンドによって書かれたオープンソースソフトウェア(OSS)のソフトウェア開発方式に関するエッセイおよび書籍である[1]。
当記事では、Cathedralの訳語に伽藍、Bazaarの訳語にバザールを使用する。訳語については、「Cathedral」の日本語訳の節を参照されたい。
伽藍方式としてGNU Emacsの開発スタイル、バザール方式としてLinuxカーネルの開発スタイルとFetchmailのマネージメント経験を挙げ、ソースコードを常時公開して多くの利用者・開発者がソフトウェア開発に携わる開発手法のメリットを主張している(「ソースコードを常時公開して多くの利用者・開発者がソフトウェア開発に携わっている」、という点はGNU Emacsでも後者と全く同じである。従って主張されているメリットは、「伽藍方式」と「バザール方式」の違いのうち、それとは異なる点に由来する)。 1997年5月27日、ドイツのヴュルツブルクで開催されたLinux Kongressで講演の形で発表された。その後、1999年に書籍として出版された。原作書籍の表紙に描かれているイラストは、トレチャコフ美術館所蔵のリュボーフィ・ポポーワによる1913年の絵画『Composition with Figures』である[2]。エッセイは2000年前後以降よりOpen Publication License 2.0の下で公開されている[1]。日本語翻訳版は山形浩生が1999年に執筆し、オープンコンテント相当の制約で公開されている。 本書はオープンソース4部作となる『伽藍とバザール』『ノウアスフィアの開墾
歴史
さまざまなソフトウェア開発の取り組みから学んだバザール方式の19の教訓を挙げ、それぞれがオープンソースソフトウェア開発における優れた開発手法に関する題目を述べている[1]。 1998年、ネットスケープコミュニケーションズがNetscape Suiteのソースコードを公開することを後押しをして、Netscape SuiteがMozilla Application Suiteとして生まれ変わることとなった[3][4][5]。
バザール方式の教訓
全ての良いソフトウェアは開発者の個人的な希望から始まる。
良いプログラマは何を書けば良いか知っている。凄いプログラマは何を書き直せば・何を再利用すれば良いか知っている。
破棄する計画を立てる。いずれにせよ、そうすることになる。[注釈 1]
適切な取り組みをしていれば、おかしな問題は自発的に主張してくる。
ソフトウェアに興味がなくなった時には、ソフトウェアを手放して優秀な後継者に引き継ぎする。
利用者を共同開発者として扱うことは迅速な実装改善と効率的なデバッグの最短ルートである。
素早く頻繁なリリース
十分なベータテスターと共同開発者の基盤があれば、大半の問題はすぐに特定されて誰かが直す。
賢いデータ構造と愚かなソースコードは、その逆であるよりずっと良い成果を出す。
あなたがベータテスターを最も有益な資産として扱うなら、彼らは最も有益な資産となり応えてくれる。
次の最適案は利用者による良いアイディアに気付かされる。後から出たアイディアの方が良いこともある。
大半の衝撃的で革新的な解決策は自身の問題の捉え方が間違っていることに気付くことから始まる。
完璧な設計はそれ以上の追加することがなくなった時ではなく、それ以上の削減することがなくなった時である。[注釈 2]
全てのツールは想像通りに便利であるべきであるが、本当に凄いツールは作者の想像を越えた便利さを与える。
どんなゲートウェイソフトウェアを実装する場合でも、データストリームへの影響は可能な限り最小限に抑え、受け手が強制しない限りはデータを決して破棄しない。
自分の書き方がチューリング完全から外れているなら、シンタックス・シュガーは手助けになる。
セキュリティシステムのセキュリティはそれが秘密である時だけ意味を成す。見掛けのセキュリティには注意すること。
おかしな問題を解決することは、おかしな問題を探すことから始まる。
開発コーディネーターが少なくともインターネットと同等に良質な交流手段を持って圧力をかけない先導手法を知っているなら、必然的に頭数は多い方が良い。
受容と影響