La possibilità di fare un fork, cioè di prendere il codice di un progetto e proseguirne lo sviluppo in modo indipendente, è una delle garanzie fondamentali del software libero. Nessuno può tenere in ostaggio un progetto open source: se chi lo guida prende una direzione inaccettabile, chiunque può ripartire dal codice esistente. Ma fare un fork è facile solo dal punto di vista tecnico. Farlo sopravvivere è un'altra storia.
Due significati della stessa parola
Il termine viene usato in due sensi molto diversi:
- fork tecnico: la copia di un repository sul proprio account per lavorarci e proporre modifiche. È il flusso normale delle pull request e non ha nulla di conflittuale;
- fork della comunità: la nascita di un progetto alternativo, con un nome diverso, manutentori propri e rilasci separati, che compete o convive con l'originale.
In questo articolo si parla del secondo caso.
Perché nascono i fork
Le ragioni ricorrenti sono poche e riconoscibili:
- cambio di licenza: il progetto originale passa a una licenza non open source e una parte della comunità prosegue dall'ultima versione libera;
- cambio di proprietà: un'azienda acquisisce il progetto e la comunità teme per il suo futuro;
- conflitti di governance: disaccordi profondi su chi decide e come;
- abbandono: i manutentori smettono di rispondere e qualcuno riprende il lavoro;
- divergenza tecnica: obiettivi così diversi che non possono convivere nello stesso codice.
Esempi noti
Alcuni casi aiutano a capire le dinamiche:
- LibreOffice è nato da OpenOffice.org quando una larga parte della comunità ha scelto di proseguire sotto una fondazione indipendente; nel tempo è diventato il ramo più attivo.
- MariaDB è nato da MySQL per iniziativa di alcuni dei suoi sviluppatori originali, dopo che MySQL era passato sotto il controllo di una grande azienda.
- Jenkins è nato da Hudson in seguito a una disputa sul nome e sul controllo del progetto.
- OpenTofu e Valkey sono nati rispettivamente da Terraform e da Redis dopo che questi erano passati a licenze non open source.
In tutti questi casi il fork ha avuto successo perché si è portato dietro una parte consistente di chi sviluppava davvero, non solo il codice.
Prima di fare un fork
Un fork divide energie, utenti e attenzione. Prima di avviarlo conviene esaurire le alternative:
- discutere apertamente il problema con i manutentori, per iscritto;
- proporre una modifica alla governance o un ruolo da co-manutentore;
- in caso di abbandono, chiedere esplicitamente il trasferimento del repository e dei pacchetti;
- verificare se esistono già altri fork attivi da sostenere invece di crearne uno nuovo.
Molti fork falliscono proprio perché ne nascono tre contemporaneamente, ciascuno con due persone.
Nome, marchi e licenza
La licenza open source permette di copiare e modificare il codice, ma quasi mai concede l'uso del nome e del logo. Il fork deve quindi:
- scegliere un nome nuovo, chiaramente distinto, e verificare che non sia già registrato;
- rimuovere o sostituire loghi e riferimenti che possano far credere a un'origine ufficiale;
- mantenere intatti gli avvisi di copyright e le licenze dei file esistenti;
- se la licenza originale è copyleft, distribuire il fork sotto le stesse condizioni.
Quando il fork parte dopo un cambio di licenza, il punto di partenza deve essere l'ultima versione rilasciata con la licenza libera: il codice successivo non può essere incluso.
Passi concreti per un fork sostenibile
- Dichiarare il motivo in un documento pubblico, sobrio e senza attacchi personali.
- Definire subito la governance, per non ripetere i problemi che hanno causato il fork.
- Mettere al sicuro l'infrastruttura: dominio, organizzazione sulla piattaforma di hosting, nomi dei pacchetti nei registri.
- Garantire compatibilità iniziale con l'originale, così che gli utenti possano passare senza riscrivere nulla.
- Pubblicare un primo rilascio rapidamente, anche solo con correzioni minori, per dimostrare che il progetto è vivo.
- Cercare una casa neutrale, come una fondazione o uno sponsor fiscale, se il fork nasce da conflitti di controllo.
In sintesi
- Il fork della comunità è una garanzia del software libero, ma divide energie e utenti.
- Nasce di solito da cambi di licenza, di proprietà, conflitti o abbandono.
- La licenza consente di copiare il codice, non di usare nome e marchi dell'originale.
- Un fork riesce se porta con sé sviluppatori attivi, governance chiara e un primo rilascio rapido.
