GitHub and the Democratization of Programmingを読んで以来、オープンソースへの興味がつきないワタクシなのですが（遅いとか言うな）、エリック・S・レイモンドのオープンソース三部作をサラッとですが読んでみました（繰り返すが遅いとか言うな）。
本書はただのにっきのただただしさんがepub, mobi形式にして下記に設置してくれてますよっと。（ありがとうございます！）
http://tdtds.github.com/esr_trilogy_ja/
epub版をiPadで読んでみたのですが綺麗ですね、読みやすいですね。
マーキングしてメモも添付できるし。フォントサイズは好みのサイズに変えれるし。検索できるし。我が国の出版業界はいったいなにをモタモ(ry
さて書評・・というか読書メモ
本書では冒頭で
- 伽羅方式＝『一人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげる』方式
- バザール方式＝『はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする』方式
としたうえで、著者自身のバザール方式での成功体験とバザール方式の代表格であるLinuxの開発を例にとりながら、バザール方式を成功に導くための教訓とその利点を語っていきます。
教訓と利点は19箇条あげられています。これらは文中に散りばめられているのですが、たまに見返し、主旨が理解できなかった場合に本書の周辺部分を読み返すきっかけとするという目的もありまして、ここにまとめておきます。
- よいソフトはすべて、開発者の個人的な悩み解決から始まる。
- 何を書けばいいかわかってるのがよいプログラマ。なにを書きなおせば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
- 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章）
- まともな行動をとってれば、おもしろい問題の方からこっちを見つけだしてくれる。
- ある仕事に興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
- ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
- はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと。
- ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
- 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
- ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
- いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
- 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
- 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
- ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
- ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
- 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
- セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
- おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
- 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数はひとつより多いほうが絶対にいい、
本書を一読するに、バザール方式の1番のメリットはデバッグでして、その効果については下記のように記述されています。
8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。
はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。リーヌスはこれに異議を唱えて、問題を理解してそれをなおす人物は、必ずしもどころかふつうは、その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。そしてそれを理解するのはだれか別の人だよ。そして問題を見つけることのほうがむずかしいとぼくが述べたことは記録しておいてね」。でも肝心なのは、見つけるのもなおすのも、だいたいすごく短期間で起きるってことだ。
(省略)プロジェクトの始めから、ぼくは他の開発者なら死んでもいいと思うような質の高いバグレポートをもらったし、しかもそれになかなかいいフィックスまでついてきた。よく考えられたコメントももらったし、ファンレターもきたし、賢い機能の提案ももらった。これでわかるのが：
10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる
バザール方式のキモがソースをオープンにすることではなく、十分なサイズのベータテスタと共同開発者を得ることなのであれば、商業目的のソフトウェア開発でも充分に活用できる組織像なのではないかと思うのです。
対内的にはモチベーションドリブンのソフトウェア開発、対外的には高い素早いバグフィクス。
あとは開発者とユーザを惹きつける魅力的なプロダクトと、
バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしているだろう。バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのはすごくむずかしいだろう。リーヌスはそんなことはしなかったし、ぼくもしなかった。あなたが生み出そうとしてる開発者コミュニティは、いじるために何か動いてテストできるものを必要としているんだ。
カリスマエンジニアですか。
コーディネーターが、とてつもないデザイン上のひらめきを自分で得る必要性は必ずしもないと思う。でも、絶対に必要なのは、その人物がほかの人たちのよいデザイン上のアイデアを認識できるということだ。
別の才能で、ソフト開発とはふつうは関連づけられないけれど、でもバザールプロジェクトではデザイン上の才覚に匹敵するほど——あるいはそれ以上——重要なものがあると思う。バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。
これは説明するまでもないだろう。開発コミュニティをつくるには、人を引きつける必要がある。自分のやっていることに興味を持たせて、各人のやっている仕事量についてみんなが満足しているように気を配る必要がある。技術的な先進性は、これを実現する役にはおおいに立つけれど、でもそれだけではぜんぜん足りない。その人が発する個性も大事だ。
最後に
受託だ自社開発だ、起業だフリーランスだ、といろいろな働き方が論じられる昨今ではありますけど、私自身がやりたいのはモチベーションドリブンなソフトウェア開発なのだなと、気づきつつある昨今なのであります。（曖昧模糊！）