Re: Seguire o guidare?
Ci tengo ad esporre brevemente la mia opinione sull'articolo postato da Giacomo Magnini su MondoZilla dal titolo: Seguire o guidare?.
Il concetto con cui si apre l'articolo è piuttosto chiaro:
E' già da un po' di tempo che sono in atto due pericolose tendenze all'interno del progetto che francamente mi lasciano molto perplesso: scopiazzare Chrome, puntare sul marketing.
Le considerazioni che seguono sono ovviamente da considerare come mia opinone personale, che non ha nulla a che vedere con la posizione ufficiale di Mozilla.
Apprezzo la volontà di esprimere pubblicamente i propri dubbi, su molte altre community o prodotti una posizione di questo tipo sarebbe stata insabbiata velocemente, il fatto che se ne parli dimostra la sanità della community Mozilla.
Questa è una caratteristica non da poco, che sicuramente rema contro la sensazione di scricchiolii espressa a fine articolo.
la cosa è cominciata con i processi separati per i plugin
Non mi trovo in pieno accordo, la separazione di un processo per i plug-in è stata chiaramente dettata dalle statistiche, visibili a tutti, presenti sul sito crash-stats. L'avvento di Chrome ha solamente portato ad una velocizzazione del processo, grazie all'uso di una parte del codice di Chromium per la gestione dei messaggi IPC.
Credo che tutto questo sia un merito: la volontà di farlo c'è sempre stata, la scelta di usare codice disponibile è merito di una visione aperta. E credo che "copiare i processi separati di Chrome" sia in realtà "usare la parte buona dell'implementazione dei processi separati di Chrome". Dopotutto Minefield ha un solo processo separato per tutti i plug-in, perchè uno dei dubbi che si sono sempre avuti su Chrome, riguarda proprio l'abuso di memoria dovuto alla necessità di condividere dati tra i processi. Si sono cercati i vantaggi lasciando indietro gli svantaggi. Questo è stare davanti, non è copiare.
(e si punta a separare ogni pagina di FF in un processo a parte, proprio come chrome)
il che, di per se, non costituisce difetto, a meno che qualcuno dimostri che esista un motivo per cui il crash di un documento in un software multi-documento debba portare al crash dell'applicazione.
e sta proseguendo in maniera spedita anche sotto l'aspetto grafico
Coprirsi gli occhi non porta a niente di buono, ed è contrario all'ideologia stessa che difendi. L'osservazione del mondo che ci circonda e la discussione aperta sono alla base della stessa. Si osservano due elementi importanti:
- consistenza con il sistema operativo
- consistenza dei concetti di interazione con l'interfaccia
Perchè molti browser (se non tutti) si dirigono verso i cosiddetti tab-on-top? Principalmente per le due ragioni di cui sopra. E devo far notare che la discussione in Mozilla, relativamente a questa caratteristica, è ancora aperta e moltissime persone della community stanno partecipando.
Detto questo, non credo che andare controcorrente sarebbe segno del fatto che Mozilla sia avanti rispetto agli altri. Significherebbe che sia la consistenza con il sistema operativo (Windows7 e Vista, siccome sulle altre piattaforme credo permarranno i tab-on-bottom), sia la consistenza dell'interfaccia, sarebbero state ignorate. Questo sarebbe un passo indietro invece.
La corretta implementazione verrà dal soppesare pro e contro dei due aspetti, cosa che evidentemente è stata fatta anche dalla concorrenza (non è che solo Mozilla abbia un ottimo team per la user experience).
E questo avviene mentre scoppiano polemiche a grappolo circa l'abbandono di MacOSX 10.4
Lasciare indietro alcune tecnologie sorpassate e non più supportate è patologico per qualsiasi software sano.
Quando si abbandonò il supporto a windows98 il numero di utenti era nettamente superiore agli utenti che oggi lamentano l'abbandono di OSX 10.4, eppure oggi non ci vediamo niente di incredibilmente sbagliato in quella scelta. Inoltre si parla di abbandono nel 2011, quando il numero di utenti sarà ancora più ridotto, a quel punto il browser non avrà grande importanza visto che tutto il sistema operativo sarà privo di patch di sicurezza e potenzialmente a rischio.
l'incentivo all'uso di Jetpack (una volta finalizzato, visto che per ora è in alto mare) per le estensioni
Jetpack è una possibile risposta ai difetti che pressoché tutti riscontriamo nel sistema delle estensioni. Ed è un'innovazione. Mi sembra che Jetpack vada in direzione opposta rispetto al senso critico dell'articolo.
l'implementazione di funzionalità a dir poco discutibili, anzi direi del tutto risibili (Personas).
Si, l'ho sempre pensato anche io, perchè sono uno sviluppatore e perchè sono un utente che dispone di una certa conoscenza tecnica.
Ma poi ho notato alcune cose:
- l'implementazione in sè non ha richiesto tempi biblici nè ha impedito la realizzazione di altri progetti. Ammetterai che Personas tecnicamente non è niente di incredibile o difficilmente realizzabile.
- Un incredibile numero di persone hanno realizzato persona, ed un ancor più incredibile numero di persone le stanno utilizzando.
- Ho visto persone a cui si sono illuminati gli occhi una volta notata la possibilità di personalizzare il browser così facilmente. Ora se riporti questa esperienza contro i 300 milioni di utenti che usano Firefox... Io, che fino ad allora mi chiedevo "Perchè?", ho iniziato a chiedermi "Perchè no?".
In base a queste considerazioni mi sono reso conto che i difetti non sono in Personas, ma nella mia visione del software. Credo che rendersi conto delle limitazioni della propria visione "tecnica" di un software sia un notevole pregio da acquisire.
Tanto per concludere con una battuta: non ti fa girare gli ammennicoli non poter cambiare facilmente lo sfondo su di un netbook con Windows 7 Starter Edition che per di più hai pagato? Eppure è un qualcosa che normalmente non vedi, avendo un'applicazione aperta di fronte ad esso. Evidentemente oggi la personalizzazione ha importanza.
Mi sembra davvero che si stia perdendo rapidamente di vista la superiorità tecnologica per inseguire i fantasmi
Credo che serva un metro di giudizio oggettivo per valutare la superiorità tecnologica, che è difficilmente individuabile.
Ad esempio, ritieni che avere ogni plug-in ed ogni tab in un processo separato (vedi Chrome) sia superiorità tecnologica? Eppure la cosa ha i suoi ovvi difetti (vedi difficoltà architetturale, di mentenimento del codice, di occupazione di memoria). Con 30 tab probabilmente oggi Chrome può occupare più memoria di Firefox, significa che Firefox è più avanzato tecnologicamente allora?
Inoltre per esperienza mi sembra che sia difficile, se non impossibile, mantenere in eterno una superiorità tecnologica, almeno in un mercato sano. Se così non fosse oggi una nota marca italiana produrrebbe le migliori auto del mondo. Un sistema sano prevede che oggi vinci e domani perdi. Prevede nuove sfide, che ti porteranno un giorno a vincere nuovamente.
E quando devi recuperare anche buchi architetturali che hai rimandato per anni, la situazione si complica molto.
Su questo non posso che quotarti, ma non credo sia una mancanza di Mozilla quanto un problema pratico di implementazione ed architettura.
Ad esempio potresti avere un componente che non funziona come vorresti. Cosa ti rallenta nel migliorarlo?
- ci sono 300 milioni di utenti, se effettui un cambiamento devi garantire loro la continuità di funzionamento. Questo rallenta naturalmetne lo sviluppo, ma assicura anche che ogni cambiamento sia pensato con molta più attenzione.
- ci sono migliaia di estensioni usate dai succitati utenti, se hai intenzione di fare grandi cambiamenti architetturali saranno più gli utenti insoddisfatti che quelli soddisfatti. Jetpack vuole venire in qualche modo incontro a questa problematica.
- Ci sono almeno tre branch stabili e supportati. Quando tocco un pezzo di codice devo fare in modo che se l'utente Tizio fa un downgrade dalla 3.6 alla 3.0 e poi un upgrade alla 3.5 tutto deve ancora funzionare perfettamente.
Gli altri progetti non hanno questi problemi? Ovviamente si, ma in maniera più lieve, perchè:
- hanno uno share di utenza minimo, in gran parte costituito da enthusiast ed utenti pronti a metter mano al cacciavite.
- hanno una base di codice più giovane. Alcune parti del codice Mozilla risalgono al 1997. Di per sè questo non è un difetto, funzionano bene e sono ottimamente testate, magari tutto il codice fosse scritto così bene da sopravvivere tanti anni. Ma quando devi fare modifiche strutturali importanti la retrocompatibilità è un dettaglio di non poco conto.
Ovviamente da sviluppatore sarei ben felice di sistemare alcune carenza strutturali senza dover tenere conto di tutto ciò. Lavorando con un numero di utenti limitato ad una base di codice giovane sarebbe anche semplice.
E' inutile nascondersi dietro un dito, la concorrenza ha una strada in discesa, Mozilla percorre un falsopiano in salita. Ma direi che confrontando Firefox 3.6 con Chrome, non vedo tutto questo allarmismo, vedo un maratoneta esperto che corre accanto ad un giovane runner. E vedo che non ha importanza chi vinca, purché il pubblico sia soddisfatto della performance di entrambi (e una delle mission di Mozilla resta quella di migliorare l'esperienza degli utenti in Rete).
Il tifo (e la critica) sono evidenza che entrambi sono sani.
E l'altro problema è che senza un prodotto migliore e differente, il marketing resta quello che è, cioé fuffa.
Non mi esprimo più di tanto sul marketing che non conosco, per mia carenza culturale (Non definirei l'esame di Economia una conoscenza sufficiente).
Volenti o nolenti, il marketing è quello che assicura le risorse per ottenere tutto quello che stai chiedendo in questo interessante articolo. Vuoi innovazione, vuoi che Mozilla stia davanti a Google, Microsoft ed Apple. Io vorrei stare davanti a Schumacher come abilità di guida, ma la mia collezione di conchiglie non basta per per una sessione di pista ed un corso di guida sportiva. Per fare un esempio terra-terra, sviluppare un browser mobile presuppone di poter acquistare schede di sviluppo e telefoni per il testing e per gli sviluppatori. Senza marketing non hai i soldi per comprare i telefoni, quindi non hai la base per avanzare la tua tecnologia.
Trovo che il lavoro fatto dal marketing sia ottimo, che siano in grado di rendere elettrizzanti le nuove caratteristiche e di renderle comprensibili al pubblico (non ad un pubblico di utenti come me o te, che ovviamente abbiamo altri metri di paragone). E so che lo fanno con grande passione, avendo conosciuto personalmente alcuni membri dello staff.
Non credo che in tutto questo ci sia qualcosa di profondamente sbagliato, a meno che non vengano portate a galla evidenza in cui il marketing abbia palesemente mentito agli utenti. Nel qual caso mi troveresti pienamente d'accordo con te.
Mozilla come piattaforma software/embedded è morta, giustamente scalzata da webkit
Si, è una tendenza interessante, che ovviamente avrà fondate ragioni d'esistere, ad esempio un codice di più semplice utilizzo, ed il fatto che webkit abbia dietro due piccoli mostri quali Google e Apple. Il secondo problema non è ovviamente risolvibile, il primo problema richiede anni di sviluppo. Se ora si decidesse di riscrivere quella parte di codice non avresti risorse per l'innovazione tecnologica che richiedi. Si tratta ovviamente di trovare il giusto compromesso di risorse.
La promessa di release stabili supportate per anni è stata fatta sparire.
Non ne sono pienamente convinto, specialmente per il discorso che ti ho fatto sopra. Ogni sviluppatore ha un'attenzione che definirei maniacale nel supporto alle versioni precedenti. Inoltre, per una mera questione di risorse, più branch attivi e supportati hai, più lo sviluppo del trunk rallenta. Quindi la richiesta che avanzi "voglio che Mozilla acceleri lo sviluppo di nuove tecnologie e che non smetta di supportare i vecchi branch", non è sostenibile.
Potresti immaginare che sia sufficiente raddoppiare il numero di sviluppatori (il che andrebbe contro le succitate critiche verso il marketing), ma è dimostrato che aumentare il numero di sviluppatori, nel breve termine, non porta ad uno sviluppo più veloce. Funziona a lungo termine e ogni giorno leggo con piacere di nuovi arrivi. I nuovi sviluppatori hanno bisogno di tempo, spesso vengono redirezionati verso i nuovi progetti (come Jetpack o le gestures) in modo che possano al tempo stesso produrre qualcosa di utilizzabile da tutti, prendere confidenza con la base codice ma non essere limitati da vecchie ideologie. Il tutto richiede il tutoraggio dei più esperti, il che ovviamente ruba cicli di sviluppo.
E' un processo patologico, non puoi farne a meno e non può cambiare dall'oggi al domani.
Sento scricchiolare l'impalcatura, e non mi piace.
Con critiche costruttive, come queste, l'impalcatura non potrà crollare mai.
Ben venga la discussione.
