「伽藍とバザール」を読んだ

投稿時刻2024年1月15日 18:43

「伽藍とバザール」を 2,024 年 01 月 15 日に読んだ。
Amazon では現在の価格は 7,594 円となっている。

目次

メモ

概要 p8

この論文ではまず、大成功したフリーソフトやオープンソースプロジェクトのフェッチメール (feochmail) を分析する。
このソフトは、リナックス (Linux) の歴史から導かれる、ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。

本論ではその理論を、二種類の根本的にちがった開発スタイルという形で論じている。

一つは FSF (Free Software Foundation) やその真似っ子たちの「伽藍」モデルで、それに対するのがリナックス界の「バザール」モデルだ。
この二つのモデルが、ソフトのデバッグ作業の性質に関する、正反対の前提からそれぞれ生じていることを示す。

続いてリナックス体験に基づき、「目玉の数さえ十分あれば、どんなバグも深刻ではない」という仮説を支持する議論を展開し、利己的エージェントによる自己修正システムとの有益な対比をしてみる。
そして、この洞察がソフトウェアの未来に対して持つ意味について、いくつか考察を行って結論としている。

伽藍方式とバザール方式 p9

リナックスは破壊的存在なり。
インターネットのかほそい糸だけで結ばれた、地球全体に散らばった数千人の開発者たちが片手間にハッキングするだけで、
超一流のOSが魔法みたいに編み出されてしまうなんて、ほんの五年前でさえ、だれも想像すらできなかったんだから。

ぼくもできなかった。
リナックスがぼくのレーダー画面に泳ぎ着いたのは一九九三年の初頭だったけれど、その頃ぼくはすでにユニックス (Unix) やフリーソフト開発に十年以上も関わってきていた。
一九八〇年代半ば、ぼくは最初期の GNU 協力者の一人だったし、ネット上にかなりのフリーソフトもリリースして、いまでも広く使われているようなプログラムのいくつか、
たとえばネットハック (nethack) 、 イーマックス (Emacs) の VC モードと GUD モード、 X ライフ (xlife) などを単独または共同で開発してきた。
だから、もうやり方はわかってるもんだと思いこんでいた。

リナックスは、ぼくがわかっているつもりでいたものを、根底から覆してくれた。
それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといったユニックスの福音は説き続けてはいた。
でも、もっと上のレベルではなにかどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。
一番大事なソフト ( OS や、イーマックスみたいな本当に大規模なツール) は伽藍のように組み立てられなきゃダメで、一人のウィザードか魔術師の小集団が、
まったく孤立して慎重に組み立てあげるべきもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。

だからリーヌス・トーヴァルズの開発スタイル――早めにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにするにはまったく驚かされた。
静かで荘厳な伽藍づくりなんかない――リナックスコミュニティはむしろ、いろんな作業やアプローチが渦を巻く、
でかい騒がしいバザールに似ているみたいだった(これをまさに象徴しているのがリナックスのアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう)。
そして、そこから一貫した安定的なシステムが出てくるなんて、奇跡がいくつも続かなければ不可能に思えた。

このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。
この世界の様子を学ぶにあたって、ぼくは個別のプロジェクトだけでなく、なぜリナックス界が混乱のうちに崩壊しないのか、
それどころかなぜ、伽藍建設者たちの想像を絶するスピードで、続々と強みを発揮し続けられるのかを理解しようとしてきた。

一九九六年半ばには、答がわかりかけてきたような気がした。
そして、その頃まったくの偶然から、自分の理論を試してみる完璧な機会がやってきた。
意識的にバザール方式で運営できるようなフリーソフトプロジェクトという形で。
そこでバザール方式を試してみた――そして、大成功。

【教訓1】よいソフトはすべて、開発者の個人的な悩み解決から始まる。 p13

これは自明のことかもしれない (昔から「必要は発明の母」って言うし)。
でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし好きでもないようなソフトを一日中シコシコ書いてることがあまりに多いんだ。
でも、リナックスの世界ではちがう――リナックス界出身ソフトの質が、平均してすごく高いのはこのせいかもしれないね。

【教訓2】なにを書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せばいいかわかってるのが、すごいプログラマ。 p14

――だからね。
すごいプログラマを気取るつもりはないけど、でもその真似くらいはしたい。
すごいプログラマの大事な特徴の一つが、建設的な面倒くさがりってヤツなんだ。
評価してもらえるのは結果であって、そのための努力じゃないってのがわかってるってこと。

そして白紙から始めるよりは、よくできた部分解から始めたほうがほぼ絶対に楽。

たとえばリーヌスは、リナックスをゼロから書き始めたわけじゃない。
i386マシン用の、小さなユニックスっぽいOSだったミニックス (Minix) のコードやアイデアを再利用するところから始めてる。
やがてミニックスのコードは全部落とされたか、あるいは完全に書き直された――でも最初のうちは、やがてリナックスとなるべき赤ん坊のための簡単な囲いを提供してくれてたんだ。

同じ精神から、ぼくは既存のPOPユーティリティを探しに出た。
そこそこ上手にコーディングされてて、開発のベースに使えるようなヤツを。

ユニックス界では、ソース共有の伝統のおかげでコードの再利用が昔からとってもやりやすかった
(このせいでGNUプロジェクトは、ユニックスというOSそのものについては、かなり不満を持ってたんだけれど、ベースOSにはユニックスを選んだ)。
リナックス界は、この伝統を技術的な極限にまでつきつめてる。
だれにでも使えるオープンなソースコードが、何テラバイトもある。
だからだれかほかの人の、ほとんど使いものになりそうなコードを探すのは、リナックスの世界ではほかのどこよりもすごくいい結果を生みやすい。

【教訓4】まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。 p17

でも、カール・ハリスの行動のほうがもっと大事だ。
かれが理解していたこと……

【教訓5】あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡す p17

なにも相談なんかしなくても、カールもぼくも、自分たちがこの世で最高の問題解決方法を実現するという共通の目標を持っていることがわかっていた。
二人にとって唯一の問題は、ぼくがこれを安心して任せられる人物だってことを証明できるかということだけだった。
それを実証してみせたら、かれはすぐさま優雅な振る舞いを見せて、ソフトをゆだねてくれた。
ぼくの順番がきたときにも、カールと同じくらいの鷹揚さを示したいなと思う。

これまたユニックスの伝統の強みで、これまたリナックスがみごとに極限まで推し進める強みでもあるんだけれど、ユーザの中にもハッカーがたくさんいるわけだ。
そしてソースコードが公開されてるから、かれらは同じハッカーでも役に立つハッカーになってくれる。
これはデバッグ時間短にはすごく役に立つ、ちょっと励ますだけで、ユーザが問題を診断し、直し方を提案してくれて、一人でやるよりずっと早くコードを改善できるようにしてくれる。

【教訓3】捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから (フレデリック・P・ブルックス著「人月の神話』第十一章) p16

あるいは言い換えると、一回とりあえず解決策を実装してみるまでは、問題を完全には理解しきれないってこと。
二回目くらいになってやっと、正しい解決法がわかるくらいの理解が得られるかもしれない。
だから、ちゃんとした問題解決をしたいなら、少なくとも一回くらいはやり直す覚悟ってくれるんだ。

【教訓6】ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグの一番楽ちんな方法。 p19

この効果の力はすごく見落としがち。
実はぼくらフリーソフト界のほとんどだれもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そして、それがシステムの複雑さに対してどれほど有効に機能するかについて、まったく見えてなかった。
リーヌスが目を開いてくれるまでは。

はっきり言って、ぼくはリーヌスの一番賢い、影響力あるハッキングというのは、リナックスのカーネル構築そのものではないと思う。
むしろ、リナックス開発モデルの発明だと思う。
本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。
「ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。
キツネのようなずるがしこい怠けぶり。
あるいはロバート・ハインラインなら「失敗するには怠惰すぎる」とでも言っただろうね。

早めのリリース、しょっちゅうリリース p21

早めにしょっちゅうリリースするのは、リナックス開発モデルの重要な部分だ。
ほとんどの開発者(ぼくを含めて)は、プロジェクトがちょっとでも大きくなったらこいつはまずいやり方だと考えていた。
初期バージョンはその定義からいってバグだらけだし、ユーザの我慢にも限度があるだろうから。

【教訓7】早めのリリース、ひんぱんなリリース。 p22

リーヌスの革新は、これをやったということじゃない(似たようなことは、もう長いことユニックスの世界の伝統になっていた)。
それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。
開発初期のあの頃だと、リーヌスが新しいカーネルを一日に何回もリリースすることだって、そんなに珍しくはなかった。
そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく共同作業をする点で、ほかのだれよりも上をいっていた。
それでうまくいったわけだ。

でも、具体的にどういうふうにうまくいってるんだろう。
そしてそれはぼくでも真似できるものなんだろうか、それともリーヌスだけにしかない独特な才能に依存したものなんだろうか？

そうは思えなかった。
そりゃもちろん、リーヌスはまったく大したハッカーだ (完全な製品レベルのOSカーネルをつくりあげられる人間が、ぼくたちの中でどれだけいるね？)。
でも、リナックスはとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。
リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリングのような、設計面での革新的天才ではないんだ(少なくともいまのところは)。
むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。
バグや開発上の袋小路を避ける第六感と、A地点からB地点にたどりつく、一番楽な道を見つけだす真の直感もある。
リナックスの設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。
じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限で済まそうとするリーヌスのエンジニアリング上の天才的洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。
この仕組みからかれがひねりだしているのは何だったんだろう。

こういう問題の立て方をすれば、質問自体が答になる。
リーヌスは、ハッカーやユーザたちをたえず刺激して、ご裏美を与え続けたってことだ。
刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、美は、自分たちの仕事がたえず(まさに毎日のように)進歩している様子だ。

リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり狙っていたわけだ。
コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザ基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。
リーヌスの行動を見ていると、次のような信念を持っていたんじゃないかと思える。

【教訓8】ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけたされて、その直し方もだれかにはすぐわかるはず。 p24

あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。
これをぼくはリーヌスの法則と呼んでる。

はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。
リーヌスはこれに異議を唱えて、問題を理解してそれを直す人物は、必ずしもどころか普通は、その問題を最初に記述する人間ではないと言った。
「だれかが問題を見つける。そしてそれを理解するのはだれか別の人だよ。
そして、問題を見つけることのほうが難しいとぼくが述べたことは記録しておいてね」。
でも肝心なのは、見つけるのも直すのも、だいたいすごく短期間で起きるってことだ。

ここに、伽藍建築方式とバザール方式のちがいの核心部分があるんだと思う。
伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、潜伏した深い現象だ。
問題を全部ほじくりだしたと確信できるようになるには、少数の人が何カ月も専念してチェックしなきゃならない。
だからリリースの間隔も開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。

一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを一つ残らず、千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。
よって、たくさん直してもらうためにリリースも増やすし、有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。

そして、これがすべてだ。
これだけで必要十分。
もしリーヌスの法則がまちがってるなら、リナ ックスカーネルほど複雑なシステム、リナックスカーネルくらいみんながよってたかってハッキングしてるようなシステムは、どこかの時点でまずい相互作用や、発見できない「深い」バグのせいで崩壊してたはずなんだ。
一方、もしリーヌスの法則が正しければ、これでリナックスが相対的にバグが少ないことを十分説明できる。

そしてこれは、そんなに驚くべきことでもなかったのかもしれない。
社会学者たちは何年も前に、同じくらいの専門家(あるいは同じくらい無知な人たち)の意見の平均は、そういう観察者の一人ランダムに選んで意見を聞くよりも、予測精度がかなり高いことを発見している。
これをかれらは「デルファイ効果」と呼んだ。
どうやらリーヌスが示したのは、これがOSのデバッグにも適用できるってことみたいだ。
つまりデルファイ効果は、OSカーネル級の複雑なものでも、開発上の複雑さをおさめることができるんだ。

ジェフ・クッキー<dutky@wam.umd.edu〉は、リーヌスの法則は「デバッグは並列処理可能だ」と言い換えることもできると指摘してくれた。感謝したい。
ジェフの知見では、デバッグするには担当者は開発コーディネータと多少のやりとりは必要だけれど、デバッグする人間同士では大した調整は必要ない。
だから、開発者を加えることで発生する、幾何級数的な複雑性と管理コスト増大という問題には直面しないで済むというわけだ。

実際問題として、デバッグする人間同士たちの作業重複によって生じる理論的な無駄は、リナックスの世界ではほとんど問題にされないようだ。
「早めしょっちゅうのリリース」の効果の一つとして、すでにフィードバック済みのバグフィックスをすばやく広めることでそういう重複をなくせるということがある。

ブルックスは、すでにジェフの見解に関連したような観察をなにげなく述べてる。
「広範に使われるプログラムをメンテナンスするコストは、おおむねその開発コストの四〇%だ。
驚いたことに、このコストはユーザ数に大きく左右される。ユーザが増えると見つかるバグも増えるのだ」(強調筆者)。

ユーザが増えると見つかるバグも増えるのは、ユーザを追加することで、プログラムをもっといろんな方法で叩いてみることができるからだ。
この効果は、そのユーザたちが共同開発者でもある場合にはさらに増幅される。
各人が、ちょっとずつちがったものの見方と分析用ツールキットをもって、その任に当たる。
「デルファイ効果」はまさにこの多様性のためにうまく機能するらしい。
デバッグという分野に限った話をすると、この多様性のおかげで試みが重複する機会も減るらしい。

だからベータテスタの数を増やしても、開発者側の立場からすれば目下の「一番深い」バグの複雑さが減るわけではないけれど、
でもだれかのツールキットがその問題にうまくマッチして、その人にとってはそのバグが深刻ではないという可能性を増してくれるわけだ。

リーヌスも、そこらへんは抜け目なくやってる。
万が一本当に深刻なバグがあったときのために、リナックスカーネルのバージョンのナンバリングには工夫がある。
ユーザ候補は、「安定」とされたカーネル最新版を使うか、最先端の新しい機能を使うかわりにバグの危険をおかすか、という選択ができるようになってる。
この戦術は、ほかのリナックスハッカーたちはまだ正式に採用していないけれど、でも採用されるべきかもしれない。
選択肢があるというのは、魅力を増すから。

【教訓9】賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。 p29

またもやフレデリック・P・ブルックス本の第十一章から。
「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。
データ構造さえみせてもらえれば、コードのほうは多分いらない。
見るまでもなく明らかだから」。

ほんとはかれが言ったのは「フローチャート」に「テーブル」だった。
でも三十年にわたる用語面・文化面での推移を考慮すれば、ほとんど同じことを言ってる。

【教訓11】「完成」(デザイン上の)とは、付け加えるものがなにもなくなったときではなく、むしろなにも取り去るものがなくなったとき。 p36

コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に自分が正しいのがわかる。
そしてこの過程で、フェッチメールのデザインは、先祖のPOPクライアントとは別の独自のアイデンティティを獲得してきた。

そろそろ名前を変える頃だった。
新しいデザインは、以前のPOPクライアントよりずっとセンドメールの双子みたいな感じになってきていた。
どっちもMTAだけれど、センドメールがプッシュして配信するのに対して、新しいPOPクライアントはプルして配信する。
だから引き継いで二カ月したところで、ぼくはこれをフェッチメールと改名した。

バザール方式の前提条件とは p45

この論文の初期レビューアーや、テスト読者たちがたえず返してきた質問は、上手なバザール形式の開発に必要な条件はなにか、というものだった。
これはプロジェクトリーダの資質と、共同開発者コミュニティをつくろうとしてコードを公開する時点での、コードの状態についての条件の両方についてのものだった。

バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしている。
バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのはすごく難しいだろう。
リーヌスはそんなことはしなかったし、ぼくもしなかった。
あなたが生み出そうとしてる開発者コミュニティは、いじるためになにか動いてテストできるものを必要としているんだ。

コミュニティ形成を始めるときには、まずなによりも実現できそうな見込みを示せなきゃならない。
別にそのソフトはとくによく書けてなくてもいい。
雑で、バグだらけで、不完全で、ドキュメントでもいい。
でも絶対不可欠なのが、開発者候補たちに、それが目に見える将来にはなに本当に使える代物に発展させられると説得できることだ。

リナックスとフェッチメールは、どちらも強力で魅力的な基本デザインをもって公開された。
ぼくが提出したバザールモデルについて考えてきた人の多くは、これがきわめて重要だということを正しく認識し、
そこからいきなり、だったらプロジェクトリーダには高度なデザイン上の直感と才能が必要にちがいないという精論に一足飛びにとびついてしまった。

でもリーヌスはデザインをユニックスからもらってる。
ぼくはもともと先祖のPOPメールからアイデアを得てる(もっとも、それは後に大きく変わった。割合から言えばリナックスよりはずっと大きな変化だ)。
ということは、バザール形式のリーダ/コーディネータはずばぬけたデザインの才能が本当にいるんだろうか、それとも他人のデザインの才能をうまく生かすだけでやっていけるんだろうか。

コーディネータが、とてつもないデザイン上のひらめきを自分で得る必要性は必ずしもないと思う。
でも、絶対に必要なのは、その人物がほかの人たちのよいデザイン上のアイデアを認識できるということだ。

リナックスもフェッチメールも、この証拠を示している。
リーヌスは(すでに述べた通り)、驚異的に独創的な設計者ではないけれど、よいデザインを認識してそれをリナックスカーネルに組み込む強力な第六感を示した。
そしてすでに述べたように、フェッチメール最大の強力なデザインアイデア(SMTP転送)は他人にもらったものだった。
この論文を早い時期に読んだ人たちは、おまえはバザールプロジェクトでのデザイン上の独創性を過小評価している、自分にはいろいろアイデアがあるもんだから、それが当然のことだと思ってるんだろう、と誉めてくれた。
確かにこれは一理ある。
ほくの最大の強みは確かに、コーディングやデバッグではなく、デザイン能力にある。

でもソフトの設計で、小利口で独創的になることの問題点は、それが習慣になってしまうことだ。
ソフトは堅牢でシンプルにしておかなきゃダメなのに、反射的にそれを媚びた複雑なものにしてしまいがちになる。
このまちがいのおかげでつぶれたプロジェクトもいくつかある。
でも、フェッチメールではそういうことにならずに済んだ。

だからフェッチメールプロジェクトが成功したのは、一部はぼくが小利口になりがちな自分の性格を抑えたからだと思う。
これは(少なくとも)バザールプロジェクトの成功にデザイン上の独創性が不可欠という議論の反証になっている。
そして、リナックスもそうだ。
もし、リーヌス・トーヴァルズが開発途上で根本的なOSデザインの革新をやってのけようとしていたら、その結果のカーネルがいまのものほど安定してうまくいっていたかどうか？

一定レベルのデザインとコード書きの能力は必要だけれど、でもバザール式のプロジェクトを始めようかと真剣に考えている人なら、ほとんどだれでもそんな最低限以上の能力はあるだろう。
フリーソフトやオープンソースコミュニティ内における評判の市場は、最後まで面倒を見られないような開発プロジェクトを始めないように、みんなに微妙な圧力をかける。
いまのところ、これはなかなかうまく機能してきたようだ。

別の才能で、ソフト開発とは普通は関連づけられないけれど、でもバザールプロジェクトではデザイン上の才覚に匹敵するほど――あるいはそれ以上――重要なものがあると思う。
バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。

これは説明するまでもないだろう。
開発コミュニティをつくるには、人を引きつける必要がある。
自分のやっていることに興味を持たせて、各人のやっている仕事量についてみんなが満足しているように気を配る必要がある。
技術的な先進性は、これを実現する役にはおおいに立つけれど、でもそれだけではぜんぜん足りない。
その人が発する個性も大事だ。

リーヌスがナイスガイで、みんなかれを気に入って手伝いたくなってしまうのは、偶然ではない。
ぼくがエネルギッシュで外向的で、大人数を動かすのが好きで、コメディアンの話術や本能をちょっと備えているのも偶然じゃない。
バザールモデルが機能するためには、人を魅了する能力が少しくらいでもあると、きわめて役に立つのだ。

フリーソフト/オープンソースの社会的な意義 p48

これはもう不動の真実だ。
最高のハックは、作者の日常的な問題に対する個人的な解決策として始まる。
そしてその問題が、実は多数のユーザにも典型的なものであるために広まる。
これで、教訓1の話に戻ってきた。
ただし、もう少し便利な形で言い直してみよう。

p49

「人月の神話」でフレデリック・P・ブルックスはプログラマの時間が代替不能だと看破している。
遅れているソフト開発に開発者を加えても、開発はかえって遅れる。
プロジェクトの複雑さとコミュニケーションコストは、開発者数の二乗で増大するのに対し、終わる作業は直線的にしか増加しないというのがかれの議論だった。
この論はそれ以来「ブルックスの法則」と呼ばれるに至り、真実をついているものとだれもが考えている。
でもブルックスの法則が唯一無二の真理なら、リナックスはありえなかっただろう。

p50

ワインバーグの分析がしかるべき評価を得なかったのは、用語のせい――インターネットのハッカーたちを「エゴがない」と呼ぶなんて、思わず笑ってしまうじゃないの。
ユニックスの歴史を見れば、リナックスから学びつつあるもの(そしてぼくが意図的にリーヌスの手法を真似ることで、実験的に小規積に確認したもの)は見えていたはずなんだ。
コーディングは基本的に孤独な活動だけれど、真に偉大なハックはコミュニティ全体の関心と能力を動員することで実現されるってこと。
閉ざされたプロジェクトの中で、自分の脳味噌だけを使う開発者は、オープンで発展的な文脈をつくりだしてデザイン空間の探索やコードの貢献、バグつぶしなどの改善をもたらすフィードバックが何百人ものユーザから戻ってくるようにできる開発者に負けてしまうんだ。

でも従来のユニックスの世界は、このアプローチをとことんまでつきつめることができなかった。
要因はいくつかある。
一つはいろいろなライセンスや商売上の秘密、商業的な利害からくる法律上の制約。
そしてもう一つは(いまにして思えば)インターネットがまだ発達しきってなかったことだ。

安いインターネット以前には、いくつかの地理的に集中したコミュニティではワインバーグの「エゴのない」プログラミングが奨励されていた。
そこでは開発者は、有能なチェック屋や共同開発者を楽にたくさん集めることができた。
ベル研、MIT、AI研、カリフォルニア大学バークレー校――こういうところは伝説的な技術革新を生み出したし、いまでも強力だ。

リナックスは、意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。
リナックス形成期が、 WWW (World Wide Web) の誕生と同時期なのは偶然ではないと思うし、
リナックスが幼年期を脱したのが一九九三から一九九四年という、ISP産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。
リーヌスは、拡大するインターネットが可能にした新しいルールに従って活動する方法を見いだした、最初の人間だったわけだ。

安いインターネットは、リナックスモデルの発展にとっての必要条件ではあったけれど、でもそれだけでは十分条件ではなかったと思う。
もう一つの重要な要素は、開発者が共同開発者を集めて、インターネットというメディアを最大限に活かすためのリーダシップのスタイルと、協力のための慣行が開発されたことだろう。

でもこのリーダシップのスタイルとはなんで、その慣行ってのはどういうものだったんだろう。
これは権力関係に基づくものではありえない――ありえたとしても、脅しによるリーダシップは、いまぼくたちが目にするような結果を生み出しはしない。
ワインバーグは、十九世紀ロシアのアナキストであるクロポトキンの『ある革命家の回想』を引用して、この点についていい議論を展開している。

「農奴を所有する一家に育ったわたしは、当時の若者たちみんなと同じように、命令したり指令したり、叱りつけたり罰したりといった行動の必要性について、まったく疑うことを知らぬままに成年に達した。
しかしかなり早い時期に、わたしは大がかりな企業を経営することになり、自由な人々と交渉することになった。
そしてまちがい一つが重大な結果を招くような状況で、わたしは命令と規律という原理にしたがって活動するのと、共通の理解という原理に基づいて行動するのとの差をだんだん理解するに至った。
前者は軍隊のパレードでは見事に機能するが、実生活において、目標が多くの重なり合う意志の真剣な努力によってしか達成できないような状況では何の価値もない」

この「多くの重なり合う意志による真剣な努力」は、まさにリナックスのようなプロジェクトには必須――そして「命令という原理」は、ぼくたちがインターネットと呼ぶアナキスト天国のボランティアたちに対しては、実質的に適用不可能だ。
効果的に活動して競争するには、共同プロジェクトを仕切りたいハッカーは、クロポトキンが「理解の原理」で漠然と示唆しているモードを使い、有益なコミュニティをリクルートしてやる気を起こさせる方法を学ばなくてはならない。
つまり、リーヌスの法則を学ばなくてはならないんだ。

前にリーヌスの法則の説明として「デルファイ効果」が考えられると述べた。
でも、生物学や経済学に見られる適応型システムも、アナロジーとして強力だし魅力もある。
リナックスの世界はいろんな意味で、自由市場や生態系のような動きを見せる。
自己中心的なエージェントがそれぞれ効用を最大化しようとして、その過程で自己調整的な自律的秩序を生み出し、それはどんな中央集権計画の何倍も複雑で効率が高くなる。
だから、こここそが「理解の原理」を探すべき場所だ。

p54

数多い例の一つを挙げると、リナックス関連文書の驚くべき多様性と品質と詳細さがある。
プログラマたちはドキュメント作成が大嫌いというのは、ほとんど神聖化された周知の事実とされている。
だったら、なぜリナックスハッカーたちはこんなにもたくさんの文書を生み出すんだろう。
明らかにリナックスのエゴブー自由市場は、商業ソフト屋さんのものすごい予算をもらった文書作成業者たちよりも、気高さに満ちた他者をいたわる行動を生み出すうえでうまく機能するわけだ。

【教訓19】開発コーディネータが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやり方を知っている場合には、頭数は一つよりは多いほうが絶対にいい。 p54

フリーソフト(オープンソース・ソフト)の未来は、ますますリーヌスのやり方を身につけた人たちのものになっていくと思う。
つまり、伽藍を後にしてバザール方式を受け入れる人たちのものだ。
これは別に、個人のビジョンと才能がもはやどうでもいいということではない。
むしろ、フリーソフトやオープンソースの最先端は、個人のビジョンと才能を出発点としつつも、それをボランタリーな利害や興味コミュニティの構築によって増幅する人々のものだと思う。

そしてこれは、単に「フリー」ソフト(オープンソース・ソフト)だけの未来像ではないのかもしれない。
問題解決にあたって、リナックスコミュニティが動員できるほどの才能プールに太刀打ちできる商業デベロッパは存在しない。
フェッチメールに貢献してくれた二百人以上を雇える財力を持つようなデベロッパですら、ごくわずかしかいない！

もしかすると、最終的にフリーソフトやオープンソース文化が勝利するのは、
協力が道徳的に正しいとかソフト「隠匿」が道徳的にまちがってるとかいう理由のためではなく(ちなみに後者については、リーヌスもぼくもそうは思わない)、
単に商業ソフトの世界が、ある問題に有能な人々の時間を幾行も多くそそぎ込めるフリーソフトやオープンソース界と、進化上の軍事競争で張り合えなくなるからかもしれない。

p60

どのみち、安いPCや高速インターネット接続の世界では、限られている唯一のリソースというのは、才能ある人々の関心だけだ。
オープンソースプロジェクトは、つぶれるときにも、別にマシンやリンクやオフィスが足りないからつぶれるんじゃない。
開発者自身が関心を失ったからという、それだけだ。

そういうことなら、オープンソースのハッカーたちが、自薦によって最大の生産性をあげるべく自ら組織化するというのは、
二重の意味で大事になる――そしてハッカー界の社会理念によって、有能な者だけが容赦なく選ばれる。
ぼくの友だちは、オープンソース界と巨大閉鎖プロジェクトとの両方を知っていて、オープンソースが成功した理由の一部は、その文化がプログラミング人口のトップ五％しか受け入れないからだ、と信じている。
彼女は、残り九五％の動員を組織するのに時間を費やしている。
そして、最高のプログラマと、単に有能なだけのプログラマとの百倍もの生産性のちがいというのを、直接見せつけられているのだ。

p63

じゃあ、伝統的なソフトプロジェクト管理のオーバーヘッドを正当化するのに、目標設定というのくらいは救ってやれるかな？かもね。
でも、そのためには、マネジメント委員会だの企業のロードマップだのが、オープンソース界で似たような役割を果たすプロジェクトごとの「優しき独裁者」や部族の長老に比べて、
価値あるみんなに共有される目標を定義するのが上手だと信ずべきまともな理由が必要になる。

こいつを正面きって主張するのは、なかなかにむずかしいことだ。
そしてそれがむずかしいのは、オープンソース側がどうのというわけではない(イーマックスの長寿ぶりとか、リーヌス・トーヴァルズが「世界征服」を語って開発者の群を蜂起させられるとか)。
むしろ、ソフトプロジェクトの目標設定にあたって、伝統的な仕組みがそのタコぶりを遺憾なく証明してきてしまったという点が問題なんだ。

ソフト工学の、口伝理論でいちばん有名なものとして、伝統的なソフトプロジェクトの六〇％から七五％は、結局完成せずに終わるか、あるいはその予定顧客に拒絶される、というものがある。
もしこの数字が多少なりとも真実に近いなら(そして多少なりとも経験あるマネージャで、これを否定する人にはお目にかかったことがない)、
多分半分以上のプロジェクトは、現実的に達成不可能か、あるいは単純にひたすらまちがっている目標を目指してすすんでいるということになる。

p64

むしろぼくは、ソフトウェア(そしてあらゆる創造的またはプロフェッショナルな仕事)についての、もっと広い教訓をここで提示してみたい。
人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばんうれしい。
簡単すぎて退屈でもいけないし。
達成不可能なほどむずかしくてもダメだ。
シヤワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。
楽しみが能率をあげる。

自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合う(それがつきはなした皮肉なやり方だったとしても)というのは、それ自体が、そのプロセスの失敗を告げるものととらえるべきだ。
楽しさ、ユーモア、遊び心は、まさに財産だ。
ぼくがさっき、「シヤワセな集団」という表現を使ったのは、別に「シ」の頭韻のためだけじゃないし、リナックスのマスコットがぬくぬくした幼形成熟(ネオテニー)っぽいペンギンなのもただの冗談じゃあない。

オープンソースの成功のいちばん大事な影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。

p68

最後に、ぼくはこの論文を寸前まで「伽藍とアゴラ」と呼ぶところだったのを白状しておこう。
アゴラというのは、ギリシャ語で自由市場や公共集会場所をさす言葉だ。
マーク・ミラーとエリック・ドレクスラーの先駆的な論文『アゴラ的システム』 (“The Agoric System”) は、市場状のコンピュータ生態学にあらわれつつある性質を記述していて、
五年後にリナックスがぼくをフリーソフト(オープンソース・ソフト)での類似現象に直面させたときも、これを読んでいたおかげで明確にものを考える準備ができていた。
この論文はウェブ上の <http://www.agorics.com/agorpapers.html> で入手可能。

p69

翌週、ぼくはネットスケープ社の招きでシリコンバレーに飛び、かれらの重役や技術陣との丸一日にわたる戦略会議(一九九八年二月四日)に出席した。
ぼくたちはネットスケープのソース公開戦略とライセンスをつくり、その他、いずれフリーソフトやオープンソース・コミュニティに重大で前向きな影響をもたらすはずの計画をつくりあげた。
この執筆時点では、これ以上の詳しい話はまだできないけれど、でも数週間以内に追って詳細が発表されるはずだ。

この数日後に、ぼくは次のように書いた。

ネットスケープは大規模な現実世界におけるバザールモデルのテスト機会を提供してくれようとしている。
フリーソフト/オープンソース文化は、いま一つの危険に直面していることになる。
もしネットスケープのやりくちがうまくいかなければ、フリーソフト/オープンソースの考え方自体がダメなせいだと思われてしまい、商業ソフトの世界はまた十年ほどは手を出そうとしなくなるかもしれない。
一方、これはまたとてつもないチャンスでもある。
この動きに対するウォール街などでの初期の反応は、慎重ながらも肯定的だった。
ぼくたちは自らの力を証明する機会を与えられているのだ。
この動きを通じてネットスケープが再び圧倒的な市場シェアを取り戻せば、それをきっかけにもうとっくに起こっていてしかるべきだったコンピュータ産業の革命が動き出すかもしれない。

この先一年は、非常に示唆的でおもしろい時期になるだろう。

p103

ただし、オープンソース活動で人々がもっと金持ちになれる方法が一つなくはない――それは、その実際に動機に貴重なヒントを与えてくれるものではある。
しばしば、ハッカー文化で人が獲得した評判は実世界でも反映されて、それが経済的に意味をもってくることがある。
もっといい仕事が得られるとか、コンサルタント契約が手に入るとか、あるいは本の執筆依頼がくるとか。

でもこの種の副作用は、よくいっても稀だし、ほとんどのハッカーにとっては副次的なものでしかない。
ハッカーたちは何度も、自分たちは金のためにやってるんじゃない、理想と愛のためにやってるんだ、と主張している。
まあこれは割り引いて聞くにしても。

でも、こういう経済的な副作用が処理されるやり方は検討する価値がある。
ソース文化そのもののなかでの評判の力学だけでも、かなりの説明力があることをみてみよう。

贈与経済としてのハッカー文化 p104

オープンソース文化での評判の役割を理解するには、歴史から離れて文化人類学と経済学に深入りし、交換の文化と贈与の文化のちがいを検討してみると役に立つ。

人間は、社会的地位のために競争しようという生まれながらの衝動がある。
それはヒトの進化の歴史のなかでからだに刻み込まれているんだ。
その歴史のうち、農業の発明に先立つ九〇％を通じて、ぼくたちの先祖は小さな遊牧式狩猟採取集団をつくって暮らしていた。
地位の高い個人は、一番健康な伴侶と最高の食料へのアクセスを手に入れた。
この地位への衝動は、主に生存に必要な財の稀少性の度合いに応じて、いろいろな形であらわれてくる。

人間が持つ組織化のほとんどの方法は、稀少性と欲求に対する適応行動だ。
それぞれの方法は、社会的地位を獲得する別々の手段を持っている。
一番簡単な方法は上意下達方式 (command hierarchy) だ。
上意下達方式では、稀少な財の配分は一つの中央権力が行って、それが軍事力でバックアップされる。
上意下達方式は、規模の変化への適応力(スケーラビリティ)がものすごくとぼしい。
大きくなるにつれて、ますます横暴で非効率になってゆく。
このため、大家族以上の上意下達方式はほぼ必ずといっていいほど、別のかたち
もっと大きな経済に寄生する存在でしかない。
上意下達方式では、社会的地位は主に恐喝力へのアクセス能力によって決まってくる。

ぼくたちの社会はもっぱら交換経済だ。
これは財の稀少性に対する洗練された適応方式で、規模の変化にもよく適応する。
稀少な財の配分は、交換と自発的な協力によって非中心的に行われる (そして実は、競争の欲望がもたらす最大の効果は協力行動を生み出すことだ)。
交換経済では、社会的地位は主にモノ(必ずしも物質的なものとは限らない)のコントロールの大小で決まる。

ほとんどの人は、この二つについては説明されるまでもなく精神的なモデルを持っているし、それらがどう相互に機能するかもわかっている。
政府や軍、ギャング集団などは、ぼくたちが「自由市場」と呼ぶもっと大きな交換経済に寄生している上意下達システムだ。
しかしながら、このどちらともまったくちがっていて、人類学者たち以外はあまり認知されていない第三のモデルがあるんだ。
これが贈与の文化だ。

贈与文化は、稀少性ではなく過剰への適応だ。
それは生存に不可欠な財について、物質的な欠乏があまり起きない社会で生じる。
穏和な気候と豊富な食料を持った経済圏の原住民の間には、贈与経済が見られる。
ぼくたち自身の社会でも、一部の層では観察される。
たとえばショービジネスや大金持ちの間でだ。

過剰は上意下達関係を維持困難にして、交換による関係をほとんど無意味なゲームにしてしまう。
贈与の文化では、社会的なステータスはその人がなにをコントロールしているかではなく、その人がなにをあげてしまうかで決まる。

だからクワキトルの酋長はポトラッチ・パーティを開く。
億万長者は派手にフィランソロフィー活動をして、しかもそれをひけらかすのが通例だ。
そしてハッカーたちは、長時間の労力をそそいで、高品質のオープンソース・ソフトを作る。

というのも、こうして検討すると、オープンソース・ハッカーたちの社会がまさに贈与文化であるのは明らかだからだ。
そのなかでは「生存に関わる必需品」―つまりディスク領域、ネットワーク帯域、計算能力などが深刻に不足するようなことはない。
ソフトは自由に共有される。
この豊富さが産み出すのは、競争的な成功の尺度として唯一ありえるのが仲間内の評判だという状況でもこの観察は、それだけではハッカー文化に見られる特徴を説明するのに十分とはいえない。

クラッカー“デューズ”は、ハッカーと同じ (電子) メディア上に息づく贈与文化を持っているけれど、その行動は大きくちがっている。
このグループの性向は、ハッカーよりもずっと強くて排外的だ。
共有するよりは秘密を隠匿したがる。
クラッカーグループでは、ソフトクラック用のソースのない実行ファイルが出回ることのほうが、そのやり方を教えるヒントが出回ることより多い。

これが示しているのは、もちろん言うまでもなく自明だろうけれど、贈与文化の運用方法は一つじゃないってことだ。
ぼくはハッカー文化の歴史について、別のところでまとめたことがある。
れがいまの行動を形成していった方法は、謎なんかじゃない。
ハッカーたちは、自分たちの文化を規定するにあたり、自分たちの競合が行われる形式の集合を利用したわけだ。
この論文ではこの先、その形式を検討することにしよう。

p116

海賊ソフト文化との対比は示唆的だ。
この文化では、地位を求めての行動は臆面なしで、これみよしですらある。
この手のクラッカーたちは、「ゼロ・ディ・ウェアーズ (Warez)」(クラックされていないオリジナルバージョンがリリースされたその日に、クラックされたソフトを配布すること)をリリースして評判を勝ち取ろうとするけれど、でもそのやり方については口をつぐむ。
この種の魔法使いどもは自分の小技を公開するのを嫌う。
だから結果として、クラッカー文化の知識ベースはごくゆっくりとしか成長しない。

ハッカーコミュニティでは、それとは対照的に、ある人の成果こそがその人の主張でもある。
ここには非常に厳格な能力主義(一番優れた職人性が勝つ)があって、そして品質は自ら語るべきだ(いや、語らなくてはいけない)という倫理が強く存在している。
一番すてきな自慢は、「とにかく動く」コードであり、そして有能なプログラマならだれでもこれがいいのがわかるだろうというものだ。
だからハッカー文化の知識ベースは急速に拡大する。

p120

全体的にみて、この二つの傾向(ギャップ埋めとカテゴリーキラー)のおかげで、時代を追うにつれてのプロジェクト開始傾向は、おおむね予想がつく。
一九七〇年代に出回っていたほとんどのオープンソースはおもちゃとデモだった。
一九八〇年代には、開発ツールとインターネットツールが主流。
そして一九九〇年代になると、中心はOSに移った。
いずれの場合にも、それ以前の分野の可能性がほとんど尽きてしまって、新しいもっと難しいレベルの問題に矛先が移っている。

このトレンドは、近未来にとっておもしろい意味を持っている。
一九九八年初頭には、リナックスはどうやら「フリーOS」というニッチにとってカテゴリーキラーとなったような感じだ――かつてなら競合OSを書いたかもしれない人たちは、
いまではリナックスのデバイスドライバや拡張を書いている。
そして、この文化がこれまで想像してきたようなローレベルのツールは、ほとんどすべてオープンソースで存在している。
あとはなにが残っているだろう？

アプリケーションだ。
二〇〇〇年が近づくにつれて、オープンソース開発がますます最後の処女地に向かってシフトすると予言してもよさそうだ。
その処女地とはすなわち、技術オンチのためのプログラムだ。
はっきりした最初のしるしとしては、GIMPの開発がある。
これはフォトショップに似た画像処理ソフトで、過去十年には商業アプリケーションの専売と思われていた、エンドユーザにやさしいGUIを持っている。
別の示唆としては、アプリケーション用ツールキットのプロジェクトを取り巻いているにぎやかさが指摘できるだろう。
KDEやGNOMEなんかだ。

最後に、評判ゲーム分析はよく挙げられる格言を説明してくれる。
人はハッカーを名乗ればハッカーになれるわけじゃない――ほかのハッカーにハッカーと呼ばれた時点で、人はハッカーになるんだ。
この観点から見た「ハッカー」というのは、技術的な能力を持っていて、しかも評判ゲームがどう機能するかわかっているということを(贈り物を提供することで)実証した人間だ。
この判断は、主に認知と文化順応に基づくもので、すでにこの文化の中にしっかり入った人々からしか与えられない。

魔法と区別がつかない p145

ウェールズの神話では、女神セリドウェンはすばらしいおなべを持っていて、それは滋養あふれる食べ物を魔法で産み出してくれる――ただし、女神だけが知っている呪文を唱えれば。
現代科学では、バックミンスター・フラーがエフェメラリゼーション (ephemeralization) という考え方を与えてくれた。
あるテクノロジーの、初期のデザインで採用された物理的なリソースが、どんどん情報によって置き換えられることで、ますます強力になると同時に安くなる現象のことだ。
アーサー・C・クラークは「ある程度以上に進歩したテクノロジーはすべて魔法と区別がつかない」という知見によって、この両者をむすびつけた。

多くの人にとって、オープンソース・コミュニティの成功はありえそうにない魔法の一種に見える。
高品質のソフトが「無料」で現れてくるなんてのは、続けばすばらしいことではあるけれど、競争と稀少資源が支配する現実世界では、長続きするとはとても思えない。
なんか落とし穴があるはずだ。

セリドウェンのおなべは、ただのインチキ手品なんだろうか。
そして、そうでないならこの文脈でのエフェメラリゼーションはどういうふうに機能しているんだろう――女神の唱える呪文というのはなんなんだろうか。

製造業的な誤解 p148

まずはじめに認識すべきなのは、コンピュータのプログラムは、ほかのすべてのツールや資本財と同じように、二種類のまったくちがった経済価値を持つ、ということだ。
いずれも利用価値と販売価値を持っているわけだ。
プログラムの利用価値というのは、それをツールとして使うときの経済価値だ。
プログラムの販売価値というのは、それを販売できる商品としてみたときの価値だ (専門の経済学用語でいえば、販売価値は消費財 <final good> としての価値で、利用価値は中間財としての価値、ということになる)。

経済学でソフト生産について論じようとするとき、ほとんどの人は「工場モデル」を仮定することが多い。
このモデルは、以下の根本的な前提に基づいている。
1 ほとんどの開発者の開発時間に対する賃金はその販売価値に基づいて決まる。
2 ソフトの販売価値は、その開発コスト (つまり、その機能を再現するのに必要な資源のコスト) とその利用価値に比例する。

つまり、人はソフトウェアの価値の特徴が、普通の工業製品と同じだとつい想定しがちだということだ。
でも、いまの想定はどっちも明らかにまちがっている。

p150

これは「メンテナンス」と呼ばれていて、どんなソフトエンジニアでもシステムアナリストでも、これがプログラマの賃金の大部分(七五％以上)を占める点には同意するはずだ。
そしてこれにともなって、ほとんどのプログラマの労働時間が割かれるのは(そしてプログラマの給料の大部分を占めるのは)、まったく販売価値のないインハウスのコーディングやメンテナンスだということになる。
これは、新聞の求人欄のプログラマ募集広告を見てみればすぐに確認できることだ。

そこらの新聞の求人欄を眺めてみるのは、なかなかに啓蒙的な実験なので、読者のみなさんも是非やってみてほしい。
「プログラミング、データ処理、ソフトエンジニア」の欄で、ソフト開発に関連した求人を見てみよう。
そこで開発予定のソフトが、社内利用か販売用かで求職を分類してみること。

すぐにわかるのが、「販売用」という一番広いくくりを使っても、
二〇の求職のうちで少なくとも一九は利用価値のみのために支払われる仕事だということだ(つまり、中間財としての価値に支払いが行われているということになる)。
ソフト産業のうちで販売価値に基づいて動いているのがたった五％だと考えられるのは、これが根拠だ。
しかしながら、この論文での分析はこの比率の数字にはあまり影響されない。
これが一五％か、ひょっとして二〇％だったとしても、経済的な意味合いは基本的には変わらない。

逆転した共有地 p156

みんなが思っているモデルを疑問視したんだから、こんどはぼくたちが別のモデルをつくれるか見てみよう――オープンソースの協力体制を維持可能にする、ゴリゴリの経済学的な説明だ。

これはいろいろちがったレベルで検討しなければならない問題だ。
一つのレベルとして、まずオープンソース・プロジェクトに貢献する個人の行動を説明しなきゃならない。
別のレベルではリナックスやアパッチみたいなオープンソース・プロジェクトでの協力を維持する経済的な力を理解しなきゃならない。

またもや、まずはこの問題理解の妨げとなる、えらく広まっている通俗モデルを打破するところから始める必要がある。
協力的行動を説明しようというあらゆる試みには、ギャレット・ハーディンの「共有地の悲劇」が影を落とすことになるんだ。

ハーディンの有名な議論では、まずお百姓さんたちの村に共有の草地があるものと想像してみてほしい。
お百姓さんたちは、そこで牛に草を食べさせる。
でも、牛が草を食べるとその共有地の状態は悪くなる。
草は引きちぎられて、泥の穴が残り、そこに草がまた生えるまでには時間がかかる。
もし、草の食べ過ぎを防ぐような、放牧権を割り当てる方針が合意され(そして強制され！)なければ、
お百姓さんたちは一人残らず、我先に急いでなるべくたくさんの牛をそこに放って、共有地がただの泥沼と化す前に最大の価値をそこから引きだそうとするはずだ。

協力行動について、多くの人の直感的なモデルはいまの例とだいたい同じだ。
これは実は、オープンソースの経済問題についてあまりいい診断にはなっていない。
オープンソースの問題はただ乗り問題(提供不足)であって、混雑した公共財(使いすぎ)ではないからだ。
それでも、最初に出てくる反論のほとんどは、これが裏付けになっている。

共有地の悲劇モデルだと、予想される結果は三通りしかない。
一つは泥沼。
一つは、だれか脅しの使える主体が、村のために配分方針を強制する方法(共産主義的な解決法だ)。
三番目は、村人たちが自分の守れる範囲を柵で囲って、維持可能な状態を保つことだ(知的所有権による解決)。

このモデルを反射的にオープンソースに適用するために、みんなオープンソースの寿命はすごく短いはずだと予想する。
インターネット上では、プログラマの割く時間の配分を強制するはっきりした方法はないので、このモデルを使うと、共有地はどうしても細分化して崩壊するしかない。
ソフトのいろんな部分部分がクローズドになって、共同のプールに還元される作業の量は急激に減ることになる。

ところが経験的にいって、実際のトレンドはその正反対なのは明らかだ。
オープンソース開発の広がりと分量(これはたとえば、 Metalab への登録や、 freshmeat.net での一日あたりのアナウンス量なんかで計れる)は着実に増えている。
明らかに、「共有地の悲劇」が実際のできごとをとらえきっていない、重要な部分があるんだ。

答の一部はもちろん、ソフトは使っても価値が減らないという事実からくる。
それどころか、オープンソース・ソフトは広く使われることで、その価値を高める。
利用者たちが自分自身のバグ修正や追加機能(コードパッチ)を追加してくれるからだ。
この逆転共有地では、みんなが放牧すればするほど草が増えるわけだ。

答のもう一つの部分としては、共通のソースコードのベースに対する小さなパッチの推定市場価値を回収するのは難しいという点があげられる。
たとえばぼくが、悩ましいバグの修正パッチを書いたとしよう。
そして多くの人が、そのパッチには金銭的な価値があることを認識したとする。
その人たちから、ぼくはどうやってお金を集めればいいだろうか。
伝統的な支払い方式では、オーバーヘッドが大きすぎて、こういう場合に適切となるような少額の支払いをするときには大きな問題になる。

でももっと本質的な点として、その価値は回収が難しいだけでなく、一般的にいってその値段を決めることさえなかなかできない、ということが指摘できる。
思考実験として、理論的に見て理想的な少額支払いシステムがインターネット上にできたとしよう――高セキュリティで、だれでも使えて、オーバーヘッドなし。
さて、「リナックスカーネルのいろんな修正」というパッチをあなたが書いたとする。
これに対する要求価格はいくらにすればいいだろう。
買い手候補は、そのパッチを見ないで、いくら支払うべきかどうすればわかるだろう。

ここに出てきたのは、F・A・ハイエクの「計算問題 (calculation problem)」の戯画版みたいなものだ――この取引をスムーズに行うには、
このパッチの機能的な価値を評価して、それに応じた値段をつけてくれると信頼できるような、超存在が必要になってしまう。

残念ながら、超存在はいまも昔もかなり品薄なので、パッチ作者たるハック素留造くんの選択肢は二つしかない。
そのパッチを抱え込んでおくか、あるいはフリーでプールに投げ出すか。
前者だと、なにも得られない。
後者でも、なにも得られないかもしれないけれど、でもほかの人たちに相互に与えあうよう奨励して、いずれハック素留造くんの問題を解決してくれるような贈与につながるかもしれない。
二番目の選択は、一見愛他的だけれど、実はゲーム理論的な意味で、最適に利己的な行動になっている。

刺身のツマ p171

このモデルは、ハードウェアメーカー用だ(ここでのハードウェアというのは、イーサネットや周辺機器ボードから、コンピュータシステム丸ごとまでなんでも含まれる)。
市場の圧力のせいでハード企業もソフトを書いてメンテナンスしなくてはならない(下はデバイスドライバから、設定ツールを経て、上は全OSにいたるまで)。
でも、ソフト自身は収益を産まない。
これはオーバヘッドだ――しかも、しばしばそれがかなりの負担になる。

この状況では、オープンソース化はだれでも思いつく。
失う収入はゼロだから、なにも損はしない。
ベンダーとして手に入れるものは、劇的に大きくなった開発者プールと、顧客ニーズへの高速で柔軟な対応、そしてピアレビューを通じた信頼性向上だ。
たぶん顧客のロイヤルティも高まるだろう。
顧客の技術スタッフたちが、そのコードにますます時間をさいて、必要なカスタマイズを行えば行うほどそうなるはずだ。

ハードウェアのドライバをオープンソース化することについては、ベンダーからよく出てくる反論がいくつかある。
それをここでの一般的な議論とごちゃまぜにするより、この問題だけをまとめた「補遺」を書いておいた。

オープンソースの「将来に不安がない」効果がとくに強いのは、この「刺身のツマ」モデルの場合だ。
ハードウェア製品は有限の製造期間とサポート期間しかない。
それ以降になると、顧客は自分で何とかするしかない。
でもドライバのソースが手に入って、それを必要に応じてパッチできたら、同じ会社の満足したリピート顧客になる可能性が高まる。
この「刺身のツマ」モデルを採用し非常に劇的な例は、一九九九年三月半ばにアップル・コンピュータが、マックOS Xの核であるダーウィン (Darwin) をオープンソース化すると決断したことだ。

レシピをまいて、レストランを開け p172

このモデルでは、あるソフトウェアを使って、クローズドなソフトのポジションを確立するのではなく(これだと、「ロスリーダ・市場ポジション確保」ケースになる)、サービスのポジションを確立する。

(昔はこれを「カミソリを配って、カミソリの刃を売れ」と呼んでいたけれど、
でも製品とサービスの結びつきは、カミソリとカミソリの刃のアナロジーほどは緊密なものじゃない。)

レッドハットをはじめとするリナックスディストリビュータがやっているのは、こういうことだ。
かれらが実際に売っているのは、ビット自体という意味でのソフトではない。
ちゃんと動くOSを組み立てて試験することによる付加価値なんだ。
さらに、そのOSは売り物になって、同じブランドのほかのOSと互換性があるという保証が(明示的にではなくても)ある。
かれらの価値提案のほかの面としては、無料インストールサポートや、サポート契約継続オプションの提示なんかがある。

オープンソースの市場構築効果は、そもそも最初からサービス的な立場にいるような企業にとってはとくに強力なものとなる。
最近の、とても示唆的な事例がデジタル・クリエーションズだ。
ここはウェブサイトのデザイン会社で、一九九八年に創業し、複雑なデータベースや取り引きサイトを得意としている。
かれらの主要ツール、この企業の知的所有権の至宝は、オブジェクト出版ソフトで、いくつか名前を変えて装いも変わってきたけれど、いまはゾープ (Zope)と呼ばれているソフトだ。

アクセサリー p175

このモデルでは、オープンソース・ソフトのアクセサリーを売ることになる。
一番低いところでは、コーヒーカップやTシャツ。
ハイエンドでは、質の高い編集と製本でのドキュメンテーション。

アクセサリー会社としては、オープンソース関連ソフトの優れた参考書をたくさん出している出版社のオライリー(O'Reilly Associates)がいい例だ。
オライリーは、有名なオープンソース・ハッカー(たとえばパールのラリー・ウォールやブライアン・ベーレンドルフ)を実際に雇っている。
これは、選んだ市場での評判を高めるためだ。

未来をフリーに、現在を売れ p176

このモデルでは、クローズドなライセンスでバイナリとソースをリリースするけれど、そのライセンスに期限をつける。
たとえば、フリーな再配布は認め、商業利用は有料にして、リリースの一年後か、あるいはベンダーが倒産・廃業した場合にはGPLになるようなライセンスを書けばいい。

このモデルでは、顧客はその製品がニーズにあわせてカスタマイズできるのが確実にわかる。
ソースが手に入るからだ。
その製品は、将来の不安がない――ライセンスは、最初の会社がつぶれても、オープンソース・コミュニティがそれを引き継げると保証しているから。

販売価格と販売量は、こういう顧客の期待に基づいているので、最初の企業としては、完全なクローズドソースのライセンスでリリースするときよりも高い収入を得られるはずだ。
さらに古いコードがGPL化されるから、念入りなピアレビューも受けるし、もとの作者としては七五％のメンテナンスコストも、ある程度節約できることになる。

ソフトをフリーに、ブランドを売れ p177

これは実例のないビジネスモデルだ。
ソフト技術をオープンソース化して、テストスイートや、互換性標準を持っておく。
そしてユーザに対し、その技術の実装が、同ブランドをつけた他製品すべてと互換性があるという証明ブランドを発行する。(サンマイクロシステムズは、ジャバやジニをこういうふうに扱えばいいのに。)

ソフトをフリーに、コンテンツを売れ p177

これもまた、まだ実例のないビジネスモデルだ。
株価のリアルタイム表示サービスのようなものを考えて欲しい。
クライアントにもサーバにもない。
客観的に信頼できる情報を提供することにある。
だからソフトはすべてオープンソース化して、コンテンツの購読を売ろう。
ハッカーたちがクライアントを新しいプラットホームに移植して、それをいろいろ保守拡張してくれるにつれて、自動的に拡大する。
(だからこそ、ADLはアクセス用のクラライアントソフトをオープンソース化すべきなんだ。)

p184

この極端なケースの一例として、一九九九年初頭にぼくは、丸太から垂木をなるべくたくさん取りたい製材所向けの、のこぎりの入れ方パターンを計算するソフトを書いている会社から相談を受けた。
「うちはオープンソースにすべきでしょうか？」。
ぼくは「ノー」と結論した。
このソフトが満たす基準といえば、かろうじてだけだ。
でもいざとなったら、経験豊かなオペレータが自分でのこぎりの入れ方を手動で計算できるだろう。

大事な点は、その製品なり技術なりがこういう物指し上でおかれた位置というのは、時間とともに変わることがある、ということ。
これについては、次のケーススタディで見ていこう。

まとめると、オープンソースをすすめる差別化要因としては次のようなものがある。
(a) 信頼性、安定性、スケーラビリティがとても重要な場合。
(b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと検証できない場合。
(c) そのソフトがその利用者のビジネス展開を決定的に左右するような場合。
(d) そのソフトが、共通のコンピュータ・通信インフラを確立するか可能にする場合。
(e) その核となるメソッド(あるいは機能的にそれと等価なもの)が、よく知られた工学的な知識の一部であるとき。

成功に対処する p190

「共有地の悲劇」は、今日のようなかたちでのオープンソース開発には適用できないかもしれないけれど、だからといって、今日のようなオープンソースの勢いがこのまま続くかどうか、心配すべき理由がないということにはならない。
もし見返りが大きくなれば、キーとなるプレーヤーたちは協力から寝返るのではないか？

この質問は、いくつかのレベルで答えることができる。
ぼくたちの対抗物語である「共有地の喜劇」は、オープンソースの個々の貢献は金銭化するのが難しいという議論をもとにしていた。
でもこの議論は、すでにオープンソースと結びついた収入を持っている企業(たとえば、リナックスのディストリビュータ)の場合はかなり力を失う。
かれらの貢献は、すでに日々金銭化されている。
かれらのいまの協力的な役割は、安定しているんだろうか。

p209

――ふーむ。
さて「伽藍とバザール』についてよく質問を受けるのが、「あれではやはり開発者には金がいかないからソフト開発が止まってしまうのでは」というコメントなんですが。
これは日本に限った話じゃないと思うんですが、どう答えてます？

エリック
うーん、だから金以外の原理があるんだってことを『ノウアスフィアの開墾』で書いたんだけどねー。
それを読んでくれってことかね。
だいたい、そういう考え方自体がよくわからないよね。
人が金をもらわなきゃなにもしないと思うってことは、ほとんどすべての人間活動を否定するに等しいものね。
必要だからつくる。
おもしろいからやる。
当たり前のことだよねえ。
それをお金以外の動機づけがありえないと思っちゃうというのはね。

p211

エリック
ああ、それは賢明だと思う(笑)。
次の論文は「The Magic Cauldron」といって、 cauldron というのは魔法の鍋なんだ。
その中でオープンソースソフトがぐつぐつ煮たってて、そこからいろんな価値が魔法のように生まれてくるというイメージ。
もうだいたい書き上がっている。
たぶん六月中(一九九九年)には公開できるんじゃないかな。

中身は見てのお楽しみだけれど、基本的には、もう情報そのもので商売をするというモデルはダメだ、という話になる。
情報では金をとれない。
でもその周辺サービスや付加価値の提供で商売をすることは十分にできるんだ。
そこらへんのビジネスモデルについて、ゲーム理論的なアプローチも入れながら説明してる。

――もし情報ではまったくお金がとれないなら、それはつまりすべてのソフトは今後オープンソース化する、と考えているわけですか？

エリック
いやぼくも、あらゆるソフトがオープンソースになるとは思っていないし、そうなるべきだとも思わない。

たとえばこないだ、ある材木屋さんがきて、「うちの丸太切りソフトをオープンソース化したらどうだろうか」という相談を受けたんだけれどね。
欲しいサイズの板を入力すると、丸太の切り方を最適化してくれて、無駄なく板がとれるようにするというなかなかおもしろいソフトだった。
だけれど、まず利用者が限られているからネットワーク効果もない。
信頼性って点でもクリティカルじゃない。
多少おがくずが増えたところで、まあどうってことはないだろう。
だから、これまで通りの開発でいいし、変なライセンスを考える手間の分だけ無駄ですよ、ということでクローズドのままでいくことになったよ。

p214

――しかしオープンソースだからって、なんでもかんでもうまくいくってものではないみたいではないですか。
モジラをどう評価していますか？
開発者の一人だったジェイミー・ザビンスキーは、「Mozilla.org 顛末記:辞職と回顧』で、オープンソースそのものには好意的ですが、ネットスケープのソースコード公開は失敗だったと言っていますよね。

エリック
ああ、あれね。
いや、ジェイミーは、最前線にいて現場に近すぎたんだと思う。
かれがあの文章で言っていたことは本当だし、かれがとってもつらい立場に置かれていたのはよくわかるんだ。
かれの気持ちはとってもわかる。
ぼくもあのポジションにいたら、そう思っただろう。
でも、ジェイミーは近すぎたせいで全体像が見えなくなっているとも思う。
ぼくはモジラは成功だったと思っている。

p215

エリック
うん、ちがう。
あれの唯一最大の狙いというのは、マイクロソフトの物量攻撃によるブラウザ市場の制覇をくい止めることだったんだ。
そしてその目標は、見事に達成されている。
最新のIDGかどっかの調査でも、インターネット・エクスプローラのシェアは下がったはずだよ。
ネットスケープのブラウザがこれからも残るんだというのを、信用できる形で世界にアナウンスできたという意味で、ネットスケープのソース公開は成功したと言えると思う。

――ふーむ。
で、マイクロソフトの幹部が、NTをオープンソースにするかも、なんてことを言ってますよね。
可能だと思いますか？

エリック
まさか。
ただの目くらましだよ。
だってかれらがそんなことをするメリットってないもの。
マイクロソフトはあくまでクローズドな環境で儲けるモデルになってるから。
それにコード公開ったって、なんかすさまじいコードの量になってて、しかもまだ増殖中だって？
いやあ、見たくないなあ。

――逆はどうでしょう。
MSがBSDのOSかなんかにリナックスエミュレータをのっけてリナックスとして出すってのは、MSブランドを集めて、そのあとで独自拡張をつけてクローズド化して……。

エリック
わははははははははは。
いやぁ、エイプリルフールのネタでたくさんあったけどね。
そんなことをしたら、負けを認めたってことではない、そんなことになったら、まず世界のハッカーがいっせいに笑いものにするでしょ。
そしてその後、クローズド版を出す？
われわれとしては、こう言えるわけだ。
「ほらごらん。
かれらも基本的にわれわれのほうが優秀だって認めたよ。
きて、このあとどうしたい？
またMS式のクローズドな開発につきあって、NTみたいな沼に入り込む？
それともこっちのオーブンで中身がわかって信頼性の高いほうの道を選ぶ？」、みんなどっちを選ぶと思うね？

p218

エリック
いや、ぼくは立場を変えたつもりはない。
まず、ストールマンは、知的所有権という考え方はすべてまちがっていて、みんな自分の書いたソフトを公開しなければならないと言っている。
ぼくは、知的所有権はすばらしいと思うし、保護されるべきだと思う。
ただし、人がそれをあまり極端に行使しないことで、とってもいい有益な結果が出てくるんだよ、というのを主張しているわけだ。
人が自主的に権利を放棄したり、自分の権利を限定したりするのはすばらしいんだけれど、その権利を最初っからあげないのはダメだね。
自主的にやるのと、それを強制するのとでは雲泥の差があると思う。

それともう一つ、ぼくは自由とかの話はあまりしたくないんだ。
別にぼくだって、ゆずりあいと共有に基づく社会が嫌だと言うんじゃない。
でも、自由のためにオープンソースを使っていただく、というのは変だと思う。
オープンソースはそれ自体メリットのあることで、だから採用しましょう、というのをきちんと説得できなければ、絶対に行き詰まるよ。
だってそうでないとしたら「オープンソースは実はダメなんだけれど、自由な社会のために我慢して使ってください」ってこと？
ダメダメ。
そんなのサステイナブル (Sustainable) じゃないでしょう。
そしてぼくは、オープンソースはそれ自体で理にかなったものだと思っている。
そうじゃなきゃ、こんなのやらないよ。

ただし、オープンソースが広まることによって、ある種の社会的政治的な自由が拡大するという副作用があるかもしれないってことについては、
否定する気はまったくないし、そういう事態になってくれれば、ぼくとしてはもう願ったりかなったりだね。
「オープンソースはこんなにいいんですよ、ああそうそう、それと、もしこれがうまくいけば、社会政治的な意味ってのも出てくるかもね」、というのがぼくの立場なんだよ。

p220

――「仕事、かわってくんない？」とかを見ると、あなたは <Slashdot.com> とかニュースグループの投稿なんかについて、わかってないガキどもの青臭い発言と言いつつ、全部目を通しているみたいですね。
なぜです？
ああいうところの書き込みのほとんどはろくでもないし、普通はしばらくするとまともには見なくなると思うんですが。
あなたにとって、ああいうのはやっぱり大事なんでしょうか。

エリック
うーん、あれはぼくがマーケットリサーチできる唯一の場なんだよ。
フィードバックがないとなんでも腐るからね。
だからクズみたいな書き込みばかりだけれど、我慢して読まざるをえないんだ。
S/N比が低すぎるし、読んでいるとほんとうに頭にくるし、がっかりさせられることばかりだけれど、大事といえば大事。
電子メールとかで来るのは、ほとんどがきちんとしたものだし、もっと支持してくれるものが多いんだけれどね。

p226

エリック・レイモンドの『伽藍とバザール』『ノウアスフィアの開墾』『魔法のおなべ』は、フリーソフト・オープンソースに関する先駆的な(そして目下のところ、ほとんど唯一といっていい)論考群だ。
フリーソフトやオープンソースについて語り、考えるにあたって、この一連の論文を無視することはできない(無視している人は付け焼き刃のもぐりだ)。
そしてこの論文のすごいところは、これが現実にネットスケープ社の方針に影響を与えて、次期ブラウザのソースコード公開に踏み切らせたという、現実的な力を持っていたことだ。

p227

それをきちんと守ろう、と考えた人がいた。
この論文の中でも名前がよく登場する、リチャード・ストールマンという天才プログラマだ。
かれは、どうすればその文化を守れるか、そして発展させられるかを一生懸命考えた。
まず、旗をふるだけじゃだめだ。
完全にみんなで共有できるよう
そして開発もできて発展させられるような、おもちゃじゃない本格的なシステムをつくってしまい、それを公開して共有すること。
そして、後から派生的な著作権なんかで共有が疎外されたりすることがないように、きちんとしたライセンス条項をつくってしまうこと。
この二つだ。

前者がいかに無謀なことかは、ソフト開発の経験がある人物ならすぐに理解できる。
でもおそろしいことに、ストールマンはそれをやってしまうだけの意志と能力と蛮勇を持ち合わせていた。
そしてかれがつくりあげたライセンスがすごかった。

p228

ストールマンは、このソースコードに目をつけた。
ソフトを共有するためには、みんながこのソースコードを公開しなくてはならない。
そしてストールマンのすごかったのは、ここで甘っちょろ感傷を許さなかったことだ。
ふつうはここで「せっかく公開しても他人がそれで商売しちゃおもしろくない」とか「せっかく書いたものを勝手に変えてばらまかれるのはいやだ」とか思うのが人情だ。
インターネットのホームページを見ても「商業利用はダメ」とか「勝手に改変してはダメ」というのが結構あるだろう。
気持ちはよくわかるけれど、でもストールマンは、それでは共有の意味がないと考えた。
自由にコピー、配布、販売してかまわない。
ただし、ソースコードはつけて、そして他人がそれをコピー、配布、販売するのをじゃましてはいけない。
さらに、だれが貢献した。
というクレジットはきちんとしろ。
これがかれのつくった、GPLというライセンス条項だ。

p229

これは四部作になるはずだ。
『伽藍とバザール』では、リナックスに代表される、フリーソフト・オープンソース開発の新しい方法論が分析されている。
一見すると荒唐無稽なその手法が、なぜ高い成果をあげることが可能なのか。
そしてそれが応用可能でほかにも適用できる方法論があることが、具体的なプロジェクトを使って実証されている。
二作目の『ノウアスフィアの開墾』 は、フリーソフト・オープンソースの開発者のコミュニティ論というのが一番適切だろう。
どうして金銭的な見返りのないところで、フリーソフトやオープンソース・ソフトにみんな貢献したがるのか。
三作目の「魔法のおなべ』は、経済論となる。
フリーソフトやオープンソースというのが商売のネタとしても十分に成立するし、それどころか、ソフト開発という産業分野そのものの主流となる必然性があるのだ、と論じた論文である。

最後の一本は、“Weaving the Net of Indra”。
オープンソースやフリーソフトにおける、ソフトアーカイブの役割について分析したものだという。

本当であれば、四部作の完結を待ってまとめたいところではある。
でも、この四番目はいつできるのやらさっぱり見通しがたっていないので、これを待っているといつになるやらわからない。
また、リナックスを中心としたオープンソースやフリーソフトへの関心がいま非常に高くなっているので、これをいまの段階で書物にしておくのは十分意味があることだろう。
本になればいろんなデータベースにも登録されるし、引用や参照もしやすくなるし、ネットへのアクセスのない人も触れられるようになる。

p231

著者エリック・レイモンドは、学者でもなんでもない。
市井のフリーソフト・プログラマでしかない。
それも独学の。
でも、この論文シリーズをきっかけとして、かれはフリーソフト・オープンソースのスポークスマン役となっていて、ソフトウェアがオープンソースの条件を満たしているかを判定する、オープンソース・イニシアチブの代表をやっている。
収録したインタビューは、かれが一九九九年五月末に来日したときのものだ。

p238

さて、この論文のテーマは以下の通り……なにゆえ人は、頼まれもせず、金がもらえるわけでもないのに、
そして世の中もっと楽しいことがいっぱいあるだろうに、フリーソフトなんぞをシコシコ書いて喜んでおるのか？

これまでの答は、おたくだから(それも一因だろう)、遊び方を知らないから(それもある)、
対人関係に問題があるから(否定はしません)、ガールフレンドがいないから(悪かったですねえ)、といったハッカーの人間的な属性に着目したものだった。
でも、フリーソフトの多くはすでに十分売り物になる。
卑近な例でいうと、ぼくは「ハロウィーン文書」を訳した。
原稿用紙で三〇〇枚強にはなるから、一〇〇万円は軽くとれる。
なぜそれを商売にせず無料で公開するのか？

レイモンドの答……みんな暇だから。
暇で、物質的にはある程度充足しているから。
これは大事なポイントだ。
そして、そういう物質的に充足した社会では、従来の市場による稀少資源の配分システムが機能しない。
そのとき、別の原理が働き出す。
贈与によって名声を得るという原理だ。
これがハッカーたちにフリーソフトを書かせる動機なのだ！
レイモンドはそれを手がかりに、フリーソフトにおける「知的所有権/領有権」の概念をグリグリとえぐりだす。
これが、この論文最大の醍醐味である。

p243

この論文には、ほくでさえいろいろ反論や疑問点がある。
その最大のものが、エリック・レイモンドの挙げる前提条件。
オープンソースではみんながチェックして貢献する、というのが大きな前提となっている。
しかしながら、モジラプロジェクトでもわかる通り(そして生まれては消えてゆく無数のオープンソース・プロジェクトでもわかるとおり)、
オープンソースにしただけでは、みんながチェックしたり貢献したりしてくれるとは限らないのだ。

さらにChageLogの田宮まやはこれについて「そもそもハッカー資源が無限だという暗黙の前提があるようだ」という非常に鋭い指摘を行っている。
これも、オープンソースにしただけで人が集まるとは限らない理由の一つとして十分にあり得る。

すると結局、オープンソース化するほうが有利だ、という議論は、必ずしも成り立たなくなってしまう。
そうならないソフト分野だって結局はいろいろあることになるだろう。

この翻訳の扱いについて p250

この翻訳は、ぼくがもともと自分のホームページでずっと公開しているものだ。
エリック・レイモンドは、原文の使用についてはいっさい条件をつけない。
フリーでどこにどういう形で使ってもかまわない。
許可をとろうとすると「You may use it freely」と一言返ってくるだけだ。

だからぼくも当然、翻訳の使用については条件をつけない。
許可をとる必要もない。
お金をくれるというなら、ありがたくいただくけれど、そのほとんどはフリーソフト関係の団体に寄付してしまうのだ(この本からのあがりも)。

こうして本になっても、それは変わらない。
ぼくのウェブページにある翻訳はそのままだし、相変わらずコピー、リンク、転載、一切オッケーだ。
そんな条件を認めてくれた光芒社も実に勇気がある出版社だ。
ある意味で光芒社は、オープンソース的なビジネスモデルを追求しているわけだ。
レッドハットと同じで、中身はネット上で公開されているものと同じだ。
でも、本としてのパッケージング、さらにこれをネットからダウンロードして印刷する手間を省くというサービスを提供することで、この本は商品として成立するだけの付加価値を持つようになっているわけだ。
オープンソース関連のレファレンス本で有名で、「魔法のおなべ」ではオープンソース的なビジネスモデルの例として紹介されている出版社オライリーでも、こういうことはしていない。
「やってみたけれど、丸ごとコピーした本を出されてしまって成立しない」というのがかれらの言い分だった。

本書はオープンソースの雄とされるオライリーですらできなかったことをやろうとしているわけだ。
オープンソース・フリーソフトの基礎文献が、同時にそれ自身オープンソース・フリーソフト的なビジネスモデルの実験となっている、というのは、実に興味深い、注目される事例ではないか。
こいつをエリック・レイモンドに教えてあげよう。
「魔法のおなべ」の次期バージョンでとりあげてくれるかもしれないではないか。

謝辞 p251

傲慢な言いぐさには聞こえるだろうけれど、この論文を訳したのがたまたまぼくだったのは、ある意味で幸運だったと思う。
ある程度は技術的なことも知っていて、同時に経済学や哲学っぽい話もわかっていて、翻訳者としての能力もあって、ということになると、なかなかいないぞ。

とはいえ、ぼくだって完璧じゃあない。
この翻訳は、バザール方式での翻訳の実験でもある。
アップすると、いろんな人が続々と、誤植や誤変換、あるいはぼくの調べがつかなかった参考文献邦訳などについて、どんどん教えてくれるのだった。
そして文中に疑問点を注記しておくと、必ずだれかが「それはこういうことではないか」とコメントをくれる。

さらに、原文の加筆部分について、自ら翻訳をして送ってくれる人までいる。
とくに大量に指摘・訂正を行ってくれた人々については以下にお名前を記して、感謝する。