オープンソースのソフト開発をサポートするビジネスモデルを見てきたので、 オープンにするのと、クローズドにするのとが、それぞれどういうときに 経済的になりたつのかという、もっと一般的な質問に取り組めるようになった。 まず、各戦略のメリットがなにかをはっきり理解しておくべきだろう。

　ソース非公開のアプローチは、自分の秘密の部分からのレントを集められるように してくれる。一方で、それは完全に独立したピアレビューの可能性を閉ざしてしまう。 オープンソースアプローチは、独立ピアレビューの条件を確立するけれど、 秘密の部分からレントを集めることはできない。

　秘密の部分を持つ見返りはよく理解されている。伝統的に、ソフトウェアの ビジネスモデルは、これを中心として構築されてきている。ごく最近まで、 独立ピアレビューからくるメリットは、あまり理解されていなかった。でも、 Linux OS は、インターネットの中核ソフトやその他エンジニアリング領域の歴史から、 ぼくたちが何年も前に学んでおくべきだった教訓を、改めて思い出させてくれる —— つまり、オープンソースのピアレビューは、高信頼性と品質を実現する スケーラブルな方式としては、唯一のものだということだ。

　だから競争市場では、高い信頼性と品質を求める顧客は、ソフト製作者が オープンソース化して、サービスや付加価値や隣接市場で収入を確保する方法を 見つけると、ごほうびをあげるようになる。この現象こそが、Linux の驚異的な 成功の裏にあるものだ。Linux は 1996 年にはないも同然だったのが、1998 年末には ビジネスサーバ市場の 17% 以上を制し、2 年以内にその市場で圧倒的シェアを 占めそうな動きを見せている（1999 年頭の IDC の予測では、Linux が 2003 年までは、ほかの OS すべてをあわせたよりも急成長をとげる）。

　オープンソースの同じくらいだいじな見返りは、オープン規格を広めて そのまわりに市場をつくりあげる手段としての効用だ。インターネットの 劇的な成長は、だれも TCP/IP を所有していないという事実に負うところが大きい。 だれもインターネットの核になるプロトコルに対して、独占的な鍵を 持っていないんだ。

　TCP/IP と Linux の成功の背後にあるネットワーク効果は、かなり はっきりしているし、最終的には信頼と対称性の問題に還元される —— 共有インフラに参加しようとする主体としては、その仕組みがいちばん底まで わかれば、合理的にそれを信頼できるし、さらに特定の主体がレントを引き出したり、 支配権を行使したりする特権的な地位にあるものよりは、参加者すべてが対称の 権利を持っているほうがうれしいはずだ。

　でも、ソフト消費者にとって、対称性の問題がだいじになるためには、別に ネットワーク効果がなくったってかまわない。もしそれなりの品質を持った オープンソースの代替手段があるなら、クローズドソースなんかに依存して、 サプライヤに牛耳られた独占状態に囲い込まれることを望む消費者なんかいない。 この議論は、ソフトウェアが消費者のビジネスにとって重要性を増すにつれて、 強力なものとなってくる —— それが重要になればなるほど、それが部外者に 左右されるのは大きな問題になるわけだ。

　最後に、オープンソース・ソフトで信頼の問題と関係しただいじな 消費者メリットとしては、将来の不安がない、という点がある。ソースが 公開されていれば、消費者は、ベンダーが倒産したときにも多少は手のうちようが ある。これは特に、「刺身のツマ」の場合にだいじだ。ハードウェアの ライフサイクルは短いけれど、その影響はもっと一般的で、つまりは オープンソース・ソフトの価値が高くなるということだからだ。

　秘密部分からのレントがオープンソースの利益より高ければ、 クローズドソースのほうが経済的に引き合う。オープンソースの利益が 秘密部分からのレントより高ければ、オープンソースのほうがいい。

　これだけ見ると、大した洞察じゃない。これが大したものになるのは、 オープンソースからの見返りが、秘密の部分からのレントよりも計測や 予測しにくいということを認識したときだ —— そして、その見返りは、大目に 見積もられるよりは、ものすごく低めに見積もられることのほうが多い。 実際問題として、主流ビジネス界は 1998 年初頭の Mozilla ソースリリース以来、 その置かれた立場を考え直しはじめているけれど、それまではオープンソースの 見返りは、ごく一般的にはゼロであると（まちがって）想定されていたんだ。

　では、オープンソースの見返りはどうやって評価しようか。一般的なかたちで 答えるのはむずかしいけれど、でもほかのいろんな予測問題に取り組むのと 同じやりかたで手をつけてみよう。まず、オープンソースのアプローチが実際に 成功したり失敗したりした観察事例からはじめる。それを一般化してモデルに 仕立て、収益最大化を目指す投資家や企業にとって、オープンソースが 差し引きで儲けをもたらすような条件について、少なくとも定性的な感触くらいは 得られるようにしよう。それからデータにもどって、磨きをかけていこうか。

　『伽藍とバザール』で提出された分析から見て、 オープンソースのメリットが高いのは次のようなときだと予想できる。 (a) 信頼性、安定性、スケーラビリティがとても重要な場合、そして (b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと 検証できない場合（この 2 番目の基準は、現実的にはちょっとでも複雑な ソフトならほとんどの場合にあてはまる）。

　消費者の合理的な願望としては、独占サプライヤに囲い込まれるのを避けたいと 思う。だからソフトがその消費者にとっての役割を高めるにつれて、 オープンソースに対する興味も高まることになる（そしてその結果、 サブライヤ側がオープン化する競争市場価値も高まることになる）。したがって、 ソフトがそのビジネスにとってクリティカルな資本財になるにつれて、別の基準 (c) がオープンソースへの圧力を高めることにある（たとえば、多くの企業の MIS 部門など）。

　アプリケーションの領域となると、さっき見たように、オープンソース・ インフラは信頼と対称性をつくりだし、それが長期的には、もっと顧客を引きつけて、 クローズドソースのインフラを競争でうち破ることになる。そして、こうした 急成長市場に小さな部分を持っておくほうが、クローズドで停滞した市場の 大きな部分を持っているよりも得なことが多い。同じように、インフラソフトの 場合には、オープンソースのように、いたるところに存在することを目指すほうが、 長期的には、クローズドソースのように知的所有権からのレントで得られる メリットより高い見返りを得られる。

　実は、潜在的な顧客が、ベンダー戦略の将来の帰結について論理的に考える能力を 持ち、サプライヤによる独占を受け入れたがらないということは、もっと強い 制約条件を意味している。すでにすさまじい市場支配力を持っていないなら、 オープンソースの遍在性を選んでもいいし、クローズドソースからの直接収入方式を 選んでもいい —— でも、両方はできない。（この原理と似たものは、ほかの 分野でも見られる。たとえば、電子部品の市場では、顧客はしばしば単一ソースから しか得られないデザインは拒否する。）この議論は、もっと否定的でない形でも 表現できる。ネットワーク効果（正のネットワーク外部性）が強いときには、 オープンソースが正しいことになることが多い。

　この論理をまとめると、オープンソースがクローズドソースよりも大きな リターンを生み出すのは、それが (d) 共通のコンピュータ・通信インフラを 確立するか可能にする場合である、ということになる。

　最後に、ユニークなサービスや、非常に差別化されたサービスの提供者たちは、 自分たちのやり方が競合相手にまねされるのをおそれるインセンティブが高い。 かなめのアルゴリズムや知識ベースがよく知られているようなサービスベンダーの 場合は、それが低いだろう。つまりは、(e) カギとなる手法（あるいはそれと 機能的に等価なもの）が一般的なエンジニアリング知識の一部であるときのほうが、 オープンソースが有力になりやすい。

　インターネットの中核ソフト Apache と、Linux の ANSI 標準 Unix API 実装は、 この 5 つの基準すべての見事な見本になっている。こういう市場が オープンソースへと進化する道筋は、DECNet、XNS、IPX みたいなクローズドな プロトコルで帝国を築こうとする、15 年にわたる試みの失敗に続いて データネットワーキングが TCP/IP に再統合されたのを見てもよくわかる。

　一方では、オープンソースがほとんど意味をもたないのは、価値を生み出す ソフト技術を独占的に保有していて（これで条件 (e) は立派に満たされる）それが (a) 失敗や欠陥があまり問題にならなくて、 (b) 独立ピアレビュー以外の方法で 簡単に検証できて、(c) ビジネスの生死を左右するものではなく、(d) ネットワーク効果や遍在性によって、その価値が極端に増えたりしないような 企業の場合だ。

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

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

　まとめると、オープンソースをすすめる差別化要因としては 次のようなものがある。

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

　id Software のベストセラーゲーム Doom の歴史は、市場の圧力と製品の 進歩によって、クローズド VS オープンソースのそれぞれのメリットが大きく 変わってしまうことを示す例だ。

　Doom が 1993 年末に初めてリリースされたときには、その一人称的リアルタイムの アニーメーションはまったくユニークなものだった（要因 (e) の対極、といおうか）。 ソフト技術の見た目のインパクトも驚異的だったけれど、それを当時の非力な CPU でどう実現していたのか、何ヶ月にわたってだれも解明できなかった。 この秘密の部分は、かなり大きなレントをとれるだけの価値を持っていた。さらに、 オープンソース化からくる潜在的なメリットも小さかった。単独ゲームだったから、 ソフトは (a) 欠陥があってもコストは我慢できるくらい小さかったし、(b) 検証するのもそんなにむずかしくないし、(c) どの消費者にとっても、ビジネスを 左右するようなものではないし、(d) ネットワーク効果のメリットもない。 だから Doom がクローズドソースなのは、経済的にも合理的だった。

　でも、Doom をとりまく市場はじっとしてはいなかった。競合候補たちは、 そのアニメ技術と張り合うものを開発してきたし、Duke Nukem みたいなほかの 「一人称撃ちまくり」ゲームも出てきた。こういうゲームが Doom の市場シェアを 喰いだしてくると、秘密の部分からとれるレントの価値も下がってきた。

　一方で、シェアを拡大しようという試みは、新しい技術的な課題をもたらした —— 信頼性を高め、ゲームの機能を増し、ユーザベースを広げ、マルチ プラットホーム対応にする。さらにマルチプレーヤによる「死闘」モードと、Doom ゲームサービスの登場で、この市場にもかなりのネットワーク効果が出てきた。 このすべてはプログラマの労働時間をとるものだったけれど、id Software としてはそれを次のゲームに割きたかったわけだ。

　このトレンドすべてが、オープンソースにするメリットを増やす方向に動いていた。 ある時点で、このメリット曲線が逆転して、id が Doom のソースを公開し、 ゲームシナリオのアンソロジーみたいな二次市場でお金を儲けるように シフトするほうが、経済的に合理性が高くなった。そしてこの時点からしばらくして、 それが実現した。Doom のソースコードすべてが 1997 年末に公開された。

　Doom がケーススタディとしておもしろいのは、OS でもなければ通信・ ネットワークソフトでもないからだ。したがってこれは、ふつうのよくある オープンソースの成功とはかけ離れている。実は Doom のライフサイクルは、 逆転ポイントもちゃんとあって、今日のコード生態における アプリケーションソフトの典型になりつつあるといえる —— つまり、 通信と分散計算が、深刻な堅牢性・信頼性・スケーラビリティの問題をうみだし、 それはピアレビューによってしか対処できないわけだ。そして技術環境の境界も しょっちゅうまたがり、競合する役者の間の境界にもまたがるものとなる （そしてそこから出る信頼や対称性の問題もすべて生じる）。

　Doom は単独ゲームから対戦型の死闘ゲームへと発展した。ますます ネットワーク効果こそがコンピュータそのものになりつつあるんだ。 同じトレンドは、ERP などのいちばん重たいビジネスアプリケーションにまで 見られるようになってきている。企業がサプライヤや顧客とますます密接に ネットワーク化されるようになっているからだ —— そしてもちろん、これは World Wide Web のアーキテクチャ全体に 暗示されていることでもある。ここから導かれる結論として、ほとんど あらゆるところで、オープンソースの見返りは着実に増えつつある、 ということになる。

　もしいまのトレンドが続くなら、21 世紀でのソフト技術と製品管理の 重要な課題は、いつソフトを手放すか、ということになる —— つまり、 クローズドなコードをオープンソース・インフラのほうに渡して、 ピアレビュー効果を活用し、サービスなどの二次市場での高い収益性を 獲得するのをいつにするのか、という問題だ。

　収益的なインセテンィブから見て、この逆転ポイントははずしたくないだろう。 早すぎても遅すぎてもいけない。それ以上に、手を打つのが遅すぎると、 機会リスクが深刻になってくる —— 同じ市場ニッチでオープンソース化する 競争相手に足をすくわれる可能性があるからだ。

　これが深刻な問題なのは、その製品カテゴリーについても、ユーザのプールや オープンソースの協力へと引き込める才能のプールも、有限だからだ。そして いったんそこに引き込まれたら、それはかなり続く。もし二つの企業があって、 だいたい同じくらいの機能を持つ競合コードをどっちもオープンソース化した場合、 たぶん最初にオープンにしたほうが、最大のユーザと、最大最高の開発者を 引きつけるだろう。2 番手は残り物に甘んじるしかない。そうやって引き込まれたら、 ユーザもそれに慣れるし、開発者たちもコード自体に時間を投資するので、 それは尾を引くことになる。