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.
tredici commenti
Caro Marco,
oramai mi sono stancato di scriverlo: non sto criticando la scelta di usare il codice multiprocesso di Google, ma il fatto che negli ultimi 10 anni Mozilla non abbia saputo tirare fuori la sua versione, anzi, si è guardata bene dal muovere anche solo una virgola. E che negli ultimi dieci anni si sia trascinata dietro problemi strutturali che solo ora, sotto il peso della competizione, sta cercando di risolvere, non essendo più procrastinabili e avendo CHIARAMENTE perso il vantaggio tecnologico che aveva sugli altri, che anzi sono già oltre su diversi fronti (meno places! 
). L’embedding è stato fatto morire di stenti: le varie versioni e nomi di XUL Runner sono diventati lettera morta.
Non sono io che voglio versioni supportate più a lungo: ho solo detto che Mozilla si era impegnata a tenere in vita i branch stabili ben oltre i 18 mesi, ma che questa promessa non è stata sostituita da una nuova dichiarazione, bensì fatta cadere nell’oblio in modo che nessuno se ne ricordasse… Perché non fare una bella dichiarazione PUBBLICA chiara a a tutti di poche parole: “per poter presentare più funzionalità avanzate e più velocemente, aumenteremo il numero delle release ed accorceremo il tempo di supporto alle versioni vecchie”. Dubito che qualcuno avrebbe avuto nulla da ridire.
Le regole dei gruppi di persone che arrivano alla stessa soluzione o del numero degli sviluppatori che non dimezza i tempi di sviluppo sono belle parole, ampiamente note, ma non ho chiesto questo. Uno può appiattirsi sul mercato per rimanere a galla o esplorare nuove strade, o meglio ancora fare tutte e due le cose allo stesso tempo. Ma sopperire alle proprie carenze con la fuffa del marketing mentre si copiano i concorrenti non mi sembra una scelta lungimirante. Ma qualche testa pensante in più per i Labs non sarebbe stata meglio? Non dico un capoccione come Aza, ma di talenti Mozilla ne ha saputi cogliere a mucchi, anche nel Belpaese…
Vedere FX che passa da browser principe per lo sviluppo ed il test dei siti web, a mero “numero” dei browser da provare è un pessimo segno: questi utilizzatori (che Gandalf definisce geek) sono quelli che sviluppano il web di OGGI e quello di domani, molto più delle chiacchiere fatte in altri contesti mozilliani (ma questo è un altro discorso).
@flod beh, però in questo modo si confonde una feature con i bug ad essa legati. E’ infatti vero che la rilevazione dei plug-in obsoleti è stata implementata, che Mozilla è stata la prima a spingere per essa, e trovo quindi giusto che venga pubblicizzata. Che poi alcune cose non funzionino è probabilmente “normale”, o meglio è probabilmente segno che si è voluti inserire questa caratteristica anche se lo sviluppo della stessa era al 80% e questo succede ogni giorno.
In ogni caso trovo positivo parlare di plug-in obsoleti, primo perché anche se non dovesse funzionare la famosa barra gli utenti potrebbero comunque farsi cogliere dal dubbio dopo averne sentito parlare ed aggiornarli. Secondo la pagina plug-in check pur non essendo tradotta (sigh) è un ottimo strumento per fornire supporto agli utenti senza dovergli spiegare come si verificano i plug-in.
Probabilmente la presentazione della cosa è stata troppo appassionata, ma bisogna capire che il marketing in se funziona così, che ci piaccia o meno. Se presenti un oggetto dicendo che funziona così cosà, nessuno si interessa della cosa. Io non sono un uomo di marketing e non mi sento di valutare il loro lavoro se non valutando i risultati, così come penso loro non valutino il mio se non osservandone i risultati nel prodotto.
@prometeo evidentemente tirare fuori la propria versione significava dedicarci risorse notevoli e non disponibili. Avere la possibilità di ottenere un protocollo ipc fatto da altri (tra l’altro vorrei ricordare che gran parte del team che ha creato questo codice prima collaborava con Mozilla, ed il loro distacco ha creato un buco di conoscenze notevole) ha reso possibile farlo. Se in 10 anni non è stato fatto non è certo segno che non si sapesse farlo (infatti l’hanno fatto persone che lavoravano per Mozilla in quei 10 anni) ma che probabilmente 1) non si riteneva una priorità 2) le risorse necessarie erano ritenute eccessive. Rimosso il problema 2 grazie al codice ipc di chromium, e valutato il punto 1 in base ai crash, il progetto è partito. Peggio sarebbe stato dire “ah no, l’hanno fatto già altri, allora noi non lo facciamo più”.
Il team di sviluppo è cambiato molto negli ultimi anni, e sicuramente qualche problema interno c‘è stato (basti pensare all’abbandono degli sviluppatori di Google, passati a Chrome, di una parte degli sviluppatori di Thunderbird, passati a Postbox) e serve tempo per recuperare un insieme di conoscenze che si sono allontanate. Gli sviluppatori che sono stati assunti 2 anni fa stanno ora iniziando ad avere una visione tale che gli consente di far avanzare il prodotto come prima. Io stesso stavo imparando moltissimo da un esperto sviluppatore Toolkit che ha smesso di collaborare ed è stata una grande perdita.
Al momento probabilmente lo sviluppo è più lento, ma vedo che tutti ci mettono più del massimo che possono fare. Non trovo persone che abbiano 5 minuti liberi per farmi una revisione, ed i nuovi arrivati stanno salendo la curva di apprendimento (che grazie ad xpcom non sempre è così poco ripida).
La perdita del vantaggio tecnologico è anche segno che il mercato è cambiato, ti basta confrontare il mercato dei browser di oggi con quello di 3 anni fa. Evidentemente le altre società (dall’alto dei loro capitali, esclusa Opera che sta facendo un buon lavoro sulla 10.5, e probabilmente dovresti chiedere anche a loro perchè non l’abbiano fatto prima!) hanno investito fior di risorse per colmare il gap, Mozilla non ha mai fatto sprint ma ha sempre proseguito sulla sua strada lineare (basti pensare all’acid3).
Penso anche che non sarà mai più possibile creare un prodotto innovativo e stare sempre davanti agli altri, perchè il mercato di oggi non lo consente, perchè Apple e Google hanno tutte le risorse ed il know-how per rincorrerti e superarti in qualsiasi momento, e non si fanno grossi problemi di investimenti.
Noi abbiamo qualcosa che nessuno potrà mai creare, che è la community, ora l’obiettivo non penso sia realizzare il prodotto incredibilmente avanti agli altri, ma capire il malcontento della community e cercare di seguirne i problemi.
Personalmente mi impegnerò ad ascoltare di più le richieste e le lamentele e a spingere gli altri a fare altrettanto.
(basti pensare all’abbandono degli sviluppatori di Google, passati a Chrome, di una parte degli sviluppatori di Thunderbird, passati a Postbox
Al di là di ogni polemica, ma nessuno s‘è mai chiesto perché se ne siano andati (specie i ragazzi di Thunderbird)? ;)
@Giuliano Ho qualche idea in mente a riguardo, ma siccome non ero presente e non conosco i fatti abbastanza a fondo, preferisco tenerle per me. Sicuramente qualche errore c‘è stato, ma non sono in grado di analizzarli, mi spiace.
Stai dicendo esattamente quello che dico io: lo sviluppo è rallentato perché preso dall’arduo compito di rintuzzare la concorrenza e risolvere problemi lasciati lì a macerare per troppo tempo. Ma solo tu che sei “dentro” potevi dire che le cose stanno acquistando velocità perché gli sviluppatori nuovi stanno andando a regime… Questa è una delle risposte che cercavo!
E, ancora una volta, ripeto che va benissimo prendere il codice altrui quando è libero (non sarebbe la prima volta), specie se si parla di specificità fuori dalla portata dei mozilli (p.e. PNG, sqlite, cairo, ecc. ecc.). Ma qui stiamo parlando di roba che, come hai detto anche tu, ha girato per le stanze di Mozilla e nessuno ci ha dedicato il tempo necessario: mi vuoi dire che in 10 anni non si potevano trovare cicli liberi di un po’ di sviluppatori? O che non sarebbe stato possibile dedicarcene anche uno solo? Ti faccio anche un nome, tra l’altro sparito dall’orizzonte dopo l’ingresso in IBM, Doron Rosenberg (specialità networking ed ipc, o sbaglio?).
Nella tua disamina delle risorse che hanno dato l’addio, hai dimenticato di citare David Hyatt (non molto rimpianto all’inizio, per dirla tutta), che è l’autore del grande balzo in avanti di webkit e di Apple. Ma posso sapere chi è lo sviluppatore toolkit che ha lasciato? Pura curiosità.
D’altro canto è vero che sono arrivati anche talenti notevolissimi, anche da MS (p.e. Tarak Gles, o come cavolo si scrive), o “comprati” di sana pianta come Aza.
Invece dei 25 “marketeers”, non potevamo fare 15 e un paio di pensatori e visionari o ottimi sviluppatori magari già formati alla base del codice Mozilla? (me ne vengono in mente un paio, ma sono di parte: tutti e due vengono dal mondo SeaMonkey, Neil e Karsten).
Bell’intervento!
A Giacomo avevo già espresso le mie argomentazioni (http://mondozilla.blogspot.com/2010/02/seguire-o-guidare.html?showComment=1266530124902#c8670735371502153787) e mi trovo sostanzialmente d’accordo con la tua risposta.
No, non credo che al posto dei 25 “marketeers” una manciata di sviluppatori avrebbe cambiato le cose, credo saremmo circa al punto di oggi con forse un paio di sviluppatori più esperti (se parliamo di sostituzioni e non di aggiunte). Stiamo parlando di 25 persone (tra l’altro con svariati compiti, non solo puro marketing) e qualche centinaio (300?) di sviluppatori, che gestistono 350 milioni di utenti. Penso non troverai alcuna azienda con solo 25 persone dedicate a gestire un tale numero di utenti. Google ha molti innovatori, vero, ha laboratori interi di persone dedicate al brainstorming, ma stiamo parlando di realtà ben diverse.
Il numero di sviluppatori cresce con il crescere della fondazione, è molto probabile che 10 o anche solo 5 anni fa non ci fossero le risorse di oggi, se azzoppi il marketing, il meglio che puoi ottenere è di dimezzare gli sviluppatori.
Posso dire che sono contento?
Si è mossa un po’ di polvere e qualche briciola di informazione è venuta fuori…
Grazie per aver capito il senso dell’intervento e non aver usato il bazooka.
Buon lavoro!
Spiacente per il defacciamento… ;) Hai ancora i css dei blockquote a pallino.
E ancora non mi hai detto quale sviluppatore toolkit ha mollato! :)
Si spiace anche a me per il defacciamento, anche se in effetti il problema era a livello del servizio hosting visto che hanno usato una ulnerabilità di un loro software. Cmq mi hanno ripristinato tutto da un backup (che ovviamente non ha le ultime modifiche ai CSS ed agli script che avevo apportato).
Sistemerò quando torno in Italia.
Quanto allo sviluppatore, al momento è qui accanto a me, ha solo avuto problemi di tempo a disposizione, quindi tutto ok. il velo di mistero serve a fare audience :)
Un o più commenti sono in attesa di approvazione.
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.
Non lo chiamerei mentire, ma si sta pesantemente promuovendo una funzione (rilevamento automatico dei plugin obsoleti) che ad oggi non funziona sulla 3.6
https://support.mozilla.com/en-US/forum/3/571394
Senza contare che la pagina in questione non è ancora localizzabile, a distanza di mesi.