Gli scheletri nell’armadio di Mozilla.org

Premessa

Questo articolo non vuole rappresentare una critica fine a se stessa, ma un monito per tutti coloro che si fidano ciecamente di quanto leggono sulle press release, nelle interviste e sui blog che riguardano il mondo di mozilla.org: non sempre è tutto oro quello che luccica…

Chi scrive ha vissuto con alterne vicende il periodo di sviluppo di Mozilla da quando era ancora Netscape/AOL fino all’odierna Fondazione/Corporation, non certo come interno, ma da semplice utente/tester, tramite bugzilla, IRC ed i newsgroup. Il tutto a partire dalla Milestone 09 di Mozilla Suite, una delle prime a non esplodere appena fatto clic su un pulsante e con uno straccio di client di posta funzionante, per poi passare all’utilizzo esclusivo della Suite a partire dalla Milestone 13 (1999 o inizio 2000).

Sommario

  1. Agli albori
  2. La dicotomia Mozilla-NS
  3. Liberi da NS/AOL
  4. Il problema localizzatori
  5. Il pasticcio Firefox 1.0 in Italiano
  6. La nascita di SeaMonkey
  7. Cambiamenti in vista?
  8. Ringraziamenti

1. Agli albori

Al tempo della mia prima visita del mondo Mozilla, il progetto sembrava un grande calderone in ebollizione: a distanza molto ravvicinata venivano scritte e riscritte grandi parti di codice, anche più volte nella stessa settimana; non di rado avvenivano collisioni tra patch diverse che andavano a lavorare sullo stesso sorgente, oppure si appoggiavano su funzionalità che nel frattempo erano state completamente cambiate. Inutile dire quali risultati comportasse una situazione del genere: potevano passare dei giorni prima che fosse disponibile una versione nightly che solamente partisse…

La cosa divertente però era che il codice migliorava sensibilmente sia in qualità sia in velocità: era facile vedere patch che miglioravano le prestazioni di una specifica parte di codice anche di 2 o 3 volte, magari più volte in un mese! Non appena un programmatore trovava un qualcosa di utile, aggiungeva codice anche senza una specifica utilità immediata, ma solo perché in prospettiva poteva servire a questo e quello, e tutto era già lì pronto… Altro codice veniva aggiunto al solo scopo di poterci innestare sopra il codice proprietario di Netscape (ad esempio, nella Suite ed in SeaMonkey nel menu Finestre lo shortcut per il client AIM/ICQ integrato [Ctrl+3] è ancora inutilizzabile).

All’epoca il QA era fatto in maniera seria e rigorosa: numerose persone partecipavano alla verifica dell’effettiva chiusura dei bug e davano indicazioni su come migliorare effettivamente le cose. In pratica si trattava di un vero e proprio team apposito interno a NS, e gli esterni non venivano presi in considerazione perché non avevano idea di quale fosse l’effettivo modus operandi del processo di verifica. Visto che proprio questo gruppo è stato falcidiato nei primi tagli a NS, la qualità del QA, il suo ruolo ed il suo apporto si è via via deteriorato fino a rimanere solo e soltanto una voce di bugzilla (il QA contact, che nessuno ha mai capito bene cosa fosse). In pratica oggi il QA viene espletato dagli stessi peer reviewer o super reviewer delle patch, mentre il QA globale dell’applicazione viene lasciato a degli esterni che devono eseguire una serie prefissata di test che ben poco è variata dai test di regressione di Mozilla Milestone 09…

[Torna al sommario]

2. La dicotomia Mozilla-NS

Oltre al QA, anche gli ingegneri software avevano la loro parte di problemi: NS premeva per implementare un numero enorme di funzioni quando il codice sottostante non era ancora maturo a sufficienza per resistere allo sforzo. Molto altro codice veniva aggiunto senza mai completare la funzionalità voluta, e il codice cresceva… Peggio ancora fu quando NS decise di far uscire la versione 6, basata su codice ampiamente in beta se non addirittura in alpha. Vennero prese scorciatoie, tagliato il codice qua e là, e buttato dentro altro materiale dell’ultimo minuto. Il contraccolpo mediatico di una versione così disastrosa fu il chiodo definitivo sulla bara di NS stessa. I superstiti stabilirono un piano ben preciso e dettagliato per arrivare alla versione 1.0 di Mozilla e da lì a NS 7.

Vennero chiusi i buchi più grossi, reso più solido il codice dando una grossa stretta su tutti i bug che comportavano crash del programma o addirittura del sistema, nonché a quelli che implicavano la perdita di dati. Dopo una bella opera di pulizia finalmente uscì la versione 1.0 ed era davvero tutto un altro pianeta rispetto alle Milestone precedenti. Dopo pochi mesi vide la luce NS 7, con successivo round di licenziamenti e la necessità di ben due versioni di Mozilla prima di vedere reinseriti i fix sviluppati per NS7 che non fossero proprietari. Dopo la 1.2/1.2.1, venne la 1.3.x, forse la peggiore versione di Mozilla mai uscita, nonché l’ultima in cui David Hyatt (ora autore di Safari) ha avuto carta bianca con i suoi cambiamenti improvvisi e repentini.

La versione 1.4 è stata invece quella in cui sono state migliorate in maniera significativa la gestione della memoria e l’ottimizzazione delle prestazioni. L’apporto della comunità degli sviluppatori non NS cominciò ad avere sempre più peso, ma alcuni ingegneri NS erano rimasti a dirigere il traffico: si fece pressante anche la richiesta di modificare, spesso pesantemente, l’interfaccia utente della Suite per togliere di mezzo alcune voci inutili e riorganizzare con più razionalità certe altre funzioni. La risposta ufficiale con cui tutto venne respinto fu: poiché il codice di Mozilla non è destinato agli utenti finali (per quello ci pensa NS7), è inutile modificare l’aspetto esterno e non abbiamo risorse per farlo. Era cominciata l’ingessatura della UI.

Contemporaneamente, un ristrettissimo gruppo di sviluppatori decise di mandare a quel paese NS e di sviluppare in proprio un prodotto a parte, che fosse solo browser per non essere stoppati sul nascere a causa di sovrapposizioni e competizione interna. Venne dato un nome evocativo (Phoenix, fenice, ovvero il mitico uccello di fuoco che rinasce dalle proprie ceneri) e, per evitare che quelli di NS potessero intralciare il lavoro, venne adottata una politica feroce per l’accettazione delle patch di terze parti: non ne vogliamo. Molti sviluppatori non NS davanti a tale atteggiamento persero qualsiasi interesse nel fornire il proprio aiuto al nuovo progetto: altri ingegneri di NS venivano introdotti in maniera simil-carbonara al nuovo progetto solo quando le loro capacità tecniche venivano ritenute indispensabili (ad esempio, Doron Rosenberg, autore di quasi tutto il codice di gestione delle connessioni di rete di Mozilla e della gestione della cache).

[Torna al sommario]

3. Liberi da NS/AOL

Con il completo disimpegno di AOL/NS, e la creazione della Fondazione, si decise di proseguire nello sviluppo della Suite (unico prodotto conosciuto) e di portare avanti sia Phoenix che il nascente Thunderbird (frutto del lavoro di un solo ingegnere, Scott MacGregor). I dipendenti della Fondazione al lavoro sui sorgenti erano ridotti al lumicino, meno di dieci, e alcuni di loro neanche a tempo pieno: per fortuna IBM, Sun e RedHat ci misero dei loro programmatori o assunsero ingegneri ex-NS per proseguire lo sviluppo. Visto che si era sbandierato Mozilla come piattaforma di sviluppo per vari e diversi software (ad esempio, l’IDE Komodo, alcuni altri browser e altre applicazioni verticali), si promise che la versione 1.7 che andava a sostituire la 1.4 sarebbe stata mantenuta e supportata per almeno 2 anni, che non sono ancora scaduti…

La versione 1.0 di Firefox, nome definitivo dopo la figuraccia fatta col nome Firebird, già utilizzato da un altro noto progetto OSS per la versione free del DB ex-Borland, aveva cambiato le carte in tavola: il successo di pubblico e l’incremento di visibilità fecero pendere i favori della Fondazione definitivamente verso la coppia FF e TB, anche a costo di mandare a quel paese il discorso piattaforma Mozilla e chi nel frattempo ci aveva costruito dei prodotti sopra, o aveva inserito Gecko nei propri programmi: infatti, a causa delle scelte fatte per ridurre le dimensioni di FF, non è possibile utilizzarlo all’interno di altri programmi e non può fungere da piattaforma (per questo motivo alcune distribuzioni Linux che offrono FF e TB di base, installano pure Mozilla Suite di nascosto).

Velocemente si è deciso di mettere una pezza alla nuova situazione assumendo Benjamin Smedberg al fine di sviluppare XUL Runner, erede dello sfortunato GRE, e che per lungo tempo sembrava destinato all’oblio poiché non si era raggiunto un accordo su cosa dovesse farne parte e cosa no. Ad oggi in pratica XUL Runner contiene Gecko, l’Extension Manager, la gestione degli aggiornamenti, la gestione dei profili, la gestione della sicurezza e tutto ciò che consente le connessioni di rete: restano fuori la gestione dei segnalibri e la cronologia. Questo perché, ad esempio, sono circa 4 anni che si parla di riscrivere la gestione dei segnalibri, che è forse la parte più oscura di tutto il sorgente di Mozilla dal momento che ha conosciuto almeno due traduzioni: prima da C++ a JavaScript e poi il viceversa, con ovvi problemi di leggibilità.

3 piccole considerazioni sul programmatore appena citato:

  1. è l’autore di alcune patch che hanno aumentato in maniera considerevole i memory leak del codice di Mozilla (alcuni hanno richiesto mesi prima di essere sistemati);
  2. è lo stesso personaggio che ha messo dentro l’albero di Mozilla tutte le versioni localizzate di DOM Inspector senza discriminare in base alla lingua di produzione delle build. Cosa comporta questa scelta? Oltre alla versione inglese, vi beccate quella in cinese, polacco, russo, tedesco, ecc. per un totale di 20 lingue eccetto l’Italiano: l’installer di FF diventa troppo grosso è stata la risposta alle lamentele dei team di localizzazione esclusi;
  3. è colui che ha accusato pubblicamente i traduttori italiani di FF (tradotto: Michele Dal Corso) di aver copiato dai norvegesi e di aver procurato grossi guai alle build localizzate: peccato che il team norvegese abbia subito ammesso il proprio errore e discolpato i localizzatori italiani, ma la persona ha accuratamente evitato di scusarsi.

Nel frattempo proseguiva il lavoro di sviluppo di Mozilla Suite 1.8, venivano fatti due bug triage completi (si scelgono i bug da sistemare entro la release successiva), non solo per la beta 1 ma anche per la beta 2. Di punto in bianco, avendo già preparato il piano di riserva XUL Runner, viene dato l’annuncio dell’abbandono dello sviluppo di Mozilla Suite per la mancanza di risorse. In verità il dubbio rimane, visto che il codice della Suite di base è identico a FF/TB, mentre la UI era stata artatamente bloccata anni prima. Ovviamente oltre al blocco della UI, visto che MAS 1.7.x non poteva introdurre nuove funzionalità, cominciava ad accusare sempre più ampie differenze rispetto a FF/TB anche in termini di caratteristiche. Se il codice di base è comune, la UI non viene più modificata e le nuove funzionalità non possono essere aggiunte, quali risorse mancano? Mistero.

[Torna al sommario]

4. Il problema localizzatori

Ai tempi di NS esistevano gruppi all’interno della società che si occupavano di tradurre il browser in varie lingue, compreso l’Italiano. Dopo il fiasco NS6 e i licenziamenti seguenti alla fine della bolla speculativa su Internet del 2000, tali gruppi sono stati ridotti ad uno solo, quello tedesco, la cui sopravvivenza era giustificato dal fatto che NS aveva ancora delle attività di ISP in Germania. Le traduzioni fatte dalla comunità divennero così fondamentali per la diffusione di Mozilla nelle varie parti del mondo non anglofono, ovvero la maggior parte.

Eppure all’interno della Fondazione le necessità dei localizzatori (le persone che traducono i vari applicativi Mozilla) e le loro difficoltà venivano del tutto ignorate. I cambiamenti alla documentazione e alla UI venivano inseriti fino all’ultimo momento, senza avvisare nessuno dei localizzatori, e spesso anche in maniera molto pesante per il lavoro dei localizzatori. Ci sono voluti mesi affinché le patch sviluppate dai localizzatori in arabo, costretti a diventare sviluppatori a causa dei bug nella gestione delle stringhe da destra a sinistra (contrariamente alla nostra convenzione), fossero revisionate ed infine accettate dalla Fondazione.

In questo contesto si è scatenata una protesta originata sempre dal sottoscritto (non è che sono polemico, sono l’unico che ha dedicato una giornata a preparare la pagina web ed i riferimenti a bugzilla ed alle discussioni sui newsgroup) affinché la Fondazione tenesse in conto anche le nostre esigenze: molto duri sono stati i miei scontri con Chris Hoffman e RJ Keller, il primo dipendente di mozilla.org ed il secondo, module owner della documentazione di Help (la Guida di MAS/SM e poi anche della guida di FF), solo per breve tempo alle dipendenze di mozilla.org.

Il buon Chris voleva eliminare dalla Guida tutte le immagini ed in prospettiva metterle sul sito web di mozilla.org perché così avremo dati statistici validi, ridurremo la dimensione dell’installer e comunque la Fondazione non ha alcun problema di banda: questo è successo prima che mozilla.org diventasse irraggiungibile per 3 giorni in concomitanza con l’uscita di FF preview… Tra l’altro faceva parte dei drivers (coloro che guidano lo sviluppo di Mozilla fino ad una release stabile) ma, guarda caso, nessun altro dei drivers ha mai saputo della polemica in atto finché non ho scritto a drivers@mozilla.org: nel frattempo nelle minute delle riunioni si diceva che i localizzatori erano tutti contenti… Il buon RJ, da par grado, voleva proseguire nel discorso rimozione immagini, per poter risparmiare 300KB, arrivando a dire che la decisione è già stata presa e sono tutti d’accordo, e addirittura a mentire agli altri driver. Al termine della battaglia, ha rimesso il suo incarico di module owner per la documentazione (posizione rimasta vacante per anni, fino alla creazione del SeaMonkey Council) e si è dedicato inizialmente alla scrittura della Guida di FF, mentre ora collabora con una società che produce browser basati su Gecko (ironia della sorte: sono tutti basati sulla Suite).

[Torna al sommario]

5. Il pasticcio Firefox 1.0 in Italiano

Ad Ottobre 2004 tutta la comunità dei traduttori era in fermento per l’imminente uscita di Firefox 1.0: era stato previsto un processo molto stringente di verifica non solo delle traduzioni, ma anche dei segnalibri da distribuire con le versioni localizzate (in pratica andava tolto tutto ciò che faceva riferimento a siti non free, e, per rispettare accordi commerciali preesistenti, andava impostato Google ovunque). La cosa peggiore è che la decisione definitiva sulla lista dei segnalibri cambiò a poche ore dal rilascio ufficiale ed anche la procedura subì dei cambiamenti che non furono comunicati a nessuno.

Tutto sembrava essere risolto e con una certa soddisfazione il team Italiano (tradotto: sempre Michele) si preparava a vedere la lingua del Belpaese tra quelle ufficiali presenti al lancio del nuovo browser, per cui era stata preparata anche una accurata campagna pubblicitaria, tradotta anch’essa. Annuncio ufficiale e sorpresa sgradita: l’Italiano non c’è! Pensiamo subito ad un qualche disguido temporaneo dovuto alla fretta, e attendiamo notizie precise, tanto più che mozilla.org era sprofondato per alcune ore visto il picco di accessi (alla faccia della connettività in eccesso). Cerchiamo di tamponare la situazione mettendo online le nostre build di test semi-ufficiali, ma in breve mandiamo in crisi il nostro sito ufficiale e quasi tutti i siti personali dei soci. Anche altri mirror provvisori e gentilmente offerti, vanno in crisi quasi subito: nei primi 2-3 giorni di uscita, scaricare FF in Italiano è praticamente impossibile. Controlliamo la posta personale, i newsgroup e bugzilla alla ricerca di qualche spiegazione: nulla. Passano le ore e cresce la preoccupazione, mentre aumentano i commenti negativi, fino anche agli insulti personali, su MozillaItalia ed i suoi membri su vari siti web nostrani.

Con una certa cattiveria, decido di scoprire cosa è successo su IRC: ci vogliono circa 24 ore per riuscire a parlare con qualcuno che si occupava del rilascio di FF 1.0: infatti, dopo l’uscita ufficiale erano tutti andati a dormire dopo turni non stop di 36-48 ore per coordinare il tutto. Ancora un paio di scaricabarile vari (cominciando da Ben Goodger, deus ex machina di FF stesso, e passando dal solito Benjamin), e finisco a parlare con Axel Hecht, che mi informa che probabilmente non avevamo cambiato un paio di segnalibri sostituiti all’ultimo secondo e che nessuno si era degnato di segnalarci. Avviso Michele e nel giro di due ore eravamo pronti: qualche altra ora per fare pressing su IRC affinché sistemassero completamente la build italiana senza altri impicci, e ci mettiamo più tranquilli, anche se un po’ sconcertati. Passa altro tempo prima di comparire nella lista ufficiale delle traduzioni, ma oramai il danno è fatto e si è persa una occasione unica ed irripetibile per fare buona pubblicità in Italia a Firefox.

Dopo l’increscioso incidente, è stato deciso di avere un coordinatore per tutto ciò che concerne l10n, ed è stato scelto Axel. Le cose sembravano aver preso una nuova piega: molte questioni che sembravano bloccate hanno avuto una improvvisa svolta ed è sembrato che si fosse presa la strada giusta. Tutto risolto? Neanche per idea. Nonostante Axel sia europeo e membro di mozilla-europe, in occasione di FF 1.5 molti localizzatori si sono ritrovati a lavorare di notte per tradurre il nuovo materiale promozionale e le pagine del sito mozilla-europe appena in tempo per l’uscita ufficiale: nonostante tutto fosse stato programmato con largo anticipo, il materiale da tradurre non era stato fornito ai localizzatori. Ed una serie di correzioni alla traduzione italiana per FF non sono state accolte per 1.5.0.1 (e sembra proprio neanche per 1.5.0.2), anche se la patch era pronta non appena uscito FF 1.5.

[Torna al sommario]

6. La nascita di SeaMonkey

La decisione secca ed improvvisa di abbandonare la Suite lascia di sale alcune società e parecchi sviluppatori, specie per il momento in cui viene annunciata (appena prima dell’ultima beta prima di Gecko 1.8) e per la quantità di lavoro che era già in corso. Alcuni sviluppatori poi, memori delle negative esperienze avute all’inizio del progetto Phoenix, e contrari alla quasi totale assenza di un processo ferreo di revisione e super revisione delle patch vigente nell’ecosistema FF/TB, decidono di mettersi in gioco e di provare a subentrare alla Fondazione per lo sviluppo della Suite: nasce il SeaMonkey Council (per certi versi equivalente ai drivers di mozilla.org). La Fondazione si dimostra subito molto recettiva, ben felice di poter presentare qualcuno che si occupasse di un prodotto abbandonato alla schiera di utenti che volenti o nolenti non potevano rinunciare alla Suite. Man mano che il progetto prende corpo, la Fondazione impone una singola ma pesante condizione: non potrà essere usato il nome Mozilla, fin da subito, per poter proteggere il marchio registrato e non confondere gli utenti con un prodotto che non è genuino della Fondazione stessa, ma solo sponsorizzato.

Viene data assistenza legale allo scopo di trovare un nome ed un marchio al nuovo progetto, rispolverando il vecchio nome in codice della Suite all’epoca di NS 4.x, e vengono promesse risorse (ftp, macchine di build e test, l’uso di bugzilla) al progetto con tanto di articolato avviso stampa pubblico. Sotto pressione del sottoscritto, Brendan Eich, capo progettista di mozilla.org conferma che anche Calendar, Sunbird, e Camino non potranno usare in alcun modo il nome di Mozilla, visto che sono anch’essi progetti sponsorizzati dalla Fondazione ma non garantiti: a tutt’oggi il nome Mozilla compare ancora in quei prodotti (eccetto Camino). È evidente che la protezione del marchio è stata fatta valere esclusivamente per la Suite.

Il 30 Gennaio 2006 esce la versione definitiva di SeaMonkey 1.0, dopo appena 6 mesi di sviluppo portato avanti dalla comunità. Il gap di funzionalità (eccetto per la gestione delle estensioni e degli aggiornamenti automatici) con FF/TB è stato ridotto, il motore di rendering è identico, la UI comincia a subire qualche cambiamento (ad esempio, pannelli di preferenze e Proprietà della pagina). Funzionalità bloccate per esplicita volontà di alcune persone all’interno della Fondazione possono finalmente tornare ad essere discusse (ad esempio, feed RSS per SM Posta: la patch era pronta da 5 mesi ma chi doveva autorizzarla si rifiutava di annullare un vantaggio di TB). Un problema rimane a distanza di tanti mesi: la promessa delle machine di build non si è mai concretizzata, e tutte le build distribuite di SM sono state create da volontari e non dalle macchine prestate da mozilla.org. Per questo motivo non includono il supporto a TalkBack (lo strumento che spedisce a mozilla.org i dati raccolti in caso di crash del programma), che è un programma proprietario e di cui solo la Fondazione può utilizzare i codici. E così il testing dei crash di SM non può essere fatto, nè tutti gli utenti di Gecko possono giovarsi dei report degli utilizzatori di SM sugli errori contenuti nel codice comune.

[Torna al sommario]

7. Cambiamenti in vista?

A fine Febbraio 2006 si è svolto il FOSDEM 2006 a Bruxelles: tale evento si è segnalato soprattuto per alcuni avvenimenti storici per quanto riguarda mozilla.org e la sua comunità di utenti e sviluppatori. La Fondazione ha organizzato un meeting dei localizzatori (pagandogli il viaggio aereo) e sono state tenute alcune importanti presentazioni non solo di FF/TB ma anche di Camino e SeaMonkey. Purtroppo nessuno di MozillaItalia ha potuto partecipare, ma qualche notizia è arrivata lo stesso.

In vista dei cambiamenti previsti per FF2, c’è una buona probabilità che per mantenere la dimensione del download accettabile (quindi più o meno come quella attuale) il tristemente noto problema con DOM Inspector venga risolto alla radice: invece di essere distribuito con FF, verrà messo a disposizione su addons.mozilla.org. In tale modo saranno in grado di risolvere anche il problema delle traduzioni non ancora distribuite come ad esempio l’Italiano.

Alcuni interventi sono stati degni di nota per SeaMonkey: Paul Kim (Marketing di FF e webadmin di mozilla.com) spera che il sito mozilla.org, ora che Fondazione e Corporazione sono due entità distinte, possa essere riorganizzato ponendo l’accento sui progetti invece che sui prodotti (ma chissà perché si richiedono volontari per gestire la cosa); Gervase Markham (dipendente della Fondazione ed addetto ai problemi di licenze) si è detto della stessa opinione ed ha annunciato che verrà portata avanti una politica di branding simile a quella di Ubuntu per quanto riguarda SeaMonkey.

[Torna al sommario]

8. Ringraziamenti

Un grazie alle persone che mi hanno spinto ed aiutato a scrivere questo documento, in ordine sparso:

  • Giuliano Masseroni
  • Francesco Lodolo
  • Iacopo Benesperi