Langzeit-Entwickler

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 angeeignete 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 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 denn garn ichts 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 die Codebasis kennenzulernen und sich einen Ruf in der Gemeinschaft zu erarbeiten, er sollte jedoch keine langwierige und verstrickte Diskussionen über Codestruktur zünden. Währenddessen sollten ein Paar erfahrene Entwickler für Fragen zur bereitstehen, die jede Nachricht des Anfängers an die Verteiler, lesen sollten, 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 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 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 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 dem Entwickler stimmen, zumindest soweit, dass sie sich ein wenig mehr Zeit nehmen, um Fragen zu beantworten und Patches zu bewerten.