Patterns in the Transition From Founder-Leadership to Community Governance of Open Source
Durch die Analyse von 637 GitHub-Repositories und deren sich entwickelnden Governance-Dokumenten zeigt diese Studie, dass erfolgreiche Übergänge von der Gründerführung zur Community-Governance nicht durch tonale Veränderungen, sondern durch die schrittweise Schichtung und Verfeinerung institutioneller Rollen und Ökosystem-Ebene-Regulierungen erfolgen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Das große Ganze: Von „Einem Chef“ zu „Einem Team“
Stellen Sie sich ein beliebtes Open-Source-Softwareprojekt (wie eine kostenlose App oder Website) als einen riesigen, gemeinschaftlichen Garten vor.
Ganz am Anfang wird fast jeder Garten von einer einzigen Person gestartet – dem Gründer. Diese Person pflanzt die ersten Samen, baut den Zaun und entscheidet, wo die Tomaten hinkommen. Am Anfang funktioniert das wunderbar. Der Gründer ist der „wohlwollende Diktator“, und alle folgen einfach seiner Führung.
Aber wenn der Garten wächst, zieht er hunderte andere Gärtner an. Der Gründer kann nicht unmöglich jede Pflanze einzeln gießen, jeden Busch beschneiden oder jede Regel allein festlegen. Wenn er versucht, das zu tun, könnte der Garten zusammenbrechen oder der Gründer brennt aus. Der Garten muss sich in eine gemeinschaftlich verwaltete Organisation verwandeln, in der jeder mitreden darf und es klare Regeln gibt.
Diese Arbeit ist eine Studie darüber, wie 637 dieser digitalen Gärten diesen Übergang vollzogen haben. Die Forscher wollten wissen: Wie ändern Projekte ihre Regelwerke, wenn sie von „Einem Chef“ zu „Gemeinschaftlicher Governance“ übergehen?
Wie sie es gemacht haben: Das Lesen der „Regelbücher“
Anstatt Menschen in Chatrooms streiten zu sehen oder zu zählen, wie viele Code-Änderungen vorgenommen wurden, schauten sich die Forscher die geschriebenen Regelbücher an.
Auf GitHub (der Website, auf der diese Projekte leben) gibt es eine spezielle Datei namens GOVERNANCE.md. Betrachten Sie dies als die Verfassung des Projekts. Es ist eine einfache Textdatei, die direkt neben dem Computercode liegt. Darin steht zum Beispiel:
- „Wer darf Code zusammenführen (mergen)?“
- „Wie wählen wir einen neuen Anführer?“
- „Was passiert, wenn jemand gegen die Regeln verstößt?“
Die Forscher sammelten die erste Version dieses Regelbuchs (als das Projekt noch jung war) und die neueste Version (als das Projekt bereits ausgereift war) für 637 Projekte. Sie nutzten ein Computerprogramm, um diese Dokumente zu lesen und sie in drei einfache Teile zu zerlegen:
- Rollen (Das „Wer“): Wer darf Dinge tun? (z. B. „Mitwirkende“, „Maintainer“, „Der Lenkungsausschuss“).
- Aktionen (Das „Was“): Welche Aktivitäten werden reguliert? (z. B. „Abstimmen“, „Code prüfen“, „Entscheidungen über Features treffen“).
- Deontik (Das „Wie stark“): Wie streng sind die Regeln? (z. B. „Sie müssen dies tun“, „Sie sollten dies tun“ oder „Sie können dies tun“).
Was sie herausfanden: Der Garten wird komplexer
Die Forscher fanden heraus, dass die Regelbücher dieser Projekte mit zunehmender Reife nicht nur länger werden, sondern auch intelligenter und ausgewogener werden. Hier sind die wichtigsten Muster, die sie entdeckten:
1. Mehr spezialisierte Aufgaben (Die „Rollen“ wachsen)
Am Anfang war das Regelbuch sehr einfach. Es besagte meistens: „Jeder kann helfen“ oder „Der Gründer entscheidet“.
- Die Veränderung: Als das Projekt wuchs, begannen die Regelbücher, spezifische, spezialisierte Jobs zu definieren. Sie fügten Regeln für „Technische Komitees“, „Aufsichtsgruppen“, „Unterkomitees“ und Personen hinzu, die die Beziehungen zu anderen Projekten verwalten.
- Die Analogie: Stellen Sie sich ein kleines Familienessen vor, bei dem die Mutter alles entscheidet. Wenn die Familie zu einem riesigen Hochzeitsempfang heranwächst, haben Sie nicht mehr nur „die Mutter“. Sie bekommen einen „Oberkellner“, einen „DJ“, einen „Floristen“ und einen „Sicherheitsdienst“. Das Regelbuch begann, all diese spezifischen Rollen aufzulisten.
2. Mehr Arten von Aktivitäten (Die „Aktionen“ wachsen)
Frühe Regelbücher konzentrierten sich auf grundlegende Aktionen wie das „Einreichen von Code“.
- Die Veränderung: Spätere Regelbücher deckten eine größere Vielfalt an Aktivitäten ab. Sie begannen zu regeln, wie das Projekt mit der Außenwelt kommuniziert, wie sie Sitzungen abhalten und wie sie die Aufsicht handhaben.
- Die Analogie: Ein kleiner Club hat nur Regeln für die „Anmeldung“. Ein großer Club hat Regeln für „Fundraising“, „Veranstaltungen“, „Budgetverwaltung“ und „Schlichtung von Streitigkeiten“. Der Umfang dessen, was verwaltet wurde, wurde viel breiter.
3. Die Regeln wurden ausgewogener (Die „Entropie“ stieg)
Dies ist eine fachsprachliche Art zu sagen, dass sich die Regeln nicht mehr nur auf ein oder zwei Dinge konzentrierten, sondern sich gleichmäßig verteilten.
- Die Veränderung: In den frühen Tagen bestanden vielleicht 90 % der Regeln aus dem „Gründer“. In den späteren Tagen waren die Regeln gleichmäßiger über alle verschiedenen Rollen und Aktionen verteilt. Keine einzelne Person oder Gruppe dominierte den Text mehr.
- Die Analogie: Denken Sie an einen Scheinwerfer. Zuerst ist der Scheinwerfer auf eine einzige Person gerichtet (den Gründer). Im Laufe der Zeit bewegt sich der Scheinwerfer und beleuchtet verschiedene Menschen und Aufgaben gleichermaßen. Das „Licht“ der Verantwortung wird geteilt.
4. Die Regeln blieben „nett“ (Die „Deontik“ änderte sich kaum)
Die Forscher prüften, ob die Regeln im Laufe der Zeit strenger oder bestrafender wurden.
- Die Veränderung: Überraschenderweise taten sie das nicht. Das Verhältnis von „Sie müssen dies tun“ gegenüber „Sie können dies tun“ blieb in etwa gleich. Obwohl die Projekte riesig und komplex wurden, verwandelten sie sich nicht in strikte Polizeistaaten. Sie blieben hauptsächlich geprägt von Erlaubnis und Ermutigung statt von Verbot.
- Die Analogie: Selbst als der Garten größer wurde, änderten sich die Schilder nicht von „Bitte helfen Sie mit“ zu „Berühren Sie die Pflanzen nicht, sonst werden Sie verhaftet“. Der Ton blieb freundlich und auf Freiwilligkeit basierend.
Die wichtigste Erkenntnis
Die Arbeit kommt zu dem Schluss, dass erfolgreiche Open-Source-Projekte ihre alten Regelbücher normalerweise nicht wegwerfen und neu anfangen. Stattdessen schichten sie neue Regeln darüber.
Sie beginnen mit einem einfachen Fundament (der Vision des Gründers) und fügen mit wachsendem Projekt immer mehr Ebenen an Details, spezialisierten Rollen und geteilten Verantwortlichkeiten hinzu. Es ist wie beim Hausbau: Man beginnt mit dem Fundament und den Wänden, und im Laufe der Zeit fügt man Zimmer, ein zweites Stockwerk und eine schicke Küche hinzu. Man reißt nicht das erste Stockwerk ab, um das zweite zu bauen; man baut einfach weiter daran.
Kurz gesagt: Erfolgreiche Gemeinschaften wachsen, indem sie mehr spezifische Jobs hinzufügen und die Verantwortung verteilen, anstatt den Ton der Regeln zu ändern oder das alte System komplett zu ersetzen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.