Se gere programadores num projecto de open source, mantenha-os tempo suficiente de modo a que adquiram as capacidades técnicas e políticas — pelo menos dois anos no mínimo. Claro que nenhum projecto, open source ou não, tira partido de frequente troca de programadores. A necessidade de um recém chegado aprender os detalhes de cada vez será um travão em qualquer ambiente. Mas a penalidade é ainda maior nos projectos open source, porque programadores que saiam levam com eles não só o seu conhecimento do código mas também o seu estatuto na comunidade e as relações humanas que aí tenham feito.

A credibilidade que um programador tenha acumulado não é transferida. Para escolher o exemplo mais óbvio, um programador não pode herdar o acesso de submissão de alguém que tenha saído (ver “O Dinheiro Não lhe Pode Comprar Amor” adiante neste capítulo), assim se o novo programador não tiver já acesso de submissão, terá que submeter as diferenças até o ter. Mas o acesso de submissão é só a manifestação mais mensurável dessa perca de influência. Um programador de longo prazo também conhece todos os argumentos antigos que foram apresentados e reapresentados nas listas de discussão. Um programador novo, não tendo memória dessas conversações pode tentar levantar esses tópicos novamente, levando a uma perca de credibilidade da sua organização; os outros podem imaginar que "eles não se lembram de nada?" Um novo programador não terá sentido político das personalidades do projecto, e não será capaz de influenciar a direcção do desenvolvimento de modo tão rápido e suave do que um que já por aí ande à muito tempo.

Treine novos programadores através de um programa de envolvimento supervisionado. O novo programador deve ter contacto directo público com a comunidade de desenvolvimento desde o primeiro dia, começando por correcções de erros e tarefas de limpeza, de modo a poder aprender os fundamentos do código e adquirir uma reputação na comunidade, mas não em algo grande e não sendo envolvido nas discussões de concepção. Durante algum tempo um ou mais programadores experientes devem estar disponíveis para interrogatório e devem ler cada entrada que o programador novato faça para as listas de desenvolvimento, mesmo que se tratem de ramificações as quais os programadores experientes normalmente não prestem atenção. Isto irá ajudar a que o grupo de aperceba de pedras potenciais antes que o programador novato se enterre. Orientação privada e encorajamento nos bastidores podem também ajudar muito, em especial se o novato não estiver acostumado a uma revisão do seu código feita em paralelo de modo massivo por pares.

Quando a CollabNet emprega um novo programador para trabalhar no Subversion, sentamos-nos com ele e escolhemos uns quantos erros em aberto para que essa pessoa possa ter um cheirinho. Discutiremos os aspectos técnicos gerais das soluções e depois escolheremos pelo menos um programador experiente para (publicamente) rever as diferenças que o novo programador irá (também publicamente) colocar. Normalmente não iremos sequer olhar para a diferença antes da lista principal de desenvolvimento o ver, embora o possamos fazer se houver alguma razão para isso. O importante é que o novo programador passe pelo processo de revisão pública, aprendendo as fundações do código e em simultâneo se habitue a receber críticas de completos estranhos. Mas tentamos coordenar os tempos de modo a que as nossas próprias críticas apareçam imediatamente após a colocação da diferença. Assim a primeira crítica que a lista vê é a nossa, o que pode ajudar a estabelecer o tom para as críticas dos restantes. Também contribui para a ideia de que esta nova pessoa é para ser levada a sério: se os outros virem que estamos a gastar tempo para fazermos uma crítica detalhada, com explicações profundas e referências ao arquivo quando apropriado, irão perceber que está a ser efectuada formação, e que tal será indicativo de investimento a longo prazo. Isso pode levar a que fiquem mais favoráveis em relação ao programador, pelo menos até ao ponto de gastarem um pouco mais de tempo em responder às questões e criticar diferenças.