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\u00f9 successo condividono alcuni tratti chiave tra la loro grande diversit\u00e0 – l’ho scoperto durante la ricerca di questo articolo.
\nTra 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\u00ec tanto successo e hanno generato delle famiglie (Fedora e CentOS da Red Hat; Ubuntu e molte altre da Debian).
\nDue 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\u00e0 di contributori e Debian come comunit\u00e0 i cui aspetti commerciali erano piuttosto secondari.
\nOltre ai miei ricordi, questo articolo si basa su interviste con i seguenti leader del settore ed \u00e8 stato revisionato da altri:
\nScott McCarty, amministratore Red Hat di lunga data e attualmente product manager di Red Hat Enterprise Linux Server
\n.
\nBruce 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)
\nMatt Welsh, uno dei primi leader del Linux Documentation Project e co-autore del best-seller del 1996 Running Linux (con me come editor)
\nIn termini di base di utenti, ovviamente, Android \u00e8 la distribuzione Linux pi\u00f9 popolare. La gente lo usa anche per scopi diversi dai telefoni di Google. Ma non tratter\u00f2 Android in questa sede perch\u00e9 la sua storia e il suo ruolo nell’informatica sono cos\u00ec 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).
\nDalle mie interviste sono emersi i seguenti fattori chiave alla base del successo sia di Red Hat che di Debian:
\nRispettare e soddisfare le esigenze della comunit\u00e0
\n.
\nSeguire un processo professionale per sviluppare un prodotto affidabile
\n.
\nCreazione di un robusto sistema di packaging
\nEsplorer\u00f2 questi e altri fattori correlati in questo articolo in due parti.
\nRispettare e soddisfare le esigenze della comunit\u00e0
\nNumerose 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\u00e0.
\nAscoltare i collaboratori e gli utenti
\nDebian \u00e8 stata basata sulla comunit\u00e0 fin dall’inizio ed \u00e8 sempre rimasta tale. Questo le ha fatto guadagnare un’enorme fiducia, perch\u00e9 nessuno pensava che una mano aziendale potesse distorcere la volont\u00e0 della comunit\u00e0 o trarre profitti ingiusti. La Free Software Foundation (FSF), un’organizzazione no-profit, \u00e8 stata un importante sponsor iniziale di Debian. Sebbene Debian sia sempre stata un’iniziativa della comunit\u00e0, all’inizio del progetto \u00e8 stata creata una societ\u00e0 per vendere i CD della distribuzione.
\nSecondo McCarty e Welsh, Red Hat \u00e8 stata anche insolitamente – forse in modo unico, per un’azienda di software – attenta alla sua comunit\u00e0 fin dall’inizio. E questa comunit\u00e0, come \u00e8 stato riconosciuto, ha accettato l’azienda perch\u00e9 gli utenti sapevano che era necessaria un’entit\u00e0 aziendale per produrre i CD e distribuire la distribuzione al pubblico.
\nCollegarsi alle fonti del software
\n Ora lavoro come freelance per Red Hat e sono sempre stupito dalla quantit\u00e0 di tempo investita dal suo personale retribuito nei progetti della comunit\u00e0: 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\u00e0 invece di fornire ai clienti correzioni specifiche per Red Hat. A loro volta, gli sviluppatori che utilizzano le versioni della comunit\u00e0 – Fedora e CentOS – apportano miglioramenti che vengono accettati in Red Hat Enterprise Linux, l’offerta commerciale.
\nIntegrare il lavoro di un’azienda con la comunit\u00e0 upstream \u00e8 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\u00e9 non deve mantenere versioni biforcate. Un video di Dave Neary fornisce ulteriori informazioni su questa storica decisione.
\nJames M. Whitehurst, che \u00e8 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\u00f2 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.
\nUn attento equilibrio con il software proprietario
\nDebian dovette prendere una decisione molto difficile a met\u00e0 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\u00e9 includevano software proprietario che gli utenti apprezzavano.
\nMa la comunit\u00e0 Debian si impegn\u00f2 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 \u00e8 diventato parte di un “contratto sociale” con la comunit\u00e0 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.\u00a0
\nPenso che l’impegno verso il software libero sia stata una decisione intelligente e lungimirante che ha rafforzato la comunit\u00e0 del software libero e, in ultima analisi, ha stimolato l’adozione diffusa delle distribuzioni. Le persone potevano fidarsi di tutto ci\u00f2 che era contenuto nelle distribuzioni – non che tutto funzionasse sempre (il software non funziona cos\u00ec), ma che la comunit\u00e0 potesse mantenere il controllo sul software e dare priorit\u00e0 alle esigenze della comunit\u00e0.
\nPerens ritiene che la costante attenzione alla politica da parte della leadership di Debian sia il fattore pi\u00f9 importante del suo successo. Il dibattito in Debian \u00e8 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 \u00e8 diventato la Open Source Definition, che determina tutte le licenze approvate dall’OSI e ha valore di legge negli Stati Uniti.
\nLa governance \u00e8 necessaria
\nLa leadership di Debian ha preso una direzione molto decisa nella costruzione della comunit\u00e0: 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\u00e9 il suo libro \u00e8 uscito nel 2013, il processo \u00e8 probabilmente molto diverso oggi).
\nIl 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.
\nCome Coleman descrive l’NMP, sembra quasi un’iniziazione a una setta. Ma \u00e8 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 \u00e8 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’\u00e8 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.
\nIn ogni caso, Debian ha sviluppato organicamente un sistema per l’inserimento di nuovi talenti, un requisito fondamentale per qualsiasi progetto.
\nSecondo Perens, il progetto Debian \u00e8 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.
\nLe 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\u00e0. 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.
\nE che dire di Fedora? Certamente \u00e8 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 \u00e8 molto pi\u00f9 diffusa di cos\u00ec. Ha una comunit\u00e0 indipendente che la preferisce per i suoi meriti.
\nIl ruolo delle conferenze
\n Come nota finale sulla comunit\u00e0, le conferenze sono importanti per riunire le comunit\u00e0. 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.
\nColeman 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\u00e0 per l’anno successivo.
\nLa 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.
\n\u00a0
\nLeggi il prossimo articolo di questa serie<\/p>\n","protected":false},"excerpt":{"rendered":"