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

　経済学でソフト生産について論じようとするとき、ほとんどの人は「工場モデル」を 仮定することが多い。このモデルは、以下の根本的な前提に基づいている。

1. ほとんどの開発者の開発時間に対する賃金はその販売価値に基づいて決まる。
2. ソフトの販売価値は、その開発コスト（つまり、その機能を再現するのに必要な資源のコスト）とその利用価値に比例する。

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

　まず、販売用に書かれるコードは、プログラミング氷山の一角でしかない。 マイクロコンピュータ以前の時代には、世界中のコードの 90% は銀行や保険会社の インハウスの自社開発ソフトなのが通例だった。たぶんこれはいまでは ちがっているだろう —— ほかの産業分野がもっともっとソフト集約的に なってきたし、それにともなって金融業界の占める比率も下がってきたはずだ —— でもこのすぐ後で、コードの 95% くらいはいまでも インハウスで 書かれているという経験的な証拠を示そう。

　このコードには、MIS（経営情報システム）のほとんどの部分、つまりあらゆる 大中企業が必要とする、財務・データベースソフトのカスタマイズが含まれる。 デバイスドライバのような、技術的に専門性の高いコードも含まれる （デバイスドライバを売って儲けている人はほとんどだれもいない。この点は また後でふれる）。工作機械からジェット旅客機、自動車や電子レンジや トースターなど、各種の機械はますますマイクロチップで制御されるように なっているけれど、そのためのいろんな機器組込用コードもここに入る。

　ほとんどのインハウス開発のコードは、その環境と密に統合されているので、 それを再利用したりコピーしたりするのはとてもむずかしい（ここでいう 「環境」というのがビジネスオフィスでの事務手続きであっても、コンバイン 刈り取り機の燃料噴射システムであっても話は同じだ）。だから、 環境が変わるにつれて、ソフトをそれに適合させるために、 たえずいろんな作業が継続的に必要になってくる。

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

　そこらの新聞の求人欄をながめてみるのは、なかなかに啓蒙的な実験なので、 読者のみなさんも是非やってみてほしい（訳注： アメリカでは、新聞の求人欄が新聞本体並に分厚くて本格的になっているから これができる。日本だと、技術系の求人情報誌でやってみるといい。）。 「プログラミング、データ処理、ソフトエンジニア」の欄で、ソフト開発に 関連した求人を見てみよう。そこで開発予定のソフトが、社内利用か販売用かで 求職を分類してみること。

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

　（技術関係の会議で話をするときには、ぼくはまず質問を二つすることが多い： 聴衆のうちで何人がソフト書きで収入を得ているか、そしてその中で何人の給料が、 そのソフトの販売価値に依存しているか。最初の質問では無数の手が上がるけれど、 二番目の質問では、手はほとんどかまったく上がらない。そしてこの比率に、 聴衆のかなりの部分が驚くのがふつうだ。）

　第二に、ソフトの販売価値がその開発コストや代替コストと関係しているという 理屈は、消費者の実際の行動をみればもっと簡単に撃破できる。こういう形の関係が （減価償却前に）成り立つ財というのはいろいろある —— 食物、車、工作機械 などだ。物理的な実体のない財でさえ、販売価値が開発コストや代替コストと 強く結びついているものはある —— たとえば音楽や地図やデータベースの 複製権など。こうした財は、最初のベンダーがいなくなっても 販売価値が維持されるし、その価値が高まることだってある。

　ところがソフトウェア製品のベンダーが倒産・廃業すると（あるいは その製品がうち切られただけでも）、消費者がその製品に対して支払う値段の上限は、 その理論的な利用価値や、機能的に同じものを開発するコストとはまったく 関係なしに、すぐにゼロに近づいてしまう（この主張を確かめたければ、 手近なソフト屋さんの売れ残り商品の棚を見てごらん）。

　ベンダーが倒産したときの小売業者の行動はとっても示唆的だ 。その行動をみれば、かれらがベンダーの知らないことを知っていることがわかる。 小売業者の知っていることは：消費者が支払う価格の上限は、その ベンダーのサービスの期待将来価値であるということなんだ （ここでいう「サービス」は、拡張やアップグレード、後続商品を含む 広い概念になる）。

　いいかえると、ソフトウェアは実はほとんどサービス産業なのに、 製造業だという強力だけれど根拠レスな幻想に基づいて運営されているわけだ。

　なぜぼくたちは、こういう現実と異なる思いこみをしがちなのか考えてみるといい。 それは単純に、販売のためにソフトを作っているソフト産業のわずかな部分が、 製品を広告宣伝する唯一の部分だからなのかもしれない。それに、いちばん 目について、派手に宣伝されているソフトウェア製品は、ゲームみたいな あぶく製品で、サービスを継続する必要性がほとんどないものだからかもしれない （これはあくまで例外的な製品だ）。

　それと気にとめておくべきこととして、この製造業的な誤解のおかげで、 開発コストの実際の構成比と病的なまでに乖離した価格構造が採用されている という点がある。もし（一般に認められているように）、ふつうのソフト プロジェクトのライフサイクルコストのうちで 75% がメンテナンスや デバッグや拡張に費やされるのなら、いまみたいに購入価格は高く固定しておいて、 サポート料は低いか無料にするというよくあるやり方は、どう考えても 万人にとってよからぬ結果になるはずだ。

　消費者も損をすることになる。ソフトはサービス産業なのに、工場モデルの インセンティブはあらゆる面で、ベンダーがまともなサービス 提供を行う妨げにしかならないからだ。もしベンダーのもうけがビットを 売ることからくるなら、能力のほとんどはビットをつくってそれを出荷することに あてられる。ヘルプデスクは、収益部門ではないから、いちばん能力のない 従業員のはきだめになり、顧客の大多数を完全に追い払わない程度の、 ギリギリ最低限の資源しかまわされないことになる。

　そのまさに裏返しとして、この工場モデルを採用しているベンダーのほとんどは、 長期的には失敗することになる。固定価格からの収入だけで、果てしなく 続くサポートコストを維持するのは、市場が急速に拡大していて、昨日の 売り上げから生じるサポートコストやライフサイクルコストを、明日の収入で カバーできる場合に限られる。いったん市場が成熟して売り上げ成長が鈍ってきたら、 ほとんどのベンダーはその製品を見捨てることで コストを削るしかなくなってしまう。

　これがはっきりわかる形で行われるか（つまり製品をうち切るか）、あるいは それとなくやるか（サポートがなかなか得られないようにするか）、 どっちにしても、顧客は競合相手のほうに行ってしまうことになる （なぜかというと、それはそのサービスにかかっている期待将来価値を 破壊してしまうからだ）。短期的には、バグフィックス版を新製品と称して発表して、 新しい値札をつけることでこの罠を逃れられるだろう。でも消費者はすぐに これにうんざりしてくる。だから長期的には、唯一の方法は競合相手を 持たないことだ —— つまり、市場を実質的に独占してしまえばいい。 最終的には、残るのは一人だけしかあり得ないんだ。

　そして確かに、この手のサポート不足による失敗のおかげで、ある市場領域の 強力な二番手競合製品でさえつぶれるのは、何度もみてきたはずだ（このパターンは、 PC 用独占 OS やワープロ、会計ソフトやビジネスソフト一般の歴史を 調べてみた人なら、だれでもはっきりわかるだろう）。工場モデルがもたらす まちがったインセンティブのおかげで、一人勝ち式の市場力学がつくられてしまい、 結局は勝者の顧客も損をすることになる。

　工場モデルでなければ、どういうモデルがいいんだろう。ソフトの ライフサイクルでも実際のコスト構造を効率的に（ここでの「効率的」というのは、 ふつうの口語的な意味と経済学の専門用語での意味の両方をさす）扱うためには、 サービス契約や購読など、ベンダーと顧客の間の価値交換が 継続的に行われるような価格構造が必要だ。だから 自由市場の効率性追求条件のもとでは、成熟したソフト産業が最終的に 採用するのは、こういう価格構造だろうと予想できる。

　いままでの議論で、オープンソースソフトがこれまでの体制秩序に対して、 技術的だけでなく経済的な意味でも挑戦状をつきつけるものとなる理由について、 だんだん見えてきたと思う。ソフトを「自由／無料（フリー）」にすることで、 どうやらソフトはぼくたちを、サービス料金が支配する世界に無理矢理押しやる ことになるようだ —— そしてクローズド・ソースのビットの販売価値が、 実はずっと、かなり貧弱な目くらましだったことを暴露することになるんだ。

　「自由／無料（フリー）」という用語は、別の意味で誤解を招きやすい。 ある財のコストが下がると、それを支えるインフラに対する投資は、減るのでは なくて増えることが多い。車の値段が下がると、自動車メカニックへの需要が上がる —— それだから、いま販売価値によって対価を得ている 5% のプログラマも、 オープンソースの世界で困ったりはしないことになる。この転換の過程で損を するのはプログラマじゃなくて、不適切なクローズド・ソース戦略に賭けてきた 投資家たちなんだ。