ゲームでお金を儲けるには、モノをつくって店に並べ、買ってもらわなくてはならない。多くの場合、オープンソースの手法は、製品の箱の中に入っているコードを改良するのに有効な方法だと思う。ゲームを一度プレイして忘れてしまうような末端のユーザとの間で、バザール・スタイルのやりとりを見ることなんてありそうもないが、もしこれがうまくやれれば、コードベースの改良を助けてくれる別のゲーム開発者をうまく取り込むことができるかもしれない。
注記：たいへん稀なケースとして、最も成功したタイトルが、ゲームの新しいプラットフォームへの移植や新しいレベルや武器などの追加を行ったユーザから恩恵を受けることがある。これはソースがクローズドな製品（例：Doom や Quake の類）でさえ起こりうるのだが、経験上ゲームにおいて最も成功した 0.001% でしかうまくいかない。他にも多くの開発者がレベルをデザインするユーティリティを公開することでこの種のユーザ参加を促そうとしてきたが、こうした努力は冷酷なシカトにあいがちであった。
最も賢明な戦略は、二方面でのアプローチであるようだ。ユーザにはパッケージ製品を売る一方で、ソースコードを別のゲーム開発プロジェクトに取り組んでいる同業者のグループに無償提供するのだ。これはすべてのユーザが潜在的な共同開発者であるとする、古典的な Linux 開発モデルとははっきりと異なるが、開発プロセスを二つの概念に分けると考えるなら筋が通っている。あなたの仕事を、チームのアーティストやデザイナーにゲームエンジンやツールを提供するものと考えてみよう。それらのシステムを使って彼らが最終的に市場で売られる製品を創り出す。オープンソースの思想は、市販ゲームの最終的な製品の開発工程にはあまり合わないかもしれない。しかし、アーティストをユーザとみなすなら、ゲーム・エンジンのような再利用可能な基盤プロジェクトには見事に合致する。
現状のゲーム・プロジェクトにおいては、こうした明確な分離は少しも行われてないが、その方向にははっきりと進んでいる。今日これを行えない唯一の理由は、誰も十分に柔軟性のあるエンジンを今のところ書いてないせいだが、これこそがまさにオープンソース式、インターネット式開発に適するものである。
大抵のゲーム会社は、たくさんの社内用ユーティリティ、エディター、ファイル・コンバーター、そして場合によってはコード・ライブラリを開発してきている。そうしたものはしばしば大変粗いつくりになっていたり、特定の作業に強く特化されていたりするが、こうしたものがオープンソース化のとっかかりとなるだろう。もしこうしたツール類をもう少し汎用性を持たせて作成する少しの手間をかければ、他の人たちがツール類を改良し、維持する負担を引き受けてくれる大変よいチャンスになるだろう。ゲーム自体に使われるサポート・コードでも同じことである。リソース管理、テキスト描出、そしてオブジェクト・レンダリングといった基本的なものが、古いバージョンのものが現在のプロジェクトで使うには十分な柔軟性をもててないという理由で、何度も何度も作られてきた。もしこうしたことが一度に、適切に、しかもオープンに行われるなら、皆にとって膨大な量の無駄な時間を節約することになるだろう。一部の企業にはこうしたことを内部で標準化しようとしたとこもあるが、その作業が充分になされるのに必要なリソースをふつう持ってない。
この種のお助けプロジェクトは大変結構であるが、他の開発者をそのエンジンの上でゲーム全体をつくるように納得させ、自分のとこの将来のプロジェクトにおいて利用できる拡張を集めることができれば、それが本当のボーナスとなる。必要となるのは、売るに足るマテリアルを十分に残しながら、一方で他の開発者が魅力的と思うに足るマテリアルを提供する、バランスである。もしコンパイルをちょっと試してみるのに必要なインフラもサポート・データもなしにちょっとのソースコードを公開しただけでは、誰からも相手にしてもらえないだろう。
ソースコードを最初の何面かのレベルと一緒に、オープンソース・ライセンスの元で公開し、残りのレベルデータを市販製品として売るやり方があるだろう。他の開発者にとっては、これは自分たちのニーズに応じて容易に適応可能なオープンソース・システムのように見えるし、ユーザにとっては、最初の何面かをフリーなデモのダウンロードとして入手可能にする現状のやり方と何も違いはないように見える。
もう一つの選択肢として、ゲームに特有のコードは秘密にしておいて、一般的なコンポーネントだけをライブラリとして公開するという方式がある。クローズドなソースや知的所有権の見地から考えるのに慣れた人たちにとっては、より安全に感じられるだろうが、（前述のより）実はずっと劣る考えであると私は思う。こうしたライブラリは、他の誰もにとって使い物になるようにする前に、大部のドキュメント、サンプル・プログラム、そして少なくともある程度のサポートといったものが必要となるが、九分九厘深入りしたいと思うものではない。もし、ゲームの完全にビルド可能で動作可能な複製を公開するなら、一方で、それがある程度ドキュメントの代わりになってくれるので、こうした作業は劇的に減少するわけだ。
どのように公開しようとも、極端なモジュール化が大変重要だ。後で使用するために改良点を集めるつもりでも、もしコードが異なる百万もの方向にバラバラに分裂してたら、うまくいきっこない。誰もがトップ・レベルの、ゲームに特化した部分を変えるであろうことを知っているのだから、必ず以上の部分を、再利用したいと思っている部分と完全に分離するよう手配する必要がある。私としては、いずれゲーム本体にリンクされるたくさんの個々のライブラリとしてビルドして、こうしたライブラリが、残りのプログラムをどのようにハックしようとも、完成版ときちんと同期されつづける再利用可能なコードであることを示すことを勧める。
「魔法のおなべ」の中で、エリック・レイモンドは、最初貴重な知的所有物であって後にオープンソースとなったゲームの一例として Doom に触れた際に、第三の可能性をほのめかしている。けれども私としては、これに関しては彼は間違っていると思う。というのも、彼はゲーム産業の変動の速度というものを正確に把握できていない。ID Software が Doom のソースコードを公開した頃には、その原理はとっくに理解されていただけでなく、誰もが既にレンダリング技術における「一つおいて次」世代のものに乗り換えていた。ソースコードの公開は、彼らにしてみればうまいジェスチャーだったわけで、確かにそうしたクラシック・ゲームの内部構造を見るのは興味深いことであるが、ID Software は、それが当時人々が従事しているものとは無関係になるのを待っていたのだ。二三のプロジェクトが Doom のコードを拡張しただろうけど、そうしたものは既に懐古趣味の趣であって、現在のゲームの開発というより、クラシックなアーケード機のエミュレーションの線を狙っているのだ。
私なら、まさに正反対の主張をする。つまり、もしゲームのソースコードをオープンにしたいなら、直ちに行動を起こさねばならない。もし一年待ったら、そのコードは技術開発において一年遅れの人たちにしか関係のないものになるだろうし、一年前に取り組んでいた拡張機能の類を提供されることになるだろう。これでは運動の要点がまるっきり無になってしまう。つまり、素敵で博愛的なジェスチャーであるが、そこから何の現実的な利益を得ることがないのだ。