Behalten Sie Ihre Open-Source Programmierer lange genug bei einem Projekt um sich sowohl technische als auch politische Kompetenzen aneignen können—mindestens einige Jahre. Natürlich profitiert kein Projekt, ob Open-Source oder nicht von häufig wechselnde Programmier. Sich jedes mal neu einarbeiten zu müssen wäre in jeder Umgebung für Neulinge abschreckend. Für Open-Source Projekte ist die Strafe aber noch größer, da Entwickler die ein Projekt verlassen nicht nur ihre Kenntnisse über den Code mitnehmen, sondern auch ihre Position in der Gemeinschaft sowie die dort aufgebauten menschlichen Beziehungen.
Die von einem Entwickler angeignete Glaubwürdigkeit, kann nicht übertragen werden. Das offensichtlichste Beispiel wäre wohl, dass Commit-Zugriff nicht von einem Entwickler zum Anderen vererbt werden kann (siehe „Geld kann dir keine Liebe kaufen“ später in diesem Kapitel), wenn ein neuer Entwickler also noch keinen Commit-Zugriff hat, wird er bis dahin Patches einreichen müssen. Commit-Zugriff ist aber nur die messbarste Erscheinung für den verlorenen Einfluss. Ein langjähriger Entwickler kennt auch alle alten Streitigkeiten die immer wieder in Diskussionen in den Foren aufgeflammt sind. Ein neuer Entwickler ohne Erinnerung an solche Unterhaltungen, könnte versuchen diese Themen erneut anzusprechen, was zum Verlust der Glaubwürdigkeit Ihrer Organization führt; die anderen werden sich vielleicht wundern "ob die sich den Garnichts behalten können"? Neue Entwickler werden auch kein politisches Gespür für die Persönlichkeiten im Projekt haben und werden nicht in der Lage sein die Richtung der Entwicklung so schnell oder reibungslos zu beeinflussen, wie ein alter Hase.
Lassen Sie Anfänger sich zur Einweisung, unter Beaufsichtigung, an dem Projekt beteiligen. Der neue Entwickler sollte vom ersten Tag sehr eng mit der öffentlichen Entwicklergemeinschaft arbeiten, angefangen mit Bugfixes und Aufräumarbeiten, um den Codebase kennenzulernen und sich einen Ruf in der Gemeinschaft zu erarbeiten, er sollte jedoch keine langwierige und verstrickte Diskussionen über Codestruktur zünden. Währendessen sollten ein Paar erfahrene Entwickler für Fragen zur bereitstehen, die jede Nachricht des Anfängers an die Verteiler, lesen sollten, sogar bei Threads der sie sonst keine Beachtung schenken würden. Das wird die Gruppe helfen mögliche Steine auf dem Weg zu erkennen, bevor der Anfänger drüber stolpert. Private Anregung und Hinweise im Hintergrund können auch eine große Hilfe sein, besonders wenn der Anfänger es nicht gewohnt ist, dass sein Code der Kritik durch die Gemeinschaft unterworfen ist.
Wenn CollabNet einen neuen Entwickler einstellt, um an Subversion zu arbeiten, setzen wir uns zusammen und wählen ein paar offenestehende Fehler für die neue Person, um sich erst einmal die Krallen zu schärfen. Wir diskutieren den technischen Rahmen der Lösungen und weisen dann mindestens einen erfahrenen Entwickler an (öffentlich) den vom neuling eingereichten Patch, kritisch unter die Lupe zu nehmen (alles für die Öffentlichkeit sichtbar). Normalerweise schauen wir uns den Patch nicht einmal an, vor es auf dem Zentralen Verteiler für Entwickler zu sehen ist, auch wenn wir es könnten, gäbe es dazu einen Grund. Das wichtige für den neuen Entwickler ist die öffentliche Überprüfung durchzulaufen, dabei den Codebase kennenzulernen und sich an Kritik von völlig Fremden zu gewöhnen. Wir versuchen es aber so abzustimmen, dass unsere Bewertung möglichst bald nach dem Patch kommt. Dadurch ist unsere Bewertung die erste auf dem Verteiler, was helfen kann, den Ton der nachfolgenden Bewertungen zu setzen. Es trägt auch zu der Idee bei, dass diese neue Person ernst genommen werden soll: Wenn andere sehen wie wir uns Zeit nehmen ausführliche Bewertungen zu schreiben, mit gründlichen Erklärungen und wenn angemessen Verweise auf die Archive, werden sie es als Schulungsform erkennen, was wahrscheinlich eine längerfristige Investition andeutet. Das kann sie positiver gegenüber den Entwickler stimmen, zumindest soweit, dass sie sich ein wenig mehr Zeit nehmen, um Fragen zu beantworten und Patches zu bewerten.