Le aziende guadagnano con il software open source attraverso assistenza, servizi gestiti, sviluppo su commissione e prodotti costruiti attorno al codice. Possono anche finanziare o acquisire i progetti da cui dipendono. Porta risorse, e crea tensioni fra priorità commerciali e libertà di chi usa il software.

Il discorso nasce da un inconveniente personale: non riuscivo a usare il mio nuovo microfono su Linux come volevo, e per registrare stavo tornando su Windows. Da lì la domanda più larga: quanto dipendiamo dalle scelte di chi produce hardware, software e servizi?

Il microfono come esempio di dipendenza

Avevo comprato uno strumento per migliorare i contenuti e, sulla mia configurazione, non riuscivo ad avere l'esperienza che mi aspettavo. La frustrazione nasce dalla distanza fra quello che il prodotto può fare e quello che riesci a farci.

Parlo provocatoriamente di un microfono al «50%». Non è una misura della qualità audio: è come descrivevo la sensazione di avere funzioni bloccate nel mio ambiente.

Un problema di compatibilità non dimostra un accordo per escludere Linux. Mostra però quanto supporto, documentazione e disponibilità degli strumenti pesino sulla libertà concreta di scegliere un sistema.

Open source non significa lavoro non pagato

Sviluppare, verificare e mantenere software costa tempo. Chi programma deve poter sostenere il proprio lavoro, anche quando il codice ha una licenza aperta: è una cosa che nel dibattito si dimentica con disinvoltura.

I ricavi arrivano da supporto professionale, personalizzazioni, integrazione, gestione del servizio. Donazioni e finanziamenti contribuiscono, ma non sono l'unico modello.

Quindi non vedo una contraddizione automatica fra attività commerciale e open source. La domanda è che cosa viene venduto e quale libertà resta a chi usa il software.

Perché una grande azienda finanzia un progetto

Un'impresa può sostenere uno strumento che usa nei propri prodotti, pagare i manutentori o acquistare competenze già organizzate altrove. Spesso finanziare costa meno che ricostruire la stessa tecnologia da zero.

Non implica per forza il desiderio di bloccare il progetto prima che diventi competitivo. Esprimo quel timore, ma per attribuirlo a un'azienda specifica servirebbero prove sulle sue decisioni, e non le ho.

Il criterio che propongo è guardare agli effetti: il finanziamento rende il progetto più mantenibile? La governance resta comprensibile? Chi lo usa conserva accesso, possibilità di migrare e di collaborare?

Mozilla e i ricavi dagli accordi di ricerca

Porto l'esempio del rapporto fra Google e Mozilla, e conviene descriverlo con precisione: Mozilla riceve ricavi anche da accordi commerciali sulla ricerca, non da contributi assimilabili a donazioni.

La rendicontazione Mozilla spiega il ruolo di quegli accordi. E il fatto che un'azienda paghi un concorrente in un altro mercato non dimostra da solo che lo faccia per evitare accuse di monopolio: è un'ipotesi, non un fatto.

Resta interessante il problema della dipendenza economica: una fonte di ricavo può sostenere un'alternativa e insieme renderla sensibile alle decisioni di qualcun altro.

Red Hat e CentOS: distinguere le decisioni

Il discorso nasce anche dalle polemiche su CentOS e Red Hat, dove vanno separati due passaggi: il cambiamento di ruolo di CentOS Stream e la modifica del 2023 ai canali pubblici dei sorgenti collegati a RHEL.

Nel comunicato del 21 giugno 2023, Red Hat indica CentOS Stream come sede pubblica dei sorgenti, mantenendo l'accesso via portale per clienti e partner. Non è RHEL che diventa closed source.

Si può criticare l'effetto di quelle scelte sulle distribuzioni derivate e sull'accessibilità del processo — e la critica regge molto meglio se riguarda la decisione vera, senza confondere disponibilità, licenze e modello commerciale.

La libertà ha bisogno di alternative mantenute

Avere il codice permette di studiarlo, adattarlo e proseguire il progetto secondo la licenza. Non garantisce che esistano persone, tempo e risorse per farlo bene — e quasi sempre è quello il vincolo.

Per questo, quando dico che vorrei più open source per tutti, penso anche alla sostenibilità. Un'alternativa utile deve funzionare, essere documentata e ricevere manutenzione.

E non è inevitabile che un progetto aperto migliori con il tempo. La possibilità di trovare un errore deve tradursi in verifiche e correzioni vere, altrimenti resta una possibilità teorica.

Scegliere con più consapevolezza

Prima di affidarmi a un servizio voglio capire come si sostiene, che cosa posso esportare e quanto sarebbe difficile sostituirlo. E vorrei sostenere i progetti che uso, con contributi compatibili con quello che posso permettermi.

L'invito è a un po' di spirito critico: comodità e gratuità non esauriscono la valutazione. Modello di attività, supporto e possibilità di scelta fanno parte del prodotto quanto le funzioni che vedi sullo schermo.