Se avete uno sviluppatore pagato nel progetto, allora stabilite delle linee guida su ciò che il denaro può comprare e ciò che non può comprare. Ciò non significa che dovete postare due volte al giorno nella mailing list ripetendo la vostra nobile e incorruttibile natura. Significa solo che dovreste essere in guardia nel caso doveste disinnescare le tensioni che potrebbero crearsi per i soldi. Non è il caso di di partire assumendo che le tensioni sono lì; dovete dimostrare una consapevolezza che esse hanno la potenzialità di nascere.

Un perfetto esempio di questo ci viene dal progetto Subversion. Subversion fu avviato nel 2000 da CollabNet, che era stata la principale finanziatrice sin dal suo inizio, pagando i salari di molti sviluppatori (esclusioni di garanzia: io sono uno di essi). Poco dopo che il progetto incominciò, noi ingaggiammo un altro sviluppatore, Mike Pilato, per congiungere gli sforzi. Ma allora la codifica era già partita. Anche se Subversion era ancora molto ai primi stadi, era già una comunità di sviluppo con una serie di regole base.

L'arrivo di Mike sollevò una interessante questione. Subversione aveva già una politica su come un nuovo sviluppatore consegue l'accesso all'invio. Primo, egli invia alla mailing list alcune correzioni. Dopo che un numero sufficiente di correzioni sono arrivate da parte di altri che hanno l'accesso all'invio, per vedere se il nuovo collaboratore sa quello che sta facendo, qualcuno propone che egli giusto invii direttamente (questa proposta è privata ed è descritta in sezione chiamata «Quelli Che Fanno gli Invii»). Dato per acquisito l'accordo di quelli che avevano l'accesso all'invio uno di essi invia una email al nuovo sviluppatore e gli propone l'accesso diretto all'invio al deposito del progetto.

CollabNet aveva ingaggiato Mike per lavorare specificatamente a Subversion. Fra quelli che già lo conoscevano, non c'era dubbio sulle sue capacità nello scrivere codice e sulla sua sollecitudine nel lavorare al progetto. Inoltre gli sviluppatori volontari avevano molto buone relazioni con gli impiegati di CollabNet, e molto probabilmente non avrebbero obiettato se noi avessimo dato l'acceso all'invio a Mike il giorno che fu ingaggiato. Ma noi sapevano che avremmo creato un precedente. Se noi avessimo concesso a Mike l'accesso all'invio per decreto avremmo detto che CollabNet aveva il diritto di ignorare le linee guida del progetto, semplicemente perché era il finanziatore principale. Mentre il danno di ciò non era necessariamente immediatamente evidente, avrebbe avuto il risultato che i non salariati si sarebbero sentiti privati del diritto di voto. Altre persone hanno da guadagnarsi il loro accesso all'invio —CollabNet giusto lo compra.

Così Mike accettò di di iniziare il suo impiego a CollabNet come qualsiasi altro volontario, senza l'accesso all'invio. Egli mandava correzioni alla mailing list, dove esse potevano essere revisionate, e lo erano, da chiunque. Noi anche dicemmo che stavamo facendo così deliberatamente nella mailing list, in modo che non si sarebbe potuta perdere la puntualizzazione. Dopo un paio di giorni di concreta attività di Mike, qualcuno (non ricordo se era un collaboratore di CollabNet, o no) lo propose per l'accesso all'invio, e lui fu accettato, come sapevamo che sarebbe stato.

Questo tipo di coerenza vi dà una credibilità che il denaro non può mai comprare. E la credibilità è una moneta da avere nelle discussioni tecniche: è una immunizzazione contro il fatto di avere i propri motivi messi in discussione in un secondo momento. A caldo sembrerà che la gente vinca la battaglia con argomenti non tecnici. Il finanziatore principale del progetto, a causa del suo profondo coinvolgimento e dell'ovvio interesse alle direzioni che i progetto prende, presenta un obiettivo più grande degli altri. Essendo scrupolosi nell'osservare le linee guida del progetto sin dalla partenza, il finanziatore si fa grande quanto gli altri.

(Vedere anche il blog di Denise Cooper a http://blogs.sun.com/roller/page/DaneseCooper/20040916 per una storia simile sull'accesso all'invio. Cooper era allora una “Diva Open Source”—ricordo che era il suo titolo ufficiale—e all'entrata del blog lei racconta come la comunità di sviluppo di Tomcat spinse Sun a mantenere i propri sviluppatori allo stesso standard di accesso all'invio degli sviluppatori non Sun.)

Il bisogno che i fondatori stiano alle stesse regole di chiunque altro significa anche che il modello di amministrazione della Benevola Dittatura (vedere sezione chiamata «I Dittatori Benevoli» in Capitolo 4, L'Infrastruttura Sociale e Politica) è leggermente più difficile da far cadere in presenza di un finanziamento, specialmente se il dittatore lavora per il finanziatore principale. Siccome una dittatura ha poche regole, è difficile per il finanziatore provare che essa sta venendo governata secondo gli standard della comunità, anche quando lo è. E' certamente non impossibile; essa richiede appunto un leader del progetto che sia capace di vedere le cose dal punto di vista degli sviluppatori esterni, allo stesso modo di quelli del finanziatore, e agisca in accordo con essi. Anche allora, è probabilmente una buona idea avere propositi non dittatoriali sedendo al vostro posto, pronti a essere messi in evidenza nel momento di di qualche indicazione di diffuso malcontento nella comunità.