GNOME e le feature rifiutate, riflessioni su sviluppatori e comunità

Negli ultimi tempi il rapporto tra committenti, sviluppatori e comunità di utenti dei progetti open source è tornato in primo piano, si pensi ad esempio alle aspre critiche che Canonical – la società che sta dietro allo sviluppo della distro Ubuntu – ha attirato su di sé dopo la scelta di adottare Unity come interfaccia grafica predefinita e poi di perseguire la strada di uno sviluppo commerciale che portasse il sistema operativo su dispositivi mobili, muovendosi su percorsi poco graditi alla sua community.

E’ di ieri la notizia di un piccolo episodio avvenuto in casa GNOME che riapre la discussione su quale debba essere il ruolo delle community nel guidare la direzione di sviluppo dei progetti e di quale debba essere l’atteggiamento dei responsabili e dei singoli sviluppatori verso di essa.

L’episodio, riportato da Marco’s Box a partire da una segnalazione su Pollycoke, è il seguente.

A partire da GNOME 3.7 gli sviluppatori hanno deciso di eliminare alcune funzionalità relative al terminale di sistema e l’hanno fatto nelle secrete stanze.

Una di queste funzionalità rimosse è la possibilità di personalizzare lo sfondo del terminale rendendolo trasparente; diciamocelo, una funzionalità che può sembrare inutile ai più ma che per gli utenti avanzati è spesso utile.

Bene, accade poi che un utente decide di aprire un bug su bugzilla per segnalare la cosa e chiederne la reintroduzione.

Ecco il BUG 698544 https://bugzilla.gnome.org/show_bug.cgi?id=698544

Steps:

1. Open gnome terminal
2. Go to Edit -> Profile Preferences

Actual result: Background configuration tab is missing.

It was present in 3.6 version, please return it back.

Come potete leggere l’utente ha chiesto con educazione di ripristinare la situazione così come era fino a GNOME 3.6

Ecco la risposta che uno sviluppatore del terminale di GNOME ha subito fornito

No.

Si, avete letto bene, la risposta è stata un secco e lapidario no, senza aver aggiunto qualche motivazione per spiegare il diniego.

Ora, lavorando io in una software house che al contempo vende anche servizi oltre che sofware, da anni ho modo di vedere quotidianamente e da vicino le dinamiche che intercorrono tra chi sviluppa, i clienti che usano il prodotto, i colleghi che lo utilizzano internamente, i commerciali che lo vendono, chi si occupa di fornire i servizi ad esso collegato. Devo dire che le risposte secche come quella dell’esempio non mi stupiscono, rientrano nell’atteggiamento del “programmatore tipo”, anche se certamente non lo condivido.

Quello che posso dire è che il nostro software è passato nel giro di alcuni anni (in seguito anche alla crescita dell’azienda stessa e del numero di utilizzatori del software) da un modello basato sulle idee di poche persone (il capo e gli sviluppatori sotto di lui) a un modello più aperto, basato sull’analisi continua dei feedback raccolti dai clienti tramite questionari (con l’idea di attivare in futuro dei focus group), e internamente. Certo, è un caso differente da quello di GNOME e degli altri progetti open, perché il nostro è un SaaS di cui non rilasciamo pubblicamente il codice, e i nostri clienti sono principalmente aziende quindi il numero di utenti è relativamente contenuto. Gli utenti nel nostro caso non partecipano direttamente allo sviluppo e non costituiscono una comunità, ma certamente danno input e feedback continui sulle funzionalità, e bisogna valutare come gestirli.

Sul modello di sviluppo open source si discute molto, fin dal saggio del 1997 di Eric Raymond “La cattedrale e il bazaar”.  Quello che penso io è che i ruoli debbano essere definiti e che ognuno debba mantenerli, nel rispetto del ruolo degli altri (e possibilmente con cività ed educazione). Credo che ci debba essere un owner del progetto, che sia un’azienda o un organismo direttamente eletto da una comunità, degli sviluppatori (sia interni che membri attivi della comunità) coordinati in team, e che ci siano delle direttive sullo sviluppo che tengano conto degli input e dei feedback della comunità degli utenti. Questi feedback devono essere raccolti e vagliati attentamente per essere inclusi o meno nei futuri rilasci, motivando la scelta. L’ultima parola dovrebbe comunque spettare agli owner del progetto, poiché la community può fornire input divergenti e una decisione finale va presa.