Wenn Sie in einem Projekt ein bezahlter Entwickler sind, dann legen Sie frühzeitig die Richtlinien fest, was das Geld kaufen kann, und was nicht. Das bedeutet nicht, dass Sie es zweimal Täglich in den Foren wiederholen müssen müssen um Ihre noble und unbestechliche Natur klarzustellen. 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 Sie sich dem Potential dafür bewusst sind.
Ein perfektes Beispiel hierfür, ist in dem Subversion Projekt aufgekommen. Subversion wurde im Jahr 2000 von CollabNet angefangen, die von Anfang an als Arbeitgeber für mehrere Entwickler 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 hatte dann schon mit dem Programmieren angefangen. Obwohl Subversion sicherlich noch in seiner Anfangsphase war, hatte es bereits eine Entwicklergemeinschaft, 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 dem Entwickler Verteiler 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 indem er den direkten Commit-Zugriff auf die Repository des Projekts anbietet.
CollabNet hatte Mike ausdrücklich eingestellt, um an Subversion zu arbeiten. Bei denen die ihn kannten, zweifelte keiner an seine Fähigkeiten als Programmier oder seine 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 gleich am ersten Arbeitstag, einfach Commit-Zugriff zu geben. Wir wussten aber, dass wir einen Präzedenzfall setzen würden. Wenn wir Mike von Oben herab Zugriff auf die Repository gegeben hätten, käme es der Aussage gleich, dass CollabNet das Recht hat die Richtlinien des Projekts zu ignorieren, einfach nur weil es der größte Geldgeber war. Obwohl dieser Schaden nicht unbedingt gleich ersichtlich wäre, würde es langsam dazu führen, dass unbezahlte Entwickler sich ihrer Rechte beraubt fühlen. Andere müssen sich in dem Projekt behaupten—Collabnet kann sich seinen Einfluss einfach erkaufen.
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 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 wurde wie von allen erwartet angenommen.
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ätere Angriffe auf seine Motive. Bei einer hitzigen Debatte, greifen Leute manchmal auf Angriffe zürück ohne technischniche Bedeutung, um die Schlacht für sich zu entscheiden. Der Haupt-Geldgeber bietet durch seine tiefe Beteiligung und offensichtliche Sorgen über die Richtung die 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 beschreibt in ihrem Blog, wie die Entwicklergemeinschaft von Tomcat, Sun dazu brachte, seine eigenen Entwickler die gleichen Richtlinien für Commit-Zugriff zu befolgen, wie die Entwickler außerhalb von Sun.)
Weil Geldgeber nach den selben 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, sowie derer die für den Geldgeber arbeiten, zu sehen, und sich entsprechen 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.