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, für ein neues, nicht-diktatorisches System—bzw. eine neue Verfassung einführen. Die Gruppe wird vielleicht nicht beim ersten oder zweiten Mal diese Gelegenheit wahrnehmen, letztendlich werden sie es aber; sobald sie es tun, ist es unwahrscheinlich, dass es jemals rückgängig gemacht wird. Dieser Vorgang ist auch logisch: Wenn eine Gruppe bestehend aus N Personen, einer bestimmten Person Macht zuspricht, 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 gesalbter 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, macht es kaum eine Schritt zurück.
Die Einzelheiten dieser Systeme variieren zwar erheblich, es gibt aber zwei Gemeinsamkeiten: Erstens, die Gruppe arbeitet meistens mittels Konsens; zweitens gibt es eine formale Einrichtung zur Abstimmung, auf die man zurückgreifen kann, wenn 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 vorschlägt, man habe sich geeinigt und keiner widerspricht. Die Person, die den Konsens vorschlägt, sollte natürlich genau formulieren worauf man sich einigt, und welche Tätigkeiten sich daraus ergeben, wenn sie nicht ohnehin offensichtlich sind.
Die meisten Unterhaltungen in einem Projekt drehen sind um technische Themen, wie der beste Weg, einen Fehler zu beheben, ob eine neue Funktion hinzugefügt werden soll oder nicht, wie streng Schnittstellen dokumentiert werden sollen, usw. Regierungen basierend auf Konsens funktionieren gut, weil sie nahtlos mit der eigentlichen technischen Diskussion verläuft. Am Ende der Diskussion ist man sich meistens einig über den richtigen Kurs. Oft schreibt jemand einen 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 auch 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 nur 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, wenn jemand aus Versehen einen Commit in der Annahme macht, dass alle einverstanden sind, nur um nachher mit Einwänden konfrontiert zu werden. Diese Einwände fangen typischerweise mit einer obligatorischen Entschuldigung dafür an, dass man die vorherige Diskussion verpasst hat, wobei man dies auslassen kann, falls in den Archiven des E-Mail-Verteilers keine Aufzeichnung der Diskussion zu finden ist. 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 gibt dem Projekt eine Möglichkeit, die Auswirkungen schlechter oder übereilter Urteile rückgängig zu machen. Das wiederum gibt den Leuten die Freiheit ihren Instinkten zu vertrauen, wie viel Rückmeldung nötig ist bevor man etwas macht.
Der Ablauf um Konsens zu erreichen muss deshalb auch nicht sonderlich formal sein. Die meisten Projekten machen es nach Gefühl. Kleine Änderungen können ohne Diskussion gemacht werden, oder mit minimaler Diskussion und abschließendem 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 annehmen das Konsens herrscht, da niemand bei einer wichtigen Diskussion ausgelassen werden sollte, nur weil er nicht oft genug seine E-Mail abgerufen hat.
Wenn sich also jemand sicher ist was getan werden muss, sollte er einfach weitermachen. Das gilt nicht nur für Fehler, sondern auch für Aktualisierungen an der Webseite, Änderungen an der Dokumentation und alles andere was wahrscheinlich nicht kontrovers sein wird. 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 Leute nicht ermutigen, eigensinnig zu werden. 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 immer das Gefühl, das Bewegung mit Tatkraft einhergeht, und sind weniger bereit eine Änderung rückgängig zu machen, als sie von vornherein zu verhindern. Wenn ein Entwickler diese Tatsache jedoch missbraucht, indem er eine potentiell kontroverse Änderung zu schnell einpflegt, können und sollten Leute sich beschweren und dem Entwickler engere Grenzen setzen, bis sich die Lage verbessert.
Es wird zwangsläufig Debatten, bei denen man sich einfach nicht einig wird. Wenn alle anderen Möglichkeiten einen Stillstand aufzulösen fehlschlagen, sollte man abstimmen. Bevor eine Abstimmung aber stattfinden kann, muss es eine klare Auswahl auf dem Stimmzettel geben. Auch hier verläuft die technische Diskussion wieder glücklich mit den Entscheidungsabläufen des Projekts. 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 zu einer Wahl kommen. Wenn die Vermittler ihre Arbeit gut machen, werden sie glaubhaft eine Wahl abhalten können wenn es Zeit dafür wird, und die Gruppe wird diese Stimmzettel annehmen. 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 Wahl 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 „Schwierige Leute“ im Kapitel Kapitel 6, Kommunikation für eine Beschreibung wie man mit solchen Quertreibern umgehen sollte.
Denken Sie daran die Wahlform festzulegen, da es viele verschiedene gibt und Leute falsche Annahmen darüber treffen könnten, 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 http://de.wikipedia.org/wiki/Wahl_durch_Zustimmung für weitere Details über Zustimmungs-Wahlen. Lassen Sie sich aber nicht zu einer Debatte verleiten, welches Wahlsystem benutzet werden soll (dann stünden Sie nämlich vor einer Debatte über ein Wahlsystem, um über ein Wahlsystem abzustimmen!). Zustimmungs-Wahlen sind auch gut weil es sehr wenig an ihnen zu beanstanden gibt—es ist 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 den E-Mail-Verteiler 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 lösen. 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 über das Problem zu denken und schließlich zu einer für alle zufriedenstellende Lösung. Selbst wenn ohne solche Vorschläge, ist es meistens trotzdem besser einen Kompromiss auszuhandeln als eine Wahl zu halten. Nach einem Kompromiss, ist keiner ganz glücklich, aber zumindest gibt es anders als bei Wahlen keinen der völlig unzufrieden ist. Politischen 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 alle anderen sind es 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. Statt dessen 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 plötzlich eher bereit machen Kompromisse einzugehen und 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, bei denen alle sich einig sind, dass jede Kompromisslösungen schlimmer ist als irgend eines der Kompromisse. Bei 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 ist es, was die Wählerschaft belehrt, also kann ein frühes Ende dieser Diskussion die Qualität des Ergebnisses verringern.
(Denken Sie daran, dass diese Empfehlung widerwillig Wahlen auszurufen nicht für Wahlen über die Aufnahme von Änderungen gilt, die in „Stabilisierung Einer Neuen Version“ im Kapitel Kapitel 7, Paket Erstellung, Veröffentlichung, und Tägliche Entwicklung 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 oder für ihre besseres Urteilsvermögen andereanzuerkennen.
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 in der Repository zu pflegen, solle es klar gestellt werden, dass es bei eingeschränkten 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 dem E-Mail Verteiler Tendenzen zeigt Unruhe zu stiften oder Behinderungen zu verursachen, sollte die Gruppe sich gut überlegen ob er die Commit Berechtigungen 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 eines der wenigen Stellen an denen Geheimhaltung angemessen ist. Sie können keine Wahlen über Kandidaten auf dem öffentlichen E-Mail Verteiler halten, da es die Gefühle (und den Ruf) des Kandidaten verletzen könnte. Der übliche Weg ist statt dessen, für ein vorhandener Committer an einen privaten Verteiler zu schreiben, ausschließlich mit den anderen Commiter, mit dem Vorschlag für den neuen Kandidat. Die anderen Committer geben ihre ehrliche Meinung, mit 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 er 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 die Entfernung eines Committers, obgleich das hoffentlich niemals nötig sein wird. Siehe „Committer“ im Kapitel Kapitel 8, Leitung von Freiwilligen 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 wie Leute die Software tatsächlich benutzen passt, ist eine Lösung, auf dem E-Mail Verteiler des Projekts darüber abstimmen zu lassen. Diese sind in Wirklichkeit eher Meinungsumfragen als Abstimmungen, aber die Entwickler können wenn sie wollen die Ergebnisse als bindend betrachten. Wie bei jeder Meinungsumfrage, erklären Sie den Beteiligten, dass es eine Möglichkeit gibt Vorschläge zu machen: Wenn jemand etwas besseres einfällt, was nicht bei der Umfrage angeboten wird, kann ihre 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 anzuhalten, zumindest lange genug, um weiter darüber zu diskutieren. Sie können ein Veto irgendwo zwischen einem starken Einspruch und handfeste 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 ihr 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 http://www.apache.org/foundation/voting.html. 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.