Quando un progetto diventa più vecchio, tende a spostarsi altrove rispetto alla benevola dittatura. Questa non è necessariamente insoddisfazione nei riguardi di un particolare BD. E' semplicemente che il comando basato sul gruppo è “più stabile dal punto di vista dell'evoluzione”, per prendere in prestito una metafora dalla biologia. Ogni volta che un dittatore benevolo si ritira, un sistema non dittatoriale—stabilisce una costituzione, per così dire. TIl gruppo può non cogliere questa occasione la prima volta, o la seconda, ma alla fine lo farà; una volta fatto, la decisione è improbabile che sia mai revocata. Il senso comune spiega il perché: se un gruppo di N persone fosse per l'investire una persona di un potere speciale, ciò significherebbe che N - 1 persone stessero accettando una diminuzione della loro personale influenza. Le persone usualmente non vogliono fare ciò. Anche se lo facessero, la dittatura risultante sarebbe ancora condizionata. Il gruppo consacrò il BD, chiaramente il gruppo potrebbe deporre il BD. Perciò, una volta che il progetto ha abbandonato la leadership da parte di un individuo carismatico per un più formale sistema basato sul gruppo, è raro che torni indietro.
I dettagli su come questo sistema funziona variano largamente, ma ci sono due elementi comuni: uno, il gruppo lavora per consenso la maggior parte del tempo; due: c'è un formale meccanismo di voto con cui aiutarsi quando il consenso non può essere raggiunto.
Consenso ha solamente il significato di un accordo con il quale ognuno vuol vivere. Non è uno stato ambiguo: un gruppo ha raggiunto il consenso quando qualcuno propone che quel consenso è stato raggiunto, e nessuno contraddice questa affermazione. La persona che propone il consenso dovrebbe, certamente, stabilire di quale consenso di tratta, e quali azioni possono essere intraprese in conseguenza di esso, se non sono scontate.
La maggior parte delle conversazioni nel progetto sono su argomenti tecnici, come il giusto modo per correggere un bug, se o non aggiungere una funzionalità, quanto particolareggiatamente documentare le interfacce, ecc.. La conduzione basata sul consenso funziona bene perché si armonizza senza problemi con la discussione tecnica stessa. Alla fine di una discussione c'è generalesse l'accordo su che via intraprendere. Qualcuno può usualmente fare un post che è allo stesso tempo un sommario su quello che è stato deciso e una implicita proposta di consenso. Ciò fornisce anche ad ognuno un'ultima occasione per dire: “Aspettate, io non sono d'accordo su questo. Dobbiamo sviscerare ciò ancora per un po'”.
Per piccole, non controverse decisioni, la proposta di consenso è implicita. Per esempio, quando uno sviluppatore invia spontaneamente un correzione di bug, l'invio stesso è una proposta di consenso: “Io prendo per buono che tutti concordino sul fatto che questo bug debba essere corretto, e che questo sia il modo di correggerlo”. Ovviamente lo sviluppatore non dice in realtà ciò; egli semplicemente invia la correzione, e gli altri nel progetto, non si infastidiscono a dare il loro ok, perché il silenzio è consenso. Se qualcuno invia un cambiamento che non riscuote il consenso, il risultato è semplicemente che il progetto discute il cambiamento come se non fosse stato ancora inviato. Il motivo per cui ciò funziona nell'argomento della prossima sezione.
Il fatto che il codice sorgente è tenuto sotto il controllo di versione significa che si può tornare indietro dalla maggior parte delle decisioni. Il più comune modo in cui ciò avviene è che ognuno invia un cambiamento pensando erroneamente che ognuno sarebbe contento di esso, solo che si trova di fronte a obiezioni dopo il fatto. E' tipico che tali obiezioni incomincino con un obbligatorio encomio per aver evitato una precedente discussione, anche se questo si può evitare se chi fa l'obiezione non ricorda di una tale discussione negli archivi della mailing list. In un modo o nell'altro, non c'è ragione per la quale il tono della discussione debba essere differente se l'invio del cambiamento è avvenuto prima o dopo. Ogni modifica può essere annullata, almeno fino a quando modifiche dipendenti da essa siano introdotte (cioè la nuova codifica così verrebbe fermata se la modifica originaria fosse subito rimossa). Il sistema del controllo di versione dà al progetto il modo di annullare gli effetti di giudizi cattivi o frettolosi. Questo, a sua volta, libera la gente dall'affidarsi al proprio istinto su quante conferme siano necessarie prima di fare qualcosa.
Ciò significa anche che il processo dello stabilire il consenso non ha bisogno di essere molto formale. La maggior parte dei progetti con esso si comportano a sensazione. Le modifiche minori possono andare avanti confidenzialmente senza discussione, o con un minimo di discussione seguito da pochi cenni di accordo. Per le modifiche più significative, specialmente quelle che possono destabilizzare una gran quantità di codice, le persone dovrebbero aspettare un giorno o due prima di dare per acquisito che c'è il consenso, essendo razionale che nessuno dovrebbe essere marginalizzato in una importante conversazione semplicemente perché non ha controllato la posta abbastanza frequentemente.
Così, quando qualcuno confida di sapere quello che deve essere fatto, dovrebbe procedere e farlo. Questo non si applica solo alla correzione del software, ma all'aggiornamento del sito, alle modifiche della documentazione, e a ogni altra cosa, a meno che la cosa non sia controversa. Usualmente ci saranno solo poche occasioni in cui una azione avrà bisogno di essere annullata, e queste saranno trattate sulla base del caso per caso. Certamente, uno non dovrebbe incoraggiare la gente ad essere testarda. C'è ancora una differenza psicologica fra una decisione sotto discussione e una che ha già avuto effetto, anche se questa è tecnicamente reversibile. La gente pensa sempre che la velocità è alleata dell'azione e sarà leggermente più riluttante ad annullare un cambiamento che a prevenirlo innanzitutto. Se uno sviluppatore abusa di questo fatto inviando modifiche potenzialmente controverse troppo velocemente, comunque, la gente può e dovrebbe protestare e costringere quello sviluppatore a uno standard più stringente finché le cose migliorino.
Inevitabilmente alcuni dibattiti potranno arrivare al consenso. Quando tutte le altre vie per venir fuori da un punto morto falliscono, la soluzione è votare. Ma prima che sia raccolto il voto ci deve essere una chiara serie di scelte sulla scheda. Qui, di nuovo, il normale procedimento della discussione tecniche si unisce in modo benefico col procedimento del progetto di presa della decisioni. Il tipo di questione che vengono al voto spesso comprendono complessi e sfaccettati problemi. In ogni discussione così complessa ci sono usualmente una o due persone che occupano il ruolo di onesti mediatori: che postano sommari periodici dei vari argomenti e che tengono traccia di dove sono i punti di disaccordo (e di accordo). Questi sommari aiutano ciascuno a misurare quanto progresso è stato fatto e quanti problemi rimangono da essere elencati. Questi medesimi sommari possono servire come prototipo di scheda elettorale, dovrebbe diventare necessario un voto. Se gli onesti mediatori hanno fatto bene il loro lavoro, saranno capaci di chiamare con credibilità per il voto quando viene il momento, e il gruppo sarà contento di usare una scheda elettorale basata sui loro sommari di problemi. I mediatori stessi potranno esser partecipi al dibattito; non è necessario che essi rimangano superiori alla lite, fino a quando essi possono capire e rappresentare in modo imparziale i punti di vista, e non permettere che i propri sentimenti di parte gli impediscano di riassumere lo stato del dibattito in una maniera neutrale.
Il reale contenuto della scheda non è oggetto di controversie. Col tempo le materie vengono al voto, i disaccordi vengono condensati in pochi problemi chiave, con etichette riconoscibili e brevi descrizioni. Occasionalmente lo sviluppatore farà obiezione alla forma della scheda stessa. A volte il suo interessamento è legittimo, per esempio, che una scelta importante è stata lasciata fuori o non è stata descritta accuratamente. Ma altre volte uno sviluppatore può star cercando si evitare l'inevitabile, forse sapendo che il voto non andrà come lui vuole. Vedere sezione chiamata «Gente Difficile» in Capitolo 6, Comunicazione su come affrontare questo tipo do ostruzionismo.
Ricordatevi di specificare il sistema di voto, se ci sono molti differenti modi, e se la gente potrebbe potrebbe fare delle cattive supposizioni sulla procedura che viene usata. Una buona scelta nella maggior parte dei casi è il voto per approvazione, dove ogni votante può votare per quante scelte vuole nella scheda. Il voto per approvazione è semplice da spiegare a da contare, e diversamente da altri metodi, richiede un solo giro di voto. Vedere http://en.wikipedia.org/wiki/Voting_system#List_of_systems per maggiori dettagli sul voto di approvazione ed altri sistemi di voto, ma cercate si evitare di entrare in una lunga discussione su quale sistema usare (perché, certamente, allora voi stessi vi troverete in una discussione su quale sistema di voto usare per decidere quale sistema di voto usare). Una ragione per cui il voto di approvazione è una buona scelta è che è molto difficile per ognuno farvi obiezione;—è all'incirca tanto giusto quanto un sistema di voto può esserlo.
Infine portate il voto in pubblico. Non c'è bisogno di segretezza o anonimato nel voto su questioni che avete dibattuto pubblicamente comunque. Ogni partecipante deve postare il suo voto nella mailing list, in modo che ogni osservatore possa registrare e controllare il risultato per se stesso, e in modo tale che ogni cosa sia registrata negli archivi.
La cosa più difficile nel voto è determinare quando farlo. In generale passare al voto dovrebbe essere molto raro—un ultimo ricorso quando tutte le altre opzioni sono fallite. Non pensate che il voto sia un gran modo di risolvere i dibattiti. Non lo è. Esso mette fine alle discussioni e quindi mette fine a un modo creativo di pesare ai problemi. Nella misura in cui la discussione continua, c'è la possibilità che qualcuno venga fuori con una nuova soluzione che piace a tutti. Ciò avviene sorprendentemente spesso. Un dibattito acceso può produrre un nuovo modo di pensare ai problemi, e portare a proposte che possono soddisfare tutti. Anche quando non vengono fuori nuove proposte, è usualmente ancora meglio venire a un compromesso che sostenere un voto. Dopo un compromesso, ognuno e un po' scontento, mentre dopo un voto, alcuni sono scontenti mentre altri sono contenti. Da un punto di vista politico è preferibile la prima situazione: almeno ciascuno può avvertire di aver ricavato una ricompensa per la sua scontentezza. Egli può essere insoddisfatto, ma così è anche per gli altri.
Il principale vantaggio del voto è che finalmente sistema una questione in modo che ognuno possa andare avanti, ma esso la sistema con un conto delle teste, invece che con un dialogo razionale che porti tutti alla medesima conclusione. Più le persone hanno esperienza con i progetti open source, meno desiderose le trovo di sistemare le cose col voto. Invece essi cercheranno di esplorare soluzione non precedentemente considerate, o arrivare a un compromesso più forte di quanto avessero precedentemente pianificato. Sono disponibili varie tecniche per impedire di arrivare ad un voto prematuro. La più ovvia è semplicemente dire “Io penso che non siete ancora pronti per il voto”, e spiegare perché no. Un'altra è chiedere una informale (non vincolante) alzata di mano. Se il responso tende chiaramente da una parte o dall'altra, ciò spingerà alcuni a volere subito un compromesso, ovviando al bisogno di voto. Ma il modo più efficace è semplicemente offrire una nuova soluzione, o un nuovo punto di vista su una vecchia proposta, in modo che le persone si occupino nuovamente dei problemi invece di ripetere solamente i vecchi argomenti.
In certi rari casi ognuno può convenire che tutte le soluzioni di compromesso sono peggiori di quelle di non compromesso. Quando ciò avviene, votare è meno spiacevole, sia perché è più probabile arrivare a una soluzione migliore sia perché la gente non si dispiacerà troppo non importa quale sia il risultato. Anche allora il voto non dovrebbe essere affretto. La discussione che porta al voto è ciò che educa l'elettorato, cosicché fermare quella discussione può prematuramente abbassare la qualità del risultato.
(Notate che questo avvertimento a non chiamare il voto non si applica al voto di cambio inclusione descritto in sezione chiamata «Stabilizzare una Release» in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano. Lì il voto è più di un meccanismo di comunicazioni, un mezzo per registrare il coinvolgimento di uno nel processo di revisione del cambiamento, così che ognuno può dire quanta revisione ha avuto un dato cambiamento.)
Avere un sistema di voto solleva la questione dell'elettorato: chi accede al voto? Ciò ha la potenzialità di essere un problema sensibile, perché obbliga il progetto a riconoscere alcune persone come più coinvolte, o come aventi più giudizio di altre.
La miglior soluzione è assumere una distinzione esistente, l'accesso all'invio, e annettere il privilegio di votare ad esso. In progetti che offrono sia il pieno che il parziale accesso all'invio, la questione se coloro che hanno l'invio parziale possano votare dipende largamente dal procedimento col quale è concesso l'accesso all'invio. Se il progetto lo distribuisce liberalmente, per esempio come un modo di mantenere molti mezzi conferiti da terze parti nel deposito, allora dovrebbe essere chiaro che l'accesso all'invio parziale è in realtà solo per l'invio, non per il voto. Naturalmente permane la implicazione inversa: poiché i possessori del pieno invio avranno privilegi di voto, essi devono essere scelti non solo nella qualità di programmatori, ma anche in quella di membri dell'elettorato. Se qualcuno mostra tendenze distruttive o ostruzioniste nella mailing list, il gruppo dovrebbe esser molto prudente sul fatto di renderlo uno che può fare gli invii, anche se la persona è tecnicamente competente.
Lo stesso sistema di voto dovrebbe essere usato per scegliere nuove persone che possono fare l'invio, sia pieno che parziale. Ma qui c'è uno dei rari casi in cui la segretezza è appropriata. Non potete ricevere voti sulle potenziali persone con diritto di voto postati in una pubblica mailing list, perché la sensibilità (e la reputazione) dei candidati potrebbero essere ferite. Invece, il modo usuale è che uno con diritto di invio posti su una mailing list privata costituita solo da altri con diritto di invio, che propongono che a qualcuno sia concesso l'accesso all'invio. Gli altri con diritto di invio parlano di quello che pensano liberamente, sapendo che la discussione è privata. Spesso non ci sarà disaccordo, e quindi non ci sarà necessità del voto. Dopo aver aspettato pochi giorni per essere sicuri che tutti quelli con diritto di voto abbiano avuto modo di rispondere, il proponente manda una email al candidato, e gli offre l'accesso all'invio. Se c'è disaccordo, ne deriva una discussione come per ogni altra questione, con la possibilità che si arrivi a votare. Perché questo procedimento sia aperto e franco, il solo fatto che la discussione sta avendo luogo dovrebbe punto essere segreto. Se la persona in considerazione sapesse che essa sta andando avanti, e che quindi non gli è offerto l'accesso all'invio, potrebbe concludere che ha perso il voto, e presumibilmente ne sarebbe dispiaciuto. Certamente se qualcuno fa richiesta di accesso all'invio, allora non c'è scelta al di fuori di quella di prendere in considerazione la proposta e apertamente accettarla o respingerla. Se la seconda, allora la cosa dovrebbe essere fatta quanto più educatamente possibile, con una chiara spiegazione: “A noi piacciono le tue rettifiche, ma non ne abbiamo viste a sufficienza” o “Noi apprezziamo tutte le tue rettifiche, ma esse richiedevano considerevoli miglioramenti prima di poter essere applicate, così non ci sentiamo a nostro agio nel darti già l'accesso all'invio. Speriamo che ciò cambierà, tuttavia, col tempo” Ricordate, ciò che state dicendo potrebbe riuscire come un colpo, a seconda del livello e della confidenza con la persona. Cercate di vederla dal loro punto di vista quando gli mandate l'email.
Poiché aggiungere una nuova persona che possa fare gli invii è più conseguenziale che la maggior parte delle decisioni di una volta, alcuni progetti hanno speciali requisiti per il voto. Per esempio essi possono richiedere che la proposta riceva almeno n voti positivi e nessun voto negativo, che una super maggioranza voti a favore. Il parametro esatto non è importante; l'idea base è far si che il gruppo sia cauto nell'aggiungere nuove persone che possono fare l'invio. Simili o più stringenti requisiti possono applicarsi ai voti per rimuovere uno che può fare gli invii, sebbene si speri che ciò non sarà mai necessario. Vedere sezione chiamata «Quelli Che Fanno gli Invii» in Capitolo 8, Gestire i Volontari di più sugli aspetti del non voto per aggiungere o rimuovere le persone che possono fare gli invii.
Per certi tipi di voto può essere utile espandere l'elettorato. Per esempio, se gli sviluppatori semplicemente non possono capire se la scelta di una data interfaccia si adatta al modo in cui la gente in realtà usa il software, un modo è chiedere a tutti gli iscritti alla mailig list del progetto di votare. Questi sono in realtà sondaggi piuttosto che voti, ma gli sviluppatori possono scegliere di trattare il risultato come vincolante. Come con ogni sondaggio, assicuratevi che sia chiaro ai partecipanti che c'è una opzione inclusa: se qualcuno pensa che non sia offerta una migliore scelta nelle domande del sondaggio, la sua risposta può riuscire come il più importante risultato del sondaggio.
Alcuni progetti permettono una specie di voto conosciuto come veto. Un veto è un modo per lo sviluppatore per mettere un alt a un frettoloso o mal considerato cambiamento. Pensate a un veto come a qualcosa fra una forte obiezione e una ostruzione. Il suo esatto significato varia da un progetto all'altro. Alcuni progetti rendono molto difficile ignorare un veto; altri consento loro di essere ignorati da un regolare voto della maggioranza, magari dopo un rallentamento forzato per una ulteriore discussione. Ogni veto dovrebbe essere accompagnato da una accurata spiegazione; un veto senza una tale spiegazione dovrebbe essere considerato invalido o una comparsa.
Con il veto viene l'abuso del veto. A volte gli sviluppatori sono troppo desiderosi di sollevare steccati per sbarazzarsi di un veto, quando in realtà quello per cui erano stati chiamati era un maggior discussione. Potete prevenire un abuso di veto con l'essere molto riluttanti verso il veto voi stessi e richiedendolo quando qualcun altro usa il suo veto troppo spesso. Se necessario potete ricordare al gruppo che i veti sono vincolanti solo finché il gruppo è d'accordo che lo siano dopotutto se una chiara maggioranza di sviluppatori vuole X, allora X sta per succedere in un modo o nell'altro. O gli sviluppatori che pongono i veti fanno marcia indietro, o il gruppo deciderà di sminuire il significato di un veto.
Potete vedere gente scrivere “-1” per esprimere un veto. Questo uso proviene dall'Apache Software Foundation che ha estremamente strutturato il procedimento di voto e di veto descritto a http://www.apache.org/foundation/voting.html. Gli standard Apache si sono diffusi agli altri progetti, e voi vedrete le loro convenzioni usate con varie sfumature in molti posti nel mondo dell'open source. Tecnicamente “-1” non indica sempre un veto formale anche in accordo con lo standard Apache, ma in modo informale ciò viene preso a significare un veto, o almeno una obiezione molto forte.
Come i voti, i veti possono applicarsi retroattivamente. Non sta bene per obiettare a un veto, sulla base del fatto che il cambiamento in questione è stato già inviato, o che l'iniziativa è stata presa (a meno che non sia qualcosa di irrevocabile, come l'emissione un comunicato stampa). D'altra parte un veto che arrivi con un ritardo di settimane o di mesi verosimilmente non è da prendere molto sul serio, nè dovrebbe esserlo.