The Open Source Definition

Navigatorのソースコードの公開
―Mozillaの物語―

Jim Hamerly、Tom Pazuin、Susan Walton
ジム・ハマーリィ／トム・ペイジン／スーザン・ウォルトン
Translation by Akira Kurahone



一九九八年一月二十三日、ネットスケープ社は二つのことを公表した。その一つについて、Ｃ／Ｎｅｔは次のように伝えた。「前例のない措置として、ネットスケープ・コミュニケーションズ社はブラウザのナビゲータを無料配布することになり、数週間前から流れていた噂を裏づけた」
　そして二つ目は、次のようなものだった。「同社は、コミュニケータの次期バージョンのソースコードも無償公開する」
　ブラウザの無料配布の決定は意外なことではなかったが、ソースコードの公開は業界に衝撃を与えた。そのニュースは世界中の新聞に掲載され、オープンソースコミュニティでさえ度肝を抜かれるほどであった。かつて、大手のソフトウェア会社がクローズドなコードを公開したことはなかった。ネットスケープ社は何をねらって、それをあえて行なうことに踏み切ったのだろうか？
　我われは競争場裏の様相を一変させるという−何度目かの−決意をしていた。社外の見方としてかねてから知られていたとおり、我われは、よりよいインターネット環境を新しいレベルで確立することに取り組んでいた。一九九四年、ネットスケープ社がブラウザの初期バージョンをインターネット上で自由に配布しはじめたとき、人びとは「どうかしている！」と言ったが、我われが「ソースコードを公開する」と発表したときも、彼らは同じことを言っている。
　オープンソース化の公表にいたる話し合いの日々は、怒濤のように過ぎていった。最終決断が下される日まで、我われはバイナリ版を無料でリリースするかどうかを何か月も討議してきていた。そして、その長い話し合いの結果が最後の二十四時間になって、ソースコードを無償公開するという信じられない結果となったのである。
　ソースコードを無償公開するという発表は、内部の人間にとっても部外者にとっても性急で意外なものに思えたが、そこにいたるまでにはかなりの紆余曲折があった。ネットスケープ社の役員たちは、フランク・ヘッカーの技術白書について討論していた。ヘッカーはその中で、ネットスケープ社がソースコードを無償公開するべきであるという見解を全面的に打ち出していた。彼は、入念に行なった下調べに基づいて、エリック・レイモンドの論文「伽藍とバザール（The Cathedral and the Bazaar）」を引用しながら、技術部門からマーケティング部門、経営部門のトップ、つまりネットスケープ社の全部門のトップに語りかけた。出席者全員に手渡された二十ページに及ぶ資料の中で、彼は、今や拍車のかかりつつあるソースコード公開の動きについて次のような主張を展開した。



　技術部門にも同様の意見があった。ネットスケープ社のエンジニアの多くは、オープンソースを使って仕事をした経験があった。それに、コミュニケータのコードがＪａｖａやＨＴＭＬに強く結びついていたこともあって、大方の人間は（ソースコードを公開するという）新たな事実をそれほど大げさに考える必要はないと思っていた。Ｊａｖａには、ソースコードの公開をうながす性質がある。Ｊａｖａコンパイラはクロスプラットフォームであり、特定のマシンに依存しない実行形式のクラスファイルを生成できるので、それぞれの実行ファイルはバーチャルマシンに似ている。これがもたらす結果の一つとして、プログラマは実行ファイル（つまりＪａｖａバイトコード）を逆コンパイルしてソースコードに戻すことができる。また、ブラウザの「表示メニュー」の「文書のソース」コマンドを実行することで、誰でもＨＴＭＬで記述されているホームページの内容を取り出せたので、このＨＴＭＬはホームページを作成する一般的な記述言語になっていた。ネットスケープ社は、その流れに逆らうよりも、できればその流れにうまく乗りし、その流れを加速させ、そこから利益を得るべきだと多くの人びとは考えていた。
　ミーティングでは、意見が百出したが、ソースコードを公開すべきという提案に対する人びとの反応は、数分のうちに驚きから同意へと変化し、討論の大部分は、「実行すべきか」ということからたちまち「いつ実行すべきか」ということに移った。主だった幹部のほとんどは、すばやく行動して期日を決め、計画を実現する必要があると考えた。そして一九九八年一月、ネットスケープ社はインターネット上で、コミュニケータのソースコードを一九九八年三月中に公開することを告知した。ネットスケープ社はこの約束を真剣に守るべく、プロジェクト・ソース331という計画を発足させた。なお、プロジェクト・ソース331というプロジェクト名は、ネットスケープ社が総力をあげて一九九八年三月三十一日までにソースコードを公開する、という意味であった。
　こうして、ネットスケープ社によるソースコード無償公開の計画は実行に移された。


計画の実現
　ネットスケープ社では、コミュニケータのソースコードの本体を「Ｍｏｚｉｌｌａ」というコード名で呼んでいた。（ネットスケープ社の元々の名前であるモザイク・コミュニケーションと日本の伝説的な怪獣ゴジラとをかけ合わせて）Ｍｏｚｉｌｌａという言葉を最初に考え出したのは、このブラウザの開発チームの一員であったジミー・ザインスキー（Jamie Zawinsky）である。Ｍｏｓａｉｃよりもはるかに強い怪獣はすさまじいでスピードで開発されたが、それとともにＭｏｚｉｌｌａという言葉もすさまじいスピードで社内に広まり、このブラウザの正式コードネームとなった。やがて、大きな緑色の怪獣は社内のジョークのネタになり、会社のマスコットになり、しまいには誰もが知っているマスコットキャラクタとなった。こうして、Ｍｏｚｉｌｌａという名前は、ナビゲータのソースコードのオープンソース版を表わすことになった。ナビゲータをオープンソース化する計画の目的は、「怪獣を自由にする」ことにあったのである。
　最高のタイミングをねらってソースコードのオープンソース化を実現するためには、こなすべき課題が山ほどあった。それらは認識されしだい、いくつものカテゴリーに分類され、どのようなものか吟味された。実際のオープンソース公開までにいたる三か月は、これらの課題を解決するために費やされたが、そのペースたるや、ネットスケープユーザにはおなじみのすさまじいものであった。
　これらの課題の中で最も大変だったのは、知的所有権が第三者に帰属するモジュールの処理であった。コミュニケータのソースコードには、サードパーティのモジュールが七十五個あまり含まれていた。そして、我われは、それらソースコードの所有者全員と交渉する必要があった。我が社のエンジニアとエバンジェリストたちはチームを組織して、ネットスケープ社とともにオープンソース化を目指すというアイデアを説いて回った。それらの会社はみな、ネットスケープ社のオープンソース宣言を伝え聞いており、それぞれの決定を次の三つの選択肢から選ぶことができるようになっていた。つまり、彼らは、コードを引き上げてしまうこともできた（コードを取り除いたり入れ替えたりしてしまう）。バイナリ形式（コンパイルされた状態）で出荷することもできた。コミュニケータにソースコードを含めて出荷することもできた。しかし厄介なことに、これらの相手先との契約は独特の形態で交されているものがの多かった。契約の有効期間がまちまちであった。そのため、我われには、すべての相手先に通用するようなシナリオがなかった。
　プロジェクト・ソース331では、期限を切って問題解決にあたらなければならなかった。そのために我われは厳しい選択に迫られたが、サードパーティに参加してもらうのか、不参加ということにするのかの決定もまさに二月二十四日までに期限を切って下さなければならないことだった。その日までに参加するという返事が所有者からもらえない部分のコードは、コミュニケータのソースコードから削除するという前提で我われは交渉にあたっていた。このような期限を設定するのは造作もないことだが、いざそのときになってみると、野蛮な話である。そして、我われは、いくつかのサードパーティ製のモジュールのコードを実際に削除しなければならなかった。
　Ｊａｖａはオープンソースでなかったので、Ｊａｖａで書かれた部分はすべて削除する必要があった。この「Ｊａｖａ切除」の仕事は、二人のエンジニアにまかされた。彼らは、Ｊａｖａを使わないでブラウザを作成し、動作させなければならなかった。Ｊａｖａがしっかり組み込まれているブラウザのソースコードから、その部分をすべてはずし、その上で、ちゃんと動作するものに作り直すのは容易な仕事ではなかった。目標は、三月十五日までにソースコードを仕上げ、残りの二週間をデバッグテストの時間にとれるようにすることであった。エンジニアたちは、信じられないほど短い時間で、Ｊａｖａで書かれている部分を完全にブラウザから外さなければならなかった。
　この作業は大事業であったため、期限までに終わるはずがないと思った人も多かった。しかし、ミーティングで雰囲気が盛り上がるにつれて、戦略が練られていき、歯車は回りはじめた。プロダクトチームは、すべての作業を一時的に棚上げにし、全員が外科手術にとりかかった（彼らのほとんどは次期ブラウザの開発に携わっていた）。サードパーティの部分は、含めるのか外すのかを一つひとつのモジュールごとに決定しなければならなかった。また、ソースコード中のコメントもすべて編集し直す必要があった。作業はチーム体制で進められ、モジュールごとにチームの責任で作業が遂行された。
　我われは、非常に早い段階から、イントラネットのバグレポートシステムを利用して作業管理を行なうことにしたが、この決定はこの作業を進めるうえで非常に効果的だった。我われは、ＨＴＭＬインターフェイスを持つ顧客サービス支援情報管理ソフトＳｃｏｐｕｓを使って「Ｂｕｇｓｐｌａｔ」というバグレポートシステムを作った。このシステムは、作業管理システムとして理想的だった。新たに対応しなければならない案件が報告されると、バグが報告された場合と同様、その対応の優先順位が決定され、作業に適する人間が選定され、それぞれの情報が単純なＨＴＭＬ形式でシステムにインプットされ、メーリングリストの一環として管理されれる。そして、それぞれの作業ごとに必要な情報がメーリングリストの形でやりとりされる。作業が完了すると、関連メーリングリストは用済みになって、システムから消えるようになっている。エンジニアたちは、このイントラネットシステムを利用することで、自分の担当しているモジュールの作業状況がどうなっているかをチェックし、進捗状況を把握することができた。
　暗号化モジュールの削除も困難な作業であった。アメリカ政府が、暗号化をしている部分をすべて削除したうえで、暗号化に関わりのある部分を呼び出している部分もすべて書き直さなければならないと言い張ったからである。あるチームは、ＮＳＡ（National Security Agency−国家安全保障局）とたえず連絡をとって、当局の定めた方針に準拠する形で作業が進んでいるかを確認することが仕事となった。


新しいライセンスの作成
　コード一掃の大作戦と並行して進められたのがライセンスへの取り組みである。我われはまず、既存のライセンス形態の中にオープンコードに適用できるものがあるかという大問題を解決しなければならなかった。新しいライセンスを起草したいという者はいなかったが、知的所有権がサードパーティに帰属しているコードをすべて含めた上で、オープンソース化をはからなければならないことは誰もが承知していた。そして、知的所有権が設定されている商用ソフトウェアに対してフリーソースライセンスが適用された例は今までにまだなかった。
　そこで、オープンソースコミュニティのリーダーたちが、カリフォルニア州マウンテンビューのネットスケープ社に招待された。リーナス・トーバルズ、エリック・レイモンド、そしてティム・オライリーなどが、今後のことについて同社経営幹部や弁護士やプログラマと顔を合わせ、少人数のグループに別れて話し合った。彼らは、ネットスケープ社がこれから直面することになりそうな問題について話しい、同社の法律チームと一緒に、既存のライセンスの長所や問題点を何時間もかけて吟味した。オープンソースコミュニティのリーダーたちは、様々なアイデアに対して感想を述べる役割もはたした。
　あるチームは、ネットスケープ社の法律チームの指導のもとに既存のライセンス契約について調べ、そのうちの一つがＭｏｚｉｌｌａに適用できるかどうかを確認しようとした。彼らは、ＧＮＵ一般公有使用許諾（ＧＰＬ）、ＧＮＵライブラリ一般公有使用許諾（ＬＧＰＬ）、ＢＳＤライセンスを手始めに時間をかけて調査し、それらのライセンスによって何が解決でき、何が解決できないかをあぶりだした。それらのライセンスが過去に適用された場合と違って、ネットスケープ社の既存のコードベースは特異な状況を生み出していたが、最も厄介な問題は、ソースコード中にサードパーティのコンポーネントが含まれており、その所有者の多くとネットスケープ社が商用ライセンス契約を交していることであった。したがって、新しいライセンスは、そのようなサードパーティの利権を保護しながら、なおかつ彼らがＭｏｚｉｌｌａのソースコードに貢献できるような環境を整えるものでなければならなかった。
　著作権表示さえきちんとすればコードを無制限に書き換えられるＢＳＤライセンスは、Ｍｏｚｉｌｌａのライセンスとしてはふさわしくないと思われた。ＢＳＤライセンスでは、公開されたソースコードに加えられた変更部分のコードが、原著作者やコミュニティに還元されないおそれがあり、そうなると、Ｍｏｚｉｌｌａのオープンソース方式の開発を存続させていくのが難しくなってしまう。新しいライセンス作りにおいては、この問題を解決するだけでも大変なことであった。
　一方、ＧＰＬは必要条件の点で我われには望ましくなかった。ＧＰＬは「伝播性」のあるライセンスである。つまり、ＧＰＬのライセンシングの下では、ＧＰＬが適用されている原ソースコードと一緒にコンパイルされたコードに対してはＧＰＬを適用しなければならない。このような性質を持つＧＰＬは、商業ソフトウェアには不都合であった。たとえば、ＧＰＬが適用されると、コミュニケータと一緒にコンパイルされたサードパーティのコンポーネントもＧＰＬされなければならないが、ネットスケープ社がそれを強要することはできない。ネットスケープ社がそれらのサードパーティを支配しているわけではないからである。また、ネットスケープ社自体も、コミュニケータのコードの一部分を他の自社製品（サーバなど）に使っている。ネットスケープ社にはそのソースコードをいますぐ公開する予定はないため、それらの製品にＧＰＬの伝播性が及ぶことは、ネットスケープ社にとっても問題になのである。ＧＰＬの変形であるＬＧＰＬは、ＧＰＬより自由で制約が少なく、商用目的での開発に適用しなければならないというネットスケープ社の要求に最も合っていたが、それでもＧＰＬと同じ問題点を多く抱えていた。
　世間の注目の中で、フリーソフトウェアコミュニティの専門家や支持者をまじえての調査、検討、ミーティング続きの嵐のような一か月間が過ぎたとき、ネットスケープ社のチームは、この特殊な状況に合った新しいライセンスを作る必要があると判断した。こうして生まれたネットスケープ・パブリック・ライセンス（ＮＰＬ）は、民間企業によるフリーソース開発の促進とフリーソース開発者の保護との間に妥協点を見出そうとした点で画期的なものである。この、次世代のオープンソースライセンス作りには一か月あまりを要した。
　やはり異例の措置として、ＮＰＬの最初の草案は完成時に公開でベータテストされた。三月五日、netscape.public.mozilla.licenseというニュースグループに草案がポストされ、一般からの意見が求められた。この草案に対しては、励ましの声もあがればひやかしの声もあがった。ライセンスのある項目は、あたかも避雷針のように攻撃の的となった。その部分は、自社製品中にあるＮＰＬ適用のコードの一部を使用して作った製品にＮＰＬを適用しない特権をネットスケープ社に対して認めていたのである（つまり、ネットスケープ社に対して、非公開の派生的作業を許していた）。その部分はまた、ネットスケープ社がＮＰＬが適用されているバージョンを改訂したものにまったく別のライセンスを適用できることをネットスケープ社に対して認めていた。フィードバックを寄せてくれた人の中には、その部分が盛り込まれているだけで、ＮＰＬはオープンソースの開発コミュニティにとって容認しがたいものになっていると指摘する人もいた。
　一九九八年三月十一日、netscape.public.mozilla.licenseニュースグループにｊｗｚ（ジミー・ザインスキー）からの現状報告がポストされた。その一部は次のとおりである。


　三月二十一日、ＮＰＬ改訂版がポストされた。ソフトウェアのライセンス条項の案件がポストされることは前代未聞であり、それに対する反響はすさまじかった。「これはお粗末じゃないかと言ったら、相手はちゃんと聞いてくれた！　夢みたいだ！」という具合いである。このポストによって、初めは成功しそうにないと思っていた人びとも、これが真のオープンソースプロジェクトであることを実感したのである。ニュースグループでの討論は、プロジェクトの結論について批評することよりも、プロジェクトの前進に貢献していた。ニュースグループでの討論は新たな様相をおびて活気づいた。
　ライセンスチームは、草稿段階で発表されたＮＰＬに対してコミュニティから寄せられた批判を受けて、もう一度振り出しに戻ってライセンス作りに取り組んだ。彼らは、ネットスケープ社が、フリーソースの開発をしながらビジネス展開を可能にする、バランスのとれた解決法を模索し続けた。その結果生まれたのが、Ｍｏｚｉｌｌａ・パブリック・ライセンス（ＭｏｚＰＬまたはＭＰＬ）である。ＭＰＬは、ネットスケープ社に様々な特権を与える項目をＮＰＬから取り除いたものである（この一点を除けば、二つのライセンスはまったく同じものである）。
　一九九八年三月三十一日に初めて公開されたコードはすべてＮＰＬによって保護されており、そのコードに対する変更はすべてＮＰＬのもとに公開されなければならなかった。しかし、新しく開発されコードはＭｏｚＰＬ、または、それに類似するライセンスのもとに公開できた。原バージョンに含まれるファイルに対する変更は修正と見なされ、ＮＰＬによって保護されるが、インターネット上で表明された懸念を解消する手段として、原バージョンもしくはその後の修正バージョンに含まれないファイルは、修正と見なされず、ＮＰＬが適用されないことになっている。この部分に対しては、どのライセンスを適用してもいいことになっている。オープンソースのプロジェクトでよく用いられるＧＰＬは、ＮＰＬやＭｏｚＰＬと互換性のあるライセンスではない。ＧＰＬは、その規定事項に制約や許容を加えることを禁じているため、他のどのライセンスとの間にも互換性を持たないようにできている。ＧＰＬは、ＧＰＬが適用されているソフトウェアを使って開発されるコードに対してＧＰＬを適用することを義務づけている。ついでながら、ＧＰＬは、それが適用されたコードを配布する者に、すべてのコードを完全な形で配布することを求めているが、ＮＰＬにはそのような制約はない。
　netscape.public.mozilla.licenseニュースグループでの討論は、ある重要な問題をはっきりと浮き彫りにしていた。開発者たちは、ネットスケープ社にバグの修正と新しいコードとの違いを認めることを要求していた。確かに、「バグの修正をして、プログラムにちょっとした修正を加えている」ことと、「プログラムに新しい機能を書き加えている」ことは同じではない。人は、このふたつに対してまったく別の感情を抱く。たいていの人はバグの修正の公開をよいことであり、何かに貢献することの価値は、それ自体が報いであると考えている。しかし、新しく作成したコードとなると話は別である。新しいコードの作成に時間とエネルギーを費やした人が見たくないのは、ほかの誰かがそれを利用して金儲けをする姿である。
　ＮＰＬとＭｏｚＰＬは、Ｍｏｚｉｌｌａのコードベースのオープンソース形式での開発を促進する目的で作られた。しかし、そこには、もうひとつ別の目的が最初から意図されていた。ネットスケープ社が自社が知的所有権を有するソースコードを公開する初の大企業になろうとしたのは、オープンソース形式での開発に世間の注目を集めようとしたからである。それには、収益をあげている大企業がこの方式を採用して、この流れに乗ることを可能にする雰囲気づくりが重要であった。それまで提案されていたオープンソースライセンスの法的基盤は、企業どうしが開発プロジェクトで手を結びあうことが難しかった。Ｍｏｚｉｌｌａについて言えば、このライセンスは開発プロジェクトを思い通りに進めるためのものだったのである。
　我われは、将来のバージョンのためにソースコードを公開することで、インターネットコミュニティ全体と契約し、ブラウザ市場に新風を巻き起こそうとした。世界中の優秀なプログラマが我われのコードに取り組み、ブラウザに創造的なエネルギーを注ぎこんでくれるというアイデアによって、人びとは、困難に出会っても歩き続けようとする意欲をかきたてられたのである。


Ｍｏｚｉｌｌａ．ｏｒｇ
　オープンソースプロジェクトに携わった経験を持つ人びとは、どこか場所を見つけて、公開されたソースコードの開発を存続させていく必要性を認識していた。ネットスケープ社がソースコードの公開を発表した次の夜、ジミーはＩｎｔｅｒＮＩＣに新しいドメイン名を登録し、どのようにしたら分散型の開発プロジェクトを推進していけるかの原案を作成した。mozilla.orgの誕生である。
　成功するオープンソースプロジェクトが例外なくたどる−かならずしも意図的ではない−ひとつのパターンがある。多くの場合、そこにはメンテナンス役をする個人やグループが存在する。最初からそういう人がいるわけではない。そういう人は、次のような段階を経て登場する。まず、最初のうちは、個人々々が、自分の関心のある部分の開発に取り組み、一日の終わりに、多少は機能の向上した何かを手に入れる。しかし、一か月後にソフトウェアの新バージョンが登場したら、彼がせっかく追加した変更部分は外され、彼の作業は無駄になってしまう。ソフトウェアが一変してしまったりすれば、もっと具合が悪い。
　オープンソースの開発者たちが、自分の手がけたパッチを配布パッケージに含めることを要求するのは、そのような状況で貧乏くじを引かないためである。しかし、配布パッケージにパッチが含まれるようになれば、いろいろなコードが出回るようになり、そのうちプロジェクトのメンバーの一人が立ち上がって、「私がパッチをひとまとめにしてリリースしてもいいですよ」と言うようになる。そして、自分のパッチを次のリリースに入れるにはどうすればいいのかわからない人間が出てきて、「ほかの誰にパッチを託してよいかわからないから、あの人に託そう。手慣れているようだから」と言うようになる。こうして時がたつにつれて、みんながパッチを託す人物が、プロジェクトを保守する存在になっていくのである。
　しかし、Ｍｏｚｉｌｌａのオープンソースプロジェクトでは、そのようにことは運ばなかった。mozilla.orgは、プロジェクトの保守役・調整役をはたすように最初から計画されていた。我われには、こういった役割の存在がいずれ必要になることがわかっていたので、情報配布の基本的枠組みを提供する場を最初から設けることにしたのである。
　これに続く数か月間、mozilla.orgは、資金やコンピュータを調達したり、メーリングリストを開設したり、プロジェクトを機能させるのに必要な基盤を作ったりした。とにかく、mozilla.orgという組織を軌道にのせて機能させなければならなかった。ソースコードが公開されると同時にmozilla.orgが稼働することが何よりも重要だったのである。我われの準備が整わなければ、半年後には誰か他の人間がその役割をはたすことになるだろうが、ネットスケープ社は、何もしないで他の人間のやることをながめているような会社ではない。
　ソースコードを公開するということは、ネットスケープ社がインターネットのコミュニティと手を組むことを意味していた。そして、それが実現されるためには、ネットスケープ社のクライアント製品開発部とmozilla.orgは同じ組織ではないということを誰もが受け入れなければならなかった。mozilla.orgの目的は、ソフトウェアに取り組む世界中の人びとのコーディネーター役をはたすことにあった。製品開発部の目的は、Ｍｏｚｉｌｌａコードに基づくネットスケープ社の製品を出荷することであった。この二つのグループは同じ製品を取り扱っているため、利権が重複する可能性があった。しかし、mozilla.orgを背景とするグループは、インターネットのコミュニティの人たちから、「彼らはネットスケープ社の利益だけを考えており、ネットスケープ社の製品だけを出荷しようとしている」などと言われたら、よきコーディネーター役を努めることができないのがわかっていた。したがって、この二つのグループの分離は、実質的なものでなければならなかった。そして、インターネットのコミュニティにはっきりわかる形で分離されていなければならなかった。


カーテンの向こう側
　たとえば、開発者がコードを書き換えて、「このコードを使ってもらえますか」と名乗りをあげると、どんなことが起こるのだろうか。mozilla.orgの重要な役割の一つは、そのような申し出があったとき、受け入れられるコードとそうでないコードを判別することである。我われは、多くの問題を考慮に入れなければならない。第一は、それは役に立つのだろうかというメリットの問題である。、第二は、ＮＰＬと互換性のあるライセンスが適用されているかどうかである。我われは、ＮＰＬと互換性のあるライセンスが適用されていないコードは受け入れないことにした。そうしなければ、個別のソースコードディレクトリをいくつも管理しなければならなくなってしまうからである。情報交換をできなくするような手段を講じたりしなければならないからである。また、一人ひとりの関係者に大量の法律文書を用意したりする必要が生じるからである。プロジェクトの管理にミスの起こる可能性がきわめて高くなるからである。
　Ｍｏｚｉｌｌａは高度にモジュール化されたコードベースであるため、イメージ処理ライブラリやＸＭＬパーサーなどの主要モジュールには、かならず所定の「オーナー」がいる。それはその分野のコードに最も詳しい人物であり、そのモジュールに入れるべきものとそうでないものを決定できる人である。
　モジュールのオーナーの多くはネットスケープ社のエンジニアだが、中にはインターネットからの参加者もいる。モジュールのオーナーがコードを書き換える（たとえばイメージライブラリにＡＰＩを書き加える）と、その修正はmozilla.orgに送られて配布バージョンに加えられる。提供者とモジュールのオーナーとの間に争いが生じた場合には、mozilla.orgが仲裁に入って最終的な判断を下す。そのときmozilla.orgは、フェアプレーを守り続けられなければ誰からも相手にされなくなり、ほかの誰かに任務を奪われてしまうことを肝に銘じている。
　mozilla.orgは、ネットスケープ内部の開発者とインターネット上の人びとがコードに取り組むことになるという事実に対処しなければならなかった。コード開発のために内部で使われていた方法は、ウェブで使えるようにする必要があり、また、すべてのプラットフォーム、すべての時間帯で使えるようにする必要があった。これは、
ＢｏｎｓａｉとＴｉｎｄｅｒｂｏｘでツリーコントロールをすることによって実現した。
　「Ｂｏｎｓａｉ」は、アーカイブのコンテンツを問い合わせをするためのツールである。図書館の受付のように、あなたは、取り組んでいるコードを「登録」したり、ほかの人が何を「登録」をしたかを調べたりすることができる。このツールは、バックグラウンドでコードを実行しながらコードツリーをチェックしている。ツリーが壊れると、Ｂｏｎｓａｉは警告メッセージを発し、原因が特定されるまで登録を中断する。ログを見れば、どの問題がいつ発生したかを特定できる。以前、ネットスケープ内部の開発者が使っていたこのツールは、mozilla.orgにおいても世界中の開発者によって使われるようになり、どのプラットフォーム上からもブラウザ経由でじかに使えるようになった。
　Ｔｉｎｄｅｒｂｏｘは検出用ツールであり、ソースツリーの状況を教えてくれる。ツールなしで十人以上の開発者を集めれば、一種の爆発が起こる。そこで、「Ｔｉｎｄｅｒｂｏｘ」のような潜在的な爆発状況を制御するプログラムが必要なのである。このツールを使うと、誰が何を登録したかが（Ｂｏｎｓａｉへの問い合わせによって）わかる。どのプラットフォームがうまく構築されて、どのプラットフォームが壊れているかがわかる。特定のビルドで使用されたファイルの状態もわかるので、誰がおかしなことをしたかをつきとめることができる。


一九九八年のエイプリルフール
　一九九八年三月末日まであと十日ほどになり、期限がどんどん近づいていた。コードの公開を祝ってパーティを開くべきだというのが大方の意見だったが、そのために何か準備されたわけでもなかった。このプロジェクトの幕切れにふさわしく、一般の人びとをネットスケープの世界に招待するという画期的なイベントとなったパーティは語り草になっている。
　あるミーティングで、ジミーは、サンフランシスコのナイトクラブを借り切って世界中の人びとを招待し、その模様をインターネットを通じて放送する計画について述べた。「従業員でない人たちをパーティに招待するということですか？　でも、前例がありませんよ」。しかし、プロジェクトの幕切れにふさわしく、しばらく迷ったあとに出たのは……「それでいいじゃないか」という意見だった。
　このパーティは人びとの記憶に残るだろう。四月一日の夜、ジミーは、サンフランシスコで最大のナイトクラブ「サウンドファクトリー」を借り切った。ＤＪたち（Ａｐａｃｈｅプロジェクトのブライアン・ベーレンドルフもいた）は、mozilla.orgのＴシャツやソフトウェアを何千も配った。ネットオブジェクト、マクロメディア、ＤＥＣ、Ｂｅ、ワイヤード、アン-アメリカン・アクティビティズといった会社の製品も大量に配った。
　午後八時、「Mozilla Dot Party」が開場になったときには、会場入り口にはすでに行列ができていた。一時間半後、パーティ会場は消防規則ぎりぎりの二千人の客であふれ、行列はナイトクラブのまわりをひとめぐりしていた。人びとは入れ替え制で二十人ずつ店内に通され、お開きまでに三千五百人以上が入場した。その中には、フリーソフトウェアの権威であるブリュスター・カール（Brewster Kahle　ＷＡＩＳの発案者）やエリック・レイモンドもいた。彼らのほかに来場していた数百人のエキスパートたちは腕時計の時刻を合わせ、世界中の人びとと同時にＭｏｚｉｌｌａのために乾杯した。また、バーチャルな形で参加した人たちの中には、アムステルダムのワーフ城に集まった百人以上の人たちがいた。その他にも、ノルウェー、モントリオール、ペンシルヴェニア州、ノースカロライナ州、ウィスコンシン州、コロラド州、アラバマ州でも様々なグループが集いあっていた。
　サンフランシスコの会場に設置された三つの映写スクリーンは、秒速60行ほどでＭｏｚｉｌｌａのソースコードがスクロールしていた（この速度で150万行に及ぶコードをすべて見るためには、パーティを七時間あまり延長しなければならなかっただろう）。コフィー・ブラウン・バンド（主役はネットスケープ社のエンジニア）が後半のステージで演奏している最中に、エリック・レイモンドがステージに駆け上がり、フルートの独奏を披露してみんなを驚かせた。そろそろお開きになるころ、ナビゲータの開発チームとmozilla.orgのメンバーが前の晩にサインとナンバーを書きこんだソースコードＣＤが一ダース分群衆の中に投げ入れられた。こうして、怪獣は解き放たれたのだ。