Wenn Sie ein bezahlter Entwickler in einem Projekt sind, dann stellen Sie frühzeitig Richtlinien auf, die festlegen, was für Geld käuflich ist und was nicht. Das bedeutet nicht, dass Sie es zweimal täglich in den Foren wiederholen müssen, um Ihre noble und unbestechliche Natur zu verdeutlichen. Es bedeutet lediglich, dass Sie auf Gelegenheiten achten sollten, um Spannungen zu entschärfen, die durch Geld entstehen könnten. Sie müssen nicht von vorhandenen Spannungen ausgehen; Sie müssen allerdings zeigen, dass es das Potential dazu gibt.
Ein perfektes Beispiel hierfür hat das Subversion-Projekt zu bieten. Subversion wurde im Jahr 2000 von CollabNet gestartet, das von Anfang an als Arbeitgeber für mehrere Entwickler und der größte Geldgeber für das Projekt gewesen ist (Anmerkung: Ich bin einer davon). Bald nach Beginn des Projekts stellten wir einen weiteren Entwickler ein, Mike Pilato, um dem Projekt beizutreten. Wir hatten schon mit dem Programmieren angefangen und obwohl Subversion sicherlich noch in seiner Anfangsphase war, hatte es bereits eine Entwicklergemeinschaft mit wenigen einfachen Grundregeln.
Die Ankunft von Mike warf eine interessante Frage auf. Subversion hatte bereits ein Verfahren, nach dem neue Entwickler Commit-Zugriff bekamen. Zuerst reicht man ein paar Patches auf der Entwickler-Liste ein. Nachdem genügend Patches eingetroffen sind, damit anderen Committer sehen können, dass der neue Mitwirkende weiß, was er macht, schlägt jemand vor, ihm den direkten Zugriff zu gewähren (dieser Vorschlag findet im Privaten statt, wie in „Committer“ beschrieben). Angenommen die Committer stimmen überein, schreibt einer von ihnen dem neuen Entwickler eine Mail, in der er ihm den direkten Commit-Zugriff auf das Projektarchiv des Projekts anbietet.
CollabNet hatte Mike ausdrücklich eingestellt, um an Subversion zu arbeiten. Bei denen, die ihn kannten, zweifelte keiner an seinen Fähigkeiten als Programmierer oder seiner Bereitschaft, an dem Projekt zu arbeiten. Desweiteren hatten die freiwilligen Entwickler eine sehr gute Beziehung zu den Mitarbeitern von CollabNet und hätten wahrscheinlich keine Einwände, Mike einfach gleich am ersten Arbeitstag Commit-Zugriff zu geben. Wir wussten aber, dass dies einen Präzedenzfall sein würde. Wenn wir Mike von oben herab Zugriff auf das Projektarchiv gegeben hätten, käme das der Aussage gleich, dass CollabNet das Recht hätte, die Richtlinien des Projekts zu ignorieren, einfach nur, weil es der größte Geldgeber war. Obwohl dieser Schaden nicht unbedingt gleich ersichtlich gewesen wäre, hätte es langsam dazu geführt, dass unbezahlte Entwickler sich ihrer Rechte beraubt fühlen: Andere müssen sich ihren Commit-Zugriff erarbeiten – CollabNet kann ihn sich kaufen.
Mike willigte also ein, seine Arbeit bei CollabNet wie jeder andere freiwillige Entwickler anzufangen, ohne Commit-Zugriff. Er schickte Patches an die öffentlichen Foren, wo sie von allen überprüft und kritisch beurteilt werden konnten und wurden. Wir erklärten auch öffentlich unser explizites Vorgehen, um Missverständnisse zu vermeiden. Nach ein paar Wochen solider Aktivität von Mike schlug jemand (ich kann mich nicht mehr erinnern, ob es ein Entwickler von CollabNet war oder nicht) vor, ihm Commit-Zugriff zu gewähren, und er wurde akzeptiert, wie von uns erwartet.
Diese konsequente Durchsetzung verschafft einem Glaubwürdigkeit, die man mit Geld nicht kaufen kann. Und Glaubwürdigkeit ist eine wertvolle Währung bei technischen Diskussionen: Es schützt einem vor späterer Infragestellung der eigenen Motive. Bei einer hitzigen Debatte greifen Leute manchmal auf Angriffe ohne technischische Bedeutung zurück, um die Schlacht für sich zu entscheiden. Der Haupt-Geldgeber bietet durch seine tiefe Beteiligung und offensichtliche Sorgen um die Richtung, welche das Projekt nimmt, eine breiteres Ziel als die Meisten. Indem er gewissenhaft alle Richtlinien des Projekts von Anfang an wahrnimmt, stellt der Finanzier sich auf derselben Ebene wie alle anderen.
(Siehe auch den Blog von Danese Cooper bei http://blogs.sun.com/roller/page/DaneseCooper/20040916 für eine ähnliche Geschichte um Commit-Zugriff. Cooper war damals die "Open-Source-Diva" von Sun Microsystem's – ich glaube, das war ihr offizieller Titel – und sie beschreibt in ihrem Blog, wie die Entwicklergemeinschaft von Tomcat Sun dazu brachte, die gleichen Richtlinien für Commit-Zugriff für seine eigenen Entwickler zu befolgen wie für die Entwickler außerhalb von Sun.)
Weil Geldgeber nach denselben Regeln spielen müssen wie alle anderen, lässt sich das Modell der gütigen Diktatur (siehe „Gütige Diktatoren“ im Kapitel Kapitel 4, Soziale und politische Infrastruktur) nur schwer anwenden, wenn Geld im Spiel ist, insbesondere, wenn der Diktator für den Geldgeber arbeitet. Da eine Diktatur wenig Regeln hat, ist es schwierig für einen Geldgeber zu beweisen, dass er die Normen der Gemeinschaft befolgt, selbst wenn das der Fall ist. Es ist sicherlich nicht unmöglich, es erfordert aber einen Projektleiter, der in der Lage ist, die Dinge sowohl aus der Sicht der externen Entwickler als auch derer, die für den Geldgeber arbeiten, zu sehen und sich entsprechend zu verhalten. Selbst dann ist es wahrscheinlich eine gute Idee, ein nicht diktatorisches Modell bereit zu halten, welches man bei Anzeichen von breiter Unzufriedenheit in der Gemeinschaft vorschlagen kann.