Entscheidungsstrukturen und -prozesse

Wie werden in (doppelt) Freien Projekten Entscheidungen getroffen? Wie sehen die Entscheidungsstrukturen und -prozesse aus?

Generell gibt es dabei kein universelles Modell, sondern jedes Projekt entwickelt seine eigenen Prozesse und Strukturen. Generell hängt die formelle Struktur von Projekten dabei stark von der Art und Größe des Projekts ab („Form follows function“).

Der kleinste gemeinsame Nenner all dieser Modelle besteht vielleicht darin, dass sie alle mehr oder weniger starke meritokratische Elemente enthalten.

Kleinere Projekte: Maintainer-Modell

Hauptsächlich in kleineren und mittleren Projekten ist das Maintainer-Modell weit verbreitet. Dabei gibt es eine Person, die Maintainer/in, die die Hauptverantwortung für das Projekt trägt und im Zweifelsfall Entscheidungen fällt. Die Maintainer/in ist normalerweise die/in Gründer/in des Projekts oder eine von dieser benannter Nachfolger/in. Verschwindet die Maintainer/in, ohne eine Nachfolger/in zu benennen, kann sich jemand in Eigeninitiative zur neuen Maintainer/in erklären, aber nur wenn sie/er behutsam vorgeht (vgl. Eric Raymond, Literatur: Freie Software).

Die Maintainer/in werden dabei bisweilen als „wohlwollende Diktator/in“ (benevolent dictator) bezeichnet. Dieser Begriff ist jedoch irreführend, da Maintainer/innen keineswegs über eine diktatorische Machtfülle verfügen. Vielmehr entspricht die Maintainer-Rolle eher dem, was in der Ethnologie als „Big Man“ bezeichnet wird. Der „Big Man“ (Big Woman?) ist der Sprecher einer egalitären Gruppe, seine Position ergibt sich aus seiner Persönlichkeit, seinen Fähigkeiten und seiner Initiative (z.B. als Gründer eines Freien Projekts), er muss sich seiner Position immer wieder würdig erweisen, sonst riskiert er, sie zu verlieren; er hat keine formelle Macht und Kommandogewalt über die Projekt/Stammesmitglieder.

Maintainer/innen treffen die ultimativen Entscheidungen in Bezug auf ein Projekt, doch sie behalten ihre Autorität auf Dauer nur dann, wenn ihre Entscheidungen mit denen der Hacker-Gemeinschaft übereinstimmen. Wenn die Beschlüsse nicht plausibel oder akzeptabel sind, kann die Gemeinde forken und das Projekt ohne die alten Maintainer weiterentwickeln. (Beispiele dafür sind Wechsel zu weniger freien Lizenzmodellen, die regelmäßig zu Projektsplits führen.)

Viele kleine Projekte werden im Wesentlichen von einer einzigen Person betrieben, dabei handelt es sich sozusagen um eine Maintainer/in ohne formelles Team.

Große Projekte

Bei der Organisation größerer Projekte gibt es diverse Varianten. In einigen Fällen ist die Organisationstruktur dabei klar definiert und dokumentiert (z.B. bei Debian: [1], [2]); bei anderen Projekten wie KDE und dem Linux-Kernel ist die Struktur ebenfalls gefestigt, aber weniger komplex und formal.

Kernteam

Bei manchen Projekten steht statt einer einzelnen (Haupt-)Maintainer/in ein Kernteam von mehreren Personen an der Spitze, die Entscheidungen unter sich aushandeln. Das Kernteam wird dabei entweder von den Entwickler/innen gewählt (z.B. NetBSD), oder die Mitglieder des Kernteams können weitere Mitglieder einladen (z.B. Netfilter).

Zwiebelförmige Struktur

Große Projekte (z.B. der Linux-Kernel oder KDE) sind meist zwiebelförmig (bzw. hierarchische Baumstruktur) aufgebaut: um die zentralen Maintainer/in (Linus Torvalds im Falle von Linux) bzw. das Kernteam (die Mitglieder der kde-core-devel im Falle von KDE) herum gibt es eine Reihe von Maintainer/inne/n bzw. Bereichsverantwortlichen, die für einzelne Teilbereiche zuständig sind, die u.U. ihrerseits wiederum auf dieselbe Weise in mehrere Bereiche unterteilt sind.

Jede Maintainer/in / Verantwortliche entscheidet dabei für ihren Teilbereich jeweils, welche Patches und Bugfixes sie annehmen und nach oben weitergeben. Maintainer für Teilbereiche werden dabei entweder von der übergeordneten Maintainer/in benannt oder es handelt sich um dabei meist die Initiator/innen eines (Teil-)Projekts oder von diesen benannte Nachfolger. Positionen werden also meist nicht aufgrund von Wahlen besetzt, sondern aufgrund einer Maintainer-Entscheidung oder einfach dadurch, dass sie eine Rolle übernimmt und sich ihrer als würdig erweisen – in beiden Fällen basiert ihr Einfluss auf ihrer Reputation, sie sind abhängig von dem Urteil der anderen Entwickler/innen.

Wahlen

In einigen Projekten werden Positionen dagegen in demokratischen Wahlen vergeben. Teilnahmeberechtigt sind dabei nur diejenigen, die sich des Projekts als „würdig“ erwiesen haben, entweder indem sie eine Reihe von Beiträgen geleistet haben oder (wohl einzigartig im Falle von Debian) nach Durchlaufen eines formelles Prüfungsprozesses.

Die Struktur des Debian-Projekts ist in der „Verfassung“ geregelt. Offizielle Debian-Entwickler/innen müssen eine Reihe von Prüfungen bestehen, bevor sie diesen Titel erhalten; sie wählen aus ihren Reihen eine Projektleiter/in (für die Dauer eines Jahres), die für die Repräsentation nach außen und die interne Koordination zuständig ist.

In der Wikipedia wird über die Kandidatur von Administrator/inn/en ebenfalls per Abstimmung entschieden. Stimmberechtigt sind Nutzer, die schon eine größere Anzahl von Beiträgen für die Wikipedia beigesteuert haben.

Lose Strukturen

Einige Projekte haben nur sehr lockere Strukturen, wo der Maintainer/in den Projektmitgliedern praktisch freie Hand gibt (z.B. bei WorldForge) oder es gar keinen formellen Maintainer/in gibt, sondern alle Entscheidungen in direkter IRC-Kommunikation abgestimmt werden (z.B. Eisfair).

Konfliktlösung und Sanktionsmechanismen

Normalerweise wird beim Treffen von Entscheidungen Konsens angestrebt; bei Debian wird abgestimmt, wenn kein Konsens zustande kommt. Bei der Wikipedia gibt es die Möglichkeit von Meinungsbildern, bei denen es aber mehr auf den Austausch von Argumenten als auf bloßes Stimmenzählen ankommt – bei simplen Stimmenzählen bestünde in knappen Fällen auch zu leicht die Möglichkeit der Manipulation durch die Anlegung zusätzlicher künstlicher Identitäten (sog. „Sockenpuppen“).

In vielen anderen Projekten holt in solchen Fällen die Maintainer/in ein Meinungsbild ein (das sie aber nicht unbedingt bindet) oder legt ein Veto gegen ein bestimmten Vorgehen ein (mit Begründung) – in beiden Fällen hat die Maintainer/in zwar das letzte Wort, kann aber keineswegs willkürlich entscheiden, da sie ihre Entscheidung der Projektgemeinschaft plausibel machen muss. Wo die Möglichkeit einer Maintainer-Entscheidung fehlt, werden Konflikte über Verhandlungen gelöst, die von sachlichem Austausch bis zu „Flame Wars“ reichen können. Entweder wird dabei ein Konsens bzw. für alle akzeptabler Kompromiss erzielt, oder eine Seite gibt nach. Ist beides nicht möglich, kann es zur Aufspaltung des Projekts kommen (Fork).

Forking ist aber nur das letzte Mittel – nach Möglichkeit wird es vermieden, da es das Projekt schwächt. Manchmal, insbesondere bei technischen Konflikten, kann ein Fork auch nur temporär sein und es später zu einer Wiedervereinigung des aufgespalteten Projekts kommen (so im Falle des GCC/EGCS-Splits). In vielen Fällen schläft nach einem Fork nur eines der beiden Teilprojekte mangels Beteiligung ein (z.B. die GetWiki-Abspaltung von MediaWiki; sämtliche Forks der Wikipedia wie z.B. Wikinfo scheinen bestenfalls vor sich hin zu dümpeln). In anderen Fällen richten sich sich abgespaltene Projekte neu aus (z.B. ist OpenBSD eine Abspaltung des Betriebssystems NetBSD, die wohl aufgrund persönlicher Konflikte entstand, mittlerweile aber v.a. die Ausrichtung auf Computersicherheit betont). Dass beide Projekte mit weitgehend unveränderter Ausrichtung auf Dauer parallel existieren (wie. z.B. bei Emacs/XEmacs), ist eher selten.

Generell gibt es gibt keine Richter/innen, die eine alle Beteiligten bindende Entscheidung treffen können, aber bisweilen wird in extremen Konfliktfällen auf die Einschaltung von Vermittler/innen (arbitrators) zurückgegriffen (z.B. Wikipedia:Vermittlungsausschuss). Normalerweise gibt es auch keine formellen Sanktionen, die sowieso nicht durchgesetzt werden könnten. Nur in sehr schweren Fällen wird jemand aus dem Projekt ausgeschlossen (dies kann auf verschiedene Weise geschehen: durch Austragen aus der Mailingliste, Entzug der CVS-Schreibrechte, Blockieren des Nutzeraccounts im Falle der Wikipedia). In weniger schweren Fällen erfolgt die Sanktionierung per „shaming and blaming“, d.h. dem Austeilen negativer Reputation durch öffentliche Anprangern von (mutmaßlichem) Fehlverhalten/Fehlentscheidungen. Oder eine missliebige Person wird ab sofort einfach ignoriert (eine informelle Form des Ausschlusses). Generell gibt es nur Möglichkeiten, Menschen von etwas abzuhalten, aber nicht sie zu etwas zu zwingen – für letzteres fehlen die Sanktionsmöglichkeiten.

Literatur

Diese Darstellung basiert in großen Teilen auf den Werken von Frauke Lehmann (Literatur: Motivation) und Pekka Himanen (Literatur: Hackerethik).