Finché un progetto ha un solo autore, la governance è semplice: decide lui. Appena arrivano altri contributori, però, nascono domande che il codice non risolve. Chi può accettare una modifica? Chi sceglie quando rilasciare? Cosa succede se due manutentori non sono d'accordo? Chi può dare o togliere i permessi di scrittura? La governance è l'insieme delle risposte a queste domande, e un progetto che non le scrive le subisce comunque, solo in modo implicito.
Perché scriverla prima dei problemi
I conflitti di governance esplodono quasi sempre nel momento peggiore: durante una discussione accesa su una funzionalità, dopo un cambio di lavoro del fondatore, quando un'azienda inizia a contribuire molto. Se le regole esistono già, si applicano. Se non esistono, ogni decisione diventa una questione di potere personale.
Una governance esplicita serve anche a chi valuta il progetto dall'esterno: un'organizzazione che deve dipendere da un software per anni vuole sapere come vengono prese le decisioni.
I modelli più diffusi
Dittatore benevolo
Una persona, di solito il fondatore, ha l'ultima parola su tutto. Il termine inglese è Benevolent Dictator For Life (BDFL). Funziona quando quella persona ha visione chiara, tempo e la fiducia della comunità.
- Pro: decisioni rapide, coerenza tecnica.
- Contro: tutto dipende da una persona; la successione è un problema irrisolto.
Diversi progetti noti sono passati da questo modello a uno collegiale quando il fondatore ha deciso di fare un passo indietro.
Gruppo di manutentori
Un insieme di persone con permessi di scrittura decide per consenso informale. Spesso ognuno ha responsabilità su una parte del codice, documentata in un file come CODEOWNERS o MAINTAINERS.
- Pro: distribuisce il carico, riduce la dipendenza da una persona.
- Contro: senza regole per i disaccordi, le decisioni controverse si bloccano.
Comitato tecnico o consiglio direttivo
I progetti più grandi separano spesso due livelli: un comitato tecnico che decide su architettura e rilasci, e un organo che si occupa di aspetti non tecnici come fondi, marchi e codice di condotta. I membri vengono eletti dai contributori attivi o nominati secondo regole scritte, con mandati a termine.
- Pro: stabilità, legittimità, rappresentanza di interessi diversi.
- Contro: processi più lenti, necessità di elezioni e verbali.
Meritocrazia per livelli
Alcune comunità definiscono una scala di ruoli: utente, contributore, committer, membro del comitato. Si sale di livello per contributi riconosciuti nel tempo, su proposta di chi è già al livello superiore.
Come si prendono le decisioni
Indipendentemente dal modello, servono meccanismi concreti. I più usati:
| Meccanismo | Come funziona | Quando è adatto |
|---|---|---|
| Consenso pigro | Una proposta passa se nessuno si oppone entro un termine | Decisioni ordinarie |
| Voto con veto | Ogni manutentore può bloccare, motivando | Modifiche rischiose al codice |
| Maggioranza | Si conta il voto dei membri aventi diritto | Elezioni, regole interne |
| Documento di proposta | Si scrive un RFC discusso pubblicamente | Cambiamenti di architettura o di API |
Il consenso pigro è prezioso perché evita che tutto richieda riunioni: chi propone scrive «se non ci sono obiezioni entro 72 ore procedo», e il silenzio diventa approvazione.
Cosa mettere in un GOVERNANCE.md
Un file di governance utile non è lungo. Deve rispondere a poche domande precise:
- Ruoli: quali esistono e cosa può fare ciascuno.
- Accesso ai ruoli: come si diventa manutentore, chi decide, quali criteri.
- Uscita dai ruoli: inattività, dimissioni, rimozione per violazioni.
- Decisioni: quale meccanismo si usa per quale tipo di scelta.
- Disaccordi: chi ha l'ultima parola quando il consenso non arriva.
- Modifiche alla governance: come si cambiano queste stesse regole.
Un esempio di regola chiara: «Un contributore diventa manutentore su proposta di un manutentore esistente, se nessun altro manutentore si oppone entro sette giorni. I manutentori senza attività per dodici mesi passano allo stato emerito e perdono i permessi di scrittura, che possono riottenere su richiesta.»
Errori frequenti
- Copiare la governance di un progetto enorme in uno con tre persone: crea burocrazia senza benefici.
- Lasciare permessi di scrittura a persone inattive: è un rischio di sicurezza oltre che di governance.
- Non distinguere tra chi contribuisce e chi paga: un'azienda che finanzia non dovrebbe ottenere automaticamente potere decisionale, a meno che sia dichiarato.
- Regole scritte ma non applicate: peggio di nessuna regola, perché minano la fiducia.
Nel mio lavoro, quando un progetto mi chiede un parere sulla sua organizzazione, la prima domanda che pongo è sempre la stessa: se domani il manutentore principale sparisse, chi avrebbe le chiavi del repository, del dominio e dei pacchetti pubblicati? La risposta dice quanto il progetto è davvero governato.
In sintesi
- La governance esiste sempre: scriverla evita che diventi una questione di potere personale.
- I modelli principali vanno dal dittatore benevolo al comitato eletto, con molte varianti.
- Servono meccanismi decisionali chiari, come consenso pigro, veto motivato e RFC.
- Un buon GOVERNANCE.md definisce ruoli, accesso, uscita, decisioni e risoluzione dei disaccordi.
