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 Meritokratie, 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 technische 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 aufzunehmen, sowie auf eingehende Bug-Meldungen zu reagieren. Ü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 formelle Leitungsstrukturen 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 selbstorganisierenden 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: die Möglichkeit, es zu forkende. Gabel im Sinne einer Gabelung: jeder kann eine Kopie des Quellcodes nehmen und daraus ein neues Projekt starten. Dieses wird als Fork bezeichnet und steht meistens in Konkurrenz zu dem ursprünglichen Projekt. Das paradoxe daran ist, dass die Möglichkeit von Forks zumeist ein viel größerer Antrieb ist, als ein tatsächlich bestehender Fork, der übrigens sehr selten eintritt. Ein Fork ist schlecht für alle (die Gründe dafür werden in im Kapitel genauer untersucht), je ernster die Gefahr eines Forks wird, desto größer ist die Bereitschaft der Projektbeteiligten, Kompromisse einzugehen, um diese Gefahr abzuwenden. 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, in dem sie selbst nach eigenem Ermessen regieren könnten. Würde dieser König sich nicht völlig anders benehmen, als einer dessen Untertanen auf Gedeih und Verderb an ihn gebunden sind? Projekte sind deshalb, auch ohne formal demokratische Struktur, faktisch Demokratien, zumindest bei wichtigen Entscheidungen. Die Kopierbarkeit von Projekten impliziert die Aufspaltbarkeit; diese wiederum impliziert Konsens. Möglich, dass eine große Bereitschaft besteht, einem Anführer zu vertrauen (das bekannteste Beispiel ist wohl Linus Torvalds bei der Entwicklung des Linux-Kernels), aber nur deshalb, weil sie es sich so ausgesucht haben, und das ist ganz und gar nicht ironisch oder zynisch gemeint. Der Diktator hat keine magische Macht über das Projekt. Eine wesentliche Eigenschaft aller Open-Source-Lizenzen ist, dass sie keiner einzelnen Partei die Entscheidungsgewalt über Änderungen am Code oder seine Nutzung einräumen. Wenn der Diktator plötzlich anfangen würde, schlechte Entscheidungen zu treffen, würde das Unruhe hervorrufen, gefolgt von einer Revolte und einem Fork. Aber so weit kommt es meist nicht, da der Diktator vorher Kompromisse eingeht. Aber auch wenn die Aufspaltbarkeit die Obergrenze für die Macht Einzelner im Projekt bestimmt, heißt das nicht, dass es nicht große Unterschiede in der Leitung von Projekten geben würde. Sie werden nicht jede einzelne Entscheidung auf die Frage hinauslaufen lassen wollen, ob das jemanden zu einem Fork veranlassen könnte. Das würde ermüdend wirken und eine Menge Energie von der eigentlichen 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 mit dieser weise 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 ein Stückweit 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 offensichtlich wird, 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 gegen Entscheidungen von oben 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, dass 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, wohl aber die Fähigkeit, 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, erfolgreich ein Projekt zu starten – technische Kompetenz, die Fähigkeit andere zur Beteiligung überzeugen zu können, usw. – sind genau die Qualitäten, die jeder gütige Diktator besitzen muss. Natürlich besitzen die Gründer auch automatisch eine gewisse Erfahrung mit dem Projekt, was ausreichen kann, allen Beteiligten eine gütige Diktatur als einfachsten Weg erscheinen zu lassen. 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 hatten, das sie das Projekt in eine andere Richtung führen sollten, 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. Die Leute reden mitunter vom Zugriff auf den 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 mit einem weniger zentralisierten System besser 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 dezentrales System für Entscheidungen benutzen, wie im nächsten Abschnitt beschrieben. Mit zunehmenden Alter neigen Projekte dazu, vom Modell des gütigen Diktators zu offeneren demokratischen Systemen zu wechseln. Das ist nicht zwangsläufig auf Unzufriedenheit mit einem bestimmten gütigen Diktator zurückzuführen. Ein gemeinschaftliches Regierungssystem ist auf Dauer einfach stabiler. Immer wenn ein gütiger Diktator zurücktritt, oder versucht die Entscheidungsgewalt gleichmäßiger zu verteilen, bekommt die Gruppe eine Gelegenheit, ein neues, nicht-diktatorisches System einzuführen – sich sozusagen eine neue Verfassung zu geben. Die Gruppe wird diese Gelegenheit vielleicht nicht beim ersten oder zweiten Mal wahrnehmen, doch letztendlich wird sie es; sobald sie es tut, ist es unwahrscheinlich, dass das jemals rückgängig gemacht wird. Dieser Vorgang ist auch logisch: Wenn eine Gruppe bestehend aus N Personen, einer bestimmten Person Macht zuspräche, würde das bedeuten, dass N - 1 Personen damit einverstanden wären, ihre eigene Macht zu verringern. Menschen können sich auf so etwas im Allgemeinen nicht einigen. Selbst wenn, wäre das entstandene System auch nur bedingt eine Diktatur: Ein von der Gruppe erkorener gütiger Diktator kann genau so gut durch die Gruppe wieder abgesetzt werden. Sobald ein Projekt von der Führung durch eine einzelne charismatische Person zu einem formaleren gemeinschaftlichen System wechselt, wird es schwerlich einen Schritt zurück tun. Die Einzelheiten dieser Systeme variieren zwar erheblich, es gibt aber zwei Gemeinsamkeiten: Erstens, die Gruppe arbeitet meist im Konsens; zweitens, es gibt eine formale Einrichtung zur Abstimmung, auf die man zurückgreifen kann, sobald kein Konsens erreicht werden kann. Konsens bedeutet lediglich eine Vereinbarung, mit der jeder leben kann. Es ist kein unklarer Zustand: Eine Gruppe hat Konsens erreicht, wenn jemand behauptet, man habe sich geeinigt und keiner widerspricht. Die Person, die den Konsens konstatiert, sollte natürlich genau formulieren worauf man sich einigt, und welche konkreten Schritte sich daraus ergeben, falls diese nicht offensichtlich sind. Die meisten Unterhaltungen in einem Projekt drehen sind um technische Themen, z.B. den besten Weg, einen Fehler zu beheben, ob eine neue Funktion hinzugefügt werden soll oder nicht, wie streng Schnittstellen dokumentiert werden sollen, usw. Konsens-basierte Entscheidungen funktionieren gut, weil sie nahtlos mit der technischen Diskussion verlaufen. Am Ende der Diskussion ist man sich meist über den richtigen Kurs einig. Oft schreibt jemand eine abschließende Zusammenfassung der Entscheidungen, und schlägt dadurch implizit den Konsens vor. So gibt es eine letzte Möglichkeit, Einspruch zu erheben, um das Thema gründlicher zu besprechen. Bei kleinen, nicht kontroversen Entscheidungen ist der Konsensvorschlag implizit. Wenn ein Entwickler zum Beispiel spontan einen Commit macht, um einen Fehler zu beheben, ist das zugleich ein Konsensvorschlag: "Ich nehme an, dass wir alle darüber einstimmen, dass dieser Fehler behoben werden muss und dies der Weg dazu ist". Natürlich sagt das der Entwickler nicht tatsächlich; Er macht einfach den Commit, und die Anderen im Projekt machen sich nicht die Mühe, ihre Zustimmung zu geben, da Schweigen hier Zustimmung bedeutet. Wenn jemand einen Commit macht, bei dem sich herausstellt, dass es keinen Konsens gab, wird die Änderung so besprochen, als wäre sie noch gar nicht gemacht. Der Grund dafür ist Thema des nächsten Abschnitts. Die Tatsache, dass der Quellcode des Projekts in der Versionsverwaltung gehalten wird, hat zur Folge, dass die meisten Entscheidungen leicht rückgängig gemacht werden können. Der häufigste Fall ist, dass jemand einen Commit in der falschen Annahme ausführt, dass alle einverstanden seien, und sich kurze Zeit später mit Einwänden konfrontiert zu sehen. Diese Einwände beginnen im Allgemeinen mit der obligatorischen Entschuldigung dafür, dass man die vorangegangene Diskussion verpasst habe, wobei man dies auslassen kann, falls in den Archiven der Mailingliste keine Aufzeichnung der Diskussion zu finden sind. So oder so sollte der Ton nach dem Commit nicht anders sein als davor. Jede Änderung kann rückgängig gemacht werden, zumindest solange, bis davon abhängige Änderungen eingeführt werden (wie neuer Code, der nicht mehr funktionieren würde, wenn man die Änderung plötzlich herausnehmen würde). Die Versionsverwaltung eröffnet dem Projekt die Möglichkeit, Auswirkungen schlechter oder übereilter Entscheidungen rückgängig zu machen. Das wiederum gibt den Leuten die Freiheit, sich in der Frage auf ihren Instinkten zu verlassen, wie viel Rücksprache eine Aktion erfordert. Der Vorgang der Konsenssuche muss deshalb auch nicht sonderlich formal sein. In den meisten Projekten läuft das nach Gefühl. Kleine Änderungen können ohne Diskussion erledigt werden, oder nach minimaler Diskussion und beiläufigem Abnicken. Bei größeren Änderungen, besonders solchen die eine Menge Code instabil machen könnten, sollten die Beteiligten ein bis zwei Tage warten, bevor sie Konsens annehmen, denn bei einer so wichtigen Diskussion sollte niemand übergangen werden, nur weil er seine E-Mails nicht oft genug abgerufen hat. Wenn sich also jemand sicher ist, was getan werden muss, sollte er es einfach durchziehen. Das gilt nicht nur für Fehlerbehebungen, sondern auch für Aktualisierungen der Website, Änderungen an der Dokumentation und alles andere, für das Kontroversen unwahrscheinlich sind. Es gibt selten Fälle, bei denen etwas rückgängig gemacht werden muss, und diese können jeder für sich behandelt werden. Natürlich sollte man Menschen nicht zu Eigensinnigkeit ermutigen. Es gibt immer noch einen psychologischen Unterschied zwischen einer Entscheidung, die zur Debatte steht und einer, die bereits getroffen wurde, selbst wenn sie technisch umkehrbar ist. Menschen haben das Gefühl, dass Bewegung mit Tatkraft einhergeht, und sind deshalb seltener bereit eine Änderung rückgängig zu machen, als sie von vornherein zu verhindern. Wenn ein Entwickler diese Tatsache missbraucht, indem er eine potentiell kontroverse Änderung zu schnell einpflegt, kann und sollte man sich beschweren und dem Entwickler engere Grenzen setzen, bis hier Besserung eintritt. Zwangsläufig wird es Debatten geben, bei denen man sich einfach nicht einig wird. Wenn alle anderen Möglichkeiten fehlschlagen, einen Stillstand aufzulösen, sollte man abstimmen. Bevor aber eine Abstimmung stattfinden kann, muss es eine klare Auswahl auf dem Stimmzettel geben. Auch hier läuft die technische Diskussion glücklicherweise mit den Entscheidungsabläufen des Projekts zusammen. Die Art von Fragen, die zu einer Abstimmung führen, drehen sich oftmals um komplexe, mehrschichtige Angelegenheiten. Bei jeder dieser komplexen Diskussionen gibt es meistens ein oder zwei Personen mit der Rolle des ehrlichen Vermittlers: sie fassen periodisch die verschiedenen Argumente zusammen und behalten den Überblick über die zentralen Streitpunkte (und Übereinstimmungen). Diese Zusammenfassungen helfen allen, den Fortschritt einzuschätzen und erinnern daran, welche Punkte noch offen sind. Sie dienen auch als Prototypen für die Stimmzettel, sollte es zur Abstimmung kommen. Wenn die Vermittler ihre Arbeit gut machen, werden sie glaubhaft abstimmen können, sobald das nötig wird, und die Gruppe wird diese Stimmzettel akzeptieren. Die Vermittler können an der Debatte teilnehmen; es ist nicht nötig, dass sie sich aus dem Schlachtgetümmel heraushalten, solange sie die Ansichten Anderer verstehen und angemessen repräsentieren können, und die Meinungen ihrer Partei sie nicht daran hindert, den Stand der Diskussion auf eine neutrale Art zusammenzufassen. Der tatsächliche Inhalt des Stimmzettels ist normalerweise nicht kontrovers. Bis es zu einer Abstimmung kommt, hat sich die Meinungsverschiedenheit auf ein paar Kernpunkte reduziert, mit erkennbaren Namen und kurzen Beschreibungen. Ab und zu wird ein Entwickler die Form des Stimmzettels beanstanden. Manchmal sind diese Bedenken gerechtfertigt, wenn beispielsweise ein wichtiger Punkt auf dem Stimmzettel ausgelassen oder nicht richtig beschrieben wurde. Zuweilen kann ein Entwickler aber auch lediglich die Absicht haben, das Unausweichliche hinauszuschieben, vielleicht mit dem Wissen, dass die Wahl nicht zu seinen Gunsten ausfallen wird. Siehe im Kapitel für eine Beschreibung wie man mit solchen Quertreibern umgehen sollte. Denken Sie daran, die Wahlform festzulegen, da es viele verschiedene gibt und es falsche Annahmen darüber geben könnte, welche Form benutzt wird. Meistens ist eine Zustimmungs-Wahl eine gute Entscheidung, bei der jeder Wähler für so viele der Kandidaten auf den Stimmzettel stimmen kann wie er möchte. Zustimmungs-Wahlen sind einfach zu erklären und auszuzählen, und im Gegensatz zu anderen Wahlsystemen erfordern sie nur einen Wahlgang. Siehe für weitere Details über Zustimmungs-Wahlen. Lassen Sie sich aber nicht zu einer Debatte verleiten, welches Wahlsystem benutzt werden soll (dann fänden Sie sich schnell in einer Debatte über ein Wahlsystem, um über ein Wahlsystem abzustimmen!). Zustimmungs-Wahlen sind auch gut, weil es sehr wenig an ihnen zu beanstanden gibt – sie sind so gerecht, wie ein Wahlsystem nur sein kann. Und schließlich sollten die Wahlen öffentlich gehalten werden. Es gibt keinen Grund für Geheimhaltung oder Anonymität bei einer Wahl, bei der zuvor sowieso öffentlich debattiert wurde. Lassen Sie jeden Beteiligten seine Stimmen an die Mailingliste schicken, damit jeder Beobachter selber die Ergebnisse nachrechnen und überprüfen kann, und alles in den Archiven aufgezeichnet wird. Das schwerste bei Wahlen ist zu bestimmen, wann es dafür Zeit ist. Im allgemeinen sollten Wahlen sehr selten sein – als letztes Mittel, wenn alle anderen fehlgeschlagen sind. Betrachten Sie Wahlen nicht als eine tolle Möglichkeit, Debatten zu klären. Das sind sie nicht. Sie beenden Diskussionen und dadurch auch kreative Überlegungen zu dem Problem. So lange die Diskussion weitergeht, kann jemand auf eine neue Lösung kommen, die allen gefällt. Das geschieht überraschend oft: Eine lebhafte Debatte kann zu einer neuen Art führen, das Problem anzugehen und schließlich zu einer für alle zufriedenstellenden Lösung. Selbst ohne solche Vorschläge ist es meist dennoch besser, einen Kompromiss auszuhandeln als eine Wahl abzuhalten. Nach einem Kompromiss ist keiner ganz glücklich, aber zumindest gibt es anders als bei Wahlen keinen der völlig unzufrieden ist. Politisch gesehen ist die erste Situation vorzuziehen: Zumindest bekommt jeder das Gefühl, etwas für seine Unzufriedenheit bekommen zu haben. Er mag unzufrieden sein, aber das sind alle anderen auch. Der Hauptvorteil einer Abstimmung ist die Lösung der Frage, damit alle endlich weitermachen können. Es wird aber durch das Zählen von Köpfen erledigt, anstatt durch einen vernünftigen Dialog, der alle zum selben Ergebnis führt. Die Bereitschaft, Fragen durch Wahlen zu lösen, scheint mir mit zunehmender Erfahrung der Teilnehmer bei Open-Source-Projekten abzunehmen. Stattdessen versuchen Sie, vorher nicht in Erwägung gezogene Lösungen zu erkunden, oder größere Kompromisse einzugehen, als sie ursprünglich geplant hatten. Es gibt verschiedene Möglichkeiten, um eine voreilige Wahl zu verhindern. Die offensichtlichste ist einfach zu sagen, "Ich denke nicht, dass wir schon bereit für eine Wahl sind" und zu erklären warum. Eine weitere ist, eine informelle (nicht bindende) Zählung durchzuführen. Wenn die Reaktion klar in die eine oder andere Richtung tendiert, wird es manche Teilnehmer plötzlich kompromissbereiter und damit eine formelle Wahl überflüssig machen. Die effektivste Lösung ist aber, einfach eine neue Lösung anzubieten, oder eine neue Sicht auf einen alten Vorschlag, damit Leute sich erneut mit dem Sachverhalt befassen, anstatt immer wieder die gleichen Argumente zu wiederholen. Es gibt auch seltene Fälle, in denen alle sich einig sind, dass jede Kompromisslösung schlimmer ist als jeder der Nicht-Kompromisse. In einem solchen Fall gibt es weniger an einer Abstimmung auszusetzen, sowohl weil es wahrscheinlich zu einer besseren Lösung führt, als auch weil die Beteiligten nicht sonderlich unglücklich mit der Lösung sein werden, egal wie es ausgeht. Auch dann sollte man die Wahl nicht übereilen. Die Diskussion, die der Wahl vorausgeht, bildet die Wählerschaft auch weiter, also kann ein frühes Ende dieser Diskussion die Qualität des Ergebnisses schmälern. (Denken Sie daran, dass diese Empfehlung zur Zurückhaltung beim Ausrufen von Wahlen nicht für Wahlen zur Aufnahme von Änderungen gilt, die in im Kapitel beschrieben werden. Dort sind Wahlen eher ein Mittel zur Kommunikation, eine Möglichkeit seine Beteiligung an der Überprüfung einer Änderung kundzugeben, damit alle erkennen können ob eine Änderung ausreichend überprüft wurde). Bei einem Wahlsystem stellt sich die Frage nach der Wählerschaft: Wer darf wählen? Das kann eine sensible Frage sein, da es das Projekt zwingt, bestimmte Personen offiziell für ihre Beteiligung anzuerkennen oder für ihr besseres Urteilsvermögen gegenüber anderen anzuerkennen. Die beste Lösung ist einfach eine vorhandene Unterscheidung wie den Commit-Zugriff zu nehmen, und das Wahlrecht daran festzumachen. Bei Projekten mit mehreren Ebenen für den Zugriff, hängt die Frage ob Personen mit geringerem Zugriff wählen können, größtenteils von dem Ablauf ab mit dem die Zugriffsrechte gewährt werden. Wenn ein Projekt sie freizügig austeilt, um beispielsweise eine Vielzahl an Programmen von dritten Parteien im Projektarchiv zu pflegen, solle es klar gestellt werden, dass es bei eingeschränktem Commit-Zugriff wirklich um die Pflege der Software geht und nicht um die Wahlberechtigung. Die umgekehrte Implikation gilt natürlich auch: Da Personen mit vollem Commit-Zugriff Wahlberechtigte sind, müssen sie nicht nur als Programmierer, sondern als Mitglieder der Wählerschaft ausgesucht werden. Wenn jemand auf der Mailingliste dazu tendiert, Unruhe zu stiften oder Behinderungen zu verursachen, sollte die Gruppe sich gut überlegen ob er die Commit-Berechtigung bekommt, selbst wenn diese Person guten Code schreibt. Das Wahlsystem selbst, sollte benutzt werden um neue Commiter zu wählen, sowohl Teil- als auch Vollberechtigte. Hier ist allerdings eine der wenigen Stellen an denen Geheimhaltung angemessen ist. Sie können keine Wahlen über Kandidaten auf der öffentlichen Mailingliste halten, da es die Gefühle (und den Ruf) des Kandidaten verletzen könnte. Der übliche Weg ist stattdessen, dass bereits bestehende Commiter an einen privaten Verteiler schreiben, ausschließlich im Kreise der anderen Committer, mit dem Vorschlag für den neuen Kandidaten. Die anderen Committer geben ihre ehrliche Meinung, in dem Wissen, dass die Diskussion privat ist. Oft wird es keinen Einspruch geben und eine Wahl ist nicht notwendig. Nachdem man ein paar Tage gewartet hat, um allen Committern genügend Reaktionszeit zu geben, schreibt der Antragsteller dem neuen Kandidaten eine E-Mail indem ihm der Commit-Zugriff angeboten wird. Wenn es Einwände gibt, wird wie bei jeder anderen Frage eine Diskussion entstehen die möglicherweise mit einer Abstimmung endet. Damit diese Diskussion offen und ehrlich abläuft, sollte die bloße Tatsache, dass sie stattfindet geheim gehalten werden. Wenn die Person die in Betracht gezogen wird davon wüsste und niemals das Angebot bekäme, könnte er daraus schließen, dass er die Wahl verloren hat und wäre wahrscheinlich gekränkt. Wenn jemand natürlich explizit nach Commit-Zugriff fragt, dann gibt es keine andere Möglichkeit als den Vorschlag in Betracht zu ziehen und ihn entweder anzunehmen oder abzuweisen. Wenn letzteres der Fall ist, dann sollte es so höflich wie möglich verlaufen, mit einer eindeutigen Erklärung: "Wir mögen deine Patches, haben davon aber bisher nicht genug gesehen", oder "Wir mögen deine Patches, mussten aber wesentliche Anpassungen machen, damit sie angewandt werden konnten, also fühlen wir uns noch nicht Wohl dabei, dir derzeit Commit-Zugriff zu geben. Wir hoffen allerdings, dass sich das mit der Zeit ändert". Bedenken Sie, dass ihre Worte der Person einen Schlag versetzen könnte, je nachdem wie selbstsicher sie ist. Versuchen Sie aus der Sicht des Empfängers zu sehen wenn Sie die E-Mail schreiben. Da es eine schwerwiegendere Entscheidung ist einen neuen Committer aufzunehmen als die meisten anderen einmaligen Entscheidungen, haben manche Projekte besondere Anforderungen für solche Abstimmungen. Es kann beispielsweise erforderlich sein, n Stimmen für und keine gegen den Kandidaten zu bekommen, oder die Zustimmung einer qualifizierte Mehrheit. Die genaue Grenze ist nicht wichtig; grunsätzlich geht es darum bei der Aufnahme Vorsicht walten zu lassen. Ähnliche, oder noch strengere, spezielle Anforderungen können bei Abstimmungen über das Entfernen eines Committers, obgleich das hoffentlich niemals nötig sein wird. Siehe im Kapitel für weiteres über Aspekte zu der Aufnahme und Entfernung neuer Committer, ohne Zusammenhang mit Wahlen. Für bestimmte Abstimmungen, kann es sich lohnen den Wahlkreis auszuweiten. Wenn die Entwickler beispielsweise einfach nicht herausbekommen, ob eine bestimmte Schnittstelle zu der Art passt, in der Leute die Software tatsächlich benutzen, ist eine Lösung, auf der Mailingliste des Projekts darüber abstimmen zu lassen. Dies sind in Wirklichkeit eher Meinungsumfragen als Abstimmungen, aber die Entwickler können die Ergebnisse als bindend betrachten, wenn sie wollen. Wie bei jeder Meinungsumfrage erklären Sie den Beteiligten, dass es eine Möglichkeit gibt, Vorschläge zu machen: Wenn jemandem etwas besseres einfällt als bei der Umfrage angeboten wird, kann seine Reaktion zu dem wichtigsten Ergebnis der Umfrage werden. Manche Projekte erlauben besondere Stimmen, bekannt als Veto. Ein Veto ist ein Weg für einen Entwickler eine übereilte oder schlecht überlegte Änderung aufzuhalten, zumindest lange genug, um weiter darüber zu diskutieren. Sie können ein Veto irgendwo zwischen starken Einspruch und handfester Obstruktion einordnen. Seine genaue Bedeutung unterscheidet sich von einem Projekt zu anderen. Manche Projekte machen es sehr schwer ein Veto aufzuheben; andere erlauben ihre Aufhebung durch eine gewöhnliche Mehrheit, etwa nach einer erzwungenen Verzögerung für weitere Diskussion. Jedes Veto sollte von einer ausführliche Erklärung begleitet werden; ein Veto ohne Erklärung sollte gleich als ungültig erachtet werden. Mit Vetos kommt das Problem des Missbrauchs. Manchmal sind Entwickler zu begierig den Einsatz zu erhöhen indem Sie ein Veto aussprechen. Sie können den Missbrauch von Vetos verhindern, indem Sie selber nur widerstreben darauf zurückgreifen, sowie indem Sie sanft darauf hinweisen wenn jemand anderes das Veto zu oft benutzt. Falls nötig, können Sie die Gruppe auch daran erinnern, dass Vetos nur so lange bindend sind, wie die Gruppe sich darüber einig ist – schließlich wird sich Änderung X durchsetzten, wenn eine klare Mehrheit der Entwickler X machen will. Entweder wird das Veto zurückgezogen, oder die Gruppe wird sich entschließen seine Bedeutung zu verringern. Sie werden Leute vielleicht "-1" schreiben sehen, um ein Veto auszudrücken. Diese Nutzung kommt von der Apache Software Foundation, die einen hochgradig strukturierten Ablauf für Abstimmungen und Vetos hat, beschrieben bei . Die Apache-Normen haben sich auf andere Projekte übertragen und Sie werden ihre Konventionen in unterschiedlichem Maße an vielen Stellen in der Open-Source-Welt beobachten können. Technisch gesehen, bedeutet "-1" nicht immer ein formelles Veto, selbst nach den Apache-Normen. Informell wird es jedoch für gewöhnlich als solches betrachtet, oder zumindest als starken Einspruch. Wie Stimmen bei einer Wahl, kann ein Veto auch im Nachhinein ausgesprochen werden. Es ist nicht in Ordnung einem Veto mit der Begründung zu widersprechen, dass die zur Debatte stehende Änderung bereits durchgeführt oder die Aktion bereits getätigt wurde (es sei denn es handelt sich um etwas unumkehrbares, wie eine Pressemitteilung). Andererseits wird und sollte ein Veto welches Wochen oder Monate später ankommt wahrscheinlich nicht sonderlich Ernst genommen werden. Irgendwann wird die Anzahl der Vereinbarungen und Übereinkünfte die in Ihrem Projekt umhergehen derart groß werden, dass sie irgendwo aufgezeichnet werden müssen. Damit ein solches Dokument rechtmäßig ist, sollten Sie klarstellen, dass es auf Diskussionen und Vereinbarungen auf den Mailinglisten beruht, die bereits in Kraft sind. Wenn Sie es zusammenstellen, verweisen Sie auf die relevanten Threads in den Archiven und immer wann Sie an einen Punkt erreichen, bei dem Sie sich nicht sicher sind, fragen Sie nochmal nach. Das Dokument sollte keine Überraschungen enthalten: Es ist keine Quelle für Vereinbarungen sondern lediglich ihre Beschreibung. Wenn es Erfolg hat, werden Leute natürlich anfangen es zu Zitieren, als eine Quelle für Autorität, was aber nur bedeutet, dass es den allgemeinen Wille der Gruppe zutreffend widerspiegelt. Dieses ist das Dokument, welches in im Kapitel angespielt wird. Wenn das Projekt noch sehr jung ist, werden Sie selbstverständlich die Richtlinien auslegen müssen, ohne den Vorteil einer langen Historie im Projekt, worauf Sie sich beziehen können. Mit zunehmender Reife der Entwicklungergemeinschaft, können Sie die Sprache anpassen um widerzuspiegeln, welche Abläufe sich tatsächlich entwickelt haben. Versuchen Sie nicht alles abzudecken. Kein Dokument kann alles umfassen, was Leute wissen müssen um an einem Projekt teilzunehmen. Viele der Konventionen die ein Projekt entwickelt werden nie ausgesprochen oder explizit erwähnt und würden von dem wichtigen aber nicht offensichtlichem Material ablenken. Es hat beispielsweise keinen Sinn, Richtlinien wie folgende zu schreiben "Seien Sie höflich und respektvoll zu anderen auf der Mailingliste und fangen Sie keine Flamewars an", oder "Schreiben Sie sauberen, lesbaren, bugfreien Code". Diese Sachen sind natürlich wünschenswert, da es allerdings kein denkbares Universum gibt, indem sie nicht wünschenswert wären, ist ihre Erwähnung der Mühe nicht wert. Wenn Leute auf der Mailingliste unhöflich sind oder fehlerhaften Code schreiben, dann werden sie nicht damit aufhören, nur weil es die Richtlinien des Projekts es vorschreiben. Solche Situationen müssen bei ihrem Auftreten behandelt werden, nicht durch pauschale Ermahnungen sich gut zu benehmen. Wenn das Projekt andererseits spezifische Richtlinien hat wie man guten Code schreibt, z.B. Regeln über die Dokumentation jeder API in einem bestimmten Format, dann sollten diese Richtlinien so vollständig wie möglich niedergeschrieben werden. Der Inhalt des Dokuments lässt sich gut bestimmen, durch die die Fragen von Neulingen sowie anhand der Beschwerden, denen erfahrene Entwickler am häufigsten begegnen. Das bedeutet nicht zwangsläufig, dass es zu einer FAQ werden sollte – es braucht wahrscheinlich eine kohärentere erzählerische Struktur, als es eine FAQ bieten kann. Es sollte aber genauso auf tatsächlichen Fragen basieren, nicht auf solchen die Sie erwarten gestellt zu bekommen. Ein Projekt mit einem gütigen Diktator, oder Mitglieder mit besonderen Vollmachten (Präsidenten, Vorsitzende, was auch immer), sollte das Dokument als gute Gelegenheit betrachten, den Ablauf für Nachfolger festzulegen. Manchmal kann das so einfach sein wie bestimmte Personen als Ersatz zu benennen, sollte der gütige Diktator das Projekt aus irgend einem Grund verlassen. Wenn es einen gütigen Diktator gibt, kann im allgemeinen nur der Diktator selber damit durchkommen einen Nachfolger zu benennen. Wenn es gewählte Vorstandsmitglieder hat, dann sollten die gleichen Abläufe die bei ihrer Wahl verwendet wurden in dem Dokument beschrieben werden. Wenn es ursprünglich keinen Ablauf gab, dann sollten Sie sich innerhalb des Projekts auf einen bestimmten Ablauf einigen bevor Sie darüber schreiben. Menschen können empfindlich sein, was hierarchische Strukturen angeht. Das wichtigste ist vielleicht klarzustellen, dass die Regeln überdacht werden können. Sollten die Konventionen in dem Dokument anfangen das Projekt zu behindern, erinnern Sie alle daran, dass es ein lebendes Spiegelbild der Absichten der Gruppe sein soll, und keine Quelle für Frustration und Behinderung. Wenn jemand es sich zur Gewohnheit macht, unangebrachterweise immer gerade dann wenn ihm Regeln im Weg stehen, darum zu bitten, diese neu zu überdenken – ist Schweigen manchmal die beste Taktik. Wenn andere mit den Beschwerden übereinstimmen, werden sie auch das Wort ergreifen und es wird offensichtlich sein, dass sich etwas ändern muss. Wenn sonst keiner zustimmt, dann wird die Person nicht sonderlich viel Resonanz erhalten und die Regeln werden so stehenbleiben wie sie sind. Zwei gute Beispiele für Projekt-Richtlinien sind der Subversion Community Guide unter und die Dokumente zur Organisation der Apache Software Foundation unter und . Die ASF ist in Wirklichkeit eine Sammlung von Software-Projekten, rechtlich als eine Gemeinnützige Organisation aufgestellt, also tendieren ihre Dokumente stärker dazu, Leitungsabläufe zu beschreiben als Konventionen für Entwickler. Sie sind es trotzdem lesenswert, denn sie stellen die gesammelte Erfahrung einer Vielzahl von Open-Source-Projekten dar.