conundrum

il primo Luglio, contrariamente alle mie aspettative, sono stato eletto insieme ad altre sei persone a far parte della Board of Directors della Fondazione GNOME.

GNOME: Gnu's Not Unix Network Object Model Environment. Well, at least the first thing's still true.

la direzione tecnica del progetto non è tra i compiti della Fondazione: per quello ci si affida ai maintainer dei vari moduli, e al release team per quanto riguarda l’integration and release management; non che si possa dare una qualsivoglia forma di “direzione tecnica” in un progetto complesso come Gnome: come posso costringere i maintainer di — ad esempio — Evince e EoG a cambiare radicalmente l’intento e scopo dei loro due progetti? mica vengono pagati dalla Fondazione.

detto questo, parte della mia “piattaforma elettorale” era, ed è, incentrata sull’idea che Gnome debba crescere e piantarla di essere un desktop environment — cosa che ha cessato di essere se non nel nome da quasi dieci anni a questa parte.

l’idea che si possa scrivere un desktop in isolamento da quanto avviene dal kernel in su, e dalle applicazioni in giù, è ridicola e infantile. esattamente come l’idea che si possano cambiare pezzi a costo zero senza che il risultato cambi, o che tutto quanto debba essere realizzato usando astrazioni per minimizzare l’impatto di cambiare i pezzi. entrambe sono posizioni che non reggono la prova dei fatti — posizioni che possono funzionare se si vive nel mondo dei sogni in cui le decisioni sono interamente dettate da dettagli tecnici; oppure se non si è mai dovuto creare un prodotto. in entrambi i casi, nella stanzetta adiacente, Babbo Natale e la Fatina dai Capelli Turchini vi spiegheranno che il mondo non funziona così, e che essere il nuovo Enlightenmen 17 non garantisce a varia gente di campare.

l'architecture diagram di Gnome 4.0

esistono anche ragioni tecniche, ovviamente, per non voltronizzare un progetto; scrivere astrazioni risulta in perdita di tempo, performance e alla fine risulta in costi di mantenimento superiori: invece di mantenere una sola superficie di contatto tra due pezzi indipendenti (ognuno con i suoi limiti e bug), dobbiamo mantenerne due, con tre pezzi, di cui uno interdipendente. insomma, come fare il giocoliere con tre palle, di cui una piena di nitroglicerina.

tutto questo per quale motivo, poi? per poter garantire “libertà”?

garantire quale libertà? e a chi, poi?

la libertà garantita da una licenza FSF o OSI-approved non implica che qualunque cosa io scriva debba essere interoperabile con qualunque pezzo di codice in esistenza; se scrivo una libreria per leggere e scrivere JSON che usa come base GLib mica devo anche scrivere la parte che funziona con le Qt: sarebbe eminentemente stupido.

come nei cicli di sviluppo - totally fucking amazing: n / 2 + 1. quality: n / 2.

scrivere un’interfaccia grafica che permetta all’utente di portare a termine un lavoro ha centinaia di dipendenze: kernel, driver, API per spedire pixel verso il monitor, API per ricevere input da tastiera, touchscreen o mouse; networking, device discovery, color management, graphics system; ognuna di queste si porta dietro le sue richieste e le sue dipendenze — e tutto questo va preso in considerazione come un unico blocco quando si vuole andare a definire una piattaforma per scrivere applicazioni. esistono standard, ma di solito sono troppo a basso livello per essere anche solo remotamente utili per scrivere un sistema operativo moderno. un sistema operativo che riesca a reggere la competizione, che scali verso le piattaforme mobili, e verso il computing condiviso e distribuito.

hipster gnome loves focus follows mouse

continuare a guardarci l’ombelico non aumenta la libertà degli utenti; né, ancora peggio, aumenta il numero di utenti — ovvero il pool da cui il progetto trae nuove risorse per scrivere applicazioni e componenti.

ovviamente, perdere i pochi utenti che abbiamo può essere visto come ancora peggio — ma siamo seri: perdere gli hipster per strada non è quasi mai una gran brutta cosa.

tutto questo rambling porta a Gnome OS — ovvero: prendere atto che stiamo scrivendo un sistema operativo; non una distribuzione: dovremmo essere stupidi per scrivere una distro nel 2011. un sistema operativo non è una distribuzione, nonostante alcuni tentino di farlo passare come tale; fare packaging del software è una cosa che esiste solo nel mondo del desktop Linux — e di solito serve solo per dare l’idea che chi impacchetta software stia contribuendo in maniera costruttiva allo sviluppo dell’open source.

intendere Gnome come un sistema operativo significa pensare che i progetti che compongono Gnome, e le loro dipendenze, siano trattati come un’unica struttura; una serie di garanzie per scrivere applicazioni, una developer experience che porti a una user experience consistente e professionale — il tutto sviluppato sotto gli occhi di tutti. il ché non significa “con il contributo di tutti”, bensì “aperto a tutti”.

non è per nulla banale, e la potenziale hubris di questa operazione è probabilmente misurabile sulla stessa scala delle migliori tragedie greche. ditemi, però, che non ne valga la pena. ditemi che bisognerebbe rimanere a fare un desktop environment per quelli che usano l’interfaccia grafica per lanciare trenta terminali e un browser. ditemi che bisogna accontentarsi del 2% degli utenti, oppure che bisognerebbe far diventare tutti quanti dei nerd inveterati.

ditemelo pure. mi scuso in anticipo se me ne andrò ridendo.