L'impegno di Red Hat verso l'open source: una risposta alle modifiche di git.centos.org

Ho trascorso buona parte del fine settimana a camminare e a riflettere sulla reazione scatenata dal mio recente articolo del blog. Ci hanno definito malvagi, e io sono stato accusato di essere un dirigente IBM infiltrato a cui è stato affidato il ruolo di trasformare Red Hat in un sistema "closed source". E questa è solo una minima parte delle accuse. Intendo chiarire le cose. 

Mi chiamo Mike McGrath e sono Vice President di Core Platforms Engineering presso Red Hat. Sono qui da 16 anni, ma prima di assumere questo ruolo sono stato un volontario del progetto Fedora. L'open source e tutto ciò che questo concetto implica hanno per me un'enorme importanza. La scorsa settimana, molte persone hanno detto cose scortesi e false sui dipendenti Red Hat che, come me, amano questo lavoro fino in fondo.

A dispetto delle voci che attualmente circolano su Red Hat, i risultati del nostro duro lavoro sono accessibili anche ai non clienti. Red Hat utilizza e utilizzerà sempre un modello di sviluppo open source. Quando troviamo un errore o scriviamo una funzionalità, condividiamo il codice con la community upstream, e ciò va a vantaggio di tutti i membri della community, non solo di Red Hat e dei nostri clienti.  

Non ci limitiamo a prendere i pacchetti upstream e a ricompilarli. Per andare incontro alle esigenze di clienti e partner, le migliaia di persone che lavorano in Red Hat dedicano il loro tempo a scrivere codici per nuove funzionalità, a correggere errori, a integrare pacchetti diversi per i quali offrono quindi assistenza a lungo termine. 

Dedichiamo ore e nottate al backporting di una patch per un codice che ha ormai più di 5/10 anni; supportiamo 3 o 4 flussi di release principali, e a tutti applichiamo patch e backport. Inoltre, le correzioni che sviluppiamo per i problemi di RHEL non sono applicate solo a RHEL, ma prima vengono distribuite upstream, a progetti quali Fedora, CentOS Stream o al progetto del kernel stesso, e poi estese con il backporting. Offrire manutenzione e assistenza a un sistema operativo per 10 anni è un compito arduo, ed è difficile quantificare l'enorme valore del nostro lavoro.

Continueremo a inviare il nostro codice upstream e a rispettare le licenze open source utilizzate dai nostri prodotti, inclusa la GPL. Quando dico che rispettiamo le varie licenze open source applicabili al nostro codice, dico sul serio. Sono rimasto colpito e deluso dal numero di persone che ha dato un'interpretazione sbagliata a proposito del software open source e della GPL in particolare, in particolare gli analisti e gli esperti di settore, che ritengo dovrebbero saperne di più. Questi dettagli, incluse le licenze e i diritti open source, hanno un grande valore che Red Hat ha contribuito non solo a creare, ma anche a preservare e a far crescere. 

Penso che molto del disappunto suscitato dalla nostra recente decisione in merito alla distribuzione downstream dei codici sorgente provenga da chi non è disposto a pagare per il tempo, l'impegno e le risorse che destiniamo a RHEL, o da chi desidera creare nuovi pacchetti per il proprio profitto. Ritengo ipocrita la richiesta di codice RHEL da parte di queste persone. 

Red Hat deve pagare chi fa questo lavoro, quei collaboratori appassionati che lavorano per ore e ore e che credono nei valori dell'open source. Ricompilare il codice creato dai nostri collaboratori per poi rivenderlo così com'è, senza alcun valore aggiunto, rende insostenibile la produzione del software open source nelle sue varie fasi, incluse le attività di backporting strategiche e le funzionalità e le tecnologie future che vengono sviluppate upstream. Se questo lavoro non sarà più sostenibile, verrà interrotto, con ripercussioni negative per tutti.

Mi riferisco in particolare alle ricompilazioni, diverse dalle distribuzioni che possono, ad esempio, aggiungere una nuova architettura o un flag di compilazione. Red Hat offre supporto completo per espandere le funzionalità di Linux, non per imitarle. 

Non molto tempo fa, Red Hat attribuiva un valore al lavoro svolto da ricompilatori come CentOS. Inviavamo i nostri SRPM a git.centos.org in un semplice pacchetto che ne agevolava la ricompilazione; abbiamo persino tolto il nostro marchio. Più di recente, abbiamo stabilito che non conveniva avere un ricompilatore downstream. 

L'opinione generalmente accettata secondo cui queste ricompilazioni gratuite non sono altro che un modo per sfornare esperti in RHEL e trasformarsi in vendite non corrisponde al vero. Vorrei vivere in un mondo così, ma la realtà è ben diversa. C'è invece un gruppo di utenti, molti dei quali appartengono a organizzazioni IT di grandi dimensioni, che vuole i vantaggi della stabilità, del ciclo di vita e dell'ecosistema hardware di RHEL, senza dover effettivamente sostenere i costi del servizio di manutenzione, degli ingegneri, degli autori di contenuti e tutte le altre figure professionali che ci lavorano. Questi stessi utenti hanno anche deciso di non utilizzare nessuna delle tante altre distribuzioni Linux in circolazione.

In un ecosistema open source sano, concorrenza e innovazione procedono di pari passo. Red Hat, SUSE, Canonical, AWS e Microsoft creano distribuzioni Linux con il proprio marchio, impegnandosi in iniziative volte allo sviluppo dell'ecosistema. Tutte queste varianti utilizzano e contribuiscono al codice sorgente Linux, ma nessuna pretende di essere "completamente compatibile" con le altre.

Infine, non otteniamo alcun valore da una ricompilazione di RHEL e Red Hat non ha alcun obbligo di semplificare le cose ai ricompilatori; questa è una decisione che spetta solo a noi. Arrivo quindi a CentOS Stream, al cui riguardo c'è un'immensa confusione. Riconosco che siamo di fronte a un cambiamento epocale di una tradizione di lunga data, e cambiamenti di questo genere possono creare grande confusione, che nel nostro caso si è manifestata con le accuse di voler diventare "closed source" e delle presunte violazioni alla licenza GPL. CentOS Stream esiste come file binario distribuibile ma anche come repository sorgente. Il codice sorgente gitlab CentOS Stream è quello utilizzato per realizzare le release di RHEL, è aperto e disponibile a tutti gli utenti. Perciò, definire RHEL "closed source" è assolutamente falso ed errato. CentOS Stream è più veloce rispetto a RHEL, perciò potrebbe non essere presente su HEAD, ma il codice è lì. Se non lo trovi, si tratta di un bug e ti chiediamo di comunicarcelo.

Gratuitamente, sono inoltre disponibili le sottoscrizioni Red Hat Developer e Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure. La sottoscrizione per gli sviluppatori offre gratuitamente RHEL agli sviluppatori, che possono utilizzare, sempre gratuitamente, fino a 16 sistemi. Il sistema può essere utilizzato dai singoli utenti per il proprio lavoro e dai clienti RHEL per il lavoro dei propri dipendenti.  RHEL for Open Source Infrastructure ha l'obiettivo di fornire alle iniziative open source (affiliate o meno a Red Hat) l'accesso gratuito a RHEL per le esigenze di sviluppo e infrastruttura.

Infine, vorrei rivolgermi a tutte le aziende open source, sia quelle che si avvalgono già ora di codice open, sia quelle che stanno pensando di passare a un modello open source. Red Hat ha creato questo modello, e mi auguro che tante aziende open source abbiano il successo che abbiamo avuto noi. Puoi decidere in autonomia se le ricompilazioni downstream sono utili per te e solo tu puoi stabilire se semplificare le cose oppure no. 

La semplice ricompilazione del codice, senza apportare modifiche né aggiungere valore, rappresenta una minaccia reale per le aziende che si occupano di open source, in tutto il mondo. È un pericolo concreto, in quanto può potenzialmente riportare l'open source a un'attività riservata a dilettanti e hacker.

Non è questa la nostra intenzione, e non è quella dei membri della community, dei clienti e dei partner. L'innovazione inizia upstream. Costruire su quanto già fatto da altri è la natura stessa dell'open source. Continuiamo a promuovere l'innovazione, sostenendoci a vicenda e guardando sempre avanti.