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, vom häufigen Wechsel unter den Programmierern. Sich jedes mal neu einarbeiten zu müssen wäre in jeder Umgebung für Neulinge schwierig. 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 angehäufte 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 „Liebe kann nicht mit Geld erkauft werden“ später in diesem Kapitel), wenn also ein neuer Entwickler noch keinen Commit-Zugriff hat, wird er bis dahin Patches einreichen müssen. Commit-Zugriff ist aber nur der messbarste Ausdruck 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 Organisation führt; die anderen werden sich vielleicht wundern "ob die sich denn garn nichts merken können"? Neue Entwickler werden auch kein politisches Gespür für die Persönlichkeiten im Projekt haben und nicht in der Lage sein, die Richtung der Entwicklung so schnell oder reibungslos zu beeinflussen, wie ein alter Hase.
Trainieren Sie Neuankömmlinge mittels eines Programms der beaufsichtigten Beschäftigung. Der neue Entwickler sollte vom ersten Tag an in engem Kontakt mit der öffentlichen Entwicklergemeinschaft stehen, angefangen mit Bugfixes und Aufräumarbeiten, so dass er die Codebasis kennenlernen und sich einen Ruf in der Gemeinschaft erarbeiten kann, er sollte jedoch keine langwierige und verstrickte Diskussionen über Codestruktur zünden. Währenddessen sollten ein Paar erfahrene Entwickler für Fragen bereitstehen und jede Nachricht des Anfängers an die Verteiler lesen, sogar bei Threads, denen sie sonst keine Beachtung schenken würden. Das wird der Gruppe helfen, mögliche Steine auf dem Weg zu erkennen, bevor der Anfänger darü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 offen stehende 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, bevor er auf dem zentralen Verteiler für Entwickler zu sehen ist, auch wenn wir es, gäbe es einen Grund dazu, könnten. 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, dass wir uns Zeit nehmen um 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 dem Entwickler stimmen, zumindest soweit, dass sie sich ein wenig mehr Zeit nehmen, um Fragen zu beantworten und Patches zu bewerten.