Cosa succede quando un progetto open source perde il suo leader

Quando Ryan Dahl si fece da parte da Node.js, il progetto sopravvisse, ma ci vollero anni di ristrutturazione della governance, un fork (io.js) e una riconciliazione prima che si stabilizzasse. Quando Guido van Rossum si dimise da BDFL di Python ('Benevolent Dictator For Life'), la community passò mesi a discutere di modelli di governance prima di approdare a uno steering council. Quando il progetto Deno si trovò ad affrontare le proprie questioni di leadership, gli effetti si propagarono a ogni sviluppatore che aveva puntato sul runtime.

Non si tratta di episodi isolati. È una caratteristica strutturale dello sviluppo open source. La maggior parte dei progetti open source rilevanti dipende da un numero ristrettissimo di persone, spesso una sola, molto più di quanto i suoi utenti immaginino. Quando quella persona se ne va, si esaurisce, cambia priorità o prende una decisione controversa, il progetto affronta una crisi esistenziale che nessuna quantità di stelle su GitHub può evitare.

Il problema del bus factor

Il 'bus factor', ovvero quante persone dovrebbero essere investite da un autobus prima che un progetto collassi, è tristemente basso per la maggior parte dei progetti open source. Uno studio del 2015 ha rilevato che oltre il 60% dei pacchetti npm aveva un solo maintainer. Un'analisi più recente delle infrastrutture open source critiche ha mostrato che molti progetti con milioni di dipendenti a valle sono mantenuti da una o due persone, spesso come lavoro volontario non retribuito.

Non è un problema ipotetico. OpenSSL, la libreria che proteggeva la maggior parte del traffico cifrato di internet, era mantenuta principalmente da due persone che vi lavoravano nel tempo libero quando fu scoperto Heartbleed. Left-pad, un banale pacchetto npm di 11 righe, fece saltare migliaia di build quando l'autore lo rimosse. Core-js, scaricato più di 25 milioni di volte a settimana, è mantenuto da un unico sviluppatore che ha dichiarato pubblicamente di riuscire a malapena a permettersi il cibo.

Lo schema è sempre lo stesso: un progetto critico nasce per iniziativa di una persona appassionata, guadagna adozione, diventa un'infrastruttura da cui dipendono milioni di utenti, eppure il carico di manutenzione resta sulle spalle della stessa una o due persone. L'importanza del progetto cresce in modo esponenziale. Il supporto no.

Modelli di governance e i loro compromessi

I progetti open source gestiscono la governance in alcuni modi distinti, ognuno con punti di forza e modalità di fallimento prevedibili.

Il modello BDFL

Una sola persona prende le decisioni finali. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz): i progetti di maggior successo hanno spesso un leader tecnico forte, il cui gusto e giudizio plasmano il progetto. Il vantaggio è una direzione chiara, una visione coerente e decisioni rapide. Il BDFL può dire di no alle funzionalità che non c'entrano, e il progetto resta focalizzato.

La modalità di fallimento è altrettanto chiara: il BDFL se ne va e non c'è nessun piano di successione. La transizione di Python dopo le dimissioni di Guido è stata turbolenta, nonostante decenni di costruzione della comunità. I progetti con comunità meno coinvolte spesso semplicemente muoiono quando il loro BDFL si fa da parte.

Il modello a fondazione

Progetti come Apache, Eclipse e la Linux Foundation fanno capo a fondazioni senza scopo di lucro con strutture di governance formali: comitati tecnici di indirizzo, elezioni dei committer, processi decisionali. Questo garantisce continuità istituzionale: il progetto sopravvive alle uscite individuali perché la struttura resta in piedi.

Il compromesso sono la burocrazia e le dinamiche politiche. La governance delle fondazioni può essere lenta, conflittuale e catturata da interessi aziendali. Alcuni sviluppatori trovano il processo dei comitati soffocante rispetto all'agilità di un progetto guidato da un BDFL. Il caso peggiore è una fondazione in cui la governance diventa più una questione di politica organizzativa che di merito tecnico.

Il modello con sponsor aziendale

React (Meta), Go (Google), Rust (inizialmente Mozilla, ora con una fondazione propria), TypeScript (Microsoft): molti grandi progetti sono sponsorizzati da aziende che assumono i maintainer principali. Questo risolve il problema dei finanziamenti: i maintainer vengono pagati, possono lavorare a tempo pieno e il progetto beneficia delle risorse ingegneristiche aziendali.

Il rischio è l'allineamento. Le priorità aziendali cambiano. Mozilla ha licenziato il team di Rust. Google ha declassato e sottofinanziato progetti open source quando il focus del business si è spostato. Quando gli interessi strategici di un'azienda divergono da quelli della community, l'attrito è inevitabile. La tendenza recente di sponsor aziendali che cambiano la licenza dei progetti (Redis, Terraform, Elastic) mostra quanto questo modello possa essere precario.

Quando i fork sono sani

Il fork, cioè la creazione di una copia concorrente di un progetto, viene spesso considerato un segno di fallimento. In realtà, nell'open source è la valvola di sicurezza definitiva. Quando la leadership fallisce, il fork permette alla community di andare avanti senza dipendere dai maintainer originali.

Il fork io.js di Node.js ha spinto Node verso un modello di governance più aperto e cicli di rilascio più rapidi. Quando i progetti si sono riuniti, Node ne ha tratto beneficio. LibreOffice, nato come fork di OpenOffice.org, ha salvato il progetto dal calo di interesse di Sun/Oracle. MariaDB, nato come fork di MySQL dopo l'acquisizione da parte di Oracle, prosegue come alternativa guidata dalla community.

Più di recente, i cambi di licenza hanno innescato fork produttivi. Quando Elastic ha cambiato la licenza di Elasticsearch, Amazon ne ha fatto il fork OpenSearch. Quando HashiCorp ha cambiato la licenza di Terraform, la community ne ha creato il fork OpenTofu sotto la Linux Foundation. Questi fork esistono perché il diritto di fare fork è l'ultimo controllo che la community ha sulla leadership di un progetto.

La chiave è che il fork funziona meglio quando si divide in modo netto la community, non solo il codice. Un fork con maintainer attivi e il sostegno della community prospera. Un fork creato da un singolo sviluppatore frustrato che nessuno segue crea solo confusione.

La spirale del burnout

La maggior parte delle crisi di leadership nell'open source non nasce da un'uscita drammatica. Nasce dal burnout, cioè dalla lenta erosione della capacità e dell'entusiasmo del maintainer sotto il peso di issue, pull request, richieste di funzionalità e utenti pretenziosi.

Le dinamiche sono prevedibili. Un maintainer crea qualcosa di utile. Arrivano gli utenti. Con gli utenti arrivano segnalazioni di bug, richieste di funzionalità, domande di supporto e pretese. Il maintainer, sentendosi responsabile, cerca di rispondere a tutto. Il volume supera la sua capacità. Inizia a temere le notifiche. Risponde più lentamente, poi in modo più brusco, poi non risponde affatto. Alla fine sparisce, e il progetto entra in una fase di manutenzione zombie: tecnicamente vivo, di fatto abbandonato.

Il burnout dei maintainer open source non è una colpa personale. È un problema strutturale: i progetti generano una domanda illimitata di tempo e attenzione da parte di un numero finito di persone, senza alcun meccanismo integrato per gestirla.

Alcuni maintainer hanno trovato modi per gestirla: limiti rigidi sui tempi di risposta, delega dello smistamento a membri della community, manutenzione retribuita tramite GitHub Sponsors o Open Collective, oppure semplicemente accettando tempi di risposta più lunghi. Tutto ciò richiede però di resistere consapevolmente alla pressione di essere sempre disponibili, cosa che va contro la cultura di molte community open source.

Come appare una successione sana

Alcuni progetti hanno gestito bene i passaggi di leadership, e condividono modelli comuni.

• Conoscenza distribuita, non solo codice distribuito. Il 'sapere tribale' del progetto, cioè perché certe decisioni sono state prese, quali alternative sono state considerate e quali sono i principi di design, è documentato e non custodito solo nella testa di una persona. Le Architecture Decision Records (ADR) e le RFC dettagliate servono proprio a questo.
• Più persone con accesso in commit e autorità di rilascio. Se una sola persona può pubblicare una release, quella persona è un singolo punto di fallimento. I progetti sani hanno almeno 3-5 persone in grado di rilasciare nuove versioni in modo autonomo.
• Documenti di governance espliciti. Come vengono prese le decisioni? Chi ha autorità su cosa? Come si aggiungono nuovi maintainer? I progetti che rispondono a queste domande prima di una crisi gestiscono la successione meglio di quelli che improvvisano.
• Transizioni graduali, non partenze improvvise. Le migliori transizioni di leadership avvengono quando il leader uscente riduce deliberatamente il proprio coinvolgimento nell'arco di mesi, facendo da mentore ai successori e trasferendo esplicitamente l'autorità. Le uscite brusche, anche se in buona fede, creano vuoti.
• Sostenibilità finanziaria. I progetti con finanziamenti affidabili (tramite fondazioni, sponsor aziendali o donazioni della community) superano meglio i passaggi di consegne, perché chi subentra può essere retribuito per il proprio tempo. Chiedere a qualcuno di ereditare un lavoro a tempo pieno non retribuito è una proposta difficile da accettare.

Cosa dovrebbero fare utenti e aziende

Se il tuo business dipende dal software open source, e succede, hai un interesse concreto nella salute dei progetti da cui dipendi. Alcuni passi pratici:

1. Verifica il bus factor delle tue dipendenze. Guarda i progetti open source critici del tuo stack. Quanti maintainer attivi hanno? Quando è stata rilasciata l'ultima versione? Con che rapidità vengono affrontate le vulnerabilità di sicurezza? Un progetto con un solo maintainer e una vulnerabilità di sicurezza vecchia di sei mesi è un rischio di cui dovresti essere consapevole.
2. Finanzia ciò che usi. Se un progetto è critico per il tuo business, contribuisci al suo finanziamento. GitHub Sponsors, Open Collective e Tidelift offrono meccanismi per farlo. Il costo di finanziare un maintainer è irrisorio rispetto al costo di una dipendenza critica che smette di essere mantenuta.
3. Contribuisci a monte. Correzioni di bug, miglioramenti della documentazione, smistamento delle issue: tutto questo riduce il carico del maintainer e dà al tuo team familiarità con il codice. Se il progetto avrà mai bisogno di nuovi maintainer, sarai in una posizione favorevole per farti avanti.
4. Prepara un piano di emergenza. Per le dipendenze critiche, sai cosa faresti se il progetto venisse abbandonato? Potresti fare il fork e mantenerlo tu? Esiste un'alternativa verso cui migrare? Il momento per rispondere a queste domande è prima di averne bisogno.

La governance dell'open source non è un lavoro glamour. Non genera titoli di giornale né stelle su GitHub. Eppure la differenza tra un progetto che sopravvive all'uscita del suo fondatore e uno che non ci riesce è quasi sempre la governance: il lavoro noioso e strutturale di documentare le decisioni, distribuire l'autorità e pianificare la successione. I progetti che durano sono quelli che costruiscono istituzioni, non solo software.