ハーディンの有名な議論では、まずお百姓さんたちの村に共有の草地があるものと想像してみてほしい。お百姓さんたちは、そこで牛に草を食べさせる。でも、牛が草を食べるとその共有地の状態は悪くなる。草は引きちぎられて、泥の穴が残り、そこに草がまた生えるまでには時間がかかる。もし、草の食べ過ぎを防ぐような、放牧権を割り当てる方針が合意され（そして強制され！）なければ、お百姓さんたちは一人残らず、我先に急いでなるべくたくさんの牛をそこに放って、共有地がただの泥沼と化す前に最大の価値をそこから引きだそうとするはずだ。
　協力行動について、多くの人の直感的なモデルはいまの例とだいたい同じだ。これは実は、オープンソースの経済問題についてあまりいい診断にはなっていない。オープンソースの問題はただ乗り問題（提供不足）であって、混雑した公共財（使いすぎ）ではないからだ。それでも、最初に出てくる反論のほとんどは、これが裏付けになっている。
　共有地の悲劇モデルだと、予想される結果は三通りしかない。一つは泥沼。一つは、だれか脅しの使える主体が、村のために配分方針を強制する方法（共産主義的な解決法だ）。三番目は、村人たちが自分の守れる範囲を柵で囲って、維持可能な状態を保つことだ（知的所有権による解決）。
　このモデルを反射的にオープンソースに適用するために、みんなオープンソースの寿命はすごく短いはずだと予想する。インターネット上では、プログラマの割く時間の配分を強制するはっきりした方法はないので、このモデルを使うと、共有地はどうしても細分化して崩壊するしかない。ソフトのいろんな部分部分がクローズドになって、共同のプールに還元される作業の量は急激に減ることになる。
　ところが経験的にいって、実際のトレンドはその正反対なのは明らかだ。オープンソース開発の広がりと分量（これはたとえば、Metalabへの登録や、freshmeat.netでの一日あたりアナウンス量なんかで計れる）は着実に増えている。明らかに「共有地の悲劇」が実際のできごとをとらえきっていない、重要な部分があるんだ。
　答えの一部はもちろん、ソフトは使っても価値が減らないという事実からくる。それどころか、オープンソース・ソフトは広く使われることで、その価値を高める。利用者たちが自分自身のバグ修正や追加機能（コードパッチ）を追加してくれるからだ。この逆転共有地では、みんなが放牧すればするほど草が増えるわけだ。
　答えのもう一つの部分としては、共通のソースコードのベースに対する小さなパッチの推定市場価値を回収するのはむずかしいという点があげられる。たとえばぼくが、悩ましいバグの修正パッチを書いたとしよう。そして多くの人が、そのパッチには金銭的な価値があることを認識したとする。その人たちから、ぼくはどうやってお金を集めればいいだろうか。伝統的な支払い方式では、オーバーヘッドが大きすぎて、こういう場合に適切となるような少額の支払いをするときには大きな問題になる。
　でももっと本質的な点として、その価値は回収がむずかしいだけでなく、一般的にいってその値段を決めることさえなかなかできない、ということが指摘できる。思考実験として、理論的にみて理想的な少額支払いシステムがインターネット上にできたとしよう――高セキュリティで、だれでも使えて、オーバーヘッドなし。さて、「Ｌｉｎｕｘカーネルのいろんな修正」というパッチをあなたが書いたとする。これに対する要求価格はいくらにすればいいだろう。買い手候補は、そのパッチを見ないで、いくら支払うべきかどうすればわかるだろう。
　ここに出てきたのは、Ｆ・Ａ・ハイエクの「計算問題」の戯画版みたいなものだ――この取引をスムーズに行うには、このパッチの機能的な価値を評価して、それに応じた値段をつけてくれると信頼できるような、超越的存在が必要になってしまう。
　残念ながら、超越的存在はいまも昔もえらく品薄で、こんな場面にはお出ましいただけない。だからパッチ作者たるハック素留造くんの選択肢は二つしかない。そのパッチを抱え込んでおくか、あるいはフリーでプールに投げ出すか。前者だと、なにも得られない。後者でも、なにも得られないかもしれないけれど、でもほかの人たちに相互に与えあうよう奨励して、いずれハック素留造くんの問題を解決してくれるような贈与につながるかもしれない。二番目の選択は、一見愛他的だけれど、実はゲーム理論的な意味で、最適に利己的な行動になっている。
　
　「魔法のおなべ」（エリック・Ｓ・レイモンド）訳：山形浩生・田宮まや
　http://cruel.org/freeware/magicpot.html