23 progetti open source, pochi sviluppatori: quanto dipendiamo da curl e SQLite

Un'analisi recente condotta da Data Drop ha esaminato la cronologia di sviluppo di 23 progetti open source fondamentali tra ottobre 2025 e ottobre 2026. Il dato emerso è preoccupante: 11 di questi progetti mostrano soltanto una o due persone con almeno dieci modifiche significative nel periodo considerato. Progetti come curl, SQLite, FFmpeg e il database dei fusi orari tzdb, che supportano miliardi di dispositivi, dipendono quindi da un gruppo ristretto di sviluppatori che lavora con continuità sul codice.

Il contesto: la fragilità nascosta nelle infrastrutture

Internet sembra poggiare su datacenter enormi e società con bilanci miliardari, ma allo strato software emerge un'asimmetria critica. Il valore economico di una libreria aperta può crescere enormemente senza che aumentino in proporzione le risorse per la sua manutenzione. Incidenti passati come Heartbleed (2014), Shellshock (2014), Log4Shell (2021) e la backdoor di XZ (2024) hanno dimostrato come vulnerabilità in componenti apparentemente minori possano avere ripercussioni globali. La libertà di usare il codice non implica che il lavoro di manutenzione sia gratuito: analizzare bug, verificare vulnerabilità e gestire le release richiede competenze specialistiche e tempo.

• Concentrazione del lavoro: In 11 casi su 23, il carico di sviluppo ricade su una o due figure principali.
• Rischio operativo: La dipendenza da pochi maintainer aumenta l'impatto di un eventuale abbandono del progetto o di una vulnerabilità critica.
• Esempio concreto: Il database tzdb, essenziale per calendari e finanza, richiede aggiornamenti rapidi in risposta a decisioni politiche sui fusi orari.
• Asimmetria di risorse: Grandi aziende costruiscono prodotti commerciali su codice mantenuto spesso nel tempo libero da singoli sviluppatori.

Cosa significa per chi compra e usa software in Italia

Per l'utente finale e le imprese italiane, questa situazione si traduce in una questione di gestione del rischio. Se un'azienda basa parti rilevanti dei propri servizi su componenti open source mantenuti da poche persone, deve essere consapevole delle condizioni di sostenibilità di quel software. Non si tratta solo di etica, ma di stabilità operativa: sapere chi può intervenire in caso di emergenza, quante persone hanno privilegi di rilascio e cosa accadrebbe se il maintainer principale smettesse di lavorare al progetto è fondamentale. Le imprese dovrebbero valutare non solo il costo zero del software, ma anche il rischio associato alla sua dipendenza da risorse umane limitate. Per chi sviluppa o amministra sistemi, monitorare la salute della community dietro i componenti critici diventa una pratica di sicurezza tanto importante quanto l'installazione di patch.

La sostenibilità dell'open source richiede che chi ne trae beneficio professionale riconosca e sostenga le condizioni in cui quel software viene mantenuto, evitando che la dipendenza tecnica diventi un punto di rottura inaspettato.

Domande frequenti

Devo smettere di usare questi software?

No, non è necessario abbandonarli. Tuttavia, è importante monitorare gli aggiornamenti di sicurezza e verificare se esistono alternative o piani di continuità in caso di problemi nei progetti principali.

Quali sono i progetti più a rischio citati?

L'analisi evidenzia progetti come curl, SQLite, FFmpeg e il database dei fusi orari tzdb, dove il numero di contributori attivi con modifiche significative è estremamente basso rispetto alla loro diffusione globale.

Come può un'azienda proteggere i propri sistemi?

Le aziende dovrebbero mappare le dipendenze dai componenti open source critici, valutare la salute delle community di sviluppo e considerare contributi finanziari o di lavoro per sostenere la manutenzione a lungo termine.