Die soziale Steuerung von Open Source (Teil 2)

[Fortsetzung des Interviews mit George Dafermos: Teil 1]

Michel Bauwens: Charles Leadbeater hat in We Think eine sehr starke Aussage über die Steuerung von Open-Source- und kollaborativen Online-Communities formuliert: „Unter keinen Umständen handelt es sich dabei um egalitäre selbstgesteuerte Demokratien“. Glaubst du, dass das stimmt – warum oder warum nicht – und wie sollen wir die Peer-Steuerungs-Praktiken solcher Communities beurteilen? Kannst du uns etwas über deine Sicht auf die Spannung zwischen Gleichheit und Hierarchie in der Peer-Produktion erzählen? Was hältst du von dem Konzept des „gütigen Diktators“?

Ich habe Leadbeaters Buch nicht gelesen, aber ähnliche Argumente wurden auch von anderen geäußert. Gewöhnlich ist der Tenor des Arguments, dass informelle Formen der Organisation – wie sie in vielen Projekten der Peer-Produktion zu finden sind – für die Bildung von administrativen Klüngeln anfällig sind und dadurch den Nährboden für Korruption und Machtmissbrauch bereiten.

Klüngel können jedoch in allen Lebensbereichen gefunden werden. Viele soziologische Studien haben gezeigt, dass die Klüngelbildung auch für bürokratische Organisationen typisch ist, trotz aller geschriebenen Regeln und formalen Posten. Am wichtigsten ist jedoch, dass die Probleme, die diese Kritik den (oft informellen) Formen der Organisation von FOSS-Projekten zuschreibt, in formalen Organisationen viel verbreiteter und destruktiver sind. Formale „demokratische“ Organisationen wie Gewerkschaften und politische Parteien (auch solche, die egalitäre Ideale verkünden), ganz zu schweigen von gewählten Regierungen, sind Brutstätten der Korruption und Willkür beim Ausführen ihrer administrativen Befugnisse. Das sollte aber nicht so aufgefasst werden, dass alle Formen der kollektiven Organisation dazu verurteilt sind, in Korruption und Machtmissbrauch zu versinken.

Der Wunsch nach gelebter Demokratie ist nicht vergeblich. Das Problem ist vielmehr, dass wirkliche Demokratie, also die soziale Form der Regelung und Steuerung durch unmittelbare Teilhabe aller Community-Mitglieder am Prozess der Formulierung von Problemen und der Aushandlung von Lösungen, unerreichbar wird, sobald die Gruppe in eine Fraktion gespalten wird, die entscheidet und befiehlt, und eine andere, die gehorcht. Solche Strukturen sprechen dem Begriff der Demokratie hohn. Dies müssen wir bedenken, um abschätzen zu können, wie demokratisch die Communities der Peer-Produktion wirklich sind. Wir sollten uns ansehen, wie Entscheidungen getroffen werden: Basiert die Entscheidungsfindung auf direkter Teilhabe aller Community-Mitglieder oder ist sie in den Händen einiger weniger konzentriert, die über den Rest im Namen einer wirklichen oder eingebildeten Community bestimmen? Das ist die Schlüsselfrage. Aus dieser Perspektive betrachtet läuft die soziale Regelung und Steuerung in Peer-Produktions-Communites oft viel demokratischer ab als in traditionellen „demokratischen“ Organisationen.

Das Konzept des gütigen Diktators ist sehr interessant, und es illustriert die Spannung zwischen Hierarchie und Gleichheit in der Peer-Produktion ganz gut, worauf sich deine Frage ja bezieht. Lass es mich anhand eines Beispiels erläutern. Der archetypische gütige Diktator ist Linus Torvalds, Gründer und Leiter eines wohlbekannten FOSS-Projekts: Linux. Torvalds ist der „Diktator“ von Linux in dem Sinne, dass er die höchste Autorität inne hat, wenn es darum geht zu entscheiden, welche Codebeiträge Bestandteil der offiziellen Linux-Version werden. Seine Autorität wird nicht über die Linux-Entwickler_innen, sondern über ihre Beiträge ausgeübt. Er kann ihnen nicht sagen, was zu tun ist, wie es zu tun ist oder wann es zu tun ist. Das ist der Grund, warum sein Einfluss auf das Verhalten der einzelnen Entwickler_innen marginal ist, wie einige Studien festgestellt haben (zum Beispiel Ruben van Wendel de Joodes Dissertation Understanding Open-Source Communities: An Organizational Perspective).

Damit Torvalds Entscheidungen als berechtigt angenommen werden, müssen sie mit dem Konsens der beteiligten Entwickler_innen übereinstimmen, wie er sich auf den Linux-Mailinglisten zeigt. Es ist nichts ungewöhnliches für ihn, unter dem Druck anderer Entwickler_innen eine Entscheidung zurückzunehmen. Seine Position basiert auf der Anerkennung seiner Eignung durch die Community der Linux-Entwickler_innen, weshalb seine Autorität permanent unter einem Widerrufsvorbehalt steht. Seine Rolle ist nicht die eines Bosses oder Managers im üblichen Sinne. Letztlich entspringt die Richtung des Projekts aus der kumulativen Synthese der durch die individuellen Entwickler_innen beigetragenen Änderungen.

Zusammenfassend lässt sich sagen, dass die Spannung zwischen Hierarchie und Gleichheit mit dem Grad der Kontrolle zu tun hat, die Projekt-Administratoren über die von der Basis der Entwickler_innen beigetragenen Änderungen ausüben. Stärker ausgeprägt ist diese Spannung in Projekten, die – wie Linux – eine/n Entwickler_in (oder eine Untergruppe von Entwickler_innen) dazu berechtigen, die Code-Beiträge der Entwickler_innen-Community zu akzeptieren oder zurückzuweisen. Andere große FOSS-Projekte – FreeBSD zum Beispiel – erlauben es ihren Entwickler_innen, Änderungen direkt in die Codebasis einzupflegen, ohne sie durch den Filter eines Gatekeepers zu schleusen. Folglich ist die genannte Spannung in diesen Projekten wesentlich geringer.

[Teil 3]

Ein Kommentar

Einen Kommentar hinzufügen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Entdecke mehr von keimform.de

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen