Einheit
Communities und Governance
Wie funktionieren FOSS-Communities und ihre Governance?
Lernziel
Nach dieser Einheit kannst du unterschiedliche Entwicklungsmodelle von FOSS-Projekten einordnen, typische Rollen in einer Community unterscheiden und erklären, wie Governance-Strukturen Entscheidungen, Verantwortlichkeiten und den Umgang mit Beiträgen regeln. Außerdem kennst du wichtige FOSS-Organisationen und ihre unterschiedlichen Schwerpunkte.
Zwei grundlegende Entwicklungsmodelle von FOSS-Projekten
Eric S. Raymond beschrieb 1997 in seinem Artikel The Cathedral and the Bazaar zwei grundlegende Modelle der Softwareentwicklung: die Kathedrale und den Basar. Reale Projekte lassen sich nicht immer eindeutig zuordnen, die Gegenüberstellung hilft jedoch dabei, unterschiedliche Grade von Offenheit und die Arten der Beteiligung zu verstehen.
Beim Kathedralenmodell plant und entwickelt eine klar abgegrenzte Gruppe die Software weitgehend intern. Die Öffentlichkeit erhält den Quellcode erst zu bestimmten Zeitpunkten, beispielsweise mit einer neuen Version. Ein Projekt kann damit Open-Source-Software veröffentlichen, ohne den gesamten Entwicklungsprozess öffentlich zu machen. Ein Beispiel dieses Modells ist das Android Open Source Project (AOSP), der Open-Source-Kern von Android. Neue Android-Versionen entstehen bei Google zunächst intern und werden in einem regelmäßigen Turnus veröffentlicht. Externe Beiträge sind möglich, ihre Aufnahme wird aber von Google gesteuert.
Beim Basarmodell findet die Entwicklung von Beginn an öffentlich statt. Fehlerberichte und Änderungsvorschläge können von vielen Personen eingebracht und diskutiert werden. Der Linux-Kernel gilt als bekanntes Beispiel für dieses Modell. Offenheit bedeutet dabei nicht, dass jede Person Änderungen unmittelbar in das Projekt übernehmen darf. Auch Basarprojekte benötigen Reviews, Zuständigkeiten und geregelte Entscheidungswege.
Raymond bewertet das Basarmodell als besonders leistungsfähig, weil viele Beteiligte Änderungen früh prüfen, Fehler finden und Rückmeldungen geben können. Eine öffentliche Entwicklung allein garantiert jedoch weder Qualität noch eine aktive Community. Dafür braucht ein Projekt verständliche Prozesse, verlässliche Verantwortliche und ausreichend viele Mitwirkende.
Die Zahl der Mitwirkenden hängt nicht unmittelbar von der Zahl der Nutzenden ab. Manche weitverbreiteten Projekte werden von großen, verteilten Communities entwickelt. Andere werden trotz ihrer enormen Verbreitung von einem kleinen, beständigen Team gepflegt.
Grundlegende Rollen in FOSS-Projekten
Die an einem FOSS-Projekt beteiligten Personen lassen sich unterschiedlichen Rollen zuordnen. Die Bezeichnungen und Befugnisse unterscheiden sich von Projekt zu Projekt. Häufig kommen jedoch die folgenden Rollen vor:
| Rolle | Typische Aufgaben und Befugnisse |
|---|---|
| Nutzende | Setzen die Software ein, melden Probleme, stellen Fragen und formulieren Anforderungen. Gute Fehlerberichte und Rückmeldungen sind wertvolle Beiträge für ein FOSS-Projekt. |
| Beitragende (Contributors) | Erstellen beispielsweise Quellcode, Dokumentation, Übersetzungen, Tests oder Designs von Benutzeroberflächen. Beiträge werden technisch in der Regel über Tickets (Issues) und Pull Requests beziehungsweise Patches eingereicht. |
| Committer | Dürfen geprüfte Änderungen in das zentrale Repository, also die Codebasis, übernehmen. In vielen Projekten werden aktive Beitragende nach wiederholten, hochwertigen Beiträgen und verlässlicher Zusammenarbeit zu Committern ernannt oder gewählt. |
| Maintainer oder Project Lead | Verantworten einen Teilbereich oder das gesamte Projekt. Sie priorisieren Arbeiten, koordinieren Reviews und Releases und entscheiden bei Konflikten. In größeren Projekten gibt es meist mehrere Maintainer mit klar abgegrenzten Zuständigkeiten. |
| Project Management Committee oder Technical Steering Committee | Eine Gruppe, die projektweite technische oder organisatorische Entscheidungen trifft. Ein solches Gremium kann Maintainer wählen, Releases freigeben, Richtlinien beschließen und die langfristige Ausrichtung verantworten. |
| Unterstützende Rollen | Community-Management, Release-Management, Security-Teams, Dokumentation, Übersetzung oder Veranstaltungsorganisation tragen zum Projekt bei, ohne zwingend Änderungen am Quellcode vorzunehmen. |
Nutzende und Beitragende gibt es in allen Projekten. Die weitere Unterscheidung der Beitragenden in Committer und Maintainer sowie die Etablierung von Gremien erfolgt meist, wenn Projekte wachsen. Eine Person kann mehrere Rollen innehaben, und Verantwortung kann zeitlich begrenzt oder auf einen Teil des Projekts beschränkt sein. Entscheidend ist, dass dokumentiert ist, wer welche Entscheidungen treffen darf und wie andere Personen Verantwortung übernehmen können.
Governance-Strukturen in großen Projekten und Communities
Governance bezeichnet die Regeln und Verfahren, nach denen ein Projekt geführt wird. Sie legt unter anderem fest, wer Entscheidungen trifft, wie Änderungen angenommen werden, wie Rollen vergeben werden und wie Konflikte gelöst werden. Das Entwicklungsmodell beschreibt dagegen, wie offen die Entwicklung stattfindet. Ein öffentlich entwickeltes Basarprojekt kann sowohl von einer einzelnen Person als auch von einem gewählten Gremium geführt werden.
Mit wachsender Community reichen informelle Absprachen häufig nicht mehr aus. Klare Governance-Strukturen schaffen dann:
- Nachvollziehbarkeit: Entscheidungen und ihre Begründungen werden öffentlich dokumentiert.
- Verlässlichkeit: Beitragende wissen, wie Vorschläge bewertet und Änderungen übernommen werden.
- Verantwortung: Zuständigkeiten für Reviews, Releases, Sicherheit und Wartung sind geklärt.
- Kontinuität: Das Projekt bleibt handlungsfähig, wenn einzelne Maintainer oder andere wichtige Rollen ausscheiden.
- Konfliktlösung: Ein festgelegtes Verfahren hilft, technische oder persönliche Meinungsverschiedenheiten zu moderieren.
- Neutralität: Entsprechende Regeln können verhindern, dass einzelne Unternehmen oder Interessengruppen das Projekt dominieren.
Vergabe von Rollen und Entscheidungsrechten
In kleinen Projekten bestimmt häufig die Person, die das Projekt gegründet hat, über Änderungen und die Ernennung neuer Maintainer. Größere Communities vergeben Verantwortung meist anhand nachweisbarer Beiträge und konstruktiver Zusammenarbeit über längere Zeit. Kandidatinnen und Kandidaten werden oft von bestehenden Maintainern vorgeschlagen und durch Konsens oder Abstimmung bestätigt. Open-Source-Organisationen wie Apache oder Eclipse geben dafür projektübergreifende Rahmenbedingungen vor, während die Entscheidung über konkrete Personen in den jeweiligen Projektgremien liegt.
Auch Commit-Rechte bedeuten selten, dass Änderungen ohne Kontrolle übernommen werden dürfen. Oft kommen geschützte Entwicklungszweige, automatisierte Prüfungen und das Vier-Augen-Prinzip zum Einsatz, unabhängig davon, wer Commits vornimmt. Eine etablierte Praxis ist, diese Regeln in einer Datei namens CONTRIBUTING.md im Hauptverzeichnis eines Repositories zu beschreiben und abzulegen. Am Beispiel der Middleware für Interprozesskommunikation Eclipse iceoryx lässt sich dies gut nachvollziehen. Die CONTRIBUTING.md erklärt detailliert, wie zum Projekt beigetragen werden kann. Alternativ gibt es in manchen Projekten ein Governance-Dokument oder ein Maintainer-Handbuch. Darin wird beschrieben, welche Voraussetzungen für Beiträge gelten und wer einen Pull Request freigeben darf.
Rechte an Beiträgen und Compliance
Ein Open-Source-Projekt muss sicherstellen, dass alle Beiträge zum Projekt unter der für das Projekt gewählten Lizenz veröffentlicht werden können. Dazu müssen die Beitragenden zum einen Nutzungsrechte für die von ihnen erstellten Beiträge einräumen. Zum anderen müssen Beiträge, die auf bereits veröffentlichter Software aufbauen, eine kompatible Lizenz aufweisen. Dafür werden meist zwei unterschiedliche Instrumente eingesetzt:
- Mit einem Developer Certificate of Origin (DCO) bestätigt eine beitragende Person durch den Signed-off-by-Vermerk eines Commits, dass sie den Beitrag selbst erstellt hat oder zur Weitergabe unter der angegebenen Lizenz berechtigt ist. Die Linux Foundation stellt eine oft benutzte Vorlage für DCO bereit.
- Mit einem Contributor License Agreement (CLA) räumt die beitragende Person oder ihr Unternehmen dem Projekt ausdrücklich bestimmte Nutzungsrechte ein. Ein CLA kann weitergehende Regelungen enthalten und wird meist einmalig vor dem ersten Beitrag abgeschlossen.
DCO und CLA sind im Hinblick auf Compliance wichtige Bausteine, um FOSS-Projekte nachvollziehbar zu machen, sie ersetzen aber nicht die eigentliche juristische Bewertung. Ergänzend müssen Projekte beispielsweise Lizenzangaben, Abhängigkeiten und Copyright-Hinweise prüfen. Bei sicherheitsrelevanten Änderungen, Releases oder der Aufnahme fremder Komponenten können zusätzliche Reviews notwendig sein.
Zu einer vollständigen Governance gehören außerdem ein Verhaltenskodex, ein Verfahren für Sicherheitsmeldungen, Regeln für Releases und eine dokumentierte Möglichkeit, Entscheidungen anzufechten oder eskalieren zu lassen.
Bekannte FOSS-Organisationen
FOSS-Organisationen verfolgen unterschiedliche Zwecke. Einige beherbergen und verwalten konkrete Softwareprojekte, andere stellen neutrale Governance und Infrastruktur bereit oder setzen ihren Schwerpunkt auf politische und gesellschaftliche Arbeit. Die folgenden Beispiele zeigen diese Unterschiede.
Apache Software Foundation
Die Apache Software Foundation (ASF) entstand 1999 aus der Community rund um den Apache Web-Server. Sie bietet ihren Projekten organisatorische und rechtliche Unterstützung, technische Infrastruktur und Markenverwaltung. Neue Projekte können im Apache Incubator schrittweise an die Prozesse und Prinzipien der Stiftung herangeführt werden.
Apache-Projekte organisieren sich weitgehend selbstständig. Ein Project Management Committee (PMC) trägt die Verantwortung für ein Projekt, stimmt über Releases ab und ernennt neue Committer und PMC-Mitglieder aufgrund ihrer bisherigen Beiträge. Entscheidungen sollen nach dem Prinzip „Community over Code“ möglichst im Konsens und transparent auf öffentlichen Kommunikationskanälen getroffen werden. Eine stabile Community wird höher gewichtet als guter Code. Dieses Zusammenspiel aus projektbezogener Selbstverwaltung, meritbasierter Rollenvergabe und gemeinsamer Infrastruktur wird häufig als Apache Way bezeichnet.
Linux Foundation
Die Linux Foundation ging 2007 aus dem Zusammenschluss der Open Source Development Labs und der Free Standards Group hervor. Sie bietet heute zahlreichen Projekten aus Software, Hardware, Standards und weiteren Bereichen eine neutrale organisatorische Heimat. Dazu gehören Infrastruktur, Finanzierung, Markenverwaltung, rechtliche Unterstützung, Veranstaltungen sowie Werkzeuge für Community- und Projektmanagement. Ihr Wirkungsbereich geht inzwischen weit über Linux hinaus.
Die Stiftung gibt nicht für alle Projekte ein einheitliches technisches Governance-Modell vor. Die jeweiligen Communities behalten eigene Gremien und Entscheidungsprozesse, beispielsweise ein Technical Steering Committee (TSC). Dadurch können auch konkurrierende Unternehmen an gemeinsamer Basistechnologie arbeiten, ohne dass ein einzelnes Unternehmen allein die Kontrolle ausübt. Ein weiterer Schwerpunkt der Linux Foundation liegt auf Weiterbildung: Sie bietet Kurse, Zertifizierungen und Mentoringprogramme zu Linux, Cloud-Technologien, Sicherheit und Open-Source-Management an.
Eclipse Foundation
Die Eclipse Foundation ging 2004 aus dem von IBM bereits 2001 veröffentlichten Eclipse-Projekt hervor, um die herstellerneutrale Weiterentwicklung des Projektes zu unterstützen. Die heute in Brüssel ansässige Eclipse Foundation beherbergt weit mehr als die namensgebende Entwicklungsumgebung. Sie unterstützt unter anderem Projekte, Spezifikationen und branchenbezogene Working Groups in Bereichen wie Enterprise Java, Cloud, IoT und Automotive.
Die Eclipse Foundation stellt technische Infrastruktur, einen einheitlichen Entwicklungsprozess und Regeln für herstellerneutrale Governance bereit. Committer werden projektbezogen aufgrund ihrer Beiträge gewählt. Die Foundation verbindet diese Community-Prozesse mit einem strukturierten IP-Management: Contributor Agreements, öffentliche Beitragswege und Prüfprozesse sollen sicherstellen, dass Beiträge rechtmäßig angenommen und weitergegeben werden können. Darüber hinaus unterstützt sie Ökosystementwicklung, Veranstaltungen und die Qualifizierung von Committern.
GNU-Projekt und Free Software Foundation
Das GNU-Projekt und die Free Software Foundation (FSF) sind eng miteinander verbunden, erfüllen aber unterschiedliche Aufgaben. Richard Stallman startete 1983 das GNU-Projekt mit dem Ziel, ein vollständig freies, Unix-kompatibles Betriebssystem zu entwickeln. Dazu gehören bekannte Softwarepakete wie GCC, GDB, Bash und die GNU Core Utilities.
Die FSF wurde 1985 gegründet, um das GNU-Projekt zu unterstützen und die Freiheit von Softwarenutzenden gesellschaftlich und politisch zu fördern. Sie verwaltet die GNU-Lizenzfamilie, zu der die GNU General Public License (GPL) gehört, veröffentlicht Informations- und Bildungsmaterialien und setzt sich mit Kampagnen für Freie Software ein. Im Unterschied zu Apache, der Linux Foundation und Eclipse ist die FSF nicht in erster Linie eine neutrale Dachorganisation für möglichst viele unabhängige Projekte. Ihr Schwerpunkt liegt auf der werteorientierten Free-Software-Bewegung, wobei das GNU-Projekt ihren historischen und technischen Kern bildet.
Vergleich der Organisationen
| Organisation | Schwerpunkt | Projekte, Hosting und Infrastruktur | Governance | Qualifizierung und Öffentlichkeitsarbeit |
|---|---|---|---|---|
| Apache Software Foundation | Dauerhafte, von Communities getragene Softwareprojekte | Gemeinsame Infrastruktur, Markenverwaltung und Incubator | Der “Apache Way” gibt Grundprinzipien für die individuellen Project Management Committees vor | Community-Dokumentation, Mentoring und Veranstaltungen |
| Linux Foundation | Neutrale Zusammenarbeit von Unternehmen und Entwickler-Communities | Breites Projektportfolio, Infrastruktur, Finanzierung, Standards und Veranstaltungen | Projektspezifische Governance für Projekte bzw. Charter (beinhalten oft mehrere Projekte) | Umfangreiches Kurs-, Zertifizierungs- und Mentoringangebot |
| Eclipse Foundation | Herstellerneutrale Open-Source-Projekte, Spezifikationen und Branchenkooperationen | Projektinfrastruktur, Working Groups und Ökosystementwicklung | Der Eclipse Foundation Development Process gilt für alle Projekte, Autonomie nur für bestimmte Aspekte | Committer-Training, Dokumentation, Webinare und Veranstaltungen |
| GNU-Projekt / Free Software Foundation | Entwicklung Freier Software und Schutz der Softwarefreiheit | GNU-Software, Lizenzen und unterstützende Infrastruktur | Projektbezogene Maintainer sowie GNU-Lizenzen und Compliance-Arbeit der FSF | Politische Kampagnen, Bildungsarbeit und Informationen zu Freier Software |
FOSS-Projekte benötigen eine Struktur, die zu ihrer Größe, ihren Beteiligten und ihren Zielen passt. Für Beitragende ist deshalb nicht nur die Lizenz wichtig, sondern auch die Frage, wie transparent Entscheidungen getroffen werden, wie Verantwortung erworben werden kann und welche Organisation langfristig zum Projekt passt.