Si está dirigiendo un equipo de desarrolladores en un proyecto de software libre, intente mantenerlos el tiempo suficiente para que adquieran experiencia técnica y política—un par de años como mínimo. Por supuesto que ningún proyecto, sea de código abierto o cerrado, se beneficia del intercambio incesante de programadores. La necesidad de que un recien llegado deba aprender todo de nuevo cada vez puede crear un ambiente disuasorio. Pero el castigo puede ser mayor para un proyecto de código abierto porque quienes abandonan el proyecto no sólo lo hacen con el conocimiento del código, también se llevan un status en la comunidad y las relaciones que hayan hecho.
La credibilidad acumulada por un desarrollador no puede ser transferida. El ejemplo más obvio es que un desarrollador recien incorporado no puede heredar los mismo accesos al código de quien se va (más en “El dinero no te podrá comprar el amor”), así que si el nuevo desarrollador no tiene permisos para realizar cambios, deberá enviar parches hasta que tenga estos permisos. Pero este nivel de acceso es sólo una manifestación cuantitativa de la perdida de influencia. Un desarrollador veterano tambien conoce los viejos temas que han sido tratados una y otra vez en las listas de discusión. Uno nuevo, sin tener conocimiento de estas conversaciones quizás intente sacar a flote de nuevo estos temas, llevando a una perdida de credibilidad; otros pueden que piensen: "¿Acaso esta gente no puede recordar nada?". Una nueva persona tampoco tendrá ninguna sensación política hacia las personalidades del proyecto, y no podrá influenciar la dirección del desarrollo tan rápida o sin problemas como alguien que lleva largo tiempo en el proyecto.
Hacer uso de un programa supervisado de mentoraje a los nuevos voluntarios. El nuevo desarrollador estará contacto directo con la comunidad pública de desarrollo desde el primer díam comenzando con el arreglo de errores y tareas de limpieza, para que puedan aprender la base de código y adquirir una reputación en la comunidad, sin ser un gran compromiso y discusión de diseño. Esto mientras tanto un desarrollador más experimentado puede estar disponible para asesorias, y puede supervisar cada comunicado que el novato haga a la lista de desarrollo, aun cuando esten en hilos en las cuales los desarrolladores experimentados no presenten mucha atención normalmente. Esto permitirá al grupo prevenir posibles piedras antes que el novato choque con estas. Motivación privada y ufera de las listas tambien puede ayudar mucho, especificamente si el novato no esta acostumbrado a revisiones masivas de pares en su código.
Cuando CollabNet contrata a un nuevo desarrollador para trabajar en Subversion, nos sentamos y escogemos algunos de los errores que la nueva persona pueda probarse a si mismo. Discutiremos los lineamientos técnicos de la soluciones, y despues asignar por lo menos un desarrollador experimentado para (publicamente) revise los parches que el nuevo desarrollador públique. Nostros típicamente no vemos el parche hasta que la lista de desarrollo principal lo identifica, aunque podríamos si hubiera alguna razón especial. Lo importante es que el desarrollador novato pase por el proceso de revisión pública, aprenda el código base mientras que simultaneamente se acostumbre a recibir críticas de completos extraños. Sin embargo intentamos coordinar los tiempos para que nuestras revisiones llegen inmediatamente despues que se publico el parche. De esa manera la primera revisión que la lista observe será la nuestra y ayude a marcar el tono de la conversación a otras revisiones. Tambien contribuye a la idea que esta persona se deberá tratar con seriedad: si los demas ven que que estamos poniendo de nuestro tiempo para ofrecer revisiones detalladas, con amplias explicaciones y referencias en los archivos apropiados, apreciarán que la persona esta siendo parte de algun tipo de entrenamiento, y que probablemente signifique que será una inversión a largo plazo. Esto puede hacerlos mas positivamente dispuestos en referendcia a ese desarrollador, por lo menos al grado de invertir mas tiempo explicandoles sus preguntas y revisando sus parches.