La Sottile Linea

Qualche settimana fa’ e’ stata approvata la mia richiesta per un account git sui repository del progetto Gnome, mossa dopo l’invito di Philip Van Hoof sulla mailing list di Tracker. Ne ho presto approfittato per caricare su git.gnome.org il codice di libgrss, inizialmente sviluppata su BarberaWare ma ora dipendenza di Tracker e, se e quando avro’ modo di avanzare richiesta di inclusione, modulo ufficiale di una delle prossime versioni del desktop environment.

Un paio di mail ed un paio di commit mi hanno permesso di entrare a far parte di un team ben piu’ grande di quelli cui sono stato sinora abituato, e ad un livello ben piu’ alto, di vedere il mio proprio codice girare su milioni di PC sparsi sul globo terracqueo, di oltrepassare la sottile linea che separa chi il freesoftware lo considera un passatempo da chi lo considera un obiettivo.

Cosa implica cio’?

Dal punto di vista prettamente strutturale, una sequenza di complicazioni: rigide guidelines da seguire per la formattazione del codice, la responsabilita’ di mantenere sempre sul repository qualcosa di funzionale e quanto piu’ possibile esente da bugs, il dovere di provvedere ricca documentazione di ogni funzione destinata ad essere usata da altri, l’impegno a rispettare determinate deadlines e determinati tempi di consegna per rientrare nel ciclo di sviluppo del progetto. Questa posizione mi aiuta a ricordare il fatto che il “software libero” sara’ pure “libero”, ma e’ anche “software”, ovvero un prodotto manufatto che richiede una certa precisione ed il rispetto di regole di stampo ingegneristico: bellissimo il fatto di poter condividere il sorgente, ma se non fa quello che deve esso e’ totalmente inutile e le prediche sulla “liberta’” diventano esercizi di retorica fini a se’ stessi.

Dal punto di vista sociale, il progresso e’ notevole: sorvolando sul fatto di potersela inopportunamente “tirare” con gli amici, e sulla soddisfazione di aggiungere la dicitura “Developer Gnome” sul curriculum (che ora come ora risulta essere un documento particolarmente utile…), c’e’ da considerare il credito accumulato nell’economia meritocratica in vigore nel mondo freesoftware. Pubblicare il proprio codice sui repository Gnome garantisce che esso venga visto ed usato da molta piu’ gente, e nuove opportunita’ si aprono per implementare e far implementare architetture complesse. Poco fa’ ho inviato richiesta per vedere il mio blog (non questo, ma quello piu’ tecnico) in Planet Gnome Italia, e dunque aumentare di molto la visibilita’ dei miei contenuti e delle mie idee. Un po’ alla volta si ottiene familiarita’ coi processi e con le persone, e piu’ facile viene apportare e far apportare modifiche utili ai propri scopi, sia all’interno dei progetti su cui si lavora direttamente che su altri affini.

Il mio attuale status (con i benefici sopra elencati) non deriva da eccelse ed uniche qualita’ programmatorie, ma semplicemente da un minimo impegno e da uno sforzo marginale ma oculatamente indirizzato. Come si puo’ constatare dal codice di tracker-miner-rss, che appunto e’ il componente per il quale sono stato chiamato a far parte del team Tracker, l’opera svolta non brilla per complessita’ o ingegnosita’: ho prelevato il codice che mi serviva da Liferea, usando la libraria apposita l’ho integrato con il programma principale, e basta. Un qualsiasi mediocre programmatore con qualche esperienza su piattaforma Linux avrebbe potuto fare altrettanto, magari pure in meno tempo. Cio’ vuol dire che superare la sottile linea oggetto di questo post non e’ questione di capacita’ o fortuna, ma esclusivamente di volonta’. La volonta’ di fare qualcosa di mirato e specifico per il miglioramento.

Ben venga il progettino su cui lavorare alla domenica (io stesso ne ho una lista infinita, e non ci lavoro solo alla domenica), ma molti di piu’ dovrebbero avere la fermezza di voler aggregarsi ad un progetto piu’ grande ed affermato, magari di fare il sacrificio di abituarsi alle guidelines e alle deadlines, e meglio sfruttare le risorse intellettuali di cui dispongono per dirigere la crescita verso una direzione univoca e comune, anziche’ frammentare gli sforzi in mille direzioni diverse.

Il Bugzilla di Gnome pullula di tickets aperti, molti dei quali molto facilmente risolvibili eppure lasciati li’ a marcire da anni a causa della legittima mancanza di tempo dei maintainers. Non dubito che anche KDE, OpenOffice, o qualsiasi altro progetto di grosse dimensioni siano nelle stesse condizioni. Val la pena farci un giretto, aprire qualche pagina a caso, dare uno sguardo al codice, e magari confezionare una patch. E poi un’altra. E un’altra. E chiedere un account sul repository, in modo da potersi committare le altre da soli. Ed oltrepassare la sottile linea che separa chi blatera su quanto sia bello il software libero da chi il software libero lo fa.

Pacco

A me, piace il posto dove lavoro: sperimentiamo le piu’ recenti tecnologie, accrocchiamo insieme componenti diversi per ottenerne qualcosa di nuovo, contribuiamo a diversi progetti open, ed in linea di massima i colleghi sono tutti nerd e tutti hanno buone competenze, percui spesso saltano fuori spunti di discussione interessanti. C’e’ un solo difetto nel lavorare con gente che ha passione per il proprio mestiere: talvolta la si prende sul personale. Per ovvi motivi di riservatezza non posso qui esporre il perche’ ed il percome si sia giunti in una determinata situazione, ma suppongo nessuno se ne avra’ a male se linko un contenuto pubblicamente fruibile sull’Internet (da cui comunque, volenti o nolenti, si evince buona parte del background qui “censurato”): alcune mail di questo thread sono state fatte circolare nella mailing list interna dell’azienda e ne e’ nato un discreto polverone.

Sorvolando sull’aneddoto specifico, tale avvenimento mi ha fatto “scoprire” l’esistenza di una mailing list chiamata “KDE-promo”, cui mi sono iscritto un po’ per seguire eventuali evoluzioni della commedia un po’ per la curiosita’ di studiare quali metodi avesse adottato la squadra di promoters di un progetto che dalla versione 4, come gia’ discusso, fa’ dell’hype e della fidelizzazione il punto di forza del suo successo. E sono bastate un paio di settimane di frequentazione non solo per rinsaldare le mie precedenti posizioni, ma per inasprirle ulteriormente.

Per dirla in breve: l’intero universo KDE (developers, utenti sostenitori e quant’altro) e’ tenuto ad agire in funzione di quel che viene imposto da un ristretto gruppo di markettari che coordina qualsiasi output della community affinche’ appaia luccicante e scintillante. Trovo che il thread piu’ significativo in tal senso sia quello in cui Sebastian Kugler minaccia gli sviluppatori di Plasma affinche’ aggiornino la lista di features previste per la release 4.4 in quanto troppi elementi “gialli” (ovvero: marcati come “in fase di sviluppo”) non stanno bene e danno una cattiva impressione. Elementi di questo genere se ne trovano a dozzine, nella suddetta mailing list o meno: dalla pagina in cui si dettagliano i metodi con cui far sembrare una particolare applicazione KDE come il non-plus-ultra della tecnologia dinnanzi ad un utente domestico, all’intera sezione del wiki che elenca le argomentazioni da sostenere quando si parla del progetto e dei suoi pezzi forti, ad un comodo vademecum delle cose da dire o riportare nei blog per preparare il pubblico al prossimo rilascio (cfr. generare hype), alle pubbliche declamazioni delle esaltanti e nuovissime innovazioni introdotte (tipo: le finestre raccolte in gruppi, ad esempio esistenti dalla notte dei tempi in Fluxbox).

La mia critica non va ovviamente alla legittima volonta’ di promuovere e diffondere un progetto open, anzi la squadra KDE sarebbe da ringraziare per aver iniettato nella community un germe del fattore comunicativo indispensabile per fronteggiare le strategie di marketing dei colossi commerciali, ma al contrario all’eccessivo zelo con cui si aderisce ad una filosofia fondata sull’apparenza anziche’ sulla sostanza. Va benissimo ed e’ anzi consigliatissimo impegnarsi per mettere insieme screenshots e screencasts atti a portare all’attenzione del pubblico di massa le proprieta’ di una applicazione, ma il fatto di spostare le modalita’ di ingaggio dall’esposizione delle possibilita’ concrete alle fumose ed immantenibili promesse risulta dannoso non solo al progetto in se’ ma a tutto il mondo linuxaro.

L’esempio piu’ eclatante e scontato e’ esattamente KDE4: annunciato con le fanfare come una rivoluzione del desktop computing, comprendente meravigliose tecnologie semantiche, uno stravolgente modello di interazione, un framework di potenza straordinaria, e’ stato atteso con fervore da migliaia di “addetti ai lavori” e semplici rappresentanti dell’utenza home. A tutt’oggi, con la release 4.4, solo una minuscola parte delle promesse sono state soddisfatte, l’hype va spegnendosi, il progetto viene etichettato come una bolla di sapone, la sua instabilita’ ha disintegrato le speranze (gia’ eccessivamente esasperate) accumulatesi sui blog. I sogni di gloria sono stati paccati.

Se a trarre danno da questa situazione fosse il solo KDE si potrebbe chiudere un occhio, impietosirsi di chi si e’ tirato la zappa sui piedi e tirare avanti. Ma evidentemente si son fatti i conti senza l’oste: la community freesoftware e’ ancora una minoranza (in esponenziale crescita, ma pur sempre una minoranza), al di fuori della ristretta cerchia di entusiasti ed assidui frequentatori un’opera dello spessore di KDE al pari di Gnome o OpenOffice o anche solo Firefox sono identificati come una unica entita’ (solitamente identificata come “Linux”) e la valutazione inconscia di uno si ripercuote su tutti. Dedicare tante risorse nel creare aspettativa e cosi’ poche nel realizzarla produce un effetto boomerang su se’ stessi e sugli altri: una recensione critica, e resa piu’ aspra dall’insoddisfazione di chi la scrive, aggiunge una goccia al mare di piu’ o meno fondate obiezioni al software libero, e considero una incoscienza continuare a perseguire le strade del marketing vaporoso anziche’ quelle dell’avanzamento tangibile.

Morale: producete qualcosa ed esaltatelo, anziche’ esaltare qualcosa che non esiste. Le bugie hanno le gambe corte, esattamente come corta e’ la pazienza di chi attende di avere qualcosa di solido tra le mani.

Ed ora, ho gia’ scritto abbastanza chiacchere: torno a stendere un po’ di codice.