Inhaltsverzeichnis
Das erste, was viele über freie Software wissen wollen, ist meist: "Wie funktioniert das? Was hält ein Projekt am Laufen? Wer trifft die Entscheidungen?". Ich bin immer unzufrieden mit dem faden Geschmack der Antworten über die Leistungsgesellschaft, den 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, sagen aber nichts über den täglichen Ablauf in einem Projekt, oder wie Konflikte gelöst werden.
Dieses Kapitel soll zeigen, welche Grundbausteine zu einem erfolgreichen Projekt gehören. Mit "erfolgreich" meine ich nicht nur die technischer Qualität, sondern auch die Gesundheit der Gemeinschaft und seine Überlebensfähigkeit. Die Gesundheit bezieht sich auf die Fähigkeit eines Projeks, neue Codebeiträge und Entwickler anzulocken, sowie auf neue Bug-Meldungen reagieren zu können. Überlebensfähigkeit bedeutet, 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. Technischer Erfolg ist leicht zu erreichen, aber ohne eine solide Entwicklergemeinschaft wird ein Projekt scheitern, sobald es wächst, Erfolg hat oder ein charismatisches Mitglied verliert.
Es gibt verschiedene Wege zu diesem Erfolg. Manche benutzen formale Lsitungsstrukturen um ihre Debatten zu lösen, neue Entwickler einzuladen (manchmal auch auszuladen), neue Funktionen zu planen usw. Andere haben weniger formelle Strukturen, dafür halten sich die Teilnehmer bewusst zurück, um eine gerechte Atmosphäre herzustellen, in der 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.
Entwickler in einem freien Softwareprojekt, sind durch eine unverzichtbare zutat verbunden. Es ist die Möglichkeit, es zu forken[35]: jeder kann eine Kopie des Quellcodes hernehmen und ein neues Projekt starten. Es wird als Fork bezeichnet und steht meistens in Konkurrenz zu dem ursprünglichen Projekt. Das paradoxe daran ist, dass die Möglichkeit für einen Fork, für meistens ein viel größerer Antrieb ist, als ein echter Fork, die sehr selten sind. Ein Fork ist schlecht für alle (die Gründe dafür werden in „Abspaltungen“ im Kapitel Kapitel 8, Leitung von Freiwilligen genauer untersucht), also 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, völlig verschieden von 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?
Projekte sind deshalb, selbst 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, und das ist ganz und gar nicht ironisch oder zynisch gemeint. 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.
Die Möglichkeit für ein Fork gibt zwar eine Obergrenze für die Macht eines Einzelnen in einem Projekt, trotzdem gibt es 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. Hochrangige 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 Beteiligten 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.