Se state dirigendo programmatori in un progetto open source, teneteli abbastanza affinché essi acquisiscano esperienza tecnica e politica—un paio di anni come minimo. Certamente nessuno progetto nè open né closed source trae beneficio dall'uscita e dall'ingresso troppo frequente. Il bisogno di un nuovo arrivato di imparare le cordate dovrebbe essere un deterrente in ogni ambiente. Ma la penalizzazione è anche più forte nei progetti open source, perché i programmatori che escono portano con sé non solo la loro conoscenza del codice, ma anche il loro status nella comunità e le relazioni umane che hanno stabilito lì.
La credibilità che uno sviluppatore ha accumulato non può essere trasferita. Per fare il più ovvio esempio, uno sviluppatore che arriva non può ereditare l'accesso all'invio da uno che se ne va (vedere sezione chiamata «Il Danaro Non Può Comprare Ciò Che Amate» più avanti in questo capitolo), così se il nuovo sviluppatore non ha già l'accesso all'invio, avrà da inviare correzioni fin quando lo avrà. Ma l'accesso all'invio è solo la più misurabile manifestazione di perduta influenza. Uno sviluppatore di lungo termine conosce anche tutti i vecchi argomenti che sono stati triti e ritriti nelle liste di discussione. Un nuovo sviluppatore, non avendo memoria di quelle discussioni, può cercare di riportare a galla gli argomenti, portando a una perdita di credibilità per la vostra organizzazione. Gli altri potrebbero meravigliarsi “Non possono ricordarsi di ogni cosa? Un nuovo sviluppatore non avrà nemmeno un senso politico delle personalità del progetto, e non saranno capaci di influenzare gli orientamenti del progetto così rapidamente o così regolarmente come lo fa uno che vi è rimasto per lungo tempo.
Preparate i nuovi arrivati con un programma di ingaggio controllato. Il nuovo sviluppatore deve essere in contatto la comunità di pubblico sviluppo sin dal primo giorno, partendo con la correzione di bugs e le operazioni di ripulita, in modo che possano imparare il codice base e acquistare una reputazione nella comunità, e non accendere lunghe e complesse discussioni di progetto. In tutto questo tempo, uno o più sviluppatori dovrebbero essere a disposizione per domande e risposte, e dovrebbero leggere ogni post che i nuovi arrivati facciano nella mailing list degli sviluppatori, anche se in essa ci sono threads a cui gli sviluppatori non rivolgerebbero l'attenzione. Ciò aiuterebbe il gruppo a scorgere le potenziali rocce prima che i nuovi arrivati vi rimangano incagliati. Incoraggiamenti privati, dietro le scene e consigli possono anche aiutare molto, specialmente se il nuovo arrivato non è abituato ad una massiccia parallela revisione fra pari del suo codice.
Quando CollabNet ingaggia un nuovo sviluppatore per lavorare a Subversion, noi ci sediamo intorno a un tavolo e scegliamo qualche bug aperto per la nuova persona perché lui ci affondi i denti. Noi discuteremo le linee bozza delle soluzioni, e poi assegneremo almeno uno sviluppatore esperto per (pubblicamente) revisionare le correzioni che il nuovo arrivato posterà. Tipicamente non guarderemo la correzione prima che la lista degli sviluppatori la veda, sebbene lo potremmo se vi fosse qualche ragione. La cosa importante è che il nuovo sviluppatore passi attraverso il processo della pubblica revisione, imparando il codice base e simultaneamente e abituandosi a ricevere critiche da parte di perfetti sconosciuti. Ma noi cerchiamo di coordinare i tempi in modo che la nostra revisione venga immediatamente dopo che la patch è stata postata. Così la prima revisione che la lista vede è la nostra, cosa che può essere utile e impostare il tono delle altre revisioni. Ciò contribuisce anche all'idea che la nuova persona deve essere presa seriamente: se gli altri vedono che noi stiamo impiegando il tempo a fare dettagliate revisioni con esaurienti spiegazioni e riferimenti negli archivi dove è appropriato, apprezzeranno ciò come una forma di training che sta andando avanti, e ciò probabilmente significa investimento a lungo termine. Questo li renderà più ben disposti verso lo sviluppatore, almeno nella misura di spendere un tempo extra nel rispondere alle domande e nel revisionare le correzioni.