YouTube e Vimeo hanno cominciato ad offrire la possibilità di riprodurre contenuti video sfruttando l’elemento <video> dell’HTML5. Questa, da un lato, è una buona notizia per il software libero perché significa che non ci sarà bisogno del plugin proprietario Adobe Flash per riprodurre i video ^[1]. Dall’altro non è una buona notizia per il software libero perché questi contenuti saranno offerti in formato H.264. Molte persone hanno notato che Firefox non è in grado di supportare H.264 ma sembra che molti non ne capiscano il motivo o ignorino i problemi che H.264 comporta. È bene quindi riepilogare i fatti e spiegare perché Firefox non supporta H.264.

Il nocciolo del problema è semplice: H.264 è gravato da brevetti la cui licenza è controllata da MPEG-LA. Se si distribuiscono i codec H.264 in una giurisdizione dove i brevetti software sono applicabili, chi non ha pagato la licenza per il brevetto a MPEG-LA corre il rischio di venire perseguito legalmente.

Quindi, perché Mozilla non paga semplicemente la licenza per H.264 (come tutti gli altri)? Il motivo principale è che ciò violerebbe i principi del software libero in cui crediamo fermamente. In particolare, crediamo che gli utenti finali del nostro codice debbano essere in condizione di modificarlo e ridistribuirlo senza alcuna perdita di funzionalità. Questa è la libertà che le licenze copyleft (come la GPL e la LGPL, che utilizziamo per il nostro codice) intendono assicurare. È possibile ottenere le licenze del brevetto in maniera da non violare l’interpretazione letterale della licenza GPLv2 e della LGPLv2; ma non è nostra intenzione rispettarne la lettera violandone lo spirito.

Ma non esistono implementazioni (L)GPL dell’H.264? Sì, ma non sono così libere come sembrano. La loro libertà è stata silenziosamente indebolita dai brevetti (nelle giurisdizioni in cui tali brevetti esistono e sono applicabili). La licenza del software permette la ridistribuzione e l’utilizzo del codice ma la MPEG-LA può comunque impedirlo. ^[2]

Ma la MPEG-LA non si accanirà legalmente contro di me o il mio progetto, non siamo così importanti. Forse è vero ma spero che siano pochi i progetti software per cui il “rimanere insignificanti” costituisca una strategia valida. Non è certamente un’opzione per Mozilla. Se non avessimo distribuito legalmente Firefox a decine di milioni di utenti, probabilmente oggi sarebbe possibile navigare sul Web solamente con Internet Explorer su Windows. Inoltre, non è un’ottima idea confidare nella discrezionalità dell’azione penale.

Mozilla dovrebbe semplicemente includerlo senza licenza come gesto di disobbedienza civile. Potrebbe essere divertente, ma mi aspetterei molto presto un’ingiunzione che ci obblighi a disattivare H.264 e una richiesta di risarcimento danni a MPEG-LA. Non sarebbe una vittoria.

Mozilla dovrebbe individuare e utilizzare i codec H.264 già installati sul sistema. Per una serie di motivi questa sarebbe una cattiva idea, specialmente su Windows. Queste le ragioni principali:

• La maggior parte degli utenti con Windows Vista e versioni precedenti non hanno un codec H.264 installato sul sistema. Perciò per la maggior parte degli utenti questa non è una soluzione.
• Ciò risolve la questione relativa alla libertà del software per il browser (dove noi abbiamo la possibilità di far sentire la nostra voce e cercare di cambiare la situazione dei codec) ribaltandola però sulla piattaforma (su cui noi non abbiamo alcuna voce in capitolo). In questo modo non si avrà comunque un client web basato unicamente su software libero.

Ma io potrei semplicemente installare gstreamer-plugin-ugly e risolvere il problema. Questo comportamento è egoista. Ognuno dovrebbe essere in grado di navigare sul Web con un client completamente libero senza compiere strane evoluzioni per scaricare e installare oscuri programmi (il cui utilizzo tra l’altro è legalmente discutibile).

I brevetti per H.264 scadranno presto, e allora il problema si risolverà. Molti brevetti di H.264 non scadranno prima del 2017. In ogni caso, H.264 non sarà l’ultimo codec di compressione video ad essere prodotto: ci sarà un H.265 che porterà gli stessi problemi.

Gli utenti vogliono solo che i video funzionino. Voi persone legate a Mozilla siete troppo idealisti! Certo, e questa è la ragione dell’esistenza di Mozilla. Comunque, nel breve termine, gli utenti non saranno penalizzati dal momento che i contenuti video sono automaticamente disponibili anche in formato Flash. Sul lungo periodo, penso che la libertà favorirà gli utenti (non solo gli utenti di Firefox, ma TUTTI gli utenti).

Al di là dei problemi legati al supporto H.264 sui client, ci sono enormi implicazioni legate all’utilizzo di H.264 per gli autori che pubblicano contenuti web e per i provider che li distribuiscono. Al momento, la pubblicazione di contenuti in formato H.264 su Internet non richiede costi aggiuntivi, ma dopo il 2010 le cose quasi certamente cambieranno, come si può leggere in un paio di buoni articoli (in inglese). Non sapremo molto di più in merito prima della fine del mese. Il problema fondamentale non sarà legato ai costi ma al fatto che chi vorrà pubblicare contenuti H.264 dovrà assumere avvocati e concordare una licenza direttamente con MPEG-LA. Ciò non sarà probabilmente praticabile per chi vuole solo pubblicare un paio di video sul proprio sito web, aggiungere un video didattico ad un’applicazione web o inserire una sequenza video in un gioco online. Sul Web non ci sono solamente i video di YouTube; l’obbligatorietà della licenza limiterà sicuramente l’utilizzo del video sul Web (immaginate solamente che cosa sarebbe successo se avessimo avuto un simile obbligo per le immagini…). Anche se non ci fossero questioni di brevetto legate alla parte client, ciò rappresenterebbe comunque una buona ragione per Mozilla per promuovere l’utilizzo di codec completamente liberi.

La verità è che al momento nessuno di noi sa che cosa succederà. Le parti in causa che propongono l’obbligatorietà della licenza sono forti e alla maggior parte delle persone non importa della libertà del software. Noi ci stiamo impegnando al massimo per spingere Ogg Theora e non so che cos’altro possiamo fare se non diffondere il messaggio e aiutare le persone a capire che cosa c’è in gioco in questo momento.

^[1] Gnash e Swfdec possono riprodurre questi video ma in generale non possono competere con le ultime API Flash offerte da Adobe e utilizzate dai siti web più importanti.
^[2] Nella maggior parte dei casi, le implementazioni libere di tecnologia pesantemente affetta da brevetti è dannosa all’ecosistema del software libero per due motivi: confonde le persone inducendole a pensare di avere diritti che in realtà non hanno e quindi possono scoraggiare l’adozione di alternative veramente libere per tutti.

“Fa’ la cosa giusta” è una fiera eterogenea dedicata agli stili di vita sostenibili e al consumo critico il cui motto di quest’anno era “consumare meglio, consumare meno”.
“Consumo critico” significa saper scegliere con ponderazione e oculatezza ciò che si acquista e ciò che si usa. Può darsi che un browser non sia la prima cosa a cui la gente pensa ogni giorno, ma noi crediamo che Mozilla abbia compiuto una scelta intelligente partecipando a questo evento perché anche un browser, così come molti altri beni di consumo (ciò che si mangia, si indossa, si compra o dove si va in vacanza), debba assolutamente essere una scelta prettamente personale così come viene espresso in modo chiaro e forte dal  Motto di Mozilla: “Scelta e innovazione” (in inglese).

Quest’anno la fiera è stata visitata da circa 50.000 persone (il 20% in più delle 40.000 dell’anno passato)  e gli espositori sono stati circa 500. Personalmente, abbiamo calcolato che il nostro stand sia stato visitato da almeno 7.000 persone.

Quest’anno, per la prima volta, un rappresentante ufficiale di Mozilla è stato con noi allo stand per tutti e tre i giorni: William. Possiamo quindi dire che stavolta eravamo davvero “Powered by Mozilla”.

Le persone del Team di Mozilla Italia che non avevano ancora avuto l’opportunità di incontrare William, sono state profondamente colpite dalla sua vitalità, dalla sua socievolezza e dalla sua cordialità. È davvero un ragazzo super!

William e Giuliano

Fin dal primo giorno l’atmosfera allo stand era realmente eccitante. Tutti e dieci i ragazzi del Team di Mozilla Italia che hanno partecipato all’evento erano davvero felicissimi di potersi ritrovare di nuovo e di essere lì per diffondere l’utilizzo di Firefox, “il verbo” della Missione di Mozilla e più in generale tutti gli altri prodotti e progetti della “Foundation”.

Il Team di Mozilla Italia a “Fa’ la cosa giusta” 2009; da sinistra a destra: Andrea, Giuliano, Michele, Iacopo, Giacomo, Elisabetta, Giovanni, Francesco, Simone e ultimo, ma non meno importante, Stefano (che non era presente al momento dello scatto).

Non appena la fiera ha aperto i battenti, il nostro stand ha cominciato ad essere visitato da un gran numero di persone incuriosite. Molte di loro non avevano la più pallida idea di che cosa fossero Firefox e Mozilla, molte altre invece conoscevano già sia il browser che gli altri software, ma necessitavano di un qualche tipo di aiuto o  volevano avere spiegazioni più dettagliate riguardo la Missione di Mozilla e l’importanza degli “standard aperti”. Abbiamo iniziato così il a “fare il nostro lavoro” con più entusiasmo che mai. Durante i tre giorni della durata della fiera ogni visitatore è stato ricevuto come se fosse un amico e ognuno di noi ha dato il meglio di sé rispondendo alle migliaia di domande che ci sono state poste.

Per poter fornire ai nostri visitatori una maggior completezza d’informazione, abbiamo distribuito gratuitamente 1.500 CD dai quali era possibile installare Firefox, Thunderbird, centinaia di estensioni localizzate in italiano e tutti gli altri prodotti e progetti Mozilla.

Ogni giorno inoltre abbiamo distribuito cinque magliette di Firefox come premio a coloro che avessero  risposto per primi ed esattamente ad una semplice domanda riguardante il “Mondo Mozilla”. Queste domande venivano poste durante uno speciale “question time” che si è dimostrato essere uno dei momenti attesi con più entusiasmo dai nostri visitatori.

La partecipazione di Mozilla Italia a “Fa’ la cosa giusta” di quest’anno era imperniata anche sul raggiungimento di due particolari risultati: il primo, creare una collaborazione più attiva con le altre realtà open-source italiane presenti all’evento, così da condividere le diverse conoscenze acquisite e poter dar vita a nuove opportunità di collaborazioni future;  il secondo, coinvolgere il maggior numero di nuovi volontari possibile in una partecipazione propositiva alla vita della nostra comunità, così da velocizzare il processo di QA della localizzazione di tutti i prodotti Mozilla e anche delle estensioni. In tutta sincerità credo che questa volta siamo riusciti a raggiungere entrambi i traguardi.

Abbiamo inoltre avuto la fortuna di essere intervistati da Rai 3, per la trasmissione “L’Osceno del Villaggio”, che andrà in onda dal 29 di Marzo al 7 di Giugno verso le 23.30. Al momento non conosciamo ancora il giorno in cui l’intervista verrà trasmessa per cui state sintonizzati!

Intervista di RAI 3

Lo stand di Mozilla Italia ha ricevuto anche la visita inaspettata di Diego Parassole, il famosissimo attore comico, che ci ha richiesto una maglietta di Firefox con la promessa di indossarla durante il suo prossimo show. Una fantastica occasione di poter diffondere l’immagine di Firefox in giro per l’Italia attraverso un così noto testimonial. Grazie Diego!

Giovanni e Diego Parassole

Come negli anni scorsi siamo rimasti stupiti dalle molteplici tipologie di persone che si sono fermate a visitare il nostro stand: bambini, giovani, anziani, “smanettoni”, gente alle prime armi, italiani e stranieri ma la cosa che più ci ha colpito è stato il profondo interesse di tutti loro nella nostra presenza in fiera non appena comprendevano di poter applicare anche a se stessi quella “scelta e innovazione” tanto auspicata dal Motto di Mozilla .

La cosa che preferiamo di più però è avere la possibilità di incontrare i bambini delle scuole per poter spiegar loro l’importanza del software open-source cercando di fargli capire che si tratta di uno strumento che permetterà loro di esercitare sempre scelte personali senza tener conto delle “abitudini acquisite” e senza dover mai essere obbligati a “seguire il gregge”.

Lo stand di Mozilla Italia

Uno dei miei ricordi preferiti di quest’edizione di “Fa’ la cosa giusta” riguarda una particolare domanda che ci è stata posta da una delle persone al nostro stand: “Conosco già Firefox ma non lo uso, però sono davvero curioso di capire perché viene chiamato 100% software naturale” e dopo la nostra risposta: “chiamiamo Firefox 100% software naturale perché ti aiuta a mantenere pulito e sicuro il tuo personalissimo ecosistema, ovvero il tuo computer, la tua privacy e la tua possibilità di scegliere come poter vivere l’esperienza sul web” questa persona si fermò un attimo ad analizzare la spiegazione ricevuta e quindi replicò: “bene, grazie, mi avete appena aperto gli occhi. Non avevo mai pensato a queste cose come al mio personale ecosistema e ora mi pare di aver perso un’occasione importante durante tutti questi anni nei quali ho utilizzato Internet senza saperle. Non appena tornerò a casa installerò Firefox e lo utilizzerò come browser predefinito!“.

Questo è semplicemente uno delle centinaia di bei momenti occorsi durante “Fa’ la cosa giusta” 2009 che ci hanno fatto sentire gratificati sia del nostro ruolo di membri di Mozilla Italia, la comunità italiana che si occupa della traduzione e del supporto ai prodotti Mozilla, sia d’essere parte della comunità globale di Mozilla nel mondo.

Ci sentiamo davvero orgogliosi di essere riusciti a rappresentare Mozilla anche quest’anno durante questo evento a Milano ottenendo così tanto successo.

Se volete avere una panoramica più approfondita di cosa è stato per noi partecipare a “Fa’ la cosa giusta” 2009, potete sfogliare uno di questi cinque album fotografici e godervi il video qui in basso.

Video di Mozilla Italia a “Fa’ la cosa giusta” 2009 by miki64

In conclusione, posso dire che per il Team di Mozilla Italia partecipare a “Fa’ la cosa giusta” 2009″ è stata una fantastica occasione  per far conoscere a tante nuove persone la “Missione di Mozilla“, per ritrovarci di nuovo tutti insieme ancora una volta, per divertirci, ma soprattutto per sentirci davvero soddisfatti nel vedere con i nostri occhi quanto il nostro impegno giornaliero venga ripagato migliaia di volte attraverso l’entusiastico interesse che gli italiani ripongono in Firefox, Thunderbird e negli altri prodotti e progetti di “casa Mozilla”.

Infine, vorrei porgere il mio personale ringraziamento all’intera comunità di Mozilla Italia che giorno per giorno si fa in quattro con l’obbiettivo di rendere la comunità globale di Mozilla sempre più ampia e conosciuta.

Un ultimo specialissimo ringraziamento va a Mozilla e Mozilla Europe che ci hanno sponsorizzato pagando per tutte le spese che abbiamo sostenuto per la partecipazione alla fiera e che ci hanno fornito di una marea di gadget quali, adesivi, spillette, magliette, poster e braccialetti. Gadget che sono stati davvero molto apprezzati da tutti coloro che sono venuti a visitare il nostro stand!

I gadget offerti da Mozilla e Mozilla Europe

Funzioni di Camino 1.6

Di seguito, i principali cambiamenti e miglioramenti realizzati rispetto a Camino 1.5. Un elenco completo è disponibile nel nostro sito web.

• Aggiornamento software automatico
  • Camino ora cerca automaticamente nuove versioni.
• Miglioramento nella navigazione a schede
  • Quando sono aperte più schede di quante se ne possono mostrare nella barra delle schede, appaiono delle frecce ai lati sinistro e destro per consentire lo scorrimento della barra. Oltre a ciò, il menu che mostrava le schede non visibili è stato sostituito da un menu che mostra tutte le schede aperte per la finestra in primo piano.
• Compatibilità Portachiavi
  • Camino ora memorizza nel Portachiavi informazioni per diversi account sullo stesso sito.
• Miglioramento nella ricerca dalla barra strumenti
  • Il campo di ricerca presente nella barra strumenti ora include un semplice sistema per  eliminare, rinominare e riordinare i motori di ricerca.
  • Camino ora supporta i plug-in OpenSearch per i motori di ricerca. Nuovi motori di ricerca possono essere aggiunti al campo di ricerca nella barra strumenti tramite rilevamento automatico o tramite pagine web che forniscono link a plug-in OpenSearch.
• Semplificazione dell’interfaccia di ricerca
  • Il pannello Trova è stato sostituito da una barra strumenti Trova che appare vicino al lato inferiore della finestra del browser.
• Aumento delle funzioni utilizzabili con AppleScript
  • Gli AppleScript possono adesso fare riferimento a schede e finestre.
  • È ora possibile aggiungere, aprire ed eliminare segnalibri tramite AppleScript.
  • Camino ora suporta elementi personalizzati della barra strumenti scritti in AppleScript.
• Ulteriori opzioni per le lettura di feed
  • Camino ora può passare i feed per la lettura da parte di alcuni servizi web.
• Chiarificazione dell’interfaccia utente
  • Camino 1.6 include alcune nuove icone per la barra strumenti e miglioramenti dell’interfaccia per una maggiore integrazione con lo stile visuale di Mac OS X 10.5.

Problemi conosciuti

• La versione 2.2 del plug-in Flip4Mac (F4M) per la visualizzazione di contenuti Windows Media causa problemi di rendering in Camino; il team di Flip4Mac risolverà questo problema in una versione futura del plug-in.
• Dopo aver visitato un certo numero di pagine con contenuti Flash, Camino può smettere di funzionare correttamente. Uscendo e rilanciando Camino, il problema si risolve. Questo comportamento è provocato dal plug-in Flash e sarà risolto in una versione futura del plug-in.

Dopo aver perso per strada il compagno di viaggio che stava ancora smaltendo i bagordi della notte precedente, lascio l’albergo e mi dirigo all’università nella speranza di riuscire se non altro a concludere qualcosa della missione segreta affidatami.

La giornata meteorologicamente parlando non sembra affatto migliore di quella precedente. L’autobus è pieno come una strada del centro il giorno prima di Natale, con persone che parlano un inglese approssimativo e con pesanti accenti riconducibili a diverse parti d’Europa.

Arrivo e trovo la prima sorpresa: abbiamo cambiato aula, passando ad una un po’ più grande al piano inferiore fregandola a OpenSuse: non è che si respiri meglio, ma se non altro si sta più comodi e si vedono meglio le presentazioni. Altra sorpresa: il workshop sulla creazione delle estensioni si è trasformato in realtà in un talk sulla localizzazione di Mozilla, con Pascal Chevrel, Mic Berman, Carsten Book che hanno spiegato cosa e come Mozilla si sta adoperando per semplificare la vita dei localizzatori e per dotarli di mezzi diversi e adatti ai vari livelli di collaboratori, anche pagandone lo sviluppo (dei tool, non dei localizzatori!). Come postilla finale abbiamo avuto una presentazione anche di translatewiki.net e una timida offerta di collaborazione tra tutti i diversi tipi di approccio.

Si è passati poi direttamente alla presentazione dei risultati dei due questionari online pubblicati da Mozilla Europe per analizzare l’impatto e l’utilità delle singole comunità nel promuovere Mozilla e soci. Pensavo si trattasse di un’arida esposizione di dati, invece si è rivelata abbastanza indicativa di cosa ne pensano gli utenti base e avanzati della propria comunità: noto con un certo orgoglio che non solo siamo stati quarti (dopo Russia, Francia e Germania) come numero di questionari inviati, ma che siamo anche molto ben accetti dalla nostra comunità (in media), quindi grazie a tutti voi!

Finita la presentazione, sono praticamente saltato addosso a Seth Bindernagel, per cercare di spiegare di cosa abbiamo bisogno e come possono aiutarci: credo che il parlare di persona sia sempre utile ed evita le incomprensioni, e devo dire che si è dimostrato molto gentile e capace di ascoltare. Speriamo sia anche capace di operare… A coronamento della cosa, mi sono ritrovato intervistato dallo stesso Seth per un video che stanno creando per i festeggiamenti dei dieci anni di Mozilla: e speriamo di aver detto poche vac… ehm, ovvietà e di aver fatto pochi errori di inglese!

Dopo una necessaria pausa pranzo, di nuovo nella sauna più grande per sentire la presentazione di Robert Kaiser su SeaMonkey 2 e la sua comunità: non una brillante presentazione, più che altro una fotografia dello stato dell’arte e specialmente dei problemi, oltre che i vantaggi, nel rapporto con il pezzo grosso e con tutto ciò che ci gira intorno. La preview di SM2 ha impressionato più di qualcuno che non si aspettava tanti e tali cambiamenti nella vecchia suite. Un vero peccato dover lasciare così presto il tutto perdendo la sessione su Firefox Mobile, ma cercherò le informazioni necessarie altrove per poi riportarvele.

Per riassumere, un fine settimana pieno di attività interessanti anche se non si può parlare veramente di novità, e soprattutto la soddisfazione di essere riusciti finalmente ad associare dei volti ai vari nick letti su IRC o sui newsgroup.

Una giornata tutto sommato bruttina, ma certamente molto più calda del previsto: questa in sintesi la situazione climatica trovata in quel di Bruxelles al mio arrivo. Mi ero accordato via SMS con il compagno di sventure Gabriele Tittonel per sincronizzare i nostri spostamenti, e il poveretto mi ha dovuto aspettare ben più del previsto. Terminato il check-in in albergo (carino, molto centrale ma senza connettività!), ci siamo diretti verso l’autobus che ci avrebbe portato al nuovo complesso universitario ULB dove è ospitato l’evento.

Dopo una breve consultazione abbiamo deciso di ritardare l’arrivo alla mostra per una rapida sosta di supporto vitale (cibo) che mi sono prontamente versato sull’unico paio di pantaloni: e vai così!

Partiamo alla volta dell’ULB e dopo un tre quarti d’ora la maledetta tradotta ci sbarca a destinazione: seguiamo le indicazioni e raggiungiamo velocemente la destinazione ultima, ovvero la stanza delle conferenze di Mozilla, giusto in tempo per vedere la sessione di domande e risposte su Mozilla Labs Weave: per riassumere di cosa stiamo parlando, è una piattaforma software che dovrebbe facilitare il lavoro e la condivisione di gruppo, ottimizzando le risorse, e che ha lasciato solo una marea di dubbi riguardo l’effettiva privacy degli utenti di un sistema del genere che il povero Dan Mills (sviluppatore) non ha affatto dissipato.

La conferenza sul progetto Calendar l’abbiamo bellamente saltata, e a quanto pare dai racconti abbiamo fatto bene, per farci un giro nelle altre sale: ho tentato di seguire la presentazione del nuovo driver RadeonHD fatta da Egbert Eich (Suse/Novell), ma dopo dieci minuti mi ciondolava la testa e ho preferito una ritirata strategica…

Nutrita presenza di un po’ tutte le realtà Linux/FOSS più note: Suse, Fedora, CentOS (l’una accanto all’altra), OpenSolaris, OpenGroupware, tutte le razze e forme di BSD, OpenSSH, X.org (Keith Packard è ridotto a una boccia da biliardo!), KDE, Gnome, un attrezzo interessante chiamato GOsa² per gestire server, Foresight, FSFE. E tutto ciò in un solo edificio! Domani vedremo cos’altro ci riserva il resto della fiera.

Ma tornando al motivo della nostra presenza, ci siamo ripresentati alla conferenza su Thunderbird, rischiando la nostra salute: la stanza di Mozilla infatti è stata ribattezzata “the sauna room” a causa del calore che si era sviluppato dentro. L’unico abbigliamento adatto era costume e maglietta, che ovviamente non avevamo, pensando di dover invece battere i denti dal freddo. La presentazione è stata fatta da Chris Hoffman, il quale era stato investito dell’onere senza saperne molto, per cui ha fatto una presentazione rapida e quasi indolore, che possiamo riassumere in poche linee guida: integrare il Calendar, gestire meglio le estensioni, assumere circa 10 persone entro l’anno (gli unici due per ora sono David Ascher e Dan Mosedale) e con la tiepida speranza di vedere un TB3 entro l’anno. Le domande scomode non sono state poste, ovvero che fine fanno Scott MacGregor e David Benvenieu…

La presentazione seguente era sul progetto SUMO e vista la calura e l’arsura, abbiamo disertato e sfruttato la pausa per approcciare sia Tristan Nitot, presidente di Mozilla Europe, sia una serie di personaggi con cui avevamo interagito via web/irc/mail ma mai visto di persona, come Robert Kaiser, Gervase Markham, Kai Engert, Brian King, Ben Bukusch, Karsten Book, Mic, Karsten Düsterloh, Håkan Waara, David Tenser, Henrik Gemal, ecc.

Abbiamo sfidato invece le fiamme per poter seguire la presentazione di Songbird: un giovanissimo ingegnere americano di origini asiatiche, ha presentato il prodotto cercando di far capire dove vogliono puntare veramente, ovvero non a una copia del tristemente (per gli utenti Windows) noto iTunes, ma qualcosa di più, ovvero uno strumento con cui gestire tutto ciò che ruota intorno al mondo della musica: la musica stessa, ovvio, i blog, il contenuto correlato, ecc. La cosa sembra essere molto interessante sulla carta, ma ancora in fase embrionale, vedremo.

Dopo quest’ultima fatica, ci siamo diretti in albergo per una rapida sistemata in vista dei festeggiamenti per i 10 anni di Mozilla. Una gran carovana si è diretta verso il luogo prescelto: un palazzo intero per giocare a bowling, di cui Mozilla aveva riservato tutto l’ultimo piano, con musica da discoteca al massimo, e vasto buffet di pappatoria varia da cui attingere senza limite (se non quello della grandezza del tavolo).

Abbiamo approfittato per quanto possibile di quello che ci è stato offerto, tanto per non fare brutta figura, e abbiamo fatto anche una partitina a bowling contro i cugini francesi, ai quali il mio compare di viaggio ha dato una bella spazzolata: non credo che l’abbiano presa troppo bene, tant’è che ci hanno esclusi dalla partita seguente… Non sanno proprio perdere, poveretti!

La serata è praticamente terminata, almeno per il sottoscritto, dopo il taglio della torta, una bevuta di champagne ovviamente francese, un brevissimo e scontatissimo discorso di ringraziamento di Tristan, e la distribuzione delle magliette.

Piccola nota a margine: la quasi totalità degli sviluppatori Mozilla usa dei Mac e usa le versioni beta e nightly di Firefox 3 (che su Mac mi pare bruttino, ma forse non sono abituato al look and feel della mela).

Sebbene il primo browser della storia sia stato WorldWideWeb, esso serviva a scopi dimostrativi ed era disponibile solo per sistema operativo NeXT – perciò in seguito fu chiamato Nexus. Il primo browser a raggiungere un’apprezzabile popolarità internazionale fu Mosaic, il cui sviluppo fu iniziato da NCSA nel 1992.
Il leader del gruppo che lo sviluppò, Marc Andreessen lasciò NCSA insieme ad altri quattro studenti dell’University of Illinois e fondò la Mosaic Communications Corporation che diventò Netscape Communications Corporation produttrice di Netscape Navigator.
Questo browser, nato ufficialmente nel 1994, crebbe in fretta e fu la piattaforma su cui vennero messe a punto alcune tecnologie oggi diffusissime (come ad esempio JavaScript).
La società Spyglass, Inc. acquistò in seguito la tecnologia e i marchi da NCSA per produrre il suo web browser. Spyglass Mosaic fu poi venduto alla Microsoft, che lo modificò e lo rinominò come Internet Explorer.
I due browser più diffusi al mondo hanno quindi in Mosaic un antenato comune.

La guerra dei browser

Netscape Navigator, un tempo web browser di riferimento per i navigatori di Internet, vide la sua enorme popolarità declinare progressivamente ad opera del suo più grande rivale, Microsoft Internet Explorer.
Internet Explorer, infatti, che aveva debuttato nel 1993 con la versione 1.0, all’epoca non era ancora in grado di competere con la suite di Netscape sia in termini di funzionalità, sia in precisione nella resa grafica delle pagine web (rendering).
Internet Explorer non veniva ancora fornito “di serie” con il sistema operativo Microsoft Windows: l’azienda di Bill Gates non lo considerava infatti un prodotto strategico (lo stesso Bill Gates all’epoca non riteneva Internet un business) e non ne aveva spinto la diffusione, continuando a considerarlo un modulo applicativo esterno al sistema operativo, con il proposito di venderlo separatamente da Windows.

Nel 1997, quando Internet Explorer e Netscape Navigator erano entrambi giunti alla versione 4.0, Microsoft scelse però di distribuire il proprio browser insieme al sistema operativo Windows 98 (all’epoca il più diffuso al mondo). Questa mossa, molto spregiudicata, si rivelò vincente: cambiare il browser diventava per gli utenti un’operazione costosa e faticosa e così Netscape Communicator, da quasi monopolista del settore, perse rapidamente quote di mercato fino ad essere utilizzato solamente da una piccola percentuale di simpatizzanti.
La guerra dei browser si conclude virtualmente nel 2000. Da questo momento in poi, Internet Explorer diviene leader del mercato dei browser.

Mozilla e la rinascita

La parola “Mozilla” risale al 1994: era in origine il nome in codice del browser Netscape e ha due possibili interpretazioni: qualcuno dice che fosse l’unione di “Mo”, che riportava a Mosaic, e di “-zilla”, da Godzilla il dinosauro (era il 1994, anno del film “Jurassic Park” e i lucertoloni erano di moda).
Altri, invece, sostengono che fosse una contrazione di “Mosaic-Killer”, e quindi indicasse il browser destinato a succedere a Mosaic.
Nel 1998 Netscape, prima di essere assorbita dal colosso America On Line (AOL), diede vita al progetto Mozilla rilasciando il codice sorgente di Netscape 4 con licenza open source: il progetto Mozilla si proponeva di creare un browser innovativo, basato sul nuovo motore grafico Gecko (che da questo momento non verrà più abbandonato) e consentiva a tutti – professionisti, dilettanti, hacker e semplici utenti – di contribuire su base volontaria alla sua evoluzione.
In realtà, trattandosi di una suite di programmi (oltre al browser comprendeva anche un client di posta elettronica, un editor di pagine HTML e una rubrica, cui in seguito si è aggiunto anche un client IRC), il nome corretto ed ufficiale del prodotto fu Mozilla Application Suite. Il programma era multipiattaforma, ossia disponibile per i principali sistemi operativi: Microsoft Windows, GNU/Linux, Mac OS, OS/2 e Solaris.
Lo sviluppo di Mozilla avvenne in seno alla “Mozilla Organization“ – un gruppo di dipendenti della Netscape – fino al 2003, anno in cui AOL decide ritirarsi dal progetto e di smantellare l’organizzazione. I coordinatori dell’organizzazione proseguirono, costituendo la Mozilla Foundation (Fondazione Mozilla).

Nel 2001 la Microsoft lancia Windows XP e Internet Explorer 6; l’azienda di Bill Gates è ancora leader incontrastata del settore con il 95% di quota di mercato, ma l’impressione generale è che da tempo il browser Microsoft manchi di nuove caratteristiche; inoltre il prodotto comincia ad essere avvertito come molto carente sotto il profilo della sicurezza.

Firefox

Nel settembre 2002, a causa di alcune divergenze con le linee generali di sviluppo, all’interno della Mozilla Foundation venne avviata la sperimentazione su un browser derivato dal codice sorgente di Mozilla.
La filosofia progettuale puntava alla facilità d’uso, alla stabilità, alla personalizzazione, al rispetto degli standard web, alla sicurezza, alla compattezza e alla velocità.
Il primo nome scelto fu Phoenix (Fenice, in inglese), per simboleggiare la rinascita dalle ceneri di Netscape. Tale nome dovette tuttavia essere cambiato perché in conflitto con Phoenix Technologies, azienda produttrice di BIOS.
Il nome scelto fu allora Firebird, a sua volta abbandonato perché in conflitto con il database Firebird SQL.
Venne stabilito finalmente il nome Firefox.

La versione 1.0 vide ufficialmente la luce il 9 novembre 2004. Tra le varie iniziative previste per il lancio, venne avviata una sottoscrizione con l’obiettivo di pubblicare una pagina pubblicitaria sul New York Times, che raccolse complessivamente 250.000 dollari.
Firefox è open source al pari di Mozilla, e come il suo predecessore è anch’esso multipiattaforma e disponibile per sistemi Microsoft Windows, GNU/Linux, Mac OS, OS/2 e Solaris.

SeaMonkey

Nel 2005, sulla scia del successo ottenuto per Firefox (e per il client di posta Thunderbird), la Fondazione Mozilla decise di non proseguire nello sviluppo di Mozilla Application Suite, che si arrestò alla versione 1.8 beta 1. Le versioni stabili e ufficiali invece proseguirono fino alla versione 1.7.13.
Secondo la migliore delle tradizioni del software open source, dai sorgenti di Mozilla Application Suite nacque un altro progetto, detto SeaMonkey (la parola era in origine il nome in codice del browser Mozilla) coordinato dal SeaMonkey Council e ospitato sui server della Mozilla Foundation.

Il Council è un gruppo di sviluppatori totalmente indipendente dalla Fondazione Mozilla che ha deciso di seguire e continuare lo sviluppo della suite di applicazioni. La Fondazione ha appoggiato tale iniziativa fornendo le macchine, l’infrastruttura di supporto e la collaborazione di alcuni sviluppatori ufficiali che si impegnano a mantenere la compatibilità dei cambiamenti a Gecko anche per SeaMonkey.
La prima versione stabile di SeaMonkey è stata la 1.0, rilasciata il 30 gennaio 2006 e basata sullo stesso codice di Mozilla 1.8.

Una nuova guerra dei browser?

Sebbene Internet Explorer (arrivato ora alla versione 7) sia ancora il browser più diffuso, Firefox continua ad erodere progressivamente quote di mercato al rivale di Redmond.
Diversamente però da quanto accadde in passato, gli utenti del web hanno oggi tantissime alternative tra cui scegliere, dal momento che molti altri browser hanno fatto in questi ultimi anni la loro comparsa: oltre a Firefox e Internet Explorer, ricordiamo il browser freeware Opera, Chrome di Google, Safari di Apple (incluso nel sistema operativo MacOS X), Konqueror per Linux, e i molti altri browser sviluppati sul motore di rendering Gecko tra cui K-Meleon, Flock, il sopraccitato SeaMonkey (multipiattaforma), Camino per MacOS X ed Epiphany per Linux.

Ringraziamenti

Ringraziamo, per la stesura di questa breve storia dei browser, gli autori delle seguenti pagine su WikiPedia: Mosaic, Internet Explorer, Firefox, Guerra dei browser, Mozilla, Netscape Navigator, SeaMonkey, Browser.

È possibile anche scaricare un documento in formato PDF (in inglese) che illustra le principali tappe di questa storia, “commentata” da Foxkeh, la mascotte ufficiale di Mozilla Japan (le immagini contenute nel PDF sono distribuite su licenza CC per il Giappone).

Funzioni di Camino 1.5

Di seguito, i principali cambiamenti e miglioramenti realizzati rispetto a Camino 1.0. Un elenco completo è disponibile nel nostro sito web.
•    Ortografia
•    Il controllo ortografico, realizzato usando i dizionari ortografici di Mac OS X è ora attivo per i campi di testo delle pagine web.
•    Rilevazione feed RSS
•    Quando una pagina offre un feed Atom o RSS, Camino mostra un’icona nella barra dell’indirizzo e, cliccando sull’icona, passa il feed a un’applicazione predefinita per la lettura dei feed.
•    Recupero sessioni
•    Camino registra quali pagine erano aperte al momento della chiusura e può recuperarle la prossima volta che viene lanciato.
•    Dopo che una sessione di navigazione termina inaspettatamente per un blocco, Camino chiederà se si vogliono recuperare le pagine che erano precedentemente aperte.
•    Miglioramento nella navigazione a schede
•    Modalità a singola finestra: È presente ora un’opzione per aprire in nuove schede i link che invece si aprirebbero in una nuova finestra.
•    Salto indietro alla scheda: Camino ora permette di tornare alla scheda originale dopo aver consultato una pagina in un’altra scheda.
•    Compatibilità con il Portachiavi
•    Camino ora condivide con safari le voci nel Portachiavi.
•    Le voci registrate nel Portachiavi da Camino sono ora registrate in modo che anche altre applicazioni le possano leggere.
•    Blocco popup
•    La notifica del blocco popup è ora più evidente.
•    Il nuovo sistema di notifica dei popup offre maggiore controllo per la gestione dei popup.
•    Miglioramento nel controllo dei plug-in
•    Camino 1.5 permette di disabilitare tutti i plug-in.
•    Flashblock : La nuova opzione «Blocca animazioni Flash» impedisce ai filmati di avviarsi fino a che l’utente clicca sull’icona di riproduzione.
•    Ridimensionamento della finestra
•    Il comando Ridimensiona ora adatta la finestra ai contenuti della pagina corrente, invece di ampliare la finestra a tutto schermo.
•    Download
•    Una nuova icona opzionale nella barra degli strumenti permette di spostare i documenti scaricati nel cestino.
•    Le voci della finestra Download possono adesso essere automaticamente rimossi dopo il completamento o quando si esce da Camino.
•    Ricerca
•    Il campo di ricerca nella barra strumenti è ora ridimensionabile.
•    Il menù contestuale per il testo selezionato nelle pagine web ora include una voce «Cerca».
•    Gestione cookie
•    Camino ora include un’opzione per accettare i cookie solo per la sessione in corso.
•    Chiarificazione dell’interfaccia utente
•    Camino 1.5 include una sostanziale riorganizzazione dei menù e delle scorciatoie da tastiera. I pannelli delle preferenze sono stati riprogettati.
•    Contenuti web
•    Camino ora utilizza la versione 1.8.1 del sistema di visualizzazione Gecko di Mozilla, che contiene migliaia di correzioni di problemi e il supporto per nuove tecnologie come JavaScript 1.7.

Problemi conosciuti

Per informazioni su altri problemi, visita la nostra pagina di Aiuto (in inglese).

•    Alcuni utenti hanno riscontrato che le pagine sembrano non essere caricate dopo aver cliccato su un link. In questi casi, ridimensionare la finestra del browser potrebbe permettere alla pagina di essere visualilzzata correttamente.
•    Il Plug-in di Microsoft Windows Media Player (WMP) provoca significativi problemi di visualizzazione in Camino. Poiché Microsoft ha interrotto lo sviluppo di WMP per Mac OS X, Camino non supporta più l’uso del plug-in di  WMP; al suo posto, gli utenti dovrebbero scaricare il plug-in gratuito Flip4Mac (F4M), versione 2.1 o superiore, da http://www.flip4mac.com/.  La versione 2.1 provoca la visualizzazione di pagine completamente bianche quando queste contengono elementi WMP e si effettua uno scorrimento in Camino; non è attualmente prevedibile una data per la soluzione di questo problema tramite un aggiornamento del plug-in F4M.
•    Camino informa erroneamente che i caratteri predefiniti per Giapponese e Cinese Tradizionale sono «mancanti», anche se sono effettivamente installati; questo è dovuto alla mancata corrispondenza tra i nomi dei caratteri in Carbon e in Cocoa. Cambiando questi caratteri tramite il pannello di preferenze Caratteri vengono scelti i caratteri sbagliati e alcune lettere o simboli non vengono visualizzati. Si consiglia di mantenere i caratteri predefiniti oppure di cambiare le preferenze dei caratteri usando invece la finestra “Avanzate…”.

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

1. Aiutiamo Mozilla
2. La scoperta di un bug
3. Primi passi su Bugzilla
4. Evoluzione di un bug
5. Vita da patch
6. Risolto!
7. Ringraziamenti

1. Aiutiamo Mozilla

Lo sviluppo del codice di Mozilla si basa sulla presenza e sulla coesistenza di diversi elementi, ognuno con la propria importanza. Sono necessari i progettisti software per stabilire in che direzione far evolvere il codice, i programmatori per implementare tale visione, gli scrittori per documentare sia il codice sia le applicazioni, esperti di sviluppo web per modificare e migliorare l’offerta dei siti relativi a Mozilla. In ultimo, solo per l’ordine naturale dello sviluppo software ma non meno importanti, sono necessari gli utenti finali: solo loro infatti possono mettere alla frusta un prodotto e ricreare le situazioni di utilizzo più astruse.

Gli utenti finali sono gli unici in grado di superare gli schemi mentali dei progettisti software e dei programmatori, utilizzando nei modi più impensabili un software, solitamente in un modo assolutamente non previsto dal progetto originale. Mentre la fase di test pensata prima della scrittura del codice serve a verificare la correttezza del software (cioè che funzioni effettivamente come previsto), l’utilizzo da parte dell’utente finale, o meglio ancora dell’utonto, permette di verificare la robustezza del codice (ovvero che quanto scritto, anche se usato impropriamente, non generi problemi).

Per questo motivo diventa fondamentale l’apporto di tutti noi, anche semplici utilizzatori, nella ricerca, segnalazione e correzione dei bug. Al livello più semplice basta attivare TalkBack ed inviare i dati collezionati sui crash a mozilla.org (senza alcun rischio di compromettere i propri dati personali e privati), o utilizzare lo strumento Reporter per segnalare i siti che non si visualizzano correttamente con i prodotti Mozilla. Ancora, è possibile condividere le proprie esperienze in positivo o in negativo sui forum, fare pubblicità, prestare il proprio aiuto ad altri utenti come noi. Ma è possibile fare ancora un passo in più: segnalare i difetti trovati su Bugzilla, il database degli orrori errori di Mozilla!

L’unico prerequisito imprescindibile per poter compiere questo passo è la conoscenza della lingua Inglese, meglio ancora se arricchita dalla conoscenza dei termini tecnici propri dell’informatica: ciò non dovrebbe essere particolarmente complicato, visto che l’Italiano li ha adottati quasi tutti nell’uso comune (basti pensare a download, browser, plugin, ecc.).

[Torna al sommario]

2. La scoperta di un bug

Più si utilizza un prodotto software, più lo si conosce a fondo e più se ne scoprono i limiti ed i punti di forza. Questo è vero per un qualsiasi software, indipendentemente dalla sua complessità. Nel caso dei prodotti Mozilla, ciò è facilmente verificabile: un uso semplice di un programma come Thunderbird, ad esempio, può rendere felici molti utenti; appena si cominciano ad usare a fondo le caratteristiche e le funzionalità del programma per andare oltre le operazioni più semplici, ecco che si comincia a sentire il bisogno di modificare le Preferenze, magari anche quelle nascoste, e poi di ampliare la gamma delle funzionalità di base utilizzando le estensioni. E più funzioni si utilizzano e più testing del software si realizza…

In un mondo perfetto il software dovrebbe permettere l’evoluzione degli utenti senza il minimo intoppo, ma purtroppo ciò non è mai vero: prima o poi ci si imbatte in un problema. A volte è possibile aggirarlo, altre volte invece si viene completamente bloccati: in entrambi i casi è molto probabile che ci si trovi di fronte ad un bug, ovvero un errore di programmazione. Perché dico è probabile? Perché talvolta gli utenti vogliono compiere delle operazioni che non sono state nè previste nè pensate per essere eseguite nel modo da loro voluto: quindi siamo di fronte ad un limite o nella progettazione del software o nella conoscenza del software stesso da parte dell’utente.

Prendiamo in considerazione il caso di un vero e proprio bug: come dobbiamo comportarci? Per esperienza personale, prima di lanciarsi a scrivere un bel bug report su Bugzilla, conviene fare una serie di prove da soli ed in compagnia… Da soli possiamo controllare più volte se è possibile riprodurre il bug in maniera consistente, cercando di segnare tutti i passi necessari per riprodurlo. In certi casi può essere prezioso eseguire lo stesso test con un profilo pulito, in modo da evitare problemi dovuti alla stratificazione delle diverse versioni dello stesso programma. Se siamo ancora convinti di trovarci a quattr’occhi con un bug, chiediamo a qualcun altro di verificare se riesce a riprodurre il problema con la nostra sequenza di passi: se la risposta è affermativa, possiamo cominciare a pensare di spostarci su Bugzilla per il passo successivo.

È comunque possibile che ci siamo ritrovati in una condizione in cui non esiste un vero e proprio bug, ma piuttosto una carenza strutturale del programma. Sempre sottoponendo tale limitazione all’analisi e all’opinione di altre persone (più una funzione è utile a diverse classi di utenti e più è semplice chiederne l’implementazione), possiamo farci un’idea di cosa andare a chiedere ai programmatori di Mozilla. Cito un esempio: per molte persone la possibilità di estrarre allegati divisi tra messaggi di posta o newsgroup diversi è una necessità imprescindibile prima di passare all’utilizzo di un programma di posta Mozilla. Possiamo quindi spostarci su Bugzilla per sottoporre la nostra richiesta di miglioria o RFE (Request For Enhancement) ed incrociare le dita sperando che qualcuno si offra di implementarla (ad esempio la citazione precedente è in Bugzilla dal Novembre del 2000).

[Torna al sommario]

3. Primi passi su Bugzilla

Armati di tutte le nostre informazioni, puntiamo il browser su https://bugzilla.mozilla.org. Cominciamo a guardarci intorno e a fare ricerche con alcune parole chiave che possono essere uguali o simili a quelle che intendiamo usare noi; questo è un altro passo fondamentale per fare un buon bug report: dobbiamo assicurarci che nessuno lo abbia già fatto prima! Dovremo andare a spulciare tutti i bug che anche lontanamente somigliano al nostro, e se ne troviamo uno che corrisponde, verifichiamo che riporti tutte le informazioni in nostro possesso: anche se non creiamo un nuovo bug report, possiamo riportare le informazioni aggiuntive in nostro possesso, un aiuto in più per chi dovrà sistemare il problema. Creando un duplicato di un bug esistente, provochiamo un inutile spreco di risorse per tutto il sistema.

Altro passaggio fondamentale è avere un proprio account su Bugzilla: crearlo è semplicissimo e basta avere un account di posta elettronica valido. Superato questo scoglio, è giunto quindi il momento di creare un nuovo bug report: puntiamo sul pulsante New e via, riempiamo bene tutti i campi che vengono proposti dal modulo. Assicuriamoci di aver selezionato il componente esatto (cioè a quale parte di Mozilla si riferisce il bug), scegliamo un Summary sufficientemente semplice per descrivere il problema ma che contenga diverse parole chiave (in modo che chi viene dopo di noi non fatichi a trovarlo se vuole segnalare lo stesso problema), e abbondiamo con i particolari nei Details.

Quando ci sembra di aver dato tutte le informazioni possibili e pertinenti, possiamo fare clic su Submit: dopo alcuni istanti bugzilla ci avviserà che sono stati fatti i cambiamenti necessari per il bug XXXXXX. È possibile controllare come Bugzilla ha impostato alcuni campi automatici del bug: certamente lo stato del bug sarà UNCONFIRMED, cioè non confermato, perché il vostro rapporto deve essere analizzato da qualche altro volontario (e si spera esperto del componente) che deve verificare la correttezza di quanto avete scritto, della descrizione del problema dell’esattezza del componente assegnato. Alcuni altri campi riempiti in automatico sono il QA Contact (ovvero colui che dovrebbe analizzare il vostro report e confermarlo), Reporter che dovrebbe essere impostato al vostro account e Assigned To che di solito indica quale sviluppatore dovrebbe sistemare il problema (il condizionale è d’obbligo, in quanto sono tutti o quasi volontari).

Un ultimo campo da impostare con accortezza è Severity: di norma è bene lasciarlo impostato a Normal, ma esistono le dovute eccezioni. Se ad esempio il vostro bug report riguarda magari un refuso nell’interfaccia grafica, o in una finestra di dialogo, insomma, riguarda qualcosa di davvero semplice, è bene impostare il campo a Trivial. Se invece stiamo aprendo una richiesta di miglioria, dobbiamo impostare il tutto a Enhancement. Ancora, se crediamo di avere individuato un problema che compremette la sicurezza del prodotto e del suo utilizzatore, dobbiamo impostare il campo a Security: questa categoria è un po’ particolare, in quanto viene presa in carico da un team speciale che analizza il report e decide quanto è grave la falla e se renderla segreta fino a quando non viene trovata e applicata una soluzione al problema. Impostare correttamente questo campo faciliterà l’analisi altrui e, col tempo, vi farà guadagnare rispetto da parte degli sviluppatori che leggono i vostri bug report…

[Torna al sommario]

4. Evoluzione di un bug

Nella maggior parte dei casi, entro pochi giorni il nostro bug passa da UNCONFIRMED a NEW: questa è la certezza che non abbiamo scritto grosse stupidaggini, e che non sembra esserci un bug precedente uguale al nostro. In caso contrario, o il bug non è stato neanche esaminato (cosa che spesso accade per certi componenti), oppure viene subito chiuso come DUPLICATE di un altro bug. Se siamo particolarmente fortunati, lo status passa subito ad ASSIGNED: questo significa che uno sviluppatore ha deciso di prendersi il nostro bug in carico e di lavorarci sopra: non accade spesso, ma se succede, significa che abbiamo trovato davvero un bel buco!

È anche possibile che il nostro bug evolva in maniera radicale: succede a volte che descriviamo come bug un sintomo di un problema molto più grosso. Non stupiamoci quindi se in fase di analisi da parte di altre persone il tutto subisca modifiche ed aggiustamenti, oppure che il bug acquisisca delle dipendenze: Depends on significa che se non vengono sistemati prima altri bug, il nostro non può essere risolto, mentre Blocks significa che se non viene sistemato il nostro bug, altri non hanno speranza. Può anche capitare che il nostro Summary venga ritoccato per descrivere meglio il problema o renderlo più facilmente individuabile tramite ricerche, magari cambiando le parole chiave, oppure può accadere che vengano individuati dei duplicati del nostro report, oppure ancora che il nostro bug venga considerato (e chiuso) come duplicato di un altro.

Può anche succedere che vengano richiesti maggiori dettagli o magari delle prove particolari a chi ha descritto il bug, quindi il nostro lavoro non è finito una volta che abbiamo fatto clic su Submit… Notiamo che in tutti i bug c’è una lista CC: possiamo aggiungere il nostro indirizzo email alla lista in modo che ogni volta che avviene una qualche modifica al bug, verremo avvisati tramite posta elettronica. È utile ad esempio nel caso trovassimo un bug che ci interessa particolarmente, oppure nel caso scovassimo un bug simile a quello che volevamo riportare. Possiamo avere il polso della situazione dei bug che più ci interessano senza dover andare a controllare tutte le volte su Bugzilla. Non è necessario aggiungersi alla lista CC di un bug se il bug lo abbiamo creato noi oppure lo abbiamo votato (una possibilità data da Bugzilla ma che su mozilla.org non ha alcun valore), o ancora se siamo le persone assegnate a risolverlo o ne siamo il responsabile di qualità.

Può rivelarsi utile a volte allegare al bug anche una o più schermate grafiche che descrivano meglio o isolino il problema: nulla di più semplice. Generiamo lo screenshot sul nostro computer, torniamo nel bug e facciamo clic su Create new attachment: si apre un nuovo modulo in cui dobbiamo specificare il nome della schermata, darne una piccola descrizione ed istruire Bugzilla sul tipo di file che stiamo allegando. Spesso è più sicuro specificare manualmente il tipo di file senza utilizzare il riconoscimento automatico di Bugzilla che non sempre sembra essere all’altezza del compito, specialmente se si tratta di immagini o di codice (X)HTML.

[Torna al sommario]

5. Vita da patch

Se il nostro bug ha risvegliato l’interesse di qualche programmatore, può arrivare il giorno in cui in esso compare una patch, ovvero un insieme di modifiche al codice sorgente di Mozilla che dovrebbe risolvere il problema segnalato. Possiamo dare un’occhiata alle modifiche proposte facendo clic su View accanto all’allegato contenuto nella lista Attachments: ciò che compare a video non è altro che una patch in formato diff, programma diffusissimo in ambito Unix/Linux per lo sviluppo di software. A noi non sembra altro che del testo: le cose che dobbiamo notare sono le righe precedute da - e da +: le prime sono le righe eliminate, mentre le seconde sono le righe aggiunte al sorgente di Mozilla. Spesso molte modifiche che toccano numerosi file vengono condensate all’interno di un unico file di diff, e ciò permette di capire quanto un bug può influire sui sorgenti di Mozilla.

È anche possibile che nessuno si interessi al nostro bug: che fare? Se la difficoltà del problema non è insormontabile, potremmo anche pensare di sistemare da soli il tutto… A prima vista può sembrare un’impresa irrealizzabile, ma non è così. Abbiamo due possibilità: trasformare il nostro computer in un sistema di sviluppo in grado di generare le nostre personali versioni dei prodotti Mozilla (al fine di portare avanti i nostri test), oppure usare alcuni strumenti via web per cercare di generare una patch. Nel secondo caso, è possibile usare programmi particolari come PatchMaker e sfruttare servizi web di Mozilla come lxr per cercare di generare una patch corretta da sottoporre a scrutinio su Bugzilla. È una soluzione adatta nel caso di problemi davvero semplici, magari relativi a refusi del testo, ma molto scomoda per le modifiche più complesse, specie se fatte al codice sorgente di Mozilla.

L’altra soluzione possibile (creare un sistema di sviluppo) richiederà un po’ di tempo all’inizio affinché tutto funzioni a dovere, ma è uno sforzo che di solito va fatto una sola volta. Per nostra fortuna è possibile reperire informazioni dettagliate su come procedere sul sito mozilla.org per varie piattaforme, e ci sono diversi newsgroup in cui poter chiedere aiuto in caso di bisogno. Portata a termine questa impresa, siamo davvero padroni del campo: possiamo cominciare a sperimentare e prendere dimestichezza con il sistema di sviluppo, il cvs e il diff un poco alla volta (sempre seguendo le ottime informazioni disponibili su mozilla.org), magari partendo dai file (X)HTML, per poi passare ai .dtd e .properties, poi ai .js e .xul fino a cimentarsi con i file .cpp.

A poco a poco creare patch diventerà una (sana) abitudine: ma una volta creata una patch e inserita su Bugzilla che succede? Dovremo innanzitutto chiedere a qualcuno esperto di revisionarla (impostando il campo review della patch a ? ed inserendo poi l’indirizzo email del supervisore). La scelta del supervisore va fatta cum grano salis: deve essere una persona che conosce abbastanza il codice che andiamo a toccare e, come gentilezza, dovremmo cercare di chiedere la review a qualcuno che non ha una coda di richieste troppo lunga (per non oberarlo di lavoro). Ancora una volta il sito di mozilla.org ci viene in aiuto; possiamo controllare la lista dei module-owner (ovvero coloro che sono responsabili eclusivi di una parte del sorgente Mozilla) e dei peer-reviewer (altre persone esperte del modulo in questione), e scegliere in base a questo elenco.

Se la scelta non è stata felice, dopo un po’ di tempo potremo cambiare supervisore, oppure verremo informati del tempo necessario prima che la revisione venga portata a termine. La revisione può concludersi sostanzialmente in tre modi:

1. r+: significa che è andata a buon fine e che il revisore non ha nulla da eccepire
2. r+ soggetta a modifiche: significa che la revisione è stata positiva, ma a condizione che vengano effettuate le modifiche proposte nel commento
3. r-: significa che è abbiamo scritto qualcosa di davvero pessimo e tocca ricominciare da capo…

Se riusciamo ad ottenere un bel r+, a seconda del tipo di patch può essere necessario richiedere anche un sr+ (super-review), in genere dal module-owner in persona: questo si rende necessario quando il codice modificato è parecchio, oppure si cambia radicalmente aspetto o fisionomia di una parte del sorgente. Ottenuto, se necessario, anche il sr+, possiamo chiedere a qualcuno di inserire la nostra patch nell’albero dei sorgenti di Mozilla. Controllando la pagina di tinderbox (macchine che preparano a getto continuo versioni di test dei prodotti Mozilla), potremo verificare se la nostra patch è stata inserita senza procurare danni (nel commento al checkin comparirà la vostra email/il vostro nome accanto a p= oppure dopo Patch by, ed i nomi di chi ha accordato r+ ed eventuale sr+): siamo entrati nella storia di Mozilla!

[Torna al sommario]

6. Risolto!

Tutto finito? Quasi… Solitamente chi ha effettuato il checkin imposta il bug anche a FIXED, e ciò segnala che il problema dovrebbe essere risolto. Altre persone addette alla verifica (come ad esempio il QA Contact), possono quindi verificare in una nightly successiva all’introduzione della patch che il problema sia stato effettivamente risolto, e possono cambiare ancora lo stato del bug a VERIFIED FIXED: questo è lo stato ultimo di un bug su Bugzilla, e significa che il problema è stato del tutto risolto e può essere archiviato.

A volte succede però che la verifica non sia positiva, e quindi lo stato del bug viene posto a REOPENED, ovvero c’è ancora del lavoro da fare. Di solito ciò accade quando la patch ha risolto solo in parte il problema, oppure ne ha generati di nuovi che prima non c’erano (chiamati regressioni) e ne ha portati alla luce di nuovi ma molto simili (per cui sembra superfluo aprire un altro bug). In questi casi o vengono fornite nuove patch, oppure si decide di fare un backout, cioè di togliere dall’albero dei sorgenti di Mozilla la patch inserita in precedenza: di solito serve sempre tutta la trafila di revisione, anche nel caso di backout.

Chiuso il discorso? Non ancora… Un altro caso particolare sono i bug risolti a ridosso di una versione stabile di Gecko, oppure abbastanza importanti da dover far parte della prossima versione minore di un programma Mozilla (ad esempio far parte di Firefox 1.5.0.2). I bug che appartengono a questa categoria non vengono posti a RESOLVED quando la patch viene inserita nell’albero dei sorgenti principale di Mozilla (trunk): l’autore della patch attiva il flag a=? oppure blocking x.x.x? e, con una breve spiegazione, motiva questa sua richiesta. I drivers (ovvero la ristretta cerchia di sviluppatori che coordina il rilascio delle versioni ufficiali dei prodotti Mozilla) analizzano la richiesta e danno o meno il loro consenso. Una volta presa la decisione, il bug passa a VERIFIED FIXED, ma in caso di consenso favorevole, la patch viene inserita anche nell’albero di sviluppo stabile (branch), così da far parte della prossima versione ufficiale del prodotto. Il bug in quest ultimo caso acquista una piccola scritta nel campo Keywords, solitamente fixedx.x.x. Ok, ora abbiamo davvero finito!

Sotto a cercare e/o sistemare il prossimo bug!

[Torna al sommario]

7. Ringraziamenti

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

• Iacopo Benesperi
• Francesco Lodolo
• Giuliano Masseroni
• Michele Dal Corso

Scarica l’articolo! ]]> http://www.mozillaitalia.it/home/2005/09/30/firefox-su-pc-professionale/feed/ 0