.
Annunci online

Tutto quel che puo' venire in mente a un italiano che si e' sposato e spostato in california
17 luglio 2008
Tecnologie: AROS: Linux: mi sa che non ho capito un c..o dell'open source?
EDIT: di KDE 4 e di come gli utenti reagiscano come consumatori si parla anche qui.


I recenti interventi sul gruppo it.comp.os.amiga qui, per quanto legate alla prossima uscita di Amiga os 4.1 e le recenti polemiche che appaiono su linux hater blog qui e su linux.com qui, mi fanno considerare come abbia preso grandi cantonate sulle ragioni che portano il movimento open source: Ho sempre pensato che ci fossero motivazioni sociali come necessita' di strumenti informatici per chi non puo' permettersi un sistema operativo o degli applicativi di marca, per supporto a organizzazioni umanitarie e strumentazione didattica e di startup per paesi emergenti, oltre che lo scindere l'IT da quelli che sono i legami con l'industria tradizionale del software e dei sistemi operativi commerciali, la condivisione delle conoscenze e l'apertura di algoritmi e librerie fruibili a tutti per qualsivoglia scopo, senza dover trovarsi o a abbandonare il progetto o a dover pagare costose royalties in algoritmi altrimenti ripetibilissimi.

Forse sono troppo ingenuo, forse sono troppo idealista: certo che essere disillusi alle soglie dei 40 anni e' molto piu' cocente di quanto accade in gioventu'.

E capisco anche l'astio di linux hater e la frustrazione degli sviluppatori piu' nuovi di Linux o AROS, per parlare di un progetto a cui e' noto sono emotivamente legato.

Leggere qui come stia portando avanti da solo lentemente lo status report del completamento delle librerie senza l'aiuto e il feedback di molti degli altri sviluppatori, cosa che potrebbe accelerarne l'andamento, e' in parte scoraggiante.

E anche leggere in molti degli interventi di Linux Hater come alcuni dei cardini della filosofia open source si stiano rivelando controproducenti al fine stesso della filosofia FOSS: il fatto stranoto dei package managers, GNOME KDE XFCE e altri desktops, le beghe dei sound managers, il reinventare la ruota, la scusa di dover leggere i sorgenti invece di documentare adeguatamente, il come il FOSS sia attualmente penalizzato dalle lotte di potere interne, l'ego dei programmatori di cui ho gia' parlato qui e tante altre cose.

Nello stesso thread Alessandro Pellizzari dice che se si vuole raggiungere lo scopo di avere un AROS funzionante bisogna trovare un "leader spirituale che dia le direzioni per il progetto": si, poi chi non e' d'accordo forka, e gia' che gli sviluppatori sono pochi, non e' cosa buona.

Lasciando da parte AROS, ho gia' sostenuto come il mio punto di vista sia che, quando un progetto raggiunge una "massa critica" di utenti, gli sviluppatori dovrebbero avere il buon senso di sentirsi moralmente tenuti ad ascoltare le ragioni dei loro utenti o comunque di tenerle maggiormente in considerazione.

Leggendo i casini successi con KDE 4, sembra proprio che questo non sia accaduto: certe distirbuzioni hanno inserito KDE 4 come feature standard nonostante la dichiarata (ma sembra non troppo) provvisorieta' della release e gli utenti ne sono rimasti frustrati per le limitazioni delle feature non finite.

E' pero' comico leggere su linux.com qui di come il fatto che gli utenti si comportino come consumatori sia ritenuto sbagliato da chi sostiene la comunita' FOSS. Ma un utente e' un consumatore, consuma un bene, anche se non venduto, e puo' dare un feedback, anzi: se vuole partecipare alla filosofia open source di base direi che deve.

Questo doppiopesismo ricorda molto la sinistra italiana; a prima vista ci sono molti paralleli tra il FOSS e le filosofie socialiste e comuniste cosi' come tra certi comportamenti del FOSS e il proselitismo delle religioni, tra peccato e FUD, capitalisti e Microsoft: il come serva un nemico e un'ideologia per portare avanti la causa.

Io mi sono sempre tenuto fuori dalle diatribe politiche, sono una persona pratica cresciuta in una casa con madre di destra e padre comunista ma nessuno dei due mi ha cercato di spingere verso l'una o l'altra parte: ho personalmente valutato pro e contro dei reciproci punti di vista e, pur avendo alcune influenze di base, non scelgo direttamente una parte o l'altra ma piuttosto pratico i punti dell'una o dell'altra o di terze parti che condivido.

E anche per il software open source seguo la stessa filosofia: l'approccio seguto da AROS con la sua APL mi risulta piu' compatibile con il mio modo di pensare, cosi' come la stessa interfaccia di AROS e degli Amiga os: si possono manovrare sia con la GUI che senza e molto piu' facilmente di un windows o di un linux.

Ma sto uscendo fuori tema.

Sempre qui avevo citato l'articolo di Product Beautiful che parla di product management: un progetto opensource che lo voglia o meno e' un prodotto, ma un tipo speciale di prodotto: e' un  po' come l'hamburger custom di Wendy's: diamo una base e il cliente chiede espansioni o magari aggiunge cose di sue; quindi ne appende la ricetta in bacheca in modo che anche altri la possono provare o variare. E la cucina e' a vista e aperta a tutti per smanettare, col cuoco attorno in modo che i clienti non possono fare troppi danni.

Almeno in potenza.

Se vogliamo portare avanti la metafora, capita che certe volte il cuoco e' un maniaco della pulizia o non sa accettare le critiche o ha un suo modo di disporre le coltellerie e gli utensili o che d'un tratto decida che le ricette degli utenti non sono accettabili secondo i suoi criteri: il caso di pidgin.

E ancora una volta non posso far a meno di coprire il mio capo di cenere, dicendo che anche io nel mio piccolo ho sofferto di questi complessi di ego, e ne soffro tuttora: ammetto che uno dei motivi della mia contribuzione e' che mi piace che si parli bene di me, e mi piace farlo facendo cose buone per gli altri.

Poi che io sia una di quelle persone che se fa una cosa sente dei doveri morali verso gli utenti, al di la' del puro piacere, penso sia solo cosa buona. E onestamente penso dovrebbe essere uno dei reali motori dell'open source: il fare qualcosa di utile per gli altri, un modo di far diventare il mondo un posto in qualche modo migliore. Non certi giochetti di politica, le fazioni, gli ego offesi, ecc. ecc.

Anche perche' il FOSS, come altre ideologie, funziona bene sulla carta ma quando poi si porta in pratica si scontra con il fattore umano ed emotivo. Non tenerlo in conto significa negare l'esistenza di un fattore determinante.
E' esattamente cosa sta succedendo in KDE, Pidgin e in parte anche in AROS, e la rigidita' nel rispondere e nel tenere le posizioni ad oltranza non penso sia cosa buona. Se IMHO i progettisti hanno un minimo di senso etico dovrebbero accantonare gli ego, le posizioni intransigenti, le regole auree e focalizzarsi nel raggiungere una delle pietre miliari del percorso, in modo che sia un nuovo punto di partenza per cosa fare in futuro.

40 anni e ancora credo nelle favole e nel fatto che la gente possa fare la sceltapiu' ovvia e pratica, mah, mi sa che sono incurabile:(
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