ID Software は、ゲーム・エンジンを他の開発者にライセンスすることで大金を稼いできたので、彼らにとってオープンソース化というのは、とてもではないが賢明な策には見えない。思うに彼らはオープンソース・モデルの元でもなおゲームを売ることが可能で、多くのフリーな移植やハードウェアの追加サポートにより、利益を得るだろうが、他の開発者からのライセンスによる収入は決して維持できないだろう。もし報酬が十分に大きなものなら、知的所有権の目玉は健在であるし、その中身を見る手配が可能であるということだ。
けれども、ID Software は、マルチプレイヤーによるデスマッチ型ゲームの市場に完全に専念しているのだから、大抵の開発者とは著しく事情が異なる。デスマッチ型対戦は普通のゲームよりもスポーツに近い動作をするものなので例外的な存在であって、筋肉の記憶に依存していて、二三の基本的で学習された動作の反復であり、普通動ける領域は大変限られている。デスマッチ型ゲームに入れ込んだユーザは、何年も継続して同じゲームをプレイし続けがちで、目先を変えるために新しいシングルプレーヤー・ゲームを買って遊ぶとしても、マルチプレイヤーのアクションがやりたいと思ったときには長年やりなれたお気に入りのゲームに戻ってくる。シングルプレーヤー・モードで同じ面を繰り返す人間など滅多にいないが、どんなデスマッチ型ゲームのプレイヤーでも、幾つか個人的なお気に入りのゲームがあるものだ。そうしたスポーツとの類似性は、Quake シリーズにおけるチーム文化に着目すれば、特に明白である。
スポーツにおける面白さは、それをやる場所よりも、やった内容からもたらされるものだ。長方形でしきった芝生や膨らませた皮製のボールといったもので、過去数千年に渡り設備として足りてきたわけで、Quake がこれを変えるということはないだろう。環境を変えてみたり複雑にしてみたりといったことはあまり重要ではないので、ID Software が同じコンセプトに基づいたゲームを技術的に向上させただけのもので驚くべき額の金を稼いでいようと、それは大きな単一のマーケットであって、そこで儲けようと思う企業は現在のチャンピオンをうっちゃるしかない。大抵の開発者にとっては、デスマッチ型スポーツ市場を乗っ取るというお流れになった企てに賭けるより、もっと古典的なタイプのゲームにこだわるほうがずっと魅力的である。(デスマッチ型スポーツ市場はスポーツ・シミュレーションとは違うんだ。スポーツシミュレーションは実際はゲームなのだけどね、ふん！:-) 鍵となる特徴は、ゲームがその多様性や複雑なところでもって成功していることだ。グランドを駈け回る野郎どもの一団というよりは、物語性、呼び物となるアクション、値の張るホテルに滞在するプラスティックの子犬といったものを想像していただきたい。
純粋に技術的な優位性を持ったゲームを売るのは本当に、本当に難しい。技術について現状と同じところまで達するだけでも、何年もの開発と大規模な研究開発のコストがかかるし、それを全部やった挙げ句に収益があがるという保証は何もない。ほとんどの企業はそうしたことを試みすらせずに、「十分に優れた」エンジンを開発し、それからその上で優れたゲームを作ることに集中しようとする。こうした状況下では、知的所有権というものが意味を失い、ソースコードを公開しない理由など完全になくなる。ありもしない秘密をただ投げすることにより失うものは何もなく、もし共同開発によって、技術を少しでもより完全なものに近づけることができるなら、素晴らしいものを得ることになる。
矛盾するようだが、技術市場のリーダーは大抵、ソフトウェアの動作に関して最もオープンでもあるものなのだ。John Carmack（訳注：Doom、Quakeシリーズを手掛けたハッカー）は、エンジンに関する細目にわたる最新の開発やアイデアについて、定期的に .plan ファイルを更新し、Quake で使用された基礎技術はすべてゲーム自体が発売されるずっと以前に活字になっていた。ゲーム産業には多大なパラノイアも過度の秘密主義も存在するが、どういうわけかそうしたものは、実は隠すべき秘密があまりない部分に集中しているようなのだ。
この一見矛盾するように見えるこの現象に関する説明として、ゲームのコードを書く人間が、幾分特大のエゴを抱える傾向にあることが挙げられる。もしあなたが他の誰もが欲しがる技術を持つなら、それを公に見せびらかすことによってエゴを満足させることができるというものだ。他方、もしあなたが標準的で広く知られた技術のみを使っていても、あなたの仕事の価値や独創性を気持ち的に誇張するのはまったくもって簡単なことだ。営業部はこの種の考えを好み、通りかかったジャーナリストの誰にでも吹聴しはじめ、気がついてみたらプログラマーのエゴが調和もへったくれもないくらいに膨張して…というようなサイクルが繰り返されるのである。
エゴという奴はあらゆる種類のソフトウェア開発において有害であるが、特に共同作業においては避けては通れない。ゲーム開発者は皆、オープンソース手法について熟考しようがしまいが関係なく、ちょっとは視点を内に向け、この死の伝染病にかかってないか確かめるのが賢明である。malloc() はメモリを断片化する問題があるから malloc() には頼れないと主張して、結果的に libc における実装よりもずっとひどく断片化を行う自分達のメモリ・マネージャに交換するという人達を、これまで私が何度も見てきたのを信じてもらえないだろうな！
実際のところ、多くの（ひょっとしたら過半数？）商用に開発されるゲームのソースコードは本当にひどいものだ。本当にひどいんだよ。私は沢山のゲームを自分で書いてきたので、ここではちょっとした権威として喋ることができるんだ:-) ゲームは厳しい納期に合わせて開発され、一旦出荷されれば、コードベースは終わりとなり、それに触れることはその後ずっと決してないことは知られている。プロジェクトの初期においては、正しいソフトウェア工学を実践するだろう。というのも、結局のところ、１８ヶ月かそこらに渡ってそのソースコードに従事するのだし、土台となるしっかりした枠組みがあれば、それはずっと楽になる。けれども、締切りまで一月に迫った日曜の午前２時あたりという大変間近までくると、大量のバグ・レポートが１マイルの高さまで山積みとなり、そんなものは全部無用なものになる。バグが実は基本デザインの不備による症状であるなんて誰が気にかける？ 後から継ぎはぎできるというのに。そのパッチが他のもっと微妙な問題を持ち込んだとして誰が気にする？ だって数ヶ月間のテストで誰もそれを指摘しないで乗り切れさえすれば、ゲームは解き終えられているだろうし、その問題を気にかけることなんて二度とないだろう。
もしゲーム産業で働き、自分の作ったソフトウェアを貴重な知的財産であると考えるのなら、そんなことを考えるのは止めにして、自分に問いかけてみることだ。自分が書いたコードから他社が競争上の優位性を得るのが本当に心配なのか？ そうでなく、単にソースコードを見せるのが恥ずかしいだけではないか？