In molti casi è stato riscontrato che il problema è causato dal componente aggiuntivo Ask.com Toolbar, che può essere installato dal sito ask.com oppure viene installato insieme ad alcuni programmi di utilizzo comune come ImgBurn, Avira Antivirus Free, Java e altri.

Il consiglio che diamo è quello di verificare se nell’elenco dei programmi installati in Windows compaiono voci relative ad Ask.com. Nel caso in cui siano presenti, provare per prima cosa a rimuovere i programmi in questione.

Se non si è sicuri, oppure nel caso in cui anche dopo aver disinstallato questi programmi i problemi continuino a presentarsi, provare a scaricare ed utilizzare lo strumento AdwCleaner. Al lancio del programma, scegliere l’opzione Search.

Verrà effettuata una rapida scansione del sistema, al termine della quale verrà visualizzato un file di testo: nelle prime righe, verificare se compaiono voci del tipo Folder Found


Folder Found : d:\users\user\AppData\Roaming\Mozilla\Extensions\{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Folder Found : d:\users\user\AppData\LocalLow\AskToolbar
Folder Found : C:\Program Files (x86)\Ask.com
Folder Found : C:\Windows\Installer\{86D4B82A-ABED-442A-BE86-96357B70F4FE}
Folder Found : d:\users\user\AppData\Roaming\Mozilla\Firefox\Profiles\c4lf69p7.default\extensions\toolbar@ask.com


e Key Found

Key Found : HKCU\Software\APN
Key Found : HKCU\Software\AppDataLow\Software\AskToolbar
Key Found : HKLM\SOFTWARE\AskToolbar
Key Found : HKLM\SOFTWARE\APN
Key Found : HKLM\SOFTWARE\Classes\GenericAskToolbar.ToolbarWnd
Key Found : HKLM\SOFTWARE\Classes\GenericAskToolbar.ToolbarWnd.1
Key Found : HKLM\SOFTWARE\Classes\AppID\GenericAskToolbar.DLL
Key Found : HKLM\SOFTWARE\Classes\AppID\{9B0CB95C-933A-4B8C-B6D4-EDCD19A43874}
Key Found : HKLM\SOFTWARE\Classes\CLSID\{00000000-6E41-4FD3-8538-502F5495E5FC}
Key Found : HKLM\SOFTWARE\Classes\CLSID\{D4027C7F-154A-4066-A1AD-4243D8127440}
Key Found : HKLM\SOFTWARE\Classes\Installer\Products\A28B4D68DEBAA244EB686953B7074FEF
Key Found : HKLM\SOFTWARE\Classes\Installer\Features\A28B4D68DEBAA244EB686953B7074FEF
Key Found : HKLM\SOFTWARE\Microsoft\RFC1156Agent
Key Found : HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\DE28F4A4FFE5B92FA3C503D1A349A7F9962A8212
Key Found : HKLM\SOFTWARE\Classes\Interface\{6C434537-053E-486D-B62A-160059D9D456}
Key Found : HKLM\SOFTWARE\Classes\Interface\{91CF619A-4686-4CA4-9232-3B2E6B63AA92}
Key Found : HKLM\SOFTWARE\Classes\Interface\{AC71B60E-94C9-4EDE-BA46-E146747BB67E}
Key Found : HKLM\SOFTWARE\Classes\Interface\{79FB5FC8-44B9-4AF5-BADD-CCE547F953E5}
Key Found : HKLM\SOFTWARE\Classes\TypeLib\{2996F0E7-292B-4CAE-893F-47B8B1C05B56}
Key Found : HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{8856F961-340A-11D0-A96B-00C04FD705A2}
Key Found : HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{D4027C7F-154A-4066-A1AD-4243D8127440}
Key Found : HKCU\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{A5AA24EA-11B8-4113-95AE-9ED71DEAF12A}
Key Found : HKLM\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{A5AA24EA-11B8-4113-95AE-9ED71DEAF12A}
Key Found : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{D4027C7F-154A-4066-A1AD-4243D8127440}
Key Found : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{86D4B82A-ABED-442A-BE86-96357B70F4FE}
Value Found : HKLM\SOFTWARE\Microsoft\Internet Explorer\Toolbar [{D4027C7F-154A-4066-A1AD-4243D8127440}]
Value Found : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run [ApnUpdater]

In questo caso, significa che sul sistema è presente uno di questi programmi. Avviare nuovamente AdwCleaner e selezionare la voce Delete.

Il programma effettuerà la rimozione degli adware trovati e riavvierà il sistema: assicurarsi quindi di effettuare il salvataggio di eventuali file aperti prima di premere OK.
Al riavvio di Windows verrà mostrato un nuovo file di riepilogo da cui si evince che questi adware sono stati estirpati.

Ringraziamo gli utenti che hanno effettuato con noi i test e in particolare scoobidiver (del forum internazionale di supporto) per averci indicato il programma AdwCleaner.

Per altri problemi relativi a Firefox gli utenti sono invitati a chiedere supporto sul nostro forum.

Aggiornamento 20/01/2012

Il problema è stato da noi segnalato a Mozilla ed è stato aperto il bug 719561.

Scaricare i sorgenti

I sorgenti dei programmi si trovano in formato compresso bz2 sui server Mozilla. Ad esempio i link per Firefox e Thunderbird sono:

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/x.x.x/source/

http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/x.x.x/source/

dove a x.x.x va sostituita la versione che si vuole scaricare. Il file scaricato può essere decompresso con i programmi di archiviazione grafici (ark, file-roller) oppure col comando da console:

tar vfxj nomefile.tar.bz2

dopo essersi spostati nella cartella contenente il file.

Scaricare la traduzione italiana

Dopo aver scaricato i sorgenti, se si vuole il programma in italiano occorre scaricare anche i file della traduzione italiana. Per la traduzione purtroppo non esiste un semplice pacchetto da scaricare, ma bisogna scaricare i file dal repository hg (mercurial) di Mozilla. Questo comporta scaricare un grande numero di file anche inutili, perché nel repository sono presenti le traduzioni per tutti i programmi, non soltanto quello che vogliamo compilare.
Come detto, i file vanno scaricati dal repository hg, quindi assicuratevi di installare il pacchetto necessario dal vostro package manager di fiducia (tutte le distribuzioni ormai lo includono nei loro repository), oppure compilate il programma hg scaricandone i sorgenti. Ipotizzando di usare il desktop come cartella di lavoro (d’ora in avanti quando scriverò desktop in corsivo mi riferò a /home/nomeutente/Desktop, o comunque si chiami quella cartella nella vostra distribuzione. Ovviamente potete scegliere come cartella di lavoro quella che più vi piace), create una cartella (ad esempio di nome l10n) per contenere i file della traduzione. A quel punto dalla console entrate in quella cartella e date il comando:

hg clone http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/it/

ovviamente il numero 1.9.2 cambierà in futuro. Potete decidere di cancellare questa cartella dopo la compilazione, e quindi ridare questo stesso comando la volta successiva che ne avrete necessità, oppure tenerla e quindi solamente aggiornarla la volta successiva invece che scaricarla tutta nuovamente, tramite il comando:

hg pull -u

dato all’interno della cartella it.

Installare le dipendenze

Per compilare i programmi Mozilla sul computer devono essere installate delle librerie e i programmi necessari per la compilazione. Assicuriamoci quindi di avere installati i seguenti pacchetti (i nomi sono riferiti alla distribuzione Debian/Ubuntu, in questa pagina sono descritte le procedure per (Open)SUSE e RedHat/CentOS/Fedora): build-essential zip libasound2-dev libcurl4-gnutls-dev libcurl4-gnutls libnotify-dev libxt-dev libiw-dev mesa-common-dev autoconf2.13 libgtk2.0-dev gcc yasm.
A questo punto siamo pronti a partire, vediamo prima come compilare e creare un pacchetto di Firefox, e poi quello di Thunderbird (la procedura descritta per Thunderbird vale anche per Lightning e per SeaMonkey, con le dovute modifiche al file mozconfig).

Compilare Firefox

Quando si estraggono i sorgenti di Firefox viene creata la cartella mozilla-1.9.2 (di nuovo, i numeri cambieranno con le versioni successive). Dentro a questa cartella bisogna creare un file di testo chiamato mozconfig con all’interno queste righe:

ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-official-branding
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-ff-release
mk_add_options MOZ_MAKE_FLAGS="-j4"

export CFLAGS="-gstabs+"
export CXXFLAGS="-gstabs+"

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1

# Localization
mk_add_options MOZ_CO_LOCALES="it"
ac_add_options --enable-ui-locale=it
ac_add_options --with-l10n-base=desktop/l10n

Questo è il mozconfig usato da Mozilla per costruire le build. Ci sono anche tanti altri parametri da poter passare al compilatore, un elenco completo è in questa pagina. Eventuali parametri aggiuntivi potrebbero migliorare le prestazioni sul vostro sistema, limitando però l’esecuzione del programma a certi tipi di processori. Notare l’ultima riga del file: modificare il percorso se non si è usato quello che sto usando io in questa guida.
Ora esportiamo il file appena scritto tra le variabili di ambiente. Digitare nella console:

export MOZCONFIG=desktop/mozilla-1.9.2/mozconfig

A questo punto non resta che far partire la compilazione, digitare quindi il comando:

make -f client.mk build MOZ_CURRENT_PROJECT=browser

per compilare Firefox. Ora andate pure a pranzo, a cena o a fare una passeggiata, perché la compilazione richiede almeno un’ora. Dopo che la compilazione è finita creiamo il pacchetto contenente i binari. Muoversi all’interno della cartella col makefile dell’installer:

cd desktop/mozilla-1.9.2/objdir-ff-release/browser/installer

e lanciare il comando make. Una volta concluso il comando, il pacchetto .tar.bz2 contenente Firefox compilato si troverà all’interno della cartella objdir-ff-release/dist/.

Compilare Thunderbird

Quando si estraggono i sorgenti di Thunderbird viene creata la cartella comm-1.9.2 (di nuovo, i numeri cambieranno con le versioni successive). Dentro a questa cartella bisogna creare un file di testo chiamato mozconfig con all’interno queste righe:

ac_add_options --enable-application=mail
ac_add_options --enable-optimize
ac_add_options --enable-static
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --disable-shared
ac_add_options --enable-official-branding
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-release
mk_add_options MOZ_MAKE_FLAGS="-j4"

export CFLAGS="-gstabs+"
export CXXFLAGS="-gstabs+"

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1

# Localization
mk_add_options MOZ_CO_LOCALES="it"
ac_add_options --enable-ui-locale=it
ac_add_options --with-l10n-base=desktop/l10n

Di nuovo, questo è il file mozconfig usato da Mozilla per le proprie build. Valgono le stesse considerazioni fatte precedentemente per la modifica di questo file. Per esportarlo tra le variabili d’ambiente dare il comando:

export MOZCONFIG=desktop/comm-1.9.2/mozconfig

e poi il comando per la compilazione:

make -f client.mk build MOZ_CURRENT_PROJECT=mail

Di nuovo la compilazione richiede molto tempo.
Il makefile per creare il pacchetto si trova in objdir-tb-release/mail/installer/ e il file .tar.bz2 può essere recuperato in objdir-tb-release/mozilla/dist/ (notare il percorso leggermente diverso rispetto a Firefox).

Creare un pacchetto per la vostra distribuzione

Se invece di creare un file .tar.bz2 da scompattare in /usr/local preferite creare un pacchetto per la vostra distribuzione (the easy way) per poterlo gestire col vostro package manager, vi basterà installare sul sistema il programma checkinstall. A questo punto, dopo aver compilato il programma, spostatevi nella cartella objdir-*-release, lanciate il comando checkinstall e seguite le istruzioni che compariranno in console per la creazione del pacchetto.

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