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

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

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

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

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

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

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

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

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

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

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

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

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

　この手の協力を分析するときには、ただ乗り問題はあるにはあるけれど（お金や、 お金に相当する見返りがなければ仕事は充分に提供されないかもしれない）、 それがエンドユーザの数に比例するようなものではない、 ということを理解することが大切だ。オープンソースプロジェクトの複雑さと コミュニケーションのオーバーヘッドは、ほぼ完全に、参加している開発者の数の 関数になる。ソースなんか見ないエンドユーザをいくら抱えていても、 コストは実質的にゼロだ。プロジェクトのメーリングリストに流れてくる まぬけな質問の比率は高くなるかもしれない。でもこれは、FAQ（よくある質問一覧） をつくっておいて、それを明らかに読んでいない質問者はあっさり無視することで、 そこそこ簡単に対処できる（そしてこれはどちらもごくふつうに行われている）。

　オープンソースソフトの真のただ乗り問題は、むしろパッチを提出するときの 摩擦コストに比例したものとなる。この文化での評判ゲーム （『ノウアスフィアの開墾』を見てね）で失う物があまりない、潜在的な貢献者は、 金銭的な見返りがなければこう思うかもしれない：「このパッチを送っても 引き合わないよ、パッチをきれいにして、変更履歴のための要約も書いて、さらに FSF への移譲書類にサインしなきゃならないし……」　このために、 あるプロジェクトの貢献者の数（そしてその次にくるものとして、 プロジェクトの成功）は、各ユーザが貢献するにあたってくぐりぬける必要のある 関門の数と、強く反比例している。こういう摩擦コストは、単に 機械的なものではなく、政治的なものでもある。この 2 つを合わせると、 縛りのゆるい、不定形の Linux 文化が、緊密に組織化されて中央集権化している BSD 類に比べて、何倍もの創造的なパワーを発揮しているのかを説明できそうだ。 そして、Linux の台頭とともに、フリーソフト財団の相対的な重要性も 退化したのもたぶんこのためだ。

　これはこれで結構な話だ。でも、これはそのハック素留造くんがパッチを 書いてから、さてそのパッチをどうしようかという事後的な説明だ。 ぼくたちに必要な残り半分は、そもそもそのハック素留造くんがどうし そのパッチを書けたかという経済学的な説明だ。クローズドソースのソフトの 作業をすれば、販売価値を得られたかもしれないのに、ハック素留造は そうしなかった。オープンソース開発が華開くようなニッチをつくりだす ビジネスモデルというのは、どんなものだろう？