Il 6 maggio 2026, Sonatype e i principali gestori di registri di pacchetti hanno fondato il Sustaining Package Registries Working Group sotto la Linux Foundation. L’annuncio, sulla carta, sembra una buona notizia — finalmente qualcuno si preoccupa della sostenibilità dell’infrastruttura su cui gira tutto il software del pianeta. Peccato che arrivi dopo decenni di saccheggio. I download di pacchetti open source hanno raggiunto i 10.000 miliardi nel 2025 — dieci trilioni, un numero talmente grande da perdere significato — e l’82% del consumo di Maven Central, il repository cardine dell’ecosistema Java, proviene da meno dell’1% degli indirizzi IP mondiali. Chi sono quei pochi indirizzi? Indovina: l’80% del traffico arriva dai server di AWS, Azure e Google Cloud. Tre aziende con una capitalizzazione combinata che supera gli 8.000 miliardi di dollari consumano la banda, scaricano i pacchetti, costruiscono servizi commerciali sopra codice scritto da volontari. E quei volontari non vedono un centesimo.
La portata del problema si è materializzata con violenza a marzo 2026, quando Kubernetes ha ritirato Ingress NGINX — il componente più diffuso nell’intero ecosistema cloud-native, presente nel 50% degli ambienti di produzione — perché era mantenuto da una o due persone nei ritagli di tempo. Al CfgMgmtCamp di Gent, a febbraio, l’avvocato Richard Fontana di Red Hat ha parlato del “paradosso dello sfruttamento nell’open source”: i principi costruiti per massimizzare la libertà creano inevitabilmente nuovi punti di leva per chi ha potere e risorse. Non è un paradosso. È un sistema che funziona esattamente come è stato progettato — non dai programmatori, ma dal mercato che li parassita.
Il saccheggio invisibile: i numeri dello sfruttamento
Le big tech non “usano” l’open source. Lo estraggono. Come si estrae il coltan in Congo — con la differenza che qui la miniera è fatta di persone che scrivono codice dopo cena, nei weekend, durante le ferie. Il meccanismo è semplice e brutale: le licenze permissive (MIT, Apache 2.0, BSD) consentono a qualsiasi azienda di prendere codice libero, integrarlo nei propri prodotti commerciali, e rivenderne i frutti senza restituire nulla alla comunità. Zero obbligo di contribuzione, zero obbligo di finanziamento. AWS ha costruito Amazon OpenSearch Service prendendo Elasticsearch e offrendolo come servizio gestito, generando centinaia di milioni di dollari mentre Elastic non vedeva un centesimo ed era costretta a cambiare licenza per sopravvivere. Google utilizza migliaia di componenti open source nei propri servizi, dalla ricerca a YouTube a Google Cloud — e quando sponsorizza un progetto, lo fa con cifre che per le sue casse equivalgono a spiccioli dimenticati nella tasca di una giacca. Microsoft — la stessa azienda che nel 2001, per bocca di Steve Ballmer, definiva Linux un “cancro” — oggi possiede GitHub, la piattaforma dove vive la maggior parte del codice open source del mondo, e ne ha sfruttato l’ecosistema per addestrare Copilot, il suo assistente AI per la programmazione, raccogliendo miliardi di righe di codice scritte da sviluppatori che non hanno mai acconsentito a diventare dati di addestramento. Il codice scritto gratis dai maintainer torna indietro sotto forma di prodotto a pagamento. La spirale è questa, e non si inverte per buona volontà.
I numeri rendono l’ingiustizia tangibile. Il 60% dei maintainer open source lavora senza alcun compenso. Il 44% ha abbandonato o considerato seriamente di abbandonare i propri progetti per burnout — percentuale che sale al 58% tra chi mantiene software ad alta diffusione, quei pacchetti da cui dipendono catene intere di altre librerie. Più della metà dei pacchetti su npm è nelle mani di un singolo contributore. Brian Fox, CTO di Sonatype, il 6 maggio scorso ha detto senza mezzi termini che “i registri open source non sono più punti di distribuzione passivi, ma sistemi operativi e critici per la sicurezza”. Parole giuste. Peccato che le aziende che più dipendono da questi sistemi non agiscano di conseguenza. La somma che Google, Amazon, Microsoft, Anthropic e OpenAI hanno promesso collettivamente alla sicurezza dell’open source ammonta a 12,5 milioni di dollari, gestiti da Alpha-Omega e dalla OpenSSF. Facciamo due conti che valgono più di qualsiasi analisi: 12,5 milioni divisi per cinque sono 2,5 milioni a testa. Il valore di mercato di Microsoft da solo supera i 3.000 miliardi. Stiamo parlando dello 0,00008% — meno di quanto spendono per le trasferte dei dirigenti in un trimestre. Non è filantropia, è marketing.
Il paradosso strutturale è perverso: più un progetto open source ha successo, più cresce il carico su chi lo mantiene — bug report, richieste di funzionalità, patch di sicurezza, compatibilità con nuove versioni, documentazione, gestione della community — senza che cresca il supporto. Il successo, nell’open source, premia chi prende, non chi crea. Come abbiamo già analizzato parlando del paradosso di Linux nel cloud, i profitti del software libero finiscono sistematicamente nelle tasche di chi lo sfrutta commercialmente. La differenza è che nel 2026 il problema non è più ignorabile: il Sustaining Package Registries Working Group nasce proprio perché i registri — Maven Central, npm, PyPI — rischiano il collasso sotto il peso di una domanda che cresce in modo esponenziale, alimentata anche dal traffico automatizzato dei bot e degli strumenti AI, mentre i finanziamenti restano simbolici. Christopher Robinson, CTO della Open Source Security Foundation, definisce i registri “la prima linea della sicurezza della supply chain software”. Ha ragione, ma in prima linea ci sono volontari mandati allo sbaraglio, non ingegneri stipendiati. E il fronte si sta sgretolando.
Quando crolla chi regge il mondo
La storia di Ingress NGINX è un caso da manuale. A novembre 2025 Kubernetes annuncia il ritiro del controller: data di fine vita, marzo 2026. Da quel momento, niente più release, niente bugfix, niente patch di sicurezza. Il componente più usato dell’ecosistema cloud-native — installato, secondo i dati interni di Datadog, nel 50% degli ambienti di produzione mondiali — sparisce dalla mappa perché chi lo manteneva non ce la faceva più. Non due o tre team di ingegneri: una, massimo due persone, che ci lavoravano la sera e nei weekend, come hobby. Per anni il Kubernetes Security Response Committee ha cercato di attirare attenzione e risorse, senza risultato. La valanga di bug, richieste di feature e segnalazioni di sicurezza ha sepolto i maintainer sotto un carico insostenibile. A un certo punto il debito tecnico accumulato ha reso il progetto un rischio per la sicurezza — configurazioni che un tempo erano considerate funzionalità utili si sono trasformate in vulnerabilità gravi, come la possibilità di aggiungere direttive NGINX arbitrarie tramite annotazioni. E così un pezzo fondamentale dell’infrastruttura internet globale ha semplicemente smesso di esistere. Non con il botto, ma con un sospiro di esaurimento.
L’episodio si inserisce in una serie di disastri che dovrebbero togliere il sonno a chiunque lavori nel settore. Aprile 2024: la backdoor in xz-utils (CVE-2024-3094). Un attaccante sotto lo pseudonimo di Jia Tan ha passato due anni — due anni di paziente infiltrazione — a guadagnarsi la fiducia del maintainer solitario di questa libreria di compressione presente in ogni distribuzione Linux. Social engineering chirurgico, che sfruttava esattamente il tallone d’Achille strutturale dell’open source: la dipendenza da individui isolati, sovraccarichi, senza risorse e senza nemmeno un collega a cui chiedere una revisione. La backdoor avrebbe dato all’attaccante accesso root remoto a qualsiasi server Linux compromesso, attraverso OpenSSH. Se Andres Freund, ingegnere di Microsoft, non si fosse insospettito per un rallentamento di mezzo secondo nei login SSH, il codice maligno sarebbe finito in ogni server del pianeta. Non è fantascienza — è passato per un pelo. E la cosa ancora più inquietante? Ad agosto 2025, oltre un anno dopo la scoperta, i ricercatori hanno trovato 35 immagini Docker Hub — comprese build Debian — che ancora contenevano la versione compromessa. La fragilità della supply chain open source non è un rischio teorico: è un fatto documentato, con conseguenze che si trascinano per anni.
Prima di xz-utils c’era stato Log4Shell, dicembre 2021. Una vulnerabilità critica in Log4j, libreria di logging Java usata da mezzo mondo — Apple, Amazon, Tesla, la NASA, sistemi governativi di decine di paesi. Il progetto era mantenuto da un pugno di volontari. Ralph Goers, il maintainer principale, ci lavorava nel tempo libero senza retribuzione. Quando la vulnerabilità è esplosa e il panico ha investito l’industria, il mondo intero ha preteso una patch immediata da un uomo che non veniva pagato per il suo lavoro. La scena è grottesca se ci pensi: multinazionali da migliaia di miliardi in coda per la correzione da un tizio che patcha codice dal salotto di casa. Ma nel 2026 la situazione è peggiorata, perché l’intelligenza artificiale ha aggiunto un nuovo livello di pressione sui maintainer. Gli strumenti AI permettono ora di generare segnalazioni di vulnerabilità su scala industriale, ma la stragrande maggioranza sono spazzatura — report automatici, mal formulati, spesso completamente errati, che seppelliscono le segnalazioni legittime sotto tonnellate di rumore digitale. Per un maintainer già esausto, è un pagliaio che qualcuno continua a riempire di paglia mentre tu cerchi l’ago. L’AI generativa — nata anche dal codice open source, vale la pena ricordarlo — non sta aiutando chi quel codice lo scrive. Sta accelerando il collasso.
Licenze, fondi e false rivoluzioni
La risposta del mercato alla crisi è stata, fin qui, una combinazione di cambio licenza e carità pelosa. Partiamo dalle licenze. HashiCorp — creatore di Terraform e Vault, strumenti fondamentali per l’infrastruttura cloud — nell’agosto 2023 è passata dalla Mozilla Public License alla Business Source License (BSL). Elastic aveva abbandonato Apache 2.0 per la Server Side Public License (SSPL) nel 2021, dopo che AWS aveva lanciato il proprio servizio Elasticsearch gestito senza contribuire al progetto originale. MongoDB aveva fatto la stessa mossa nel 2018. Il messaggio era chiaro: le licenze permissive non ti proteggono da chi ha abbastanza soldi e ingegneri per parassitare il tuo lavoro. Ma — e qui sta il punto che molti analisti sorvolano — la SSPL e la BSL non sono licenze open source. L’Open Source Initiative non le riconosce come tali: sono “source available”, puoi vedere il codice ma non puoi farci quello che vuoi. Il software libero nato per essere un bene comune diventa proprietà di un’azienda che decide le regole del gioco. Non è emancipazione, è privatizzazione con la coscienza a posto.
Il caso Redis mostra quanto sia confuso e disperato il panorama. A marzo 2024 Redis Labs abbandona la licenza BSD per la SSPL, scatenando le proteste della comunità e la nascita del fork Valkey sotto l’ombrello della Linux Foundation — con il supporto, guarda caso, di AWS, Google ed Ericsson, le stesse aziende che col loro sfruttamento avevano spinto Redis alla resa. Poi, a maggio 2025, retromarcia clamorosa: Redis 8 torna sotto AGPLv3, una licenza genuinamente open source che però obbliga chi offre il software come servizio a rilasciare il codice delle proprie modifiche. Il ping-pong delle licenze rivela una verità scomoda: nessuno ha trovato un modello che funzioni davvero. I maintainer restano schiacciati tra la gratuità totale delle licenze permissive — che li espone al saccheggio — e la privatizzazione del proprio lavoro tramite licenze restrittive che tradiscono lo spirito originale del software libero. La soluzione, se esiste, non sta nel diritto d’autore. Sta nella struttura economica.
E i fondi? A febbraio 2026 è nato l’Open Source Endowment, presentato come “il primo fondo di dotazione al mondo per il software open source”. L’idea è quella dell’endowment universitario: si raccolgono contributi, si investono, si distribuiscono solo i profitti degli investimenti come grant ai maintainer. Tra i fondatori ci sono i creatori di cURL, Elastic, Nginx, Vue.js, ClickHouse — gente che conosce sulla propria pelle cosa significa mantenere un progetto critico senza un euro. Nobile. Peccato che il fondo abbia raccolto circa 700.000 dollari. Per contestualizzare: è quanto guadagna un singolo ingegnere senior a Google in un anno tra stipendio, bonus e stock option. Con quella cifra non mantieni nemmeno un progetto critico, figuriamoci l’intera infrastruttura software del pianeta. Il Sustaining Package Registries Working Group della Linux Foundation è un tentativo nella stessa direzione — modelli di finanziamento sostenibili, governance condivisa, difesa coordinata — ma con lo stesso limite strutturale: si chiede al mercato di autoregolarsi, si prega chi trae profitto di contribuire volontariamente. La storia ci dice come va a finire. L’elemosina non è un modello economico.
Il nocciolo della questione è politico, non tecnico né giuridico. L’open source è un bene comune — un commons digitale che funziona come i pascoli comuni descritti da Elinor Ostrom, con la differenza che qui i grandi proprietari terrieri non recintano il prato ma pretendono che i contadini continuino a coltivarlo gratis. La soluzione non verrà dall’alto, non dalle stesse aziende che traggono profitto dallo status quo. Le alternative esistono, ma richiedono un ribaltamento di prospettiva radicale. Cooperative di sviluppo software — come Igalia in Spagna, che da vent’anni contribuisce a browser, standard web e kernel Linux con un modello cooperativo che funziona e genera profitto senza padroni. Infrastrutture di calcolo gestite dalle comunità, non dagli hyperscaler — un tema che abbiamo approfondito analizzando i rischi del cloud centralizzato. Tassazione sull’uso commerciale massivo del software libero — un’idea che farebbe urlare i libertarian della Silicon Valley ma che ha una logica stringente: se usi gratis qualcosa che vale miliardi, restituisci una quota. E soprattutto, il rifiuto della licenza permissiva come default: il copyleft forte — GPL, AGPL — non è una restrizione alla libertà, è una protezione dalla predazione. Obbliga chi modifica e redistribuisce il codice a restituire le modifiche alla comunità. Non è una catena: è uno scudo.
Dieci trilioni di download all’anno. L’82% consumato da tre aziende. Un controller Kubernetes usato da metà del cloud mondiale mantenuto da due persone nel tempo libero. Una backdoor quasi catastrofica inserita sfruttando un maintainer isolato e stremato. Un fondo di salvataggio da 700.000 dollari — l’equivalente di un bonus annuale in Silicon Valley. E una casta di CEO miliardari che si riempie la bocca di “community” e “open innovation” mentre i bilanci raccontano tutt’altra storia: quella dello sfruttamento sistematico del lavoro cognitivo non retribuito. La crisi dell’open source non è un incidente. È il risultato prevedibile di un sistema che estrae valore senza restituirne nemmeno una frazione. La prossima Log4Shell, la prossima xz-utils, non è una questione di “se” ma di “quando”. E quando accadrà, le stesse aziende che spendono più per una singola convention di sviluppatori che per finanziare tutti i maintainer dei propri stack fingeranno sorpresa, annunceranno un nuovo fondo da qualche milione e torneranno a fare quello che fanno sempre: prendere senza dare. L’unico modo per spezzare il ciclo è smettere di chiedere elemosina ai miliardari e costruire alternative strutturali — cooperative, fondi obbligatori, copyleft, infrastrutture comunitarie. Il codice è nostro. È ora di smettere di regalarlo a chi ci costruisce sopra imperi.