.
Annunci online

Tutto quel che puo' venire in mente a un italiano che si e' sposato e spostato in california
TECNOLOGIE
9 luglio 2008
Tecnologie: AROS: REACTOS: Fattore Pidgin e Product Management
Immagine da Product Beautiful

A meno che qualcun'altro dei partecipanti sul cannocchiale non mi spiega come recuperare i miei articoli vecchi NON pubblicati (in attesa di tempo,ispirazione,ulteriore documentazione,ecc.), mi vedo costretto a ricominciare a scrivere questo articolo da capo, con i dovuti aggiornamenti.

Prima di tutto, vedro' di presentare il causus belli: Bug report su Pidgin , commento su Product Beautiful e ulteriore articolo su Product Beautiful a tal proposito.

La vicenda e' sicuramente nota a chi segue il progresso del software open source: da gennaio gli utenti di Pidgin si lamentano di una nuova feature che introduce il ridimensionamento automatico dell'area di testo; gli sviluppatori hanno risposto che la feature e' introdotta da loro in quanto a loro piace e non hanno intenzione di tornare indietro. La discussione e' stata serrata anche se formalmente educata ma ha portato a un sollevamento popolare contro la decisione degli sviluppatori, alla chiusura del report con il prefisso "wont_fix" ed alla creazione di un fork, funpidgin.

Tra gli interventi, quello di un utente, Dan Livingston, insegnante di "Collaborazione nel mondo Open Source" in un college americano, il quale commenta abbastanza duramente il comportamento degli sviluppatori.

Questa e' la traduzione del post di Dan Livingston, abbastanza fedele nei concetti espressi, dal Bug tracker di Pidgin:


"Io insegno "Collaborazione nel mondo Open Source" in un college locale. Stavo cercando, e ho avuto la fortuna di trovarlo in questo bug ticket, un perfetto esempio di come la comunicazione tra sviluppatori open source e utenti viene a mancare in molteplici punti fondamentali.

Ovviamente, le ragioni degli sviluppatori open source sono varie; qualcuno lo fa per diletto, altri lo fanno per la gioia di contribuire con la loro opera a fare un mondo migliore. Il problema sorge quando le ragioni degli sviluppatori vanno in conflitto conm le aspettative degli utenti finali.

Considerate un qualsiasi progetto open source di successo: gli utenti sono sedotti dalla possibilita' di svolgere le loro attivita' in modi non immaginabili prima. Una forte dedizione prende piede e come risultato porta a una base di fan evangelizzatori che ne tessono le lodi. ben presto diventa ovvio il perche' gli utenti non vogliano pensare ad alternative non-open al loro software preferito.

E cosa succede quando alcune di queste nuove potenzialita' vengono all'improvviso tolte? Cosa succede quando gli sviluppatori decidono di imporre i loro personali "dogma" al progetto? Anche una futilita' come il resize della finestra di chat porta a esprimere dissenso empaticamente.

E' facile comprendere come gli sviluppatori open source siano portati a costruire visioni dogmatiche: qualcuno di loro si industria sui limiti teorici che portano un design alla "purezza", sviluppando una repulsione per tutto quel che non rientra in tali termini. Altri diventano ossessionati dai puri dettagli metrici come la quantita' si codice usato per la manutenzione misurato in numero di linee, anche se poi si preoccupano spesso delle features, e il numero di linee di codice usato influisce solo all '1% sulla complessita' totale dell'applicazione. Altri sviluppatori, ancora, si fissano silla cosiddetta "semplicita' definitiva per l'utente", percependo che due opzioni siano meglio di cinque piu' dettagliate. La visone dogmatica piu' pericolosa e' quella che si puo' riscontrare qui: la "God Feature", ovvero "Una soluzione tecnologica che incontra ogni possibile variazione della feature desiderata dall'utente".

Il fascino iniziale del software open source e' quello secondo cui i bisogni degli utenti possano essere espressi da software di qualita' adeguata. Come i fatti sin qui narrati hanno dimostrato, fino all'arrivo di Pidgin 2.4 gli utenti piu' entusiasti ne hanno tessuto le lodi. Ma, quando gli sviluppatori hanno tolto una feature, presumibilmente nel tentativo di implementarne una "versione migliore", ma questa "versione migliore" risulta essere un netto passo indietro rispetto alle funzionalita' fin qui disponibili.

"Ecco come un software di Messaggistica dovrebbe essere","Il nostro design e' migliore","noi consideriamo solo un design 'puro' il quale implementa le vecchie funzionalita' con un nuovo paradigma che supporta anche quelle nuove", "Aggiungere un altro checkbox e' deleterio per l'interfaccia utente","Tenere due comportamenti diversi per l'interfaccia di scrittura sarebbe ingestibile","non ha senso per noi non propagare il nostro nuovo gadget fighetto"...

Questi sono tutte affermazioni che, se fatte in un ambito aziendale, porterebbero gli sviluppatori a licenziamento sicuro. Tenete nota sviluppatori: state dando un disservizio alla comunita' che pretendete di rappresentare, e lo state facendo con l'illusione di essere "nel giusto" in quanto convinti dalle vostre stesse giustificazioni.

Non importa che siate degli sviluppatori open source con l'autonomia di ignorare la vostra base utente. Non importa  che un plug-in "potrebbe" essere sviluppato per risolvere il problema. Non importa che voi sentiate che la vostra soluzione di default sia superiore. Non importa neanche che voi vogliate solo considerare soluzioni che possano essere implementate solo attraverso il nuovo framework. Non importa nemmeno che i vostri utenti abbandonino il vostro progetto se non ne condividono i progressi e tanto meno che 11mila persone scaricano i sorgenti del progetto e solo 11 se ne lamentano. Per ognuna di queste motivazioni ci sono validi motivi per respingerla.

Quindi, solo 270 si lamentano di questa feature su 11mila downloads? Quanta gente ha immediatamente rimosso il programma quando si sono accorti che non aveva piu' le semplici funzionalita' che GAIM ed altri instant messengers hanno? Quanti non sanno che stanno usando un programma che si e' irrigidito rispetto alla sua vecchia flessibilita'? Quanti usano il software oggi, ma lo cambieranno con il vecchio GAIM domani quando verrranno a sapere dai loro amici come e' piu' facile ridimensionare la finestra di input messaggio in GAIM?

Il fatto e' che scrivere testo in un programma di instant messenging e' LA piu' importante e critica funzionalita' di un programma di tal genere. Gli utenti hanno vari bisogni, che non possono essere soddisfatti dalla vostra "soluzione unica per tutto" che incorpora "nouvi algoritmi" che dimostrano quanto siate bravi. State ignorando la base degli utenti convinti con una dedizione alle vostre convinzioni che e' pericolosamente evidente anche al meno zeloto dei vostri adepti, e a causa di cio', state dimostrando di non essere piu' degni di soddisfare i bisogni dei vostri utenti.

Spero per tutti che ritroviate la giusta strada."


E questa e' l'ipotetica polemica risposta che Dan dice gli utenti dovrebbero vedersi ricevere dal team di sviluppo:

"Cari utenti,

State senza dubbio leggendo questa pagina perche' volete sapere come ridimensionare manualmente l'area di input testo in Pidgin. E' una feature a cui vi siete certamente abituati e che vi risulta confortevole ma, per favore prendete nota, e' una feature che non supportiamo piu'.

Abbiamo ricevuto molti reclami da una sparuta minoranza della base di utenti che persiste nel voler far sentire il loro disaccordo sull'argomento. Non fatevi influenzare: sono solo una piccolissima percentuale degli utenti di Pidgin e, se ignorati, se ne andranno a disturbare qualche altro porogetto open source.

Nondimeno, sentiamo molto importante rammentare la nostra posizione: non "aggiusteremo" la feature. Infatti, tenete presente che lo status di questo "bug ticket" e' "wontfix" Quindi, per favore, fate entrare questo per bene nelle vostre teste e levatevi dalle scatole, ok?

Noi siamo gli sviluppatori di questo software e noi sviluppiamo Pidgin in modo che possa soddisfare i nostri stessi bisogni e necessita'. Se volete unirvi a noi in questo, va bene. Solo non criticate. Per favore, se abbiamo fatto una feature in un certo modo e' perche' LA VOGLIAMO NOI IN QUEL MODO. E' cosi' difficile da capire? I nostri capi ci dicono tutto il giorno cosa dobbiamo fare. Le nostre mogli ci dicono tutto il giorno cosa dobbiamo fare (sic! ndT) Voi NON ci direte cosa dobbiamo fare.

Qualcuno dice che, come sviluppatori del migior clien di instant messenging open source, abbiamo la "responsabilita'" di servire come custodi e guardiani del nostro prezioso incarico, sostenendolo in un cittadino e membro modello della comunita' open source. Sono Stupidaggini. L'ultima volta che abbiamo controllato, non ci siamo offerti volontari per far le badanti: ci siamo offeti volontiari per scrivere software che NOI STESSI vogliamo usare.

Quindi per favore, tenetevi le vostre idee e andatevene da un altra parte. Se volete un team di sviluppo che risponda ai desideri della loro base utenti, nella speranza che ne venga fuori un software di qualita' internazionale usato da milioni di persone, allora iniziate il vostro proporio progetto open source. Non e' difficile, e' gratis, tutto quello che dovete fare e' dedicarvici il vostro tempo libero, come noi lo dedichiamo al nostro progetto.

Il team di sviluppo sarebbe molto lieto di offrire una soluzione che incontra sia i nostri stessi bisogni sia  quelli della base utenti. Pero' non riusciamo a capire i vostri bisogni: voi parlate in un arcano dialetto con forte accento straniero biscicato e balbettato che nessuno riesce a decifrare. "A me piace in quel modo!" Quella non e' una risposta adeguata! Voi dovreste elencare gli aspetti e le metriche delle vostre preferenze e desideri in una maniera a noi intelligibile cosicche' possiamo evalutarle e quindi assimilarle nella nostra raccolta di feature. Noi non possiamo attualmente assimilare nessuna delle vostre stupide ragioni per avere una area input messaggi ridimensionabile. E, come stupida intendiamo "nessuna delle soluzioni che non coincide con lo schema della nostra area di input testo ridimensionabile intelligente".

quindi , per chiarire, noi non ascolteremo ai vostri suggerimenti a meno che i vostri suggerimenti non abbiano senso per noi. Se non vi va bene, internet e' piena di altri modi in cui potete occupare il vostro tempo.

Distinti saluti,
il Team di sviluppo di Pidgin"

Cavolo! anche io quando sviluppo la mia roba avrei certe volte la fortissima  tentazione di rispondere cosi' ma, forse perche' se lo facessi mi troverei senza una lira e senza modo di pagare le bollette, mi tocca ingoiare il rospo e tirar avanti.

Comunque, venendo al sodo, ho tirato fuori la polemica su Pidgin in quanto di recente alcuni atteggiamenti del team di ReactOS sul forum, specialmente prima della release della v. 0.3.5.

Capisco e mi e' stato ribadito centinaia di volte che AROS e ReactOS devono essere definiti piu' sistemi hobbistici che sistemi "per tifentare patroni ti monto", e capisco anche che la filosofia "no schedule and rockin' " di AROS porta difficilmente persone che ne volessero far uso in progetti a fare dei piani, pero' il rovescio della medaglia e' che AROS non e' ancora abbastanza sviluppato in quanto ha un numero ridotto di sviluppatori e, palindromamente, ha un numero ridotto di sviluppatori in quanto non e' ancora adeguatamente sviluppato.

La filosofia dell'open source, al di la di quel che dicono gli evangelisti FOSS, non richiede una collaborazione attiva a livello "contribuisci codice o levati dalle scatole": una comunita' open come detto implicitamente sopra dal buon Dan Livingston prevede collaborazione anche nella attivita' stessa della comunita': richiesta di feature, bug report, propaganda, temi grafici, etc.

Ad esempio io sento di contribuire scrivendo di AROS sul mio blog, in futuro spero anche di contribuire in maniera piu' attiva, tempo lavoro e moglie permettendo.

E anche una comunita' open souce volente o nolente effettua marketing inteso come presentazione volta alla diffuzione di un prodotto: lo fa in maniera principalmente virale ovvero spargendo la voce, commentando,etc.

E chiaramente avere un miglior profilo da vendere o da presentare aiuta la comunita' nella diffusione del prodotto.

E la diffusione del prodotto attira sia utenti finali che potenziali sviluppatori.

AROS, sia per le sue apparizioni mediatiche in italia e fuori con VmwAROS, sia per le attivita' propagandistiche degli utenti e della comunita' Amiga superstite, che ne beneficia anche attraverso AfAos (AROS for Amiga OS, un progetto che porta a sostituire librerie amiga con le piu' recenti librerie AROS) , sta attualmente guadagnando utenti e sviluppatori, ma non e' ancora abbastanza.

Una migliore presentazione del progetto, lo sviluppo della documentazione -che comincia ad apparire ma si appoggia ancora troppo a quella Amiga preesistente, dal cui anche il problema con il Guru Book- magari l'apparizione di tutorials testuali e video per spiegarne l'utilizzo e infine l'apparizione di applicativi e drivers (legata pero' al comma 22 di cui sopra) porterebbero AROS ed altri sistemi alternativi ad essere molto piu' diffusi e sviluppati di quello che sono adesso.

Inoltre e' mia opinione che una volta che un progetto raggiunge una certa "massa" di utenti, l'approccio hobbistico e edonistico alla programmazione del team di sviluppo che lo ha originato non puo' piu' esserne il motivo trainante e la sola ragione di esistere di esso: dal fatto che molti utenti si appoggiano e magari svolgono attivita' critiche con esso il team acquisisce il dovere morale, se non sociale di ascoltare i loro clienti. Poi se magari vogliono modificare le cose ne possono subappaltare il mantenimento e farne una versione "director's cut" a parte; se la nuova versione acquisisce adeguato consenso possono farla confluire di nuovo nel flusso principale e cosi' via, ma non possono piu' decidere vita morte e miracoli del loro progetto tutto da soli: il progetto appartiene ANCHE alla comunita' se la comunita' lo ha adottato e lo ama.

Product Beautiful parla appunto del Product Management nella comunita' open source e di come sia sbagliato pensare che il product Management sia materia solo di attivita' commerciale; provocatoriamente ipotizza che i progetti su sourceforge appongano un bollino (all'inizio dell'articolo) in cui si dichiara se lo scopo del progetto e' principalmente verso la comunita' o verso gli sviluppatori stessi, allo scopo di evitare figuracce come quella di pidgin verso i propri utenti.

Sarei contento di sentire anche altri pareri a proposito, comunque: ttranne sparutissimi casi mi pare di predicare al deserto.
sfoglia
  

Rubriche
Link
Cerca

Feed

Feed RSS di questo 

blog Reader
Feed ATOM di questo 

blog Atom
Resta aggiornato con i feed.

Curiosità
blog letto 1 volte

Articoli Recenti

Who links to me?

Contatta Simone Bernacchia

 




IL CANNOCCHIALE