Come una distribuzione GNU/Linux ha successo, parte 1: due esempi di lunga durata

Nel mondo delle distribuzioni GNU/Linux, molte fioriscono come l’erba e poi appassiscono. Nonostante i numerosi elementi di attrattiva, molte distribuzioni non hanno una forza duratura. Ma quelle che hanno avuto più successo condividono alcuni tratti chiave tra la loro grande diversità – l’ho scoperto durante la ricerca di questo articolo.
Tra le centinaia di distribuzioni di Linux (in breve), per questo articolo ne ho scelte due che sono durate per quasi tutta la storia del sistema operativo, si sono rafforzate nel corso dei decenni, hanno dato vita a distribuzioni figlie e ancora oggi alimentano un gran numero di siti: Red Hat e Debian. Questo articolo analizza il motivo per cui queste distribuzioni hanno avuto così tanto successo e hanno generato delle famiglie (Fedora e CentOS da Red Hat; Ubuntu e molte altre da Debian).
Due distribuzioni, Red Hat e Debian, sono nate nel 1993, appena un paio d’anni dopo che Linus Torwalds aveva presentato al mondo il suo kernel. Red Hat e Debian hanno rapidamente scalzato una manciata di progetti meno professionali come Slackware e SLS. Le nuove distribuzioni hanno preso strade molto diverse: Red Hat come azienda con una grande comunità di contributori e Debian come comunità i cui aspetti commerciali erano piuttosto secondari.
Oltre ai miei ricordi, questo articolo si basa su interviste con i seguenti leader del settore ed è stato revisionato da altri:
Scott McCarty, amministratore Red Hat di lunga data e attualmente product manager di Red Hat Enterprise Linux Server
.
Bruce Perens, una delle figure di spicco dell’open source e del software libero, il cui ruolo comprende la guida del progetto Debian e la co-fondazione della Open Source Initiative (OSI)
Matt Welsh, uno dei primi leader del Linux Documentation Project e co-autore del best-seller del 1996 Running Linux (con me come editor)
In termini di base di utenti, ovviamente, Android è la distribuzione Linux più popolare. La gente lo usa anche per scopi diversi dai telefoni di Google. Ma non tratterò Android in questa sede perché la sua storia e il suo ruolo nell’informatica sono così unici. In particolare, come sottolineato da Richard Stallman, fondatore e responsabile del progetto GNU, Android fa pochissimo uso dei comandi e degli strumenti utilizzati dalle altre distribuzioni, in particolare del compilatore e delle librerie GNU che rendono possibile l’esecuzione del sistema operativo da parte di altre distribuzioni (da qui il termine preferito per le distribuzioni: GNU/Linux).
Dalle mie interviste sono emersi i seguenti fattori chiave alla base del successo sia di Red Hat che di Debian:
Rispettare e soddisfare le esigenze della comunità
.
Seguire un processo professionale per sviluppare un prodotto affidabile
.
Creazione di un robusto sistema di packaging
Esplorerò questi e altri fattori correlati in questo articolo in due parti.
Rispettare e soddisfare le esigenze della comunità
Numerose aziende come Caldera hanno adottato un approccio aziendale convenzionale. Hanno preso software da vari fornitori e progetti open source per creare CD per i loro clienti. Era come costruire e vendere una camicia o una bicicletta. Certo, molte aziende ascoltano i clienti e si basano sulle loro innovazioni, come ha sottolineato il professore del MIT Sloan Eric von Hippel. Ma poche aziende si concentrano sulle comunità.
Ascoltare i collaboratori e gli utenti
Debian è stata basata sulla comunità fin dall’inizio ed è sempre rimasta tale. Questo le ha fatto guadagnare un’enorme fiducia, perché nessuno pensava che una mano aziendale potesse distorcere la volontà della comunità o trarre profitti ingiusti. La Free Software Foundation (FSF), un’organizzazione no-profit, è stata un importante sponsor iniziale di Debian. Sebbene Debian sia sempre stata un’iniziativa della comunità, all’inizio del progetto è stata creata una società per vendere i CD della distribuzione.
Secondo McCarty e Welsh, Red Hat è stata anche insolitamente – forse in modo unico, per un’azienda di software – attenta alla sua comunità fin dall’inizio. E questa comunità, come è stato riconosciuto, ha accettato l’azienda perché gli utenti sapevano che era necessaria un’entità aziendale per produrre i CD e distribuire la distribuzione al pubblico.
Collegarsi alle fonti del software
Ora lavoro come freelance per Red Hat e sono sempre stupito dalla quantità di tempo investita dal suo personale retribuito nei progetti della comunità: compilatori, pacchetti Python e JavaScript, strumenti di rete e altro ancora. Secondo un articolo del 2005, Red Hat decise in quel periodo di contribuire le proprie modifiche a monte e utilizzare il codice sorgente della comunità invece di fornire ai clienti correzioni specifiche per Red Hat. A loro volta, gli sviluppatori che utilizzano le versioni della comunità – Fedora e CentOS – apportano miglioramenti che vengono accettati in Red Hat Enterprise Linux, l’offerta commerciale.
Integrare il lavoro di un’azienda con la comunità upstream è ovviamente positivo per gli altri utenti di software libero e per le aziende che dipendono dal codice, ma Red Hat ne trae vantaggio anche perché non deve mantenere versioni biforcate. Un video di Dave Neary fornisce ulteriori informazioni su questa storica decisione.
James M. Whitehurst, che è stato presidente del consiglio di amministrazione di Red Hat dal 2007 al 2020, ha scritto un libro idealistico ed esortativo The Open Organization: Igniting Passion and Performance (che ha ispirato anche il sito web di Red Hat). In questo libro esorta tutte le aziende ad applicare i principi dell’open source, consentendo forme radicali di sperimentazione e condivisione delle informazioni. Nessuna azienda può seguire costantemente questi ideali, ma dal mio punto di vista di libero professionista, i dipendenti di Red Hat rimangono impegnati in un ambiente di lavoro egualitario e onesto.
Un attento equilibrio con il software proprietario
Debian dovette prendere una decisione molto difficile a metà degli anni ’90: se incorporare prodotti non liberi nella distribuzione o impegnarsi per principio a includere solo software libero (pur consentendo un repository separato dove gli utenti potessero scaricare strumenti proprietari popolari). L’antropologa E. Gabriella Coleman, nel suo libro Coding Freedom, spiega che all’epoca le altre distribuzioni erano percepite come un vantaggio perché includevano software proprietario che gli utenti apprezzavano.
Ma la comunità Debian si impegnò storicamente a includere solo software libero nella distribuzione Debian, in parte a causa dei suoi primi legami con la FSF. Le discussioni che hanno portato a questa decisione sono state condotte da Bruce Perens quando era capo del progetto Debian. L’impegno è diventato parte di un “contratto sociale” con la comunità del software libero. Naturalmente, Red Hat ha lo stesso approccio, fornendo una distribuzione totalmente open source e rendendo facile l’aggiunta di software proprietario se lo si desidera. 
Penso che l’impegno verso il software libero sia stata una decisione intelligente e lungimirante che ha rafforzato la comunità del software libero e, in ultima analisi, ha stimolato l’adozione diffusa delle distribuzioni. Le persone potevano fidarsi di tutto ciò che era contenuto nelle distribuzioni – non che tutto funzionasse sempre (il software non funziona così), ma che la comunità potesse mantenere il controllo sul software e dare priorità alle esigenze della comunità.
Perens ritiene che la costante attenzione alla politica da parte della leadership di Debian sia il fattore più importante del suo successo. Il dibattito in Debian è stato incorporato da Perens nelle Linee guida per il software libero di Debian, la definizione del progetto su quale software fosse abbastanza libero da far parte di Debian. Meno di un anno dopo, quel testo è diventato la Open Source Definition, che determina tutte le licenze approvate dall’OSI e ha valore di legge negli Stati Uniti.
La governance è necessaria
La leadership di Debian ha preso una direzione molto decisa nella costruzione della comunità: non solo vagliare i nuovi manutentori, ma guidarli attraverso quello che si potrebbe definire un processo di auto-scoperta per assicurare il loro impegno verso il software libero e i processi comunitari associati. La Coleman dedica molto tempo al processo di selezione dei nuovi manutentori (NMP), come veniva chiamato all’epoca. (Poiché il suo libro è uscito nel 2013, il processo è probabilmente molto diverso oggi).
Il NMP prevedeva una serie di saggi che spiegavano le motivazioni che spingevano lo sviluppatore a diventare manutentore e che illustravano, con le parole dello sviluppatore stesso, il suo rapporto con il software libero. Sono coinvolti anche compiti logistici come l’adesione alla rete di fiducia di Debian.
Come Coleman descrive l’NMP, sembra quasi un’iniziazione a una setta. Ma è meglio se paragonata alla frequenza di una scuola di specializzazione. Se si passano da tre a sei anni a studiare storia, biologia o legge, si è costretti a ripercorrere le strade intraprese da altri prima di noi e ad assorbire i loro processi di pensiero. Si spera di poterne raccogliere le abitudini e l’impegno per una ricerca rigorosa. C’è una ragione per cui le materie della scuola di specializzazione sono chiamate discipline. Penso che l’NMP di Debian cerchi di instillare questo tipo di disciplina in un tempo relativamente breve.
In ogni caso, Debian ha sviluppato organicamente un sistema per l’inserimento di nuovi talenti, un requisito fondamentale per qualsiasi progetto.
Secondo Perens, il progetto Debian è andato oltre e ha decentralizzato lo sviluppo dei 15-20 pacchetti necessari per costruire il sistema operativo, in modo che i pezzi potessero essere sviluppati da persone in diverse parti del mondo senza un manager in comune.
Le mailing list di Debian sono state spesso criticate per i messaggi sgradevoli che vi si trovano. Il libro di Coleman fa eco a queste critiche. Ma quando ho partecipato alla conferenza Debian del 2010, ho trovato un bel gruppo di persone che si divertivano e che tenevano molto a lavorare bene come comunità. Ho pensato che dovevano migliorare la durezza della cultura online, ma che fondamentalmente erano volontari appassionati che volevano solo il massimo impegno da parte di tutti.
E che dire di Fedora? Certamente è una distribuzione utile da caricare sul proprio computer personale se si lavora per un’organizzazione che utilizza Red Hat Enterprise Linux. Ma McCarty mi dice che Fedora è molto più diffusa di così. Ha una comunità indipendente che la preferisce per i suoi meriti.
Il ruolo delle conferenze
Come nota finale sulla comunità, le conferenze sono importanti per riunire le comunità. Debian organizza conferenze in ogni continente, spostando ogni anno la sua conferenza annuale. La Fedora Contributor Conference (Flock) e la DevConf svolgono ruoli simili per gli sviluppatori e gli utenti di Fedora e Red Hat.
Coleman offre una splendida descrizione di una conferenza che fa davvero intuire cosa significhi esserci. Tuttavia, non spiega un altro punto importante: le conferenze sono fondamentali per le discussioni a livello di vertice che definiscono la direzione della comunità per l’anno successivo.
La seconda parte dell’articolo esplora gli altri due fattori del successo di Red Hat e Debian e li confronta con un paio di altre distribuzioni Linux.
 
Leggi il prossimo articolo di questa serie