Inhaltsverzeichnis
Die erste Frage, die Leute über freie Software fragen ist für gewöhnlich: "Wie funktioniert es? Was hält ein Projekt am laufen? Wer trifft die Entscheidungen?". Ich bin immer unzufrieden mit den faden Geschmack der Antworten über die Leistungsgesellschaft, dem Geist der Zusammenarbeit, Code der für sich selbst spricht, usw. Tatsache ist, die Frage ist nicht so leicht zu beantworten. Leistung, Zusammenarbeit und laufender Code gehören zwar alle dazu, helfen aber kaum den alltäglichen Ablauf in einem Projekt zu verstehen und sagen nichts darüber aus, wie Konflikte gelöst werden.
Dieses Kapitel versucht, die gemeinsamen strukturellen Grundbausteine erfolgreicher Projekte aufzuzeigen. Mit "erfolgreich" meine ich nicht nur im Sinne technischer Qualität, sondern auch die betriebliche Gesundheit und Überlebensfähigkeit. Die betriebliche Gesundheit ist die andauernde Fähigkeit des Projekts, neue Codebeiträge und Entwickler aufzunehmen, sowie auf neue Bug Meldungen reagieren zu können. Überlebensfähigkeit ist die Fähigkeit des Projekts, unabhängig von irgendeinem Beteiligten oder Geldgeber fortbestehen zu können—betrachten Sie es als die Wahrscheinlichkeit für das Weiterleben eines Projekts, selbst wenn alle Gründungsmitglieder ihre Sachen packen und sich etwas anderem widmen würden. Technischer Erfolg ist nicht schwer zu erreichen, aber ohne eine solide Entwicklergemeinschaft kann ein Projekt vielleicht nicht mit dem Wachstum des anfänglichen Erfolgs oder mit dem Verlust charismatischer Individuen zurechtkommen.
Es gibt verschiedene Wege, solch einen Erfolg zu erreichen. Manche benutzen die formale Struktur einer Regierung, um Debatten zu lösen, neue Entwickler einzuladen (manchmal auch auszuladen), neue Funktionen zu planen usw. Andere haben weniger formelle Strukturen, dafür aber eine bewusste Zurückhaltung der Teilnehmer, um eine gerechte Atmosphäre herzustellen, indem sich Leute auf diese quasi Regierungsform verlassen können. Beide Wege führen zum gleichen Ziel: das Gefühl einer beständigen Institution, die durch Gewohnheiten und Abläufe unterstützt wird, die alle Beteiligten gut verstehen. Diese Eigenschaften sind bei selbst organisierenden Systemen noch wichtiger, als bei solchen mit einer zentralen Verwaltung, da jeder sich darüber im Klaren ist, dass ein paar faule Äpfel die ganze Kiste verderben können, zumindest eine Zeit lang.
Die unverzichtbare Zutat, die Entwickler in einem freien Softwareprojekt verbindet, ist die Möglichkeit einen Fork[36] vom Code zu machen: jeder kann sich eine Kopie des Quellcodes nehmen und ein konkurrierendes, freies Softwareprojekt anfangen, die als Fork bezeichnet wird. Das paradoxe daran ist, dass die Möglichkeit für einen Fork, für freie Software Projekte meistens ein viel größerer Antrieb ist, als ein echter Fork, der nur sehr selten vorkommt. Da ein Fork schlecht für alle ist (die Gründe dafür werden in „Abspaltungen“ im Kapitel Kapitel 8, Leitung von Freiwilligen genauer untersucht), sind mehr Beteiligte bereit Kompromisse einzugehen, wenn die Gefahr für ein Fork besteht.
Ein Fork, oder vielmehr das Potential dafür, ist der Grund, dass Freie-Software-Projekte keine wirklichen Diktatoren haben. Das klingt überraschend wenn man bedenkt, wie viele "Diktatoren" oder "Tyrannen" es bei verschiedenen Open Source Projekten gibt. Diese Art der Tyrannei ist aber etwas Besonderes, recht unterschiedlich zu dem gewöhnlichen Verständnis des Wortes. Stellen Sie sich einen König vor, dessen Untertanen jederzeit eine Kopie seines Königreichs machen könnten, indem sie selbst nach eigenem Ermessen regieren könnten. Würde dieser König sich nicht völlig anders verhalten, als einer dessen Untergebenen, an ihn gebunden wären, unabhängig von seinem Verhalten?
Deshalb sind selbst Projekte ohne eine formal demokratische Struktur in der Praxis trotzdem Demokratien, zumindest bei wichtigen Entscheidungen. Die Möglichkeit das Projekt zu kopieren impliziert die Möglichkeit für einen Fork; das wiederum impliziert Konsens. Es mag sein, dass alle auf einen Anführer verweisen (das bekannteste Beispiel ist wohl Linus Torvalds bei der Entwicklung vom Linux Kernel), aber nur deshalb, weil sie es sich so ausgesucht haben, was ganz und gar nicht ironisch oder zynisch gemeint ist. Der Diktator hat keinen magischen Einfluss auf das Projekt. Eine wesentliche Eigenschaft aller Open Source Lizenzen ist, dass keine einzelne Partei die Entscheidungsgewalt über Änderungen am Code oder seine Nutzung hat. Wenn der Diktator plötzlich anfangen würde schlechte Entscheidungen zu treffen, gäbe es Unruhe, irgendwann gefolgt von einem Aufstand und letztendlich einem Fork. So weit kommt es aber meistens nicht, da der Diktator vorher Kompromisse eingeht.
Aber nur weil die Möglichkeit für ein Fork eine Obergrenze für die Macht eines Einzelnen in einem Projekt setzt heißt das nicht, es gäbe keine wesentliche Unterschiede, bei der Leitung von Projekten. Sie wollen nicht jede Entscheidung auf die Frage hinauslaufen lassen, ob jemand einen Fork in Betracht zieht. Das würde sehr schnell ermüdend werden, und Energie von echter Arbeit abziehen. Die nächsten beiden Abschnitte untersuchen die verschiedenen Wege Projekte so zu organisieren, dass die meisten Entscheidungen reibungslos verlaufen. Diese beiden Beispiele sind zugegeben idealisierte Grenzfälle; viele Projekte bewegen sich irgendwo dazwischen.
Das Modell des gütigen Diktators entspricht genau dem, wonach es sich anhört: Die letzte Entscheidungsgewalt liegt bei einer Person, von der man aufgrund ihrer Persönlichkeit und Erfahrung erwartet, dass sie weise damit umgeht.
Auch wenn der Begriff "gütiger Diktator", im Englischen bekannt als "benevolent dictator" (oder BD), der übliche Begriff für diese Rolle ist, wäre es besser ihn als einen von der Gemeinschaft anerkannten Vermittler oder Richter zu betrachten. Im Allgemeinen treffen gütige Diktatoren nicht alle oder auch nur die meisten Entscheidungen. Es ist ohnehin unwahrscheinlich, dass eine einzelne Person genügend Kenntnisse hat, um in einem größeren Projekt durchweg gute Entscheidungen treffen zu können. Hochwertige Entwickler werden sich nicht lange am Projekt beteiligen, wenn sie nicht zumindest einen Stück weit Einfluss auf seine Richtung haben. Deshalb diktieren gütige Diktatoren nicht besonders viel. Stattdessen lassen sie möglichst viel ohne ihr Zutun, durch Diskussionen oder Experimente entscheiden. Sie nehmen zwar auch selber an diesen Diskussionen teil, jedoch nur als gewöhnliche Entwickler, oftmals verweisen sie auf einen Zuständigen, mit mehr Kenntnissen über einen bestimmten Bereich. Nur wenn es klar ist, dass kein Konsens erreicht werden kann und dass der größte Teil der Gruppe eine Entscheidung haben will, damit die Entwicklung fortgesetzt werden kann, sprechen sie ein Machtwort. Der Widerwille Entscheidungen durch Gebote zu treffen, ist ein Wesenszug, den praktisch alle erfolgreichen gütigen Diktatoren teilen; er ist einer der Gründe, dass sie es schaffen, diese Rolle zu behalten.
Ein gütiger Diktator braucht eine Kombination verschiedener Wesenszüge. Erstens bedarf es eines feinsinniges Gespürs für den eigenen Einfluss im Projekt, das wiederum Zurückhaltung mit sich bringt. In der frühen Phase einer Diskussion sollte man nicht seine Meinungen und Folgerungen mit einer solchen Sicherheit ausdrücken das andere das Gefühl bekommen, es wäre sinnlos zu widersprechen. Menschen sollten die Freiheit haben ihre Ideen auszudrücken, selbst blöde Ideen. Es lässt sich natürlich nicht vermeiden, dass der gütige Diktator ab und zu selber eine blöde Idee vorschlägt, weshalb die Rolle auch die Fähigkeit erfordert, die eigenen schlechten Entscheidungen zu erkennen und sie als solche zu akzeptieren—wobei das ein Wesenszug ist, den jeder gute Entwickler aufweisen sollte, insbesondere wenn er lange beim Projekt bleibt. Der Unterschied ist aber, dass der gütige Diktator sich ab und zu solche Patzer leisten kann, ohne sich über sein Ruf all zu viele Sorgen machen zu müssen. Neue Entwickler werden sich weniger selbstsicher fühlen, also sollte der gütige Diktator seine Kritik mit etwas Gespür, sowohl für das technische als auch das psychologische Gewicht seiner Worte formulieren.
Der gütige Diktator muss nicht die besten technischen Fähigkeiten im Projekt haben. Er muss lediglich gut genug sein, um selber am Code zu arbeiten und einen Kommentar zu einer in Frage stehenden Änderung abgeben zu können, mehr aber nicht. Die Position des gütigen Diktators kann man sich weder durch einschüchternd gute Programmierfähigkeiten aneignen noch behalten. Wichtig ist vor allem Erfahrung und ein allgemeines Gespür für die Architektur von Quellcode—nicht unbedingt die Fähigkeit, auf Befehl guten Code zu produzieren, sondern die Fähigkeit, selber guten Code unabhängig von der Quelle zu erkennen.
Der gütige Diktator ist auch häufig der Gründer des Projekts, was sich aber eher so ergibt, als das es ein Grund wäre. Die Qualitäten die es ermöglichen, ein Projekt erfolgreich anzufangen—technische Kompetenz, die Fähigkeit andere zur Beteiligung überzeugen zu können, usw.—sind genau die gleichen Qualitäten, die jeder gütiger Diktator besitzen muss. Natürlich besitzen die Gründer auch automatisch eine gewisse Erfahrung mit dem Projekt, was ausreichen kann, damit eine gütige Diktatur für alle Beteiligte als der einfachste Weg erscheint.
Bedenken Sie, dass ein Fork aus beiden Richtungen droht. Ein gütiger Diktator kann genau so wie jeder andere einen Fork anfangen, und das haben gelegentlich schon welche gemacht sobald sie das Gefühl bekamen, dass sie das Projekt in eine andere Richtung führen wollten, als die Mehrheit der übrigen Entwickler. Da jeder die Möglichkeit zu einem Fork hat ist es egal, ob der gütige Diktator vollen Zugriff auf die Server des Projekts hat oder nicht. Leute reden manchmal vom Zugriff auf die Server, als sei er die ultimative Quelle der Macht in einem Projekt, tatsächlich ist er aber bedeutungslos. Die Fähigkeit, Benutzer zur Versionsverwaltung hinzuzufügen oder zu entfernen, beeinflusst nur die Kopie des Projekts die auf dem Server liegt. Anhaltender Missbrauch dieser Macht, ob vom gütigen Diktator oder jemand anderem, würde einfach zum Umzug der Entwicklung auf einem anderen Server führen.
Ob Ihr Projekt einen gütigen Diktator haben sollte oder besser mit einem zentralisierten System laufen würde, hängt größtenteils davon ab, wer die Rolle einnehmen könnte. Eine gute Faustregel ist: wenn für alle klar ist, wer der gütige Diktator sein sollte, dann ist das der richtige Weg. Wenn es aber keinen offensichtlichen Kandidaten gibt, sollte das Projekt wahrscheinlich ein zentralisiertes System für Entscheidungen benutzen, wie im nächsten Abschnitt beschrieben.