Indice
Le prime domande che la gente fa sul software libero sono: Come funziona? Cosa mantiene il progetto in funzione? Chi prende le decisioni? Io sono sempre insoddisfatto dalle risposte blande sulla meritocrazia, sullo spirito di collaborazione, sul fatto che il codice parla da sé, ecc.. Il fatto è che, alla domanda non è facile rispondere. La meritocrazia, e il codice funzionante sono parte di esso, ma essi fanno poco nello spiegare come gira il progetto sulla base del giorno per giorno, e non dicono nulla su come i conflitti vengono risolti.
Questo capitolo cerca di mostrare i puntellamenti che progetti di successo hanno in comune. Io intendo “di successo” non solo in termini di qualità tecniche, ma anche di salute operativa e di capacità di sopravvivere. La salute operativa è la capacità di incorporare strada facendo nuovi contributi di codice e di sviluppatori, e di essere reattivi ai rapporti di bugs che arrivano. La capacità di sopravvivere in un progetto è la capacità di esistere indipendentemente da un partecipante individuale o sponsor—tpensate ad essa come alla probabilità che il progetto continuerebbe anche se tutti i suoi membri fondatori si spostassero su un'altra cosa. Il successo tecnico non è difficile da conseguire, ma senza una robusta base di sviluppo e un fondamento sociale, un progetto può essere incapace di gestire la crescita che il successo iniziale porta, alla partenza di individualità carismatiche.
Ci sono molti modi per raggiungere questo tipo di successo. Alcuni riguardano una struttura di amministrazione formale, con la quale le discussioni sono risolte, nuovi sviluppatori sono invitati (o talvolta estromessi), nuove funzionalità sono pianificate, e così via. Altri riguardano strutture meno formali, ma un più conscio auto contenimento, per produrre un'atmosfera essere piacevole, cosa su cui la gente può contare come una forma di amministrazione de facto. Tutte e due le vie portano allo stesso risultato: un senso di stabilità istituzionale, supportata da comportamenti e procedure che possono essere ben compresi da chiunque partecipi. Queste caratteristiche sono anche più importanti in sistemi di auto organizzazione, che in sistemi controllati dal centro, perché in sistemi di auto organizzazione ognuno è conscio che poche mele marce possono rovinare l'intero canestro, almeno per un certo tempo.
L'ingrediente indispensabile che tiene legati gli sviluppatori in un progetto di software libero, e li rende desiderosi di arrivare a un compromesso quando necessario, èla possibilità di una diramazione del codice: l'abilità di ciascuno di prendere una copia del codice sorgente e partire con un progetto concorrente, cosa nota come forchetta. La cosa paradossale è che la eventualità di forchette nei progetti di software libero è usualmente una forza molto più grande che le forchette reali, che sono molto rare. Poichè una forchetta è un male per chiunque (per le ragioni esaminate in dettaglio in sezione chiamata «Le Diramazioni» in Capitolo 8, Gestire i Volontari), più seria diventa la minaccia di una forchetta, più le persone sono desiderose di un compromesso per evitarla.
Le forchette, o piuttosto il potenziale delle forchette, sono la ragione per cui non vi sono veri dittatori nei progetti di software libero. Questo può sembrare una affermazione sorprendente, considerato quanto è comune ascoltare qualcuno chiamato “dittatore” o “tiranno” in un dato progetto open source. Ma questo tipo di tirannia è speciale, completamente differente dall'intendere convenzionale della parola. Immaginate un re i cui sudditi potessero copiare il suo intero regnare in ogni momento e muoversi a copiarne il ruolo nella misura in cui lo vedano giusto. Non governerebbe un tale re molto diversamente da uno i cui sudditi fossero soggetti a sottostare al suo dominio, qualunque cosa facesse?
Questo è il perché anche progetti non formalmente organizzati come democrazie, in pratica, sono democrazie quando ci si trova davanti a importanti decisioni. La replicabilità suggerisce possibilità di diramazione; la possibilità di diramazione suggerisce consenso. Può ben essere che ognuno voglia far riferimento a un unico leader (l'esempio più famoso è Linus Torvalds nello sviluppo del kernel di Linux), ma ciò avviene perchè essi scelgono di fare così in un modo completamente non cinico e sinistro. Il dittatore non ha un magico potere sul progetto. Una proprietà chiave di tutte le licenze open source è che esse non danno a una parte un maggior potere che a qualche altra di decidere come il codice possa essere cambiato o usato. Se il dittatore stesse improvvisamente incominciando a prendere cattive decisioni, ci sarebbe un'agitazione, seguita probabilmente da una rivolta e da una scissione. A meno che, indubbiamente, le cose raramente vanno così lontano, il dittatore venga prima a un compromesso.
Ma appunto perché la possibilità di diramazione mette un limite superiore al potere che uno può esercitare su un progetto non significa che non ci siano importanti differenze su come il progetto viene condotto. Voi non avete bisogno del fatto che ogni decisione venga presa alla richiesta di ultima spiaggia di chi sta prendendo in considerazione una forchetta. Cosa che seccherebbe molto rapidamente e toglierebbe energia al lavoro reale. Le prossime due sezioni esaminano differenti modi di organizzare un progetto in modo tale che la maggior parte delle decisioni vadano per il verso giusto. Questi due esempi sono in qualche modo idealizzati come casi limite. Molti progetti cadono con una certa continuità fra di essi.
Il modello di dittatore benevolo è esattamente ciò che suona come: l'autorità delle decisioni finali di pende da un'unica persona, che, in virtù della personalità e dell'esperienza, si prevede che la usi saggiamente.
Sebbene “dittatore benevolo” (o BD) sia il termine standard per questo ruolo, è bene pensare ad esso come “arbitro approvato dalla comunità” o “giudice”. Generalmente i dittatori benevoli, in realtà non prendono tutte le decisioni, e nemmeno la maggioranza delle decisioni. Non è verosimile che un'unica persona potrebbe avere la necessaria esperienza per prendere costantemente buone decisioni lungo tutta l'area del progetto, e comunque, gli sviluppatori di qualità non starebbero intorno se non avessero qualche influenza sull'orientamento del progetto. Quindi i dittatori benevoli non dettano molto. Invece essi lasciano che le cose vadano avanti da sole attraverso discussioni ed esperimenti ogni volta che sia possibile. Essi partecipano a tutte le discussioni di persona, ma coma regolari sviluppatori, ma facendo riferimento a un reggente di area che ha più esperienza. Solo quando è chiaro che non può essere raggiunto il consenso, e che la maggior parte del gruppo vuole che qualcuno guidi le decisione in modo che lo sviluppo vada avanti, puntano i pedi e dicono “questo è il modo in cui deve andare”. La riluttanza a prendere decisioni per decreto è una prerogativa condivisa virtualmente da tutti i dittatori benevoli di successo; è una delle ragioni per cui essi riescono a mantenere il ruolo.
Essere un BD richiede una combinazione di caratteristiche. C'è bisogno, prima di tutto, di una sensibilità ben affilata per quanto riguarda la propria influenza nel progetto, che di volta in volta porta a un auto controllo. Nei primi stadi di una discussione un singolo non esprimerebbe opinioni e conclusioni con così tanta certezza che altri potrebbero percepire come inutile il dissentire. La gente deve esprimere pubblicamente e liberamente le idee, anche sciocche idee. E' inevitabile che il BD anche esprimerà una idea sciocca di volta in volta, certamente, e quindi il ruolo richiede anche una abilità a rendersi conto e a riconoscere quando uno ha preso una cattiva decisione sebbene questo sia un caratteristica che ogni buon sviluppatore dovrebbe avere, specialmente se rimane col progetto per un lungo tempo. Ma la differenza è che i BD può permettersi un lapsus di volta in volta senza preoccuparsi per sua credibilità a lungo termine. Gli sviluppatori con minore anzianità possono non sentirsi così sicuri, così il BD dovrebbe esprimere critiche o decisione contrarie con una certa sensibilità per quanto riguarda il peso che hanno le sue parole, sia tecnicamente che psicologicamente.
Il BD non deve aver bisogno di avere la più evidente esperienza di tutti nel progetto. Egli deve aver sufficiente esperienza sul suo codice, e capire e commentare ogni cambiamento in considerazione, ma questo è tutto. La posizione di BD è né acquisita né mantenuta per virtù di una abilità nello scrivere codice che intimidisce. Quello che è importante è l'esperienza e il senso dell'insieme nella progettazione non necessariamente la capacità di produrre una buona progettazione su richiesta, ma la capacitò di riconoscere la buona progettazione, qualunque sia la sua origine.
E' comune che il dittatore benevolo sia il fondatore del progetto. Ma questa è più una correlazione che una causa. Il tipo di qualità che rende uno capace di avviare un progetto con successo—competenza tecnica, capacità di persuadere altri ad unirsi ad esso, ecc...—sono esattamente le qualità di cui ogni BD avrebbe bisogno. E, certamente, i fondatori incominciano con una sorta di anzianità automatica, che può spesso essere sufficiente a far si che la dittatura benevola appaia il percorso di minor difficoltà per tutti gli interessati.
Ricordate che la possibilità per la forchetta esiste in entrambi i casi. Un BD può fare una diramazione dal progetto appunto facilmente come ciascun altro, e alcuni hanno occasionalmente fatto così, quando hanno visto che la direzione che essi volevano che prendesse il progetto era diversa da quella che gli altri sviluppatori volevano. A causa della possibilità di diramazione, non ha importanza se il dittatore benevolo ha la radice (i privilegi di amministratore del sistema) sui principali servers del progetto. La gente a volte parla del controllo del server come se essa fosse la fonte principale del potere in un progetto, ma nei fatti ciò è irrilevante. Il fatto di aggiungere o rimuovere le password di invio su un particolare server riguarda solo la copia del progetto che è sul server. Un prolungato abuso di questo potere, da parte del BD o di qualche altro, spingerebbe solamente lo sviluppo a spostarsi su un altro server.
Se il progetto dovrebbe avere un dittatore benevolo o se andrebbe meglio con qualche sistema meno centralizzato, dipende largamente da chi è disponibile a ricoprire il ruolo. Come regola generale, se è semplicemente ovvio per ognuno chi dovrebbe essere il BD, allora quella è la strada da prendere. Ma se non c'è un candidato per il BD immediatamente scontato, allora il progetto dovrebbe usare un processo di di presa delle decisioni decentralizzato, come descritto nella prossima sezione.