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�.