Chapitre 13. Libérons les sources — L'histoire de Mozilla

Introduction

Rendre cela possible

Mise au point de la licence

mozilla.org

En coulisses

Premier avril 1998

Introduction

Le 23 janvier 1998, Netscape publia 2 annonces. Voici comment CNet rapporta la première : « Dans un élan sans précédent, Netscape Communication fera cadeau de son navigateur Navigator, confirmant les rumeurs des dernières semaines passées. »

Voici le compte-rendu de la seconde : « Ils donneront aussi le code source pour la prochaine génération de sa suite Communicator. »

La décision de donner son navigateur ne surprit personne, mais la livraison du code source étonna toute l'industrie. Cela occupa les gros titres des journaux dans le monde entier, et même la communauté du logiciel libre fut surprise de cet élan. Jamais auparavant un grand éditeur de logiciels n'avait fourni ainsi son code. Qu'allait devenir Netscape ?

Nous avions décidé de changer les règles du jeu, mais ce n'était pas la première fois. Connu depuis toujours pour penser différemment, Netscape prenait ainsi l'engagement de construire un Internet meilleur, de le hausser à un autre niveau. Lorsque Netscape commença la distribution sans restriction de versions de son navigateur sur l'Internet en 1994, certains déclarèrent : « C'est complètement fou ! ». Quand Netscape annonce « Code Source libre », ils dit la même chose.

La période de discussion amenant à l'annonce de l'ouverture des sources se déroula à vitesse grand V. Alors qu'il avait fallu des mois de délibérations pour décider s'il fallait fournir ou non le logiciel gratuitement, 24 heures suffirent à une forte proportion des responsables pour accepter de libérer les sources.

Aussi rapide et surprenante que fut l'annonce pour le personnel et les observateurs, elle reflétait plusieurs courants de pensée convergents. Les dirigeants de Netscape discutèrent d'un livre blanc rédigé par Frank Hecker qui y exprimait une opinion de première importance car il prônait la libéralisation de leurs sources. Frank y citait l'article d'Eric Raymond, « La Cathédrale et le Bazar », en en parlant avec les gens de toute l'organisation, que ce soit les ingénieurs, le marketing ou le management. Dans un opus de 20 pages qui fut très diffusé, il plaidait la cause dont le bataillon des convaincus s'étoffait régulièrement.

Quand Netscape rendit pour la première fois Navigator téléchargeable sans restriction sur l'Internet de nombreux observateurs crurent voir une atteinte au bon sens classique de l'industrie du logiciel, et doutèrent que nous puissions gagner de l'argent « en faisant cadeau du logiciel ». Aujourd'hui, naturellement, cette stratégie est rétrospectivement perçue comme une innovation couronnée de succès, un facteur clé dans le développement rapide de Netscape; et rare sont aujourd'hui les sociétés qui ne copient pas notre stratégie d'une façon ou d'une autre. Cela soulève diverses questions, par exemple : que se passerait-il si nous reproduisions le même scénario, cette fois-ci avec le code source ?

Les ingénieurs se prononçaient de façon similaire. De nombreux employés de Netscape avaient l'habitude de travailler avec des outils libres. Et depuis que le code de Communicator était si intimement mêlé avec Java et HTML, beaucoup admettaient une vérité émergente : libérer le source pose à présent moins de problème. La nature de Java invite à une perception plus ouverte de la distribution des sources. Il est multi-plate-forme et peut être compilé en fichiers classes, exécutables indépendants de la machine car chaque binaire repose sur une machine virtuelle, donc les programmeurs peuvent décompiler l'exécutable et en étudier le code source. La commande « Voir le source » du navigateur, elle, assure la popularité de HTML d'une façon semblable. Plutôt qu'essayer de bloquer cela, beaucoup pensaient que Netscape devait le faciliter, l'encourager, et en tirer autant que faire se peut bénéfice.

Les différentes écoles de pensée fusionnèrent avec une soudaineté inattendue. Durant les réunions, la stupéfaction laissait en quelques minutes place à l'approbation. La plupart des discussions passèrent rapidement de « devons-nous ? » à « quand ? ». La plupart des acteurs clés croyaient que nous devions agir rapidement, annoncer une date ferme puis s'y tenir. En janvier, Netscape publia une promesse sur le Net : les sources de Communicator seraient livrées durant le premier trimestre de 1998. Netscape tint cette promesse avec le plus grand sérieux, et le « Project Source 331 », nom donné au fruit du travail des équipes œuvrant afin de publier le 31 mars 1998, vit le jour.

Puis la réalité s'imposa.

Rendre cela possible

Le corps du code source de Communicator fut appelé « Mozilla », nom crée par Jamie Zawinsky et la société durant le développement du Navigator. L'équipe travaillait frénétiquement pour créer une « bête » beaucoup plus puissante que Mosaic, et ce nom devint celui du code officiel de Navigator. Plus tard le gros dinosaure vert devint une blague interne, puis une mascotte pour la société, et enfin un symbole pour le public. Le nom est à présent devenu le terme générique se référant aux navigateurs Web libres dérivant du code source de Netscape Navigator. On s'employait à « libérer le Lézard ».

Une impressionnante quantité de tâches restait à accomplir afin de préparer la première publication du code. Les problèmes apparaissaient peu à peu et furent collectés et classés dans des catégories. Le trimestre suivant fut consacré à leur résolution, à la cadence infernale que Netscape connaissait bien.

La mise à disposition des modules de tierces parties inclus dans le navigateur posa l'un des plus gros problèmes. Les trois-quarts du code de Communicator en relevaient et nous devions donc contacter tous leurs propriétaires. Des équipes d'ingénieurs et d'évangélistes furent organisées pour rencontrer et convaincre chaque société de rejoindre Netscape sur la route des Sources Libres. Tous avaient entendu parler de l'annonce de Netscape et devaient choisir : leur code pouvait être supprimé ou remplacé, livré en binaire (conservé dans son état compilé) ou bien livré sous forme de code source avec Communicator. Pour compliquer les choses, de nombreux contrats étaient uniques et portaient sur différentes échéances. Aucun scénario ne pouvait s'appliquer à tous les cas.

Nous souhaitions respecter la date de publication annoncée et cela nécessitait des choix parfois difficiles. Ce fut sûrement le cas quand vint la question de la participation des développeurs des tierces parties. La règle était qu'ils devaient nous rejoindre avant le 24 février, ou leur élément serait écarté des sources. Ce type de date butoir n'est pas difficile à établir lorsque l'échéance est encore lointaine mais devint critique quand elle fut proche. Une partie du code dut être supprimée.

Les sources de la machine virtuelle Java, langage propriétaire, ne devaient pas être publiés. Trois ingénieurs se virent confier une « Java-ectomie » grâce à laquelle le navigateur pourrait être compilé puis s'exécuter sans Java. La modification du code général, très intimement mêlé à Java, exigea beaucoup de travail. Nous nous proposions de consacrer les deux dernières semaines aux tests. Les ingénieurs devaient démêler tout le code Java du navigateur avant le 15 mars, échéance très proche.

Le nettoyage du code fut un projet énorme. Beaucoup doutèrent très tôt de la date avancée mais les cerveaux commençaient à bouillir lors de réunions, des stratégies prirent forme, les roues commencèrent à tourner. L'équipe de production laissa de côté son travail (la plupart de ses membres développaient la génération suivante du navigateur) et tous s'attaquèrent immédiatement au projet. Il fallait non seulement décider du sort (inclusion ou suppression) de tout module issu d'une tierce partie mais aussi mettre au propre les commentaires du code. La responsabilité de chaque module fut assignée à une équipe et ils commencèrent à récurer.

Une des grandes innovations qui se produisit tôt fut d'utiliser le système de rapport de bogues offert par notre Intranet en tant que gestionnaire de tâches. « Bugsplat » était le surnom de Scopus, un programme de rapport de bogues à interface en HTML. Ce système de gestion des flux de documents nous épaula au mieux. Il tenait à jour la liste des nouvelles tâches décrites grâce à un simple formulaire HTML et gérait les priorités des tâches et les personnes compétentes comme autant de bogues ainsi pris en charge. Les listes de diffusion électroniques correspondantes naissaient à mesure. Sitôt la tâche (ou le bogue) résolu, toutes les listes de diffusion et les priorités disparaissaient. Les ingénieurs mesuraient l'avancement de leurs propres modules et surveillaient le déroulement du projet grâce à notre Intranet.

L'équipe d'ingénieurs peina aussi afin de supprimer les modules de chiffrement. Le gouvernement insistait non seulement pour que tout ces codes disparaissent mais encore pour que toute fonction qui y faisait appel soit réécrite. Le seul travail d'une des équipes fut de garder un contact constant avec la NSA et de gérer les problèmes de conformité.

Mise au point de la licence

Alors que le Grand Nettoyage du Code battait son plein, un autre projet devait décider de la licence de diffusion à adopter. Il nous fallait pour cela répondre tout d'abord à une importante question : l'une des licences existantes était-elle adéquate ? Personne ne souhaitait rédiger de nouvelle licence, mais tout le monde réalisa qu'il serait nécessaire de satisfaire les tierces parties et d'adopter une démarche fédérant les entreprises. Aucun logiciel propriétaire existant n'avait jamais été fourni ainsi.

Un groupe de leaders de la communauté Open Source incluant Linus Torvalds, Eric Raymond et Tim O'Reilly fut invité à visiter le campus de Mountain View. Ils participèrent à des débats avec des groupes de dirigeants, de juristes et de programmeurs afin d'exposer leurs vues et rencontrèrent de petits groupes pour discuter de problèmes spécifiques. Ils consacrèrent une grande partie de leur temps à discuter avec l'équipe juridique de Netscape des mérites et défauts des licences existantes. Ces conseillers agirent aussi comme un groupe prolifique en idées.

Une équipe conseillée par l'équipe juridique de Netscape examina les licences existantes afin de déterminer si l'une d'entre elles pouvait s'appliquer à Mozilla. Ils commencèrent par examiner la licence publique générale GNU destinée aux bibliothèques (la LGPL) et la licence BSD, et nous avons longuement analysé leurs avantages et inconvénients respectifs. Le source de base de Netscape présentait des caractéristiques propres, bien distinctes de celles des codes auxquels elles avaient été déjà appliquées. Les accords de licence ad hoc qui régissaient de nombreux composants issus de tierces parties utilisés posaient l'un des problèmes les plus épineux. La licence devait créer un environnement où ces contributeurs et d'autres nouveaux développeurs commerciaux pourraient participer au développement de Mozilla tout en préservant leurs intérêts.

La licence BSD, plus permissive, qui requiert seulement que le détenteur légal mentionné dans tout source dérivé, fut jugée insuffisante dans le cas de Mozilla. Elle aurait exposé les développeurs à constater que leurs modifications ne seraient pas reversées à la communauté. Ce point unique posait un énorme problème puisqu'il était crucial pour la viabilité à long terme des travaux de développement open source.

Les contraintes de la GPL la rendaient incompatible avec notre projet. La GPL est « contagieuse » car doit aussi protéger tout code combiné par compilation avec un code sous GPL. Cette exigence la rend inadéquate dans le cas de logiciels commerciaux. La GPL, par exemple, concernerait aussi les composants des parties tierces compilés dans les versions de Communicator, ce dont Netscape ne saurait décider, puisque nous n'en disposons pas. Et Netscape lui-même utilise une partie du code de Communicator dans d'autres produits (par exemple des serveurs). Puisque Netscape n'avait aucun plan immédiat pour fournir leur code source, l'effet viral de la GPL sur ces produits présentait un problème pour Netscape autant que pour les autres entreprises. La LGPL, une modification de la GPL plus ouverte et moins restrictive, était plus proche des besoins de Netscape pour un développement commercial, mais elle limitait les modalités de commercialisation, tout comme la GPL.

Après un mois frénétique de recherche, de discussion et de rencontres avec des experts et défenseurs du logiciel libre, et au milieu des spéculations du public, l'équipe décida qu'une nouvelle licence pourrait seule correspondre à cette situation sans précédent. La Licence Publique de Netscape (NPL), compromis entre la promotion du développement des Sources Libres par des entreprises commerciales et la protection des développeurs concernés, naquit ainsi. Le processus de création d'une nouvelle génération de licence Open Source exigea plus d'un mois.

Dans un autre élan extraordinaire le brouillon de sa toute première version fut présenté au public. Le 5 mars, une version de la NPL fut postée dans un nouveau forum de nouvelles Usenet appelé netscape.public.mozilla.license, assortie d'une demande invitant tout lecteur intéressé à la commenter. Encouragements et moqueries fusèrent. La section de la licence qui garantissait à Netscape le droit d'utiliser le code couvert par la NPL dans d'autres produits sans devoir placer ces derniers sous NPL faisait l'objet de la plupart des critiques. Cela permit aussi à Netscape de publier des versions révisées de la NPL, et de manière très controversée, de re-licencier du code sous NPL aux parties tierces sous des termes différents de ceux de cette licence. Certaines des personnes faisant des commentaires en retour, allaient si loin qu'elles suggéraient que ce seul fait rendrait la NPL inacceptable pour la communauté des développeurs Open Source.

jwz (Jamie Zawinsky) publia le 11 mars dans netscape.public.mozilla.license un état des travaux dont voici un extrait :

Premièrement, MERCI pour la somme incroyable de commentaires pertinents expédiés ! Ce fut incroyablement utile, et soyez assurés que les opinions exprimées sont très scrupuleusement prises en considération. La semaine prochaine, vous pouvez vous attendre à voir une section 5 très retravaillée. Je ne pourrai probablement pas trop la commenter (car ne souhaite pas donner de faux espoirs), mais ce que la plupart d'entre vous détestent a été clairement circonscrit.

Le 21 mars, la modification fut postée. C'était sans précédent. La réaction fut incroyable : « Je leur ai dit que c'était affreux et ils m'ont écouté ! Je n'arrive pas à y croire ! ». Le public réalisa qu'il s'agissait bien d'un projet open source, malgré son lieu de naissance surprenant. Les utilisateurs des forums Usenet, au lieu de commenter comme à l'ordinaire les résultats, guidèrent le processus de mise au point. Le ton changea dans les discussions, et la bonne volonté s'y montra davantage.

La critique de la version bêta de la NPL émise par la communauté avait renvoyé l'équipe de licence à sa table de travail. Ils cherchèrent une solution qui permettrait à Netscape de soutenir les objectifs des développeurs de logiciels libres tout en servant ses objectifs commerciaux. Le résultat fut une deuxième version de la NPL appelée Licence Publique Mozilla (MozPL). Elles sont identiques à ceci près que la NPL comporte des amendements laissant à Netscape des droits additionnels.

Tout le code réalisé pour le 31 mars 1998 fut publié sous la NPL, et toutes les modifications de ce code le seront sous NPL. Un nouveau code développé peut être publié sous la MozPL ou sous tout autre licence compatible avec elle. Des changements dans des fichiers contenus dans le code source sont considérés comme des modifications et placés sous NPL. Pour répondre à de nombreux doutes exprimés sur le réseau, les nouveaux fichiers qui ne contiennent pas de code original ou de code modifié ultérieurement ne sont pas considérés comme des modifications et ne sont donc pas couverts par la NPL. Le code résultant peut être placé sous n'importe quelle licence compatible. La GPL n'est pas compatible avec la Licence Publique Netscape ou avec la Licence Publique Mozilla car semble incompatible avec toute autre licence puisque elle interdit toute addition de restrictions ou de plus amples permissions. Tout code développé pour fonctionner avec du logiciel GPL doit à son tour être protégé par la GPL. Un autre point mineur est que la GPL insiste pour que, quand vous distribuez du code sous ses termes, elle doit être complète et entière. La NPL ne comporte pas cette condition.

Les discussions dans les forums Usenet soulignèrent un important problème : des développeurs souhaitaient voir Netscape distinguer les corrections de bogue et le nouveau code. Affirmer : « Je réalise une correction de bogue, une petite modification de votre programme, » est tout-à-fait différent de « J'ajoute une nouvelle fonction à votre programme ». Ces assertions provoquent des réactions différentes. La plupart des gens acceptent d'offrir une correction de bogue, et la récompense d'une contribution réside dans son don même. Mais il n'en va pas de même pour du code additionnel. Un développeur productif ne souhaite pas voir n'importe qui utiliser son travail afin de gagner de l'argent.

La NPL et la MozPL furent conçues pour encourager le développement ouvert sur le code de base de Mozilla, mais dès le début un autre objectif se dessina. Netscape souhaitait être la première grande entreprise à ouvrir son code propriétaire parce qu'elle voulait mieux entretenir l'intérêt d'autres grandes sociétés pour l'environnement open source. Il lui semblait primordial de créer une atmosphère propice, pousser les organisations rentables à adopter ce modèle et à participer au mouvement. L'infrastructure légale de la plupart des licences libres n'offrait que des obstacles à la coopération de sociétés. C'est pourquoi la licence de Mozilla constituait à elle seule un projet à part entière.

Nous espérions, en offrant le code source des futures versions, inviter toute la communauté de l'Internet à créer un nouveau mode d'innovation dans le marché du navigateur. L'idée selon laquelle de talentueux programmeurs à travers le monde travailleraient sur notre code, apportant au navigateur leur énergie créative, motivait tout le monde à aller de l'avant même si la progression s'avérait difficile.

mozilla.org

Les personnes qui avaient participé à des projets open source auparavant se rendaient compte que le code devait disposer d'un site de référence. Jamie enregistra la nuit même un nouveau nom de domaine et rédigea la charte des projets de développement distribués grâce à mozilla.org, qui naquit ainsi.

Les projets open source couronnés de succès suivaient tous un modèle, pas nécessairement à dessein, par lequel une personne ou un groupe assure la coordination. Les personnes travaillent sur l'aspect du code qui leur plaît, selon leurs propres envies. À la fin de la journée chacun dispose d'un module fonctionnant un peu mieux. Mais lors de la publication d'une nouvelle version du logiciel ils doivent adapter leurs modifications car le morceau de source du logiciel principal les concernant a peut-être évolué.

Les développeurs souhaitent donc voir leurs modifications intégrées dans la distribution principale. Un amas de code source et modifié sans méthode par de intervenants poussera tôt ou tard quelqu'un à se dresser et dire « Je pourrais très bien collecter une masse de modifications et constituer ainsi une nouvelle version ». Un autre contributeur pourra dès lors penser « Je ne sais pas à qui remettre ma modification, alors je vais le donner à ce type. Il semble en faire bon usage. » Le temps passe, et cette personne devient le mainteneur.

Pour ce projet open source, on mit la charrue avant les bœufs. Mozilla.org fut conçu et réalisé afin de remplir le rôle de mainteneur dès le début. Puisque cette mission serait d'une manière ou d'une autre prise en charge, nous décidâmes de créer l'infrastructure pour devenir les gestionnaires du travail.

En quelques mois mozilla.org commença à devenir une organisation, trouvant des fonds et des machines, gérant des listes de diffusion électroniques, et tissant les appuis nécessaires afin que tout fonctionne. La mission consistait simplement à préserver une organisation adéquate et fonctionnelle. Le dépôt central devait être opérationnel dès que les sources seraient publiées sous peine de voir après quelques mois un tiers endosser cette responsabilité. Netscape, comme chacun le sait, n'est pas du genre à regarder les autres faire à sa place.

Offrir le code source signifiait que Netscape collaborerait avec les utilisateurs de l'Internet. Il nous fallait impérativement bien distinguer le groupe de développement des produits clients Netscape et celui de mozilla.org. mozilla.org devait agir en tant que coordinateur de toutes les développeurs actifs tandis que l'objectif du développement produit était de coordonner les produits Netscape réalisés à partir du code de Mozilla. Puisque les deux groupes travaillent sur le même produit, les intérêts pouvaient se chevaucher. Mais le groupe derrière mozilla.org reconnut qu'il serait désastreux pour son image sur le Net que quelqu'un se tourne vers l'organisation et affirme « Ces gens n'ont que les intérêts de Netscape en tête et veulent seulement vendre leurs produits. ». Ceci signifierait que mozilla.org n'est pas le mainteneur adéquat. La séparation devait être réelle et les activistes de l'Internet le savaient.

En coulisses

Que se passe-t-il lorsque l'auteur d'une modification nous interpelle : « Eh, mozilla.org ! Prenez ce code s'il vous plaît ! ». L'un des rôles les plus importants de mozilla.org est de définir les critères d'acceptation d'une contribution. Nous devons faire face à de nombreux problèmes. Tout d'abord vient l'appréciation du mérite. Le code est-il bon ? Deuxièmement, est-il sous une licence compatible avec la NPL ? Nous décidâmes de ne pas accepter les contributions non couvertes par une licence compatible avec la NPL. Sinon elles devraient être ventilées dans des répertoires bien distincts, séparés par des murailles, et cela impliquerait de grandes manœuvres d'ordre juridique. Le risque d'erreur augmenterait énormément.

Puisque Mozilla est une base de code très modulaire chacun de ses composants majeurs, par exemple la bibliothèque de gestion des images ou l'analyseur XML, a un « propriétaire » désigné. Il connaît parfaitement le code et fait office d'arbitre lorsque l'on décide d'y inclure ou non une contribution.

De nombreux propriétaires de modules sont des ingénieurs de Netscape mais d'autres sont des volontaires externes. Quand un propriétaire de module effectue des changements (par exemple, ajoutant une API à la bibliothèque de gestion des images), il les expédie à mozilla.org qui les inclura dans les distributions. Si des différents apparaissent entre un contributeur et le propriétaire du module, mozilla.org joue le rôle d'arbitre en établissant l'appel final - toujours conscient que s'il arrête de jouer selon les règles de l'art il sera ignoré et quelqu'un d'autre endossera sa mission.

Mozilla.org devait faire face à la diversité des développeurs. Les méthodes utilisées pour travailler sur le code en interne devaient s'accommoder du Web et rester accessibles pour toutes les plates-formes, dans toutes les zones horaires. Ce fût fait avec le « contrôle d'arborescence » assuré par les outils Bonsai et Tinderbox.

L'outil « Bonsai » honore des requêtes portant sur le contenu d'une archive. Comme aux guichets d'une banque, vous pouvez grâce à lui « déposer dans la chambre forte » du code développé, et voir quels « dépôts » ont été effectués par d'autres participants. En arrière-plan il engendre constamment le code, vérifiant l'arborescence du source et lève un « drapeau rouge » en cas de problème, interdisant les dépôts jusqu'à ce que le problème soit identifié. Il engendre sur simple demande des historiques et la liste des problèmes pris en charge durant une période donnée. Bonsai, tout d'abord utilisé par les développeurs maison de Netscape, fut imposé aux activistes du monde entier œuvrant, qui y accédaient sur mozilla.org grâce à n'importe quel arpenteur Web.

Plus de dix développeurs travaillant simultanément sans outils adéquats mènent à la catastrophe. Un programme nommé « Tinderbox » gère ce travail d'équipe afin d'éviter cela en menant une sorte d'enquête dans l'arborescence des sources. Grâce à lui on connaît toujours l'identité de l'auteur d'un quelconque tronçon de code (il exploite pour cela Bonsai), quelles versions du logiciel fonctionnent ou non (et pourquoi !), et l'état des fichiers utilisables afin d'identifier les sources des défauts.

Premier avril 1998

Une semaine et demie avant la fin de mars 1998 nous avions l'impression que le temps filait de plus en plus vite vers la date butoir. Tous souhaitaient organiser une célébration de la distribution du code, mais rien n'avait été organisé. Une fête de cette nature, couplée à la publication prévue, deviendrait un événement sensationnel qui inviterait le public à pénétrer librement dans le monde de Netscape.

Lors une réunion Jamie exposa son plan de louer une boite de nuit à San Francisco, d'inviter du monde et de l'annoncer sur le Net. « Vous pensez inviter des personnes non salariées par Netscape à la fête ? Mais nous n'avons jamais fait cela auparavant ! ». Après une pause la réaction fut, comme durant tout ce projet, « Pourquoi pas ? ».

Cette fête ne sera pas oubliée de sitôt. Jamie loua « The Sound Factory », l'une des plus grosses boîtes de nuit de San Francisco, pour la nuit du 1^er avril. Des DJ (notamment Brian Behlendorf, l'un des fondateurs d'Apache) firent cadeau de centaines de T-shirts mozilla.org, de logiciels, et d'objets de NetObjects, Macromedia, Digital, Be, Wired, et de diverses sociétés non américaines.

Une longue file d'attente s'étendait déjà devant les portes de cette la « Mozilla Dot Party » lorsqu'elles s'ouvrirent à 20 heures. Une heure et demie plus tard, l'endroit était rempli à la limite tolérée par les pompiers (deux mille personnes), et la file d'attente faisait le tour du pâté de maisons. Les gens étaient accueillis par vingtaines à l'heure où d'autres s'en allaient, et à la fin de la nuit, plus de 3 500 personnes avaient passé les portes, y compris des gourous du logiciel libre comme Brewster Kahle (fondateur de WAIS) et Eric Raymond. Des centaines d'autres fans, à travers le monde, synchronisèrent leurs montres et portent un toast à la santé de Mozilla. Les fêtards virtuels incluaient plus d'une centaine de personnes au château de Waag à Amsterdam, Pays-Bas, et des groupes individuels variés en Norvège, à Montréal, Canada, en Pennsylvanie, Caroline du Nord, Colorado, Alabama et dans le Wisconsin.

À l'intérieur, trois écrans de projection déroulaient le code à la vitesse de soixante lignes par seconde. Avec ce débit, la fête aurait pu durer plus de sept heures afin d'afficher ainsi le million et demi de lignes du source de Mozilla. Eric Raymond, durant le second des deux concerts du Kofy Brown Band (parmi lesquels figure un ingénieur de Netscape), qui était venu ici de Philadelphie pour l'occasion, sauta sur la scène et surprit tout le monde avec un solo de flûte. À la fin de la nuit, une douzaine de CD de l'édition Signature du code source de Mozilla (CD signés et numérotés avant la nuit par l'équipe de d'intégration Netscape et des membres de mozilla.org) furent jetés dans la foule et saisi par quelques heureux privilégiés. Le lézard était libre !