vai alla Homepage di Apogeonline

 



Cos'è OpenPress
Glossario
Linux-FAQ
Documenti:

Open Source Definition

GNU General Public License

La cattedrale e il bazaar

Colonizzare la noosfera

Il calderone magico


Libri:

Italian crackdown

Open Sources

MediaMorfosi

GTK+/GNOME
sviluppo applicazioni


Telematica per la pace

Linux HOWTO: Installazione e configurazione

Linux HOWTO: Networking


Risorse
Feedback
vai alla Homepage di Apogeo Editore

Vai alla homepage di OpenPress

Torna al sommario
di Open Sources
Liberare il sorgente: la storia di Mozilla


di Jim Hamerly e Tom Paquin, con Susan Walton

Il 23 gennaio 1998 Netscape fece due annunci. Questo è il primo, come riportato da C|Net: "Con una mossa senza precedenti, Netscape Communications cederà il suo browser Navigator, confermando le voci delle ultime settimane".

Il secondo: "Netscape renderà pubblico anche il codice sorgente per la prossima generazione della sua suite Communicator".

La decisione di cedere il browser non arrivò inaspettata, ma il rilascio del codice stupì il settore, arrivò sulle pagine dei giornali di tutto il mondo e colse di sorpresa perfino la comunità Open Source. Mai prima di allora una grande azienda software aveva aperto il proprio codice proprietario. Che intenzioni aveva Netscape?

Avevamo deciso di cambiare terreno di gioco, e non per la prima volta. Netscape, nota da sempre per pensare in maniera anticonvenzionale, si stava questa volta impegnando a costruire un’Internet migliore su un nuovo livello. Quando Netscape diede avvio alla distribuzione non vincolata delle prime versioni del suo browser su Internet, nel 1994, vi fu chi disse "sono pazzi!". Lo stesso quando Netscape liberalizzò il codice.

Il periodo di discussione che condusse all’annuncio dell’Open Source si mosse come un treno senza conducente. Dopo mesi di riflessioni sull’opportunità di rilasciare o di non rilasciare il codice binario gratis, si raggiunse nell’incredibile spazio di ventiquattr’ore una massa critica in favore della decisione di liberare il sorgente.

Per veloce e sorprendente che l’annuncio potesse sembrare sia agli addetti che al pubblico, esso rifletteva molti percorsi di pensiero confluenti. I dirigenti di Netscape stavano discutendo un white paper di Frank Hecker che esprimeva un punto di vista emergente. Nel documento, egli propugnava la liberalizzazione del sorgente da parte di Netscape. Frank aveva fatto bene i suoi compiti, citando il saggio di Eric Raymond "La cattedrale e il bazaar" e discutendo in prima istanza con il personale in tutti i settori dell’organizzazione, dalla progettazione al marketing alla dirigenza. In un saggio di venti pagine che ebbe un’ampia diffusione, perorò il caso che si stava montando:

Quando Netscape per la prima volta rese Netscape disponibile al download libero su Internet, molti videro ciò come uno schiaffo alla normale accortezza nel commercio del software e si domandarono come mai pensassimo di guadagnare "dando via" il nostro software. Ora, naturalmente, questa strategia appare in retrospettiva come un'innovazione di successo che è stata un fattore chiave nella rapida crescita di Netscape; e sono rare, oggi, le aziende software che, in un modo o nell'altro, non la emulino. Fra l'altro, questo suscita la domanda seguente: che cosa accadrebbe se lo rifacessimo, questa volta con il codice sorgente?

I progettisti sembravano vederla allo stesso modo. Molti impiegati di Netscape avevano esperienza di lavori open source, e dal momento che il codice di Communicator era cosi strettamente integrato con Java e HTML, molti videro affiorare una verità: il salto non era cosi grande. La natura stessa di Java invita a vedute più aperte sulla distribuzione del sorgente. Dal momento che è multipiattaforma e può essere compilato fino a file di classi che risultino eseguibili indipendentemente dalle macchine su cui girano, ogni binario e come una macchina virtuale. Di conseguenza i programmatori possono decompilare l'eseguibile e ritrasformarlo in codice sorgente. Anziché cercare di ostacolare questa pratica, molti in Netscape credevano che si dovesse incoraggiare, facilitare e, se possibile, trarne profitto.

Le varie scuole di pensiero di base si incontrarono con inattesa rapidità. Nelle riunioni, le reazioni alla proposta variarono dallo shock totale all'approvazione quasi istantanea. La maggior parte delle discussioni trascorsero velocemente dal "Ma dovremmo proprio?" al "Quando cominciamo?". Era convinzione diffusa che ci si dovesse muovere in fretta, stabilire una data e darsi da fare. In gennaio, Netscape fece alla Rete una promessa: il sorgente di Communicator sarebbe stato rilasciato nel primo quadrimestre del 1998. Netscape prese la promessa dannatamente sul serio e così vide la luce il Project Source 331. Quello era il nome dello sforzo di Netscape per fare uscire il codice sorgente entro il 31 marzo 1998. Non avevamo fatto i conti con la realtà.

Darsi da fare
Il nucleo del codice sorgente di Communicator, alla Netscape era chiamato Mozilla. Si trattava di un termine dapprima inventato da Jamie Zawinsky e dal suo gruppo durante lo sviluppo di Navigator. Il team stava lavorando ad un passo altrettanto frenetico per creare una "bestia" di gran lunga più potente di Mosaic e quella paroletta divenne il "code name" ufficiale di Navigator. Più tardi, il grosso dinosauro verde divenne uno scherzo fra addetti ai lavori, quindi una mascone dell'azienda e infine un simbolo pubblico. Ora il nome comincio ad essere usato come termine generico in riferimento ai browser Web open source che sarebbero derivati dal codice sorgente di Netscape Navigator. L'intento era "liberare la Lucertola".

Ci fu moltissimo da fare per rendere il codice pronto all'esordio pubblico. Man mano che i problemi emergevano, si separavano e si raccoglievano in categorie. I tre mesi seguenti furono dedicati alla risoluzione di problemi al ritmo pazzesco ben familiare ai Netscapisti.

Uno dei problemi principali era come disporre dei moduli di terze parti inclusi nel browser. Communicator conteneva nel suo codice più di settantacinque moduli di terze parti: e tutti i proprietari del codice avrebbero dovuto essere contattati. Team interi di progettisti e di evangelisti si organizzarono per visitare e per convincere ognuna di quelle società a unirsi a Netscape sulla strada verso l'Open Source. Tutte avevano avuto notizia dell'annuncio open source di Netscape e ora ciascuna doveva fare una scelta: il loro codice poteva venir tolto o rimpiazzato, consegnato come binario (cioè mantenuto nel suo stato compilato) ovvero consegnato come codice sorgente insieme a Communicator. Per complicare le cose, molti dei contratti con le terze parti erano unici e avevano durate diverse. Non sembrava possibile trovare una soluzione universale.

Rispettare i termini fissati per il Project Source 331 era considerato essenziale. Ciò richiedeva di scegliere con assoluta determinazione, specialmente nel caso della partecipazione degli sviluppatori delle terze parti. La regola fu: o entro il 14 di febbraio sarete dentro, o il vostro elemento sarà cancellato dal sorgente. Questo genere di scadenze non è difficile da imporre quando le si prevede per tempo, ma diventano brutali poste all'ultimo momento. Arrivati al punto, parte del codice dovette essere rimosso.

Java era un linguaggio proprietario, quindi lo si dovette togliere. A tre progettisti fu affidata la "Javectomia". Il browser dovette essere costruito, compilato ed eseguito senza Java. Dato il modo in cui il codice complessivo era strettamente integrato a Java, non fu impresa da poco. L'obiettivo era di avere il codice sorgente pronto per il 15 marzo, cosi da poter usare le ultime due settimane per il testing. I progettisti si trovarono a dover districare rutto il codice di Java dal browser in un tempo assurdamente breve. Ripulire il codice fu un progetto immenso. All'inizio, molti pensarono che, semplicemente, non avremmo potuto farcela in tempo per la scadenza. Ma mentre la tensione nelle riunioni aumentava, cominciavano anche a formarsi le strategie del caso. Le ruote cominciarono a mettersi in moto. II team di prodotto lasciò perdere tutto il resto (per lo più era al lavoro sulla successiva generazione di browser) e tutti si dedicarono a questo intervento chirurgico. Non bisognava solo risolvere il problema dell'inclusione (o dell'esclusione) di ogni terza parte partecipante, ma bisognava togliere tutti i commenti dal codice. Ogni modulo fu affidato per la ripulitura a uno specifico team. Una delle grandi innovazioni che si mise subito in luce fu la decisione di usare il sistema di segnalazione dei bug intranet come task manager. Scopus, un programma di segnalazione bug con interfaccia HTML fu ribattezzato "Bugsplat". Era ideale come sistema di gestione del flusso di lavoro. Le cose da fare venivano riportate al sistema al momento in cui emergevano, inserite in un semplice modulo HTML. Proprio come quando un bug viene riportato al sistema, furono stabilite le priorità, furono stabiliti i partecipanti adatti e attorno a ogni compito fu costituita una mailing list. Quando il compito, o il bug, veniva risolto, tutte le mailing list e le priorità collassavano e sparivano alla vista. I progettisti potevano tener traccia dei progressi dei loro moduli e sorvegliare lo svolgimento del progetto collegandosi all'intranet.

La rimozione dei moduli crittografici fu un altro sforzo doloroso per il team di progetto. Non solo il governo insistette perché venisse rimosso qualunque supporto crittografico, ma ogni ansa di programmazione (hook) che lo richiamasse dovette essere riscritta. Fu compito di un team specifico il tenersi in contatto costante con la NSA e gestire i problemi di conformità.

Creazione della licenza
Parallela alla Grande Ripulitura del Codice fu la creazione della licenza. Il primo passo fu la risposta alla grande domanda: potrebbe qualcuna della licenze esistenti funzionare con il codice aperto? Nessuno aveva voglia di stilare una nuova licenza, ma. Tutti capivano che avrebbe potuto essere necessario accomodare tutto il codice di terze parti e rendere il progetto in grado di funzionare a livello aziendale. Nessun software proprietario in circolazione era mai stato rilasciato sotto una licenza di sorgente gratuito.

Un gruppo di leader della comunità Open Source, fra i quali Linus Torvalds, Eric Raymond e Tim 0'Reilly, furono invitati a visitare il campus di Mountain View. Parlarono a un pubblico di dirigenti, avvocati e programmatori della ragione per cui si trovavano lì e s'incontrarono con piccoli gruppi per parlare di alcuni dei problemi che avrebbero probabilmente dovuto affrontare. Trascorsero molto tempo con l'ufficio legale Netscape discutendo le licenze esistenti, i loro punti forti e i problemi che creavano. Questi consulenti agirono anche da cassa di risonanza per le idee.

Una squadra si immerse nell'esame degli accordi di licenza esistenti con l'ausilio e la guida dell'ufficio legale Netscape, cercando di determinare se uno di questi potesse funzionare per Mozilla. A cominciare dalla GNU General Public License, la GNU Library General Public License (LGPL) e la licenza BSD, facemmo studi accurati per determinare esattamente quali problemi esse risolvessero e quali creassero. A differenza del codice a cui questi accordi erano nel passato stati applicati, il codice di base esistente di Netscape presentava circostanze uniche. Una delle questioni più spinose erano gli accordi privati di licenza che regolavano gran parte delle componenti di terze parti usate nel codice. La licenza doveva delineare un ambiente in cui questi sviluppatori commerciali e altri nuovi potessero fornire il loro codice a Mozilla proteggendo nello stesso tempo i loro interessi commerciali.

La licenza BSD, più permissiva e che richiede solo che si faccia cenno al detentore del copyright in tutte le modifiche del codice, fu giudicata insufficiente allo sviluppo di Mozilla. Avrebbe lasciato gli sviluppatori col rischio che modifiche al loro lavoro non venissero restituite né a loro né al resto della comunità. Questo punto rappresentava di per sé un bel problema, dal momento che era cruciale per la fattibilità a lungo termine degli sforzi di sviluppo Open Source.

D'altra parte, i requisiti della GPL la resero indesiderabile in questo progetto. La GPL i "virale"; applicata a un pezzo di codice originale, ogni altro codice assieme a cui l'originale sia compilato deve anch'esso ricadere sotto GPL. Quest'aspetto la rese improponibile per gli sviluppatori di software commerciale. Per esempio, la GPL avrebbe richiesto che le componenti di terze parti compilate in versioni commerciali di Communicator fossero rilasciate anch'esse sotto GPL, il che ricade fuori dal controllo di Netscape, dal momento che Netscape non controlla quelle terze parti. E Netscape stessa usa una porzione del codice di Communicator in altri prodotti (come i server). Dal momento che Netscape non ha piani immediati per rilasciarne il codice sorgente, l'effetto virale della GPL su questi prodotti presenterebbe lo stesso problema a Netscape come ad altre aziende. La LGPL, modifica della GPL più aperta e meno restrittiva, era più vicina alle necessita di Netscape per l'uso con sviluppi commerciali, ma conteneva ancora troppi dei tranelli della GPL.

Dopo un mese frenetico di ricerche, discussioni, riunioni con esperti e rappresentanti della comunità del free software, e mentre il pubblico attendeva perplesso, il team concluse che questa situazione unica richiedeva una nuova licenza. La Netscape Public License (NPL) aprì nuovi terreni nel tentare di raggiungere un compromesso Fra la promozione dello sviluppo a sorgente libero da parte di imprese commerciali e la protezione degli sviluppatori di free software. II processo di creazione di una licenza Open Source di nuova generazione richiese oltre un mese.

Con un'altra mossa del tutto inusitata, non appena la prima versione della Netscape Public License (NPL) fu completata, venne sottoposta a un betatesting pubblico. Il giorno 5 marzo, una versione fu pubblicata nel newsgroup netscape.public. mozilla.license e fu avanzata una richiesta di commento pubblico, fra lo scherno generale. Fu in particolare una sezione della licenza ad attirarsi le ire più accese: quella che concedeva a Netscape dei diritti speciali sull'uso di codice coperto dalla NPL stessa in altri prodotti Netscape, senza che quei prodotti ricadessero sotto NPL. Consentiva anche a Netscape di pubblicare versioni rivedute della NPL e, questo il dettaglio più controverso, di rilicenziare a terze parti codice coperto da NPL sotto termini diversi dalla NPL. Venne osservato perfino che sarebbe bastato questo solo fatto a rendere inaccettabile la NPL alla comunità Open Source.

L'11 marzo apparve su netscape.public.mozilla.license uno stato dei lavori firmato jwz (Jamie Zawinsky). Diceva fra l'altro:

"Prima di tutto, GRAZIE per l'incredibile e significativo riscontro che ci avete dato! è stato d'immenso aiuto, e siate certi che ogni opinione è stata presa nella più grande considerazione."

La prossima settimana potrete notare come la sezione 5 sia stata radicalmente rielaborata. Non dovrei probabilmente dilungarmi in commenti (non voglio alimentare aspettative mal riposte), ma il messaggio di odio di molti di voi verso quella sezione, così com'è adesso, ci è arrivato forte e chiaro.

Il 21 marzo la revisione fu pubblicata, una cosa senza precedenti. La reazione fu incredula: "Ho detto loro che faceva schifo, e mi hanno dato retta! Non riesco a crederci!". La gente si accorse allora che si trattava di un progetto Open Source, genuino, malgrado il suo luogo di nascita poco ortodosso. Le discussioni in corso sui newsgroup aiutavano a dirigere il processo più ancora che fornire commenti sui suoi risultati. I toni della discussione, che continuava, mutarono; il morale era alle stelle.

La critica della comunità alla beta della NPL aveva costretto il team che se ne occupava a ritornare alla lavagna in cerca di una soluzione che permettesse a Netscape di bilanciare due obiettivi: impegnare gli sviluppatori di sorgente libero e continuare a perseguire mete di profitto. Ne risultò una seconda licenza che agisse all'interno della NPL, la MozPL (Mozilla Public License). Le due licenze erano identiche, salvo il fatto che la NPL includeva degli emendamenti che garantivano diritti supplementari a Netscape.

Tutto il codice pubblicato inizialmente il 31 marzo l998 fu rilasciato sotto NPL, e tutte le modifiche a quel codice devono essere rilasciate sotto NPL. Il nuovo codice sviluppato può essere rilasciato sono MozPL o sotto ogni altra licenza compatibile. Cambiamenti a file contenuti nel codice sorgente sono considerati modifiche e sono coperti da NPL. E, con riguardo alle preoccupazioni espresse da molti su Internet, nuovi file che non contengano alcunché del codice originale o di quello susseguentemente modificato non sono coperti da NPL. Questo codice risultante può essere coperto da qualunque licenza compatibile. La GPL non è compatibile con la Netscape Public License o con la Mozilla Public License. La GPL è per natura incompatibile con ogni altra licenza, dal momento che proibisce l'aggiunta di qualunque restrizione o di ulteriori sconfinamenti. Tutto il codice sviluppato per funzionare in associazione con software GPL deve venire a sua volta coperto da GPL. Un altro punto minore è che la GPL insiste che il codice, quando venga distribuito secondo i suoi termini, sia completo e intero. La NPL non include questa condizione.

Le discussioni sui newsgroup avevano posto in grande rilievo un fatto importante: gli sviluppatori avevano bisogno che Netscape acconsentisse a una distinzione fra le correzioni dei bug e il codice nuovo. Chiaramente, una cosa è dire "sto correggendo un bug, una piccola modifica al vostro programma", e tutt'altra "aggiungo al vostro programma una caratteristica nuova". Due sensazioni molto diverse! Per molti andava benissimo dar via una "bug fix", il valore del contributo essendo premio a se stesso. Ma il codice nuovo e tutta un'altra faccenda. Uno sviluppatore che abbia fatto una gran mole di lavoro originale non vorrà vedere un altro che la usa per il proprio guadagno.

La NPL e la MozPL erano state progettate per incoraggiare lo sviluppo aperto sulla base del codice di Mozilla, ma fin dall'inizio avevamo in mente anche un altro obbiettivo. Netscape aspirava ad essere la prima grande azienda ad aprire il suo codice proprietario, perché intendeva patrocinare un più ampio interesse delle società nello sviluppo in ambiente Open Source. La cosa più importante era creare un'atmosfera che rendesse possibile a grandi organizzazioni a scopo di lucro di adottare questo modello e partecipare al movimento. L'infrastruttura legale in gran parte delle licenze Open Source è un grave ostacolo alla cooperazione interaziendale. Con Mozilla la licenza era progetto di se stessa. Concedendo il codice per versioni future, speravamo di coinvolgere l'intera comunità della Rete nella creazione di un'innovazione nel mercato dei browser: l'idea che ci sarebbe stato in giro per il mondo un gran numero di dotati programmatori a smanettare sul nostro codice, infondendovi la propria energia creativa, motivava tutti a tener duro.

Mozilla.org
Chi già aveva esperienza di progetti Open Source si rese conto che il codice aveva bisogno di un posto in cui vivere. La notte successiva all'annuncio da parte di Netscape della liberalizzazione del codice, Jamie registrò presso l'Internic un nuovo nome di dominio e tracciò un grafico del funzionamento dei progetti a sviluppo distribuito. Era nato Mozilla.org.

I progetti Open Source fortunati seguono sempre uno schema, non necessariamente stabilito dal progetto. Di solito, una persona o un gruppo cura il coordinamento. I partecipanti lavorano sull'aspetto del codice che più li interessa, seguendo il loro istinto. Alla fine della giornata, si ritrovano con qualcosa che funziona un po' meglio per loro. Ma che cosa succede un mese dopo, quando esce una nuova versione del software? L'impulso è svanito e si ritrovano al punto di partenza: o più indietro ancora, perché il software può essere cambiato.

Ne risulta che gli sviluppatori vogliono che le loro patch siano incluse nella distribuzione (nel prodotto) principale. Ma se c'è in giro solo un mucchio di codice sorgente e un po' di gente che ci lavora sopra, alla fine qualcuno si alzerà e dirà: "Tanto vale che raccolga un po' di patch e le rilasci". Quando arriva un altro chiedendosi come includere la sua patch nella prossima release, dirà: "Non so a chi darla, allora la do a quello lì. Sembra che faccia un buon lavoro". Col tempo, quella prima persona diventa il curatore.

In questo progetto Open Source i buoni stavano davanti al carro. Mozilla.org era stato concepito e progettato per assumere il ruolo del curatore fin dal principio. Dal momento che il ruolo sarebbe stato coperto in un modo o nell'altro, decidemmo di creare l'infrastruttura per divenire la stanza di compensazione.

Nei mesi seguenti, mozilla.org cominciò a costruire un'organizzazione, ottenendo fondi e macchine, istituendo mailing list e sviluppando tutto quando era necessario perché funzionasse. La missione non era altro che mettere in moto l'organizzazione. Era cruciale che ci fosse un deposito centrale operativo non appena il codice fosse rilasciato. E se non fossimo stati pronti, nel giro di sei mesi avremmo visto qualcun altro farlo. Netscape non è nota per restarsene seduta a guardare gli altri che fanno le cose.

Cedere il codice significava per Netscape collaborare con la Rete. E c'era un altro concetto cruciale che si doveva accettare: il Netscape Client Product Development Group e mozilla.org non erano la stessa organizzazione. L'obiettivo di mozilla.org è di fungere da coordinatore per tutti coloro che, nel mondo, lavorano sul software. L'intento del Product Development è di consegnare prodotti, prodotti Netscape basati sul codice di Mozilla. Dal momento che entrambi i gruppi lavorano sullo stesso prodotto, gli interessi possono sovrapporsi. Ma il gruppo dietro mozilla.org sapeva che sarebbe stato disastroso che la Rete, considerando l'organizzazione, pensasse: "Questa gente ha a cuore solo gli interessi di Netscape; pensano solo a preparare prodotti Netscape". Questo avrebbe significato per mozilla.org il fallimento dell'obiettivo di essere un buon curatore del progetto. La separazione doveva dunque essere reale e la Rete doveva saperlo.

Dietro il sipario
Che cosa succede quando uno sviluppatore effettua una modifica e comincia a dire "ehi, mozilla.org, prendete il mio codice"? Uno dei compiti più importanti di mozilla.org è tracciare i confini fra il codice accettabile e quello inaccettabile. Molti sono i fattori per determinarlo. In primo luogo il merito. E' buono? In secondo luogo, si trova sono una licenza compatibile con la NPL? Abbiamo deciso infatti di non accettare contributi che non siano sotto una licenza NPL-compatibile. Diversamente, ci dovrebbero essere directory separate, muraglie cinesi e tonnellate di gergo legale per tutte le parti in causa. Il potenziale d'errore andrebbe alle stelle e oltre.

Dal momento che Mozilla è un codice di base altamente modulare, ogni modulo principale, come la Image Library o il parser XML, ha il suo "titolare" designato. Quella persona conosce meglio di ogni altro il codice ed è arbitro di che cosa possa entrarvi e che cosa no.

Molti titolari dei moduli sono progettisti di Netscape, altri sono arrivati a bordo dal mare magnum della Rete. Quando un titolare di modulo effettua una modifica (per esempio, aggiungendo un'API all'Image Library), essa è inviata a mozilla.org per essere inclusa nelle distribuzioni. Se insorge una divergenza fra chi contribuisce e il titolare di modulo, mozilla.org 6.inge da arbitro e sua è l'ultima parola (senza dimenticare mai che, se non sarà equa, verrà ignorata e qualcun altro assumerà l'arbitrato).

Mozilla.org ha dovuto combattere con il fatto che sul codice sarebbero stati al lavoro sia gli sviluppatori di Netscape sia sviluppatori indipendenti, via Rete. I metodi usati internamente per lavorare sul codice hanno dovuto adeguarsi al Web e rendersi accessibili su tutte le piattaforme, in tutti i fusi orari. Ciò è stato reso possibile con il "controllo ad albero" (tree control) effettuato dagli strumenti Bonsai e Tinderbox.

."Bonsai" è uno strumento tramite il quale è possibile eseguire ricerche sui contenuti di un archivio. Come al banco di una biblioteca, vi si può "registrare" il codice su cui si è lavorato, o vedere quali altre "registrazioni" siano state effettuate da altri. In background il codice è costantemente eseguito, controllando l'albero del codice. Se l'albero s'interrompe, viene emessa una bandiera rossa, fermando ulteriori registrazioni finché il problema non sia stato identificato. I log possono essere controllati e i problemi fatti risalire a un momento particolare. Già usato da Netscape internamente, è stato trasportato su mozilla.org per essere usato dagli sviluppatori in tutto il mondo e direttamente, via browser, su qualunque piattaforma.

Se avete più di dieci sviluppatori insieme al lavoro senza strumenti, ci sarà un'esplosione. Questa è la teoria dietro "Tinderbox", un programma che tiene sotto controllo questa situazione potenzialmente esplosiva. Tinderbox è uno strumento "detective". Permette di vedere che cosa stia succedendo nell'albero del sorgente. Mostra chi ha registrato che cosa (chiedendolo a Bonsai), quali piattaforme abbiano lavorato con successo e quali invece abbiano ceduto, il modo esatto in cui hanno ceduto e lo stato dei file che costituiscono il codice fornito, in modo da poter rintracciare il possibile autore del danno.

Primo aprile 1998
Eravamo a una settimana e mezza dalla fine di marzo 1998, la scadenza si stava approssimando velocemente. Avvertivamo tutti l'esigenza di celebrare degnamente con una festa il rilascio del codice, ma nessuno aveva ancora fatto niente. In accordo con il resto del progetto, quel party selvaggio sarebbe stato un evento senza precedenti che avrebbe ammesso il pubblico dentro il mondo di Netscape, senza nessuno schermo.

Fu Jamie che, in una riunione, espose il suo piano: affittare un nightclub a San Francisco, invitare il mondo intero e diffondere il tutto sulla Rete. "Intendi dire invitare al party anche dei non dipendenti? Ma non lo abbiamo mai fatto...". In carattere con il resto del progetto e dopo una breve pausa, la reazione fu: perché no.'

Quella festa non verrà dimenticata presto. Jamie affittò uno dei nightclub più grandi di San Francisco, The Sound Factory, per la notte del primo aprile. I DJ (Fra i quali Brian Behlendorf, fondatore di Apache) distribuirono migliaia di magliette di mozilla.org, software e gadget di NetObjects, Macromedia, Digital, Be, Wired e unAmerican Activities.

All'apertura delle porte del "Mozilla Doti Party", alle otto, c'era già la coda. t. Un'ora e mezza dopo, il locale aveva raggiunto la capienza massima concessa dalle norme di sicurezza, duemila persone, e la coda faceva il giro dell'isolato. La gente veniva ammessa in gruppi di venti man mano che altra gente lasciava il party, e prima che la notte fosse finita oltre 3500 avevano varcato le soglie: fra questi, guru del free software come Brewster Kahle (fondatore di WAIS) e Eric Raymond. Altre centinai;i di persone in tutto il mondo sincronizzarono gli orologi e brindarono a Mozilla. I partecipanti virtuali erano un gruppo di oltre cento dall'Olanda e gruppi sparsi in Norvegia, Montreal, Pensylvania, Carolina del Nord, Wisconsin, Colorado e Alabama. All'interno, tre schermi di proiezione facevano scorrere il codice alla velocità di sessanta righe al secondo (in quel modo, la festa avrebbe dovuto durare più di sette ore per mostrare tutto il milione e mezzo di righe del codice di Mozilla). Nel corso del secondo di due set suonati dalla Kofy Brown Band (ne era membro un progettista Netscape), Eric Raymond, giunto da Filadelfia per l'occasione, salto sul palco e sorprese tutti con un assolo di flauto. Verso la fine della serata, una dozzina di CD del codice sorgente di Mozilla "Signature Edition" (firmati e numerati la sera prima dal Netscape Build Team e da membri di Mozilla.org) furono gettati a qualche fortunato fra la folla.

La lucertola era libera!

Copyright © 1995-1999 Apogeo srl, Milano