Open source: il costo nascosto è non sapere chi lo mantiene

Una libreria entra in produzione, risolve un problema e smette di attirare attenzione. Non ha una fattura mensile, non richiede una trattativa commerciale, non compare fra i fornitori strategici. A volte non compare neppure nell’inventario tecnico, perché è arrivata insieme a un’altra dipendenza. Poi arriva una vulnerabilità, una release incompatibile o semplicemente una persona che non ha più tempo di occuparsene. Ed ecco che il software che sembrava non costare nulla presenta il conto.

Il problema non è l’open source. È l’abitudine di scambiare l’accesso al codice per una garanzia di continuità. Una licenza aperta ti dà possibilità preziose: leggere, modificare, distribuire e, se necessario, assumerti la manutenzione. Non ti promette che qualcuno continuerà a farlo al posto tuo. Questa differenza, nelle aziende, dovrebbe essere un requisito di architettura. Invece viene spesso scoperta durante un incidente.

Undici su ventitré: un numero utile, purché non gli si faccia dire troppo

Una ricerca pubblicata da Data Drop ha esaminato la storia pubblica di 23 componenti open source diffusi in telefoni, browser e server, considerando il periodo dal 7 ottobre 2025 al 7 ottobre 2026. La soglia scelta per definire un contributore regolare è almeno dieci commit nell’anno, esclusi merge e bot. Secondo il dataset messo a disposizione dagli autori, 11 dei 23 progetti selezionati hanno una o due persone sopra quella soglia.

È un segnale significativo, non una sentenza. Non significa che metà dell’open source mondiale dipenda da due persone; il campione è selezionato e non rappresentativo dell’intero ecosistema. E soprattutto non significa che chi fa nove commit non contribuisca, che un progetto con pochi commit sia abbandonato o che la persona che firma una modifica coincida con chi gestisce release, revisioni, segnalazioni e sicurezza. La ricerca stessa esplicita questi limiti. Se trasformiamo una metrica parziale in una classifica di progetti “sicuri” e “insicuri”, stiamo semplicemente sostituendo una cattiva decisione con una cattiva dashboard.

Il dato, però, rende visibile qualcosa che gli indicatori tradizionali di disponibilità e performance non misurano: la concentrazione della conoscenza e della capacità di intervenire. Un componente può funzionare perfettamente oggi e avere una continuità operativa fragile domani. Non è una contraddizione: è la differenza tra stato corrente e resilienza.

Il bus factor non è un giudizio sulle persone

Il cosiddetto bus factor prova a rispondere a una domanda scomoda: quante persone devono diventare indisponibili perché un progetto perda conoscenze essenziali? La formulazione è brutale, ma il punto non è la biografia di chi mantiene il codice. È la distribuzione delle responsabilità, la possibilità di trasferire competenze, l’esistenza di review indipendenti e di un percorso di successione.

Prendiamo il database dei fusi orari, tzdb. Nella rilevazione citata, Paul Eggert firma 218 dei 251 commit dell’anno, circa l’87%. Il numero non dimostra che il database sia inaffidabile. Mostra quanto sia importante sapere chi può validare un cambiamento normativo, come vengono gestiti gli aggiornamenti e quali procedure restano operative se il referente principale non è disponibile. In un sistema che calcola scadenze, pagamenti o appuntamenti internazionali, l’errore di un fuso orario non è una curiosità accademica.

C’è anche il controesempio che impedisce di fare moralismo: SQLite è sviluppato da un gruppo ristretto ma adotta un modello di supporto commerciale. Il numero delle persone non descrive, da solo, la qualità della governance. Conta anche il modo in cui il lavoro viene finanziato, verificato, distribuito e documentato.

La lezione di xz non è che bisogna diffidare dei volontari

Nel marzo 2024 la scoperta di una backdoor nelle versioni 5.6.0 e 5.6.1 di xz Utils mostrò quanto un componente apparentemente secondario potesse diventare un punto d’ingresso nella catena software. Il CERT-EU documentò l’interferenza con l’autenticazione SSH in determinate configurazioni e raccomandò il ritorno a versioni non compromesse. Non fu un difetto inevitabile dell’open source: fu un attacco alla fiducia e al processo di distribuzione.

Ridurre quell’episodio alla formula “un maintainer solo è pericoloso” sarebbe comodo e superficiale. Un progetto può avere molti contributor e controlli di rilascio insufficienti; un altro può avere pochi sviluppatori e procedure di review solide. Il rischio cresce quando accessi, decisioni e conoscenza si concentrano senza verifiche proporzionate all’impatto del componente. È un problema di architettura organizzativa almeno quanto di codice.

Un componente gratuito non elimina il costo della responsabilità: decide soltanto chi lo sta pagando, e spesso lascia il conto fuori dalla vista.

Una SBOM è l’inizio dell’inventario, non la fine dell’analisi

Molte organizzazioni stanno imparando a costruire una Software Bill of Materials: un elenco dei componenti che compongono applicazioni e servizi. È un progresso, ma un elenco di nomi e versioni non risponde alle domande più importanti quando qualcosa si rompe. Chi riceve l’avviso? Chi decide se aggiornare? Chi può riprodurre la build? Chi verifica che la patch non introduca un’incompatibilità? Chi sa sostituire la libreria se la manutenzione si ferma?

La Census III della Linux Foundation e di Harvard, basata su milioni di osservazioni di librerie utilizzate in produzione, conferma un fenomeno più ampio: molto software diffusissimo è sviluppato da pochi contributori. Il rapporto non valida il conteggio specifico 11 su 23, che resta proprio dello studio Data Drop; rafforza però la necessità di misurare criticità e dipendenze, anziché fermarsi al numero di download o alla popolarità del repository.

In pratica, accanto alla SBOM servirebbe una scheda di responsabilità per le dipendenze più importanti: impatto sul servizio, referente interno, canale di aggiornamento, finestra massima di esposizione alle vulnerabilità, percorso di test e rollback, alternative realistiche. Non è necessario compilare un dossier per ogni pacchetto transitivo. È necessario sapere quali componenti possono fermare davvero il business e assegnare a ciascuno una risposta operativa.

Tre controlli che costano meno di un’emergenza

Il primo controllo è distinguere la criticità dalla notorietà. Un parser usato da un solo processo di importazione può essere più importante di una libreria famosa presente in una pagina marginale, se un suo errore blocca la fatturazione. L’ordine di priorità nasce dall’impatto sul sistema, non dalle stelle su GitHub.

Il secondo è misurare la sostituibilità. Una dipendenza può avere codice pubblico e API formalmente standard, ma richiedere mesi per essere rimpiazzata perché tutto il prodotto ne assume comportamenti particolari. È lo stesso problema di progettazione che emerge quando un componente diventa aperto senza cancellare il lock-in: possedere il codice non equivale a poter cambiare architettura a costo zero.

Il terzo è mettere alla prova il processo prima dell’incidente. Aggiornare una dipendenza critica in staging, riprodurre una build, testare un rollback e simulare l’assenza del referente non sono esercizi burocratici. Sono verifiche di continuità. Anche l’articolo su Deno, Cloudflare e la portabilità reale porta alla stessa distinzione: dichiarare una possibilità tecnica non significa averne verificato la praticabilità operativa.

Il finanziamento è una scelta di rischio, non una donazione per sentirsi migliori

La ricerca distingue correttamente i grant pubblici individuati dall’assenza di compensi in assoluto. È una distinzione fondamentale: non trovare un finanziamento nei registri consultati non autorizza a descrivere qualcuno come non pagato. E un contratto di supporto, un contributo aziendale o una review finanziata possono contare più di una campagna pubblica vistosa.

Per un’impresa che dipende davvero da un componente, finanziare test, audit, documentazione o manutenzione può essere un investimento nella continuità della propria catena produttiva. Non deve essere necessariamente filantropia, né garantisce immunità dagli incidenti. È una scelta più razionale che aspettare il prossimo problema e scoprire allora di non avere né competenze interne né interlocutori esterni.

La domanda da portare alla prossima riunione tecnica

Quando un software entra in azienda, siamo abituati a chiedere quanto costa acquistarlo, integrarlo e farlo girare. Per l’open source la prima voce può essere zero, e questa è una straordinaria opportunità. Ma proprio per questo le altre voci vanno rese esplicite. Non serve trasformare ogni libreria in un contratto: serve evitare che una dipendenza strategica rimanga senza un responsabile.

La prossima volta che qualcuno presenta una soluzione dicendo che è gratuita perché open source, la risposta non dovrebbe essere né entusiasmo automatico né diffidenza ideologica. Dovrebbe essere una domanda tecnica molto concreta: se domani questo componente smette di essere mantenuto, chi se ne accorge, chi decide e quanto tempo abbiamo per intervenire? Se non sappiamo rispondere, il costo esiste già. Semplicemente non lo abbiamo ancora misurato.