In sezione chiamata «La Possibilità di Diramazione» in Capitolo 4, L'Infrastruttura Sociale e Politica, noi vedemmo come la possibilità di una diramazione abbia un effetto importante su come il progetto viene amministrato. Ma cosa accede quando una diramazione si verifica veramente? Come dovreste gestire la cosa? E quali effetti dovete aspettarvi che la cosa abbia? All'inverso, quando dovreste iniziare una diramazione?
La risposta dipende da che tipo di diramazione è? Alcune diramazioni si hanno per un amichevole e inconciliabile disaccordo sulla direzione del progetto; forse la maggior parte sono dovute a disaccordi tecnici e a conflitti interpersonali. Certo, non è sempre possibile dire le differenza fra le due cose, in quanto elementi tecnici possono coinvolgere elementi personali. La cosa che tutte le diramazioni hanno in comune è che un gruppo di sviluppatori (o talvolta anche uno solo degli sviluppatori) ha deciso che i costi del lavorare con qualcuno o tutti gli altri ora non prevalgono sui benefici.
Una volta che il progetto si biforca, non c'è una risposta definitiva alla domanda su quale diramazione è il “vero” o “originale” progetto. La gente parlerà in modo colloquiale della diramazione F che viene dal progetto P, come se P sta continuando per la sua normale traiettoria senza una marcia inferiore, mentre F diverge in nuovo territorio, ma questa è, in effetti, una dichiarazione di come quel particolare osservatore avverte la cosa. E' fondamentalmente una questione di percezione: quando una larga percentuale di osservatori è d'accordo, l'affermazione incomincia a diventare vera. Non è il caso che ci sia una verità oggettiva sin dall'inizio, una che noi siamo solo imperfettamente capaci di percepire all'inizio. Piuttosto, le percezioni sono la verità oggettiva, poichè in ultima analisi una diramazione—o un progetto—sono una entità che esiste solo nella mente della gente comunque.
Se quelli che stanno iniziando una diramazione ritengono di star facendo crescere un nuovo ramo fuori dal progetto principale, la questione della percezione è risolta immediatamente e facilmente. Ognuno, sviluppatori e utilizzatori, tratterà la diramazione come un nuovo progetto, con un nome (magari basato sul vecchio nome, ma facilmente distinguibile da esso), un sito separato, e una filosofia separata per quanto riguarda gli obbiettivi. Le cose riusciranno disordinate, comunque, quando ambedue le parti riterranno di essere i guardiani legittimi del progetto originale e quindi di avere il diritto di continuare ad usare in nome originale. Se c'è qualche organizzazione con diritto di marchio sul nome, o con un controllo legale sulle pagine web o sul dominio, ciò di solito risolve il problema per decreto: quella organizzazione decide chi è nel progetto e chi nella diramazione, perché detiene tutte le carte in una guerra di pubbliche relazioni. Naturalmente, raramente le cose arrivano fino a questo punto: dal momento che ciascuno conosce quali sono le dinamiche del potere, eviterà di combattere una battaglia il cui esito è noto in partenza, e giusto salta dritto alla fine.
Fortunatamente, nella maggior parte dei casi, c'è un piccolo dubbio su quale sia il progetto e quale la diramazione perchè una diramazione è, in essenza, un voto di fiducia. Se più della metà degli sviluppatori sono favorevoli a qualunque corso si propone di prendere la diramazione, di solito non c'è bisogno della diramazione il progetto può andare per quella strada da sé, a meno che non diventi una dittatura con un dittatore particolarmente testardo. D'altra parte, se meno della metà degli sviluppatori sono favorevoli, la diramazione è proprio una ribellione di una minoranza, e la cortesia e il senso comune indicano che essa dovrebbe ritenersi un ramo divergente piuttosto che la linea principale.
Se qualcuno minaccia una diramazione nel vostro progetto, mantenete la calma e ricordate gli obiettivi a lungo termine. La sola esistenza di una diramazione non è ciò che fa male a un progetto; piuttosto è la perdita di sviluppatori e utilizzatori. Il vostro vero scopo non è schiacciare la diramazione, ma minimizzare i suoi effetti dannosi. Potete essere furiosi, potete ritenere che la diramazione fu ingiusta e non necessaria, ma esprimere questo pubblicamente può solo alienare gli sviluppatori indecisi. Invece non obbligate la gente a fare scelte esclusive, e siate collaborativi e pratici con la diramazione. Per iniziare, non togliete l'accesso all'invio a qualcuno nel vostro progetto solo perché ha deciso di lavorare alla diramazione. Lavorare sulla diramazione non significa che la persona ha improvvisamente perso la sua competenza a lavorare al progetto originale; coloro che fanno gli invii prima dovrebbero rimanere quelli che fanno gli invii dopo. Oltre a ciò voi dovreste esprimere il desiderio di restare quanto più compatibili possibile con la diramazione, e dire che sperate che gli sviluppatori trasferiranno i cambiamenti fra il progetto e la diramazione quando è opportuno. Se avete l'accesso amministrativo ai servers, offrite a quelli della diramazione l'aiuto delle sovrastrutture al momento dell'avvio. Per esempio, offrite loro una copia completa con la storia profonda del deposito del controllo di versione, se essi non hanno altro modo di ottenerla, cosicché essi non abbiano a partire senza dati storici (ciò può essere non necessario a seconda del sistema di controllo della versione). Chiedete loro se c'è qualcos'altro di cui abbiano bisogno, e fornitelo se potete. Chinatevi all'indietro per mostrare che non state fra i piedi e per mostrare che la diramazione avrà successo o fallirà per i suoi meriti e nient'altro.
Il motivo per fare tutto ciò e farlo pubblicamente non è in verità quello di aiutare la diramazione, ma convincere gli sviluppatori che la vostra parte è una scommessa sul sicuro, apparendo quanto meno vendicativi possibile. In guerra talvolta ha senso (senso strategico, non umano) costringere la gente a scegliere una parte, ma nel software libero quasi sempre non lo ha. Infatti, dopo una diramazione, alcuni sviluppatori spesso lavorano apertamente ad ambedue i progetti e fanno del loro meglio per tenere le due cose compatibili. Questi sviluppatori aiutano a tenere aperte le linee di comunicazione dopo la diramazione. Essi permettono al vostro progetto di beneficiare di nuove interessanti funzionalità della diramazione (si, la diramazione può avere cose che volete), e anche accrescere le possibilità di una fusione per strada.
A volte una diramazione ha così successo, che anche se era considerata dai suoi stessi istigatori come diramazione dall'inizio, diventa la versione che ognuno preferisce, e alla fine soppianta l'originale per richiesta popolare. Un esempio famoso di ciò fu la diramazione GCC/EGCS. La GNU Compiler Collection (GCC, prima la GNU C Compiler) è il codice nativo di compiler open source più popolare, e anche uno dei più portabili compilatori del mondo. Dovuto al disaccordo fra i manutentori ufficiali del GCC e la Cygnus Software.,[26] uno dei gruppi di sviluppatori più attivi, Cygnus creò una diramazione di GCC chiamata EGCS. La diramazione era deliberatamente non antagonistica: gli sviluppatori EGCS , in qualunque momento, non cercavano di descrivere la loro versione di GCC come una nuova versione. Invece si concentrarono sul fatto di rendere EGCS quanto migliore possibile, incorporando patch ad un ritmo superiore a quello dei manutentori dello GCC ufficiale. EGCS guadagnò in popolarità, e alla fine alcuni principali distributori di sistemi operativi decisero di impacchettare EGCS come loro compilatore di default invece di GCC. A questo punto, diventò chiaro ai manutentori di GCC che insistendo sulla denominazione "GCC" mentre ognuno passava alla diramazione EGCS avrebbe caricato ognuno con un inutile cambiamento di nome, ma non avrebbe fatto niente per impedire la migrazione. Così GCC adottò il codice base di EGCS, e c'è ancora un solo GCC, ma grandemente migliorato con la diramazione.
Questo esempio mostra perché non potete sempre considerare una diramazione come una assoluta cosa brutta. Una diramazione può essere dolorosa e non benvenuta al momento, ma voi non potete sapere se avrà successo. Quindi, voi e il resto del progetto dovete tenerci un occhio su, ed essere preparati non solo ad assorbirne il codice e le funzionalità quando possibile, ma nei casi più estremi, anche ad unirvi alla diramazione se essa raggiunge le dimensioni di popolarità del progetto. Certo, sarete spesso in grado di predire la probabilità di successo di una diramazione guardando chi si unisce ad essa. Se la diramazione è partita dai più grandi lamentosi del progetto e ad essa si è aggiunta una manciata di sviluppatori scontenti che non si stavano comportando costruttivamente comunque, essi hanno sostanzialmente risolto il problema con voi con la diramazione, e voi probabilmente non dovete preoccuparvi della diramazione portando via slancio al progetto originale. Ma se vedete sviluppatori influenti ed rispettati che sostengono la diramazione, ve ne dovrete chiedere il perché. Magari il progetto stava essendo eccessivamente restrittivo, e la migliore soluzione è adottare nella linea principale del progetto alcuni o tutti gli atti contemplati dalla diramazione—in sostanza evitare che la diramazione diventi tale.
Tutto il consiglio qui è nell'ipotesi che stiate facendo una diramazione come ultima risorsa. Esaurite tutte le altre possibilità prima di iniziare una diramazione. Fare una diramazione significa quasi sempre perdere sviluppatori, con solo una incerta promessa di acquisirne di nuovi dopo. Essa significa anche iniziare una competizione per l'attenzione degli utilizzatori: chiunque stia per scaricare ha da chiedere a se stesso: “Hmm, voglio questo o l'altro?” Qualunque dei due voi siate, la situazione è sporca, perché è stata introdotta una domanda che non c'era prima. Alcune persone sostengono che la diramazione è salutare per l'ecosistema del software nella sua interezza, per il classico argomento della selezione naturale: sopravviverà il più adatto, che significa che, alla fine, ognuno ottiene il software migliore. Questo può essere vero dal punto di vista degli ecosistemi, ma non è vero dal punto di vista di un singolo progetto. La maggior parte delle diramazioni non riescono, e la maggior parte dei progetti non sono contenti di essere biforcati.
Un corollario è che non dovreste usare la minaccia di una diramazione come tecnica estremistica di una discussione—“Fate le cose come dico io o io biforcherò il progetto!”—poiché chiunque è al corrente che un diramazione ch non riesce ad attrarre sviluppatori dal progetto originale è improbabile che viva a lungo. Tutti gli osservatori—non solo gli sviluppatori, ma utilizzatori e impacchettatori del sistema operativo anche—si faranno la loro idea su che parte scegliere. Voi dunque dovreste apparire estremamente riluttanti a un diramazione, così se alla fine la fate, possiate reclamare che era l'ultima via rimasta.
Non trascurate di tenere in conto tutti i fattori nel valutare il potenziale successo della vostra diramazione. Per esempio, se molti degli sviluppatori in un progetto hanno lo stesso datore di lavoro, allora anche se sono scontenti e privatamente favorevoli alla diramazione, è improbabile che lo dicano così a voce alta se il loro datore di lavoro è contro di essa. Molti programmatori di software libero amano pensare che avere una licenza libera sul codice significa che nessuna compagnia può dominare lo sviluppo. E vero che la licenza, in un senso definitivo, è un garante di libertà—se gli altri vogliono abbastanza fortemente biforcare il progetto, ed hanno le risorse per farlo, essi possono. Ma in pratica, alcuni team di progetti furono in gran parte finanziati da una entità, e non c'è motivo di pretendere che non interessi quel supporto dell'entità. Se essa si oppone alla diramazione, è improbabile che i suoi sviluppatori vi prendano parte, anche se segretamente lo vogliono.
Se tuttavia concludete che dovete fare la diramazione, allineatevi privatamente col supporto prima, quindi annunciate la diramazione in un modo non ostile. Anche se siete arrabbiati, o in disappunto, con i proprietari correnti, non dite questo nel messaggio. Giusto spassionatamente dichiarate ciò che vi ha portato alla decisione di una diramazione, e che non volete significare nessuna intenzione malevola verso il progetto da cui vi diramate. Dando per ipotesi che voi la considerate una diramazione (come opposta a una conservazione di emergenza del progetto originale), mettete l'accento sul fatto che non state diramando il nome ma il codice, e scegliete un nome che no vada in conflitto col nome del progetto. Potete usare un nome che contiene o si riferisce al nome originale, finché ciò non apre la porta a una confusione di identità. Certo è bene spiegare in modo prominente sulla pagina web della diramazione che essa discende dal programma originale, e anche che essa spera di soppiantarlo. Solo non fate si che la vita degli utilizzatori sia più difficile obbligandoli a sbrogliare una disputa di identità.
Infine, potete ottenere che le cose partano con il piede giusto concedendo automaticamente a tutti coloro che avevano l'invio nel progetto originale l'accesso all'invio nella diramazione, inclusi quelli che erano apertamente in disaccordo con la necessità di una diramazione. Anche se essi non usano mai l'accesso all'invio, il vostro messaggio è chiaro: ci sono disaccordi qui, ma non nemici, e date il benvenuto ai contributi di codice provenienti da ogni origine competente.