Meritokratie ist eines der Grundprinzipien der Bewegung für freie und quelloffene Software. Sie ist zugleich einer der umstrittensten Begriffe, und die Kluft zwischen den unterschiedlichen Bedeutungen, die ihr zugeschrieben werden, ist in manchen Projekten eine Quelle echter und schädlicher Konflikte.
Lassen Sie uns die Bedeutung des Wortes analysieren, denn seine potenzielle Mehrdeutigkeit kann die Debatte und die verschiedenen Standpunkte erheblich beeinflussen.
Die auf dem Commit-Graph basierende Legitimitätstheorie
Eine Auslegung der Meritokratie besagt, dass die Entscheidungsgewalt den Beiträgen folgen sollte und dass diese am besten anhand des Codes gemessen werden. Nach dieser Ansicht haben diejenigen, die am meisten zum Code beigetragen haben, das Recht, über die Zukunft des Projekts zu entscheiden, da sie den Quellcode kennen und im wahrsten Sinne des Wortes ein persönliches Interesse daran haben.
Für ein Projekt in der Anfangsphase ist dies keine unvernünftige Position. Zwar ist es auch notwendig, sich um die Infrastruktur zu kümmern, Mittel zu beschaffen und die Beziehungen zu Medien und Institutionen zu pflegen, doch wenn die Hauptherausforderung technischer Natur ist, die Community klein ist und wenig auf dem Spiel steht, ist es sinnvoll, dass diejenigen, die den Großteil der Arbeit leisten, auch die meisten Entscheidungen treffen.
Das Problem entsteht, wenn dieses Prinzip unverändert auf einen ganz anderen Kontext übertragen wird. Ein FOSS-Projekt, das seit fünfzehn oder zwanzig Jahren läuft, von Millionen von Menschen genutzt wird, in einem komplexen regulatorischen und rechtlichen Umfeld agiert, Unternehmensnutzer hat und politische Auswirkungen mit sich bringt, ist nicht mehr dasselbe. Die Anwendung derselben Governance aus den Anfängen auf die Realität eines großen Projekts führt nicht zu guten Ergebnissen, sondern zu einer technisch hochentwickelten und strategisch blinden Organisation.
Was das Commit-Diagramm nicht misst
Die auf der Anzahl der Commits basierende Theorie der Meritokratie hat einen blinden Fleck:
Sie misst nur eine Art von Beitrag und lässt andere fast unsichtbar werden.
Betrachten wir, was im Diagramm nicht enthalten ist:
- Die Autoren der Dokumentation, die die Software für Nutzer zugänglich gemacht haben, die sonst die Nutzung aufgegeben hätten.
- Das Lokalisierungsteam, das ganze Sprachgemeinschaften in das Projekt einbezogen hat.
- Die Prüfer, die grobe Fehlerberichte in zur Behebung bereite Berichte umwandelten. Die Community-Moderatoren, die das Projekt auf kostenerheblicher persönlicher Anstrengungen für Neulinge offen hielten.
- Die Menschen, die Jahre damit verbrachten, Beziehungen zu Medien, Institutionen und der Politik aufzubauen und so die Voraussetzungen für die breite Akzeptanz der Software schufen.
Diese Beiträge führen zwar nicht zu Commits, aber sie sorgen für Nutzer, Akzeptanz, Nachhaltigkeit und Relevanz. In einem ausgereiften Projekt machen sie oft den Unterschied zwischen Software, die einfach nur existiert, und Software, die wirklich zählt.
Ein Governance-Modell, das diese Mitwirkenden vom Entscheidungsprozess ausschließt oder versucht, sie an den Rand zu drängen, ist eine partielle Meritokratie, da es nur eine Art von Exzellenz anerkennt und alle anderen ignoriert.
Das Problem von Interessenkonflikten
Es gibt eine zweite Dimension dieses Arguments, die einer Analyse bedarf.
Wenn die Governance eines Projekts auch Personen umfasst, die bei Unternehmen angestellt sind, welche direkte kommerzielle Interessen an der Ausrichtung des Projekts haben, wird die Frage der Meritokratie komplexer. Die Frage ist nicht, ob diese Mitwirkenden fähig sind – denn das sind sie zweifellos –, sondern ob die um ihre Beiträge herum aufgebauten Governance-Strukturen zuverlässig Entscheidungen hervorbringen können, die der Mission des Projekts dienen und nicht den Interessen ihrer Arbeitgeber.
> Florian Effenberger:
Dies ist kein Vorwurf, sondern eine einfache Beobachtung. Interessenkonflikte sind nicht mit böser Absicht verbunden, sondern liegen der Situation inne. Ein Governance-Modell, das dies nicht berücksichtigt, ist nicht mehr meritokratisch und ist sich zudem seiner eigenen Grenzen weniger bewusst.
Eine gesunde Governance in einem ausgereiften FOSS-Projekt erfordert eine Vielfalt an Perspektiven:
Menschen, die Code beitragen, aber auch Menschen, die die Nutzergemeinschaft, die institutionelle Mission und die langfristige Nachhaltigkeit des Projekts als öffentliches Gut und nicht als kommerzielles Kapital vertreten. Es geht nicht darum, Entwickler auszuschließen, sondern sicherzustellen, dass kein einzelnes Interesse – wie legitim es auch sein mag – der einzige Faktor ist, der Entscheidungen bestimmt.
Aufbauen für diejenigen, die nach uns kommen
Alle großen FOSS-Projekte sind generationsübergreifend, denn die Menschen, die sie ins Leben gerufen haben, sind nicht diejenigen, die sie in zehn oder zwanzig Jahren aufrechterhalten werden; daher werden die heute getroffenen Entscheidungen bezüglich Architektur, Governance und der Frage, welche Beiträge geschätzt werden und welche nicht, das prägen, was die nächste Generation erbt. Und es muss etwas sein, auf dem man aufbauen kann, nicht etwas, das man umgehen muss.
Dies definiert das Thema Meritokratie völlig neu. Aus dieser Perspektive wird der Wert eines Beitrags nämlich nicht allein durch seinen aktuellen Wert bestimmt, sondern auch durch seinen Wert für die Zukunft des Projekts.
Meritokratie in einem großen Open-Source-Projekt liegt nicht in der Anhäufung von Commits als Anspruch auf Autorität, sondern darin, die besten Voraussetzungen zu schaffen, damit das Projekt auch in Zukunft weiter wachsen kann. Die Frage ist nicht, wer am meisten geleistet hat, sondern wer etwas aufbaut, das die nächste Generation tatsächlich nutzen und weiter entwickeln kann.
Unser Verständnis von Meritokratie
Das ursprüngliche Prinzip, auf dem die FOSS-Meritokratie beruht, bleibt gültig:
Entscheidungen müssen von denen getroffen werden, die die Arbeit leisten, die die Konsequenzen verstehen und die sich ihren Platz durch echte Beiträge und nicht durch Organisationspolitik verdient haben. Dieses Prinzip muss gewahrt bleiben.
Beiträge können jedoch viele Formen annehmen, und Leistung hat eine zeitliche Dimension, die der Commit-Graph nicht erfasst. Die Leistung, den Quellcode zu erstellen, ist real und verdient Anerkennung, aber dies gilt auch für die Leistung, eine Community aufzubauen, Dokumentation zu pflegen, Barrierefreiheit zu gewährleisten, rechtliche Komplexitäten zu bewältigen und die institutionellen Beziehungen zu sichern, die das Projekt für die Menschen am Leben erhalten, die es erben werden.
Eine echte Meritokratie findet einen Weg, all dies anzuerkennen und zu würdigen. Ein Projekt, das Meritokratie mit der Dominanz einer einzigen Art von Mitwirkenden verwechselt, wie fachkundig diese auch sein mögen, wird seinen eigenen Werten nicht gerecht. Und ein Projekt, das sich den Interessen einer Untergruppe von Mitwirkenden beugt, auf Kosten künftiger Generationen, ist keine Meritokratie, sondern eine Form der Aneignung, die durch die Sprache der Fairness verschleiert wird.
Meritokratie ist ein komplexes, facettenreiches Konzept, mit dem es sich lohnt, sich auseinanderzusetzen, um etwas aufzubauen, das zukünftige Generationen gerne erben werden.
