Freie Software produzieren

Obwohl schon eine Weile unter einer Creative Commons-Lizenz erhältlich, ist das Buch »Producing Open Source Software. How to Run a Successful Free Software Project« ^[1] von Karl Fogel ^[2] im deutschsprachigen Raum kaum rezensiert worden. Ok, das Buch wurde auf englisch verfasst, aber gleichzeitig ist es so interessant, dass es mehr Aufmerksamkeit verdient. Vielleicht erleichtert die folgende Besprechung ja den Einstieg. Übersetzungen stammen von mir.

Karl Fogel hat eine Anleitung zur Gründung (oder Übernahme) und Weiterentwicklung eines Freien Softwareprojektes geschrieben. Grundlage sind vor allem seine Erfahrungen aus dem Subversion-Projekt ^[3]. Ausgangspunkt ist die These: »Die meisten Freien Softwareprojekte schlagen fehl«. Fast checklistenartig kann man das Buch als Ratgeber verwenden, um die verschiedenen Fallen auf dem Weg zum erfolgreichen Projekt zu umgehen. Was aber macht ein Projekt erfolgreich, und was sind die Hauptschwierigkeiten?

»Die Vergänglichkeit, oder besser die potenzielle Vergänglichkeit, von Beziehungen ist vielleicht die gewaltigste Aufgabe in einem neuen Projekt. Was wird all diese Leute überzeugen lang genug zusammenzubleiben, um etwas Nützliches herzustellen? Die Antwort auf diese Frage ist komplex genug, um den Rest des Buches zu beanspruchen, aber wenn sie in einem Satz ausgedrückt werden soll, dann würde dieser so lauten:

Die Leute sollten spüren, dass ihre Verbindung zu einem Projekt und ihr Einfluss auf das Projekt direkt proportional ist zu ihren Beiträgen.

Keine Klasse von Entwicklern oder potenziellen Entwicklern sollte sich jemals aus nicht-technischen Gründen herabgesetzt oder diskriminiert fühlen.«

Ein besonderer Schwerpunkt liegt also auf den sozialen Prozessen in einem Projekt. Das macht das Buch so lesenswert und auch über den Rahmen von Softwareentwicklung hinaus nützlich. Schauen wir, ob die Erwartungen erfüllt werden.

Die Gliederung der Hauptkapitel sieht so aus:

1. Einleitung
2. Starten
3. Technische Infrastruktur
4. Soziale und politische Infrastruktur
5. Geld
6. Kommunikation
7. Paketerstellung, Freigabe und tägliche Entwicklung
8. Management von Freiwilligen
9. Lizenzen, Copyrights und Patente

Im Folgenden gehe ich auf die Kapitel 4, 6 und 8 ausführlicher ein.

Soziale und politische Infrastruktur

Obwohl oft genannt erfassen Meritokratie ^[4], Kooperation ^[5] und lauffähiges Programm (IETF ^[6]: »Wir lehnen Könige, Präsidenten und Abstimmungen ab. Wir glauben an groben Konsens und lauffähige Programme«) nicht umfassend die Erfolgsfaktoren Freier Softwareprojekte. Um eine Kontinuität im Projekt zu erreichen, sind zwei weitere Faktoren entscheidend: Die Spaltbarkeit (forkability) des Projektes und die gutmütige Diktatorenschaft (benevolent dictatorship).

Ein Fork ^[7] ist die vollzogene Spaltung eines Projektes, was die Aufteilung der menschlichen (und ggf. infrastrukturellen) Ressourcen bedeutet. Die Möglichkeit eines Forks steht jedem offen. Da ein Fork niemandem nutzt, die Möglichkeit zum Fork die treibende Kraft hinter dem Willen zum Konsens. Daher gibt es in Freien Projekten auch keine wirklichen Diktatoren im Sinne eines Tyrannen [vgl. dazu auch einen früheren Blogbeitrag ^[8]]. Einen »gutmütigen Diktator« würde Fogel deswegen auch eher als von der Community akzeptierten »Schiedsrichter« bezeichnen. Ein guter Schiedsrichter lässt die Dinge sich selbst entwickeln, Diskussion und Experimente sind die wichtigsten Mittel. Nur im Notfall hat der Schiedsrichter das letzte Wort.

Mit zunehmendem Alter und zunehmender Größe entwickeln sich Projekte weg von der gutmütigen Diktatorenschaft hin zu »konsensbasierter Demokratie«. Ein Konsens ist dann erreicht, wenn niemand einer Konsensformulierung widerspricht. Kann ein Konsens in diesem Sinne nicht erreicht werden, ersetzen Abstimmungen immer öfter die Entscheidung durch einzelne Schiedsrichter. Es bleibt jedoch die schwierige Entscheidung zu treffen, wann genau eine Abstimmung sinnvoll ist, denn einen Abstimmung beendet einen Diskussionsprozess. In manchen Projekte gibt es wiederum ein Veto, um zu schnelle Entscheidungen zu verhindern. Fogel empfiehlt, die gefundenen Regeln in einem Projekt aufzuschreiben, damit diese für alle (gerade auch neue Mitglieder) transparent sind.

Kommunikation

Die Fähigkeit gut zu Schreiben ist auf lange Sicht wichtiger als die Fähigkeit gut zu programmieren. Das Schreiben per E-Mail ist in den meisten Projekten der zentrale Kontakt zu anderen Projektmitgliedern. Deswegen gilt:

»Du bist was du schreibst.«

Folgende Punkte sind zu beachten:

• Struktur und Formatierung: Inhaltlich klar geschriebene und sauber formatierte Mails erleichtern das Lesen für andere ungemein. Einige Regeln haben sich etabliert: Nur-Textformat, Zeilenlänge maximal 72 Zeichen, Text in Absätze aufteilen, Absätze durch Leerzeilen trennen, bei Antworten die nicht gemeinten Teile des Ursprungstextes löschen, Betreff sorgfältig formulieren und ggf. ändern etc.
• Inhalt: Erleichtere Anderen das Lesen deines Beitrages. Fasse längere Beiträge zusammen. Suche Archiv-URLs heraus, wenn du dich auf zurückliegende Debatten beziehst. Verwende keine Übertreibungen, betreibe keine sprachliche Aufrüstung aus Angst, nicht gehört zu werden. Lies deine Mail noch einmal durch bevor du sie abschickst: Kannst du sie kürzen oder freundlicher formulieren?
• Ton: Technische Diskussionen tendieren zu einem knappen sachlichen Schreibstil, und daran ist auch nichts Falsches. In bestimmten Situationen ist es jedoch angebracht, emotionale Botschaften zu senden. Ein Smiley oder ein guter Wunsch zeigen, dass man positiv gestimmt ist, auch wenn die Aussagen inhaltlich kritisch waren. Wer aufmerksam über längere Zeit die Kommunikation beobachtet, wird herausfinden, welche Formen bei wem angemessen ist.
• Grobheiten erkennen: Bestimmte Ausdrucksweisen werden als grob oder unhöflich wahrgenommen. Dies kann Ausdruck unterschiedlicher Kommunikationskulturen sein. Diese gilt es herauszufinden, um damit gut umzugehen. Ein knapper Schreibstil ist meist Ausdruck begrenzter Zeit und nicht von Unfreundlichkeit oder Kälte. Bei Fehlermeldungen helfen Basisfragen, bestimmte Fehlerquellen auszuschließen; sie sollen nicht demonstrieren, dass der Fragende blöd ist: In der Regel gibt es keine verborgene Bedeutung hinter einer Frage. Manchmal kann es helfen, dies explizit dazu zu schreiben. Echte Grobheiten sind jedoch klar zurückzuweisen.
• Gesicht: Verwende deinen Screen-Namen konsistent überall, wo du schreibst: Mails, Chats, Wikis etc. Verwende deinen Klarnamen, oder wenn Anonymität erforderlich ist, verwende konsistent einen echt klingenden Aliasnamen — es ist dein Gesicht im Netz. Die Verwendung von Titeln wie Dr. oder Prof. in einer Diskussion wirkt ausschließend und drückt eher Unsicherheit aus. Es geht um den Respekt der Person, nicht des Titels. Signaturen am Ende einer Mail sollten möglichst kurz und unaufdringlich sein. Auf sie ganz zu verzichten, ist auch nicht verkehrt.

Fogel befasst sich ausführlich mit Fallstricken:

• Schreibe nicht ohne Zweck: Du must nicht auf alles antworten. Es gibt jedoch zwei gute Gründe zu schreiben: Du erkennst einen Fehler in einem Vorschlag, den niemand anderes wahrnimmt; du beobachtest eine Misskommunikation zwischen anderen und kannst das klären.
• Produktive vs. unproduktive Diskussionen: Wenn sich Inhalte wiederholen oder die Diskussion ins Allgemeine abdriftet, dann sinkt — technisch ausgedrückt — die Signal-Rausch-Rate. Auch hier ist es wichtig, wie du intervenierst: Schiebst du irgendwem die Schuld zu (oder allgemein den anderen) und beschwerst dich oder beschreibst du unter Verwendung einer einschließenden „wir“-Formulierung den Stand und machst Vorschläge zum weiteren Vorgehen (»Hier stehen wir, und das können wir tun«).
• Umso softer das Thema, desto länger die Debatte: Nicht-technische Debatten (Organisation, Veröffentlichungen etc.) können ausufern, weil hier jede/r eine Meinung beitragen kann. Die Beobachtung, dass sich die Intensität der Debatte umgekehrt proportional zur Komplexität des Themas verhält, ist als Fahrradschuppen-Effekt ^[9] in die Literatur eingegangen. Das beste, was man hier tun kann, ist auf eben diesen Effekt aufmerksam zu machen, ganz sind jedoch »Fahrradschuppen-Anstreich-Parties« nicht zu vermeiden.
• Vermeide »heilige Kriege«: Beim »heiligen Krieg« verhält es sich ähnlich wie bei Diskussionen um die Farbe des Fahrradschuppens. Der Unterschied ist jedoch die persönliche Intensität, die mit solchen Debatten verbunden wird. Verständnis für eine andere Position wird hier als Schwäche interpretiert. Das beste ist, Themen für »heilige Kriege« vorab zu minimieren (Lizenzen etc.). Ist er einmal entbrannt, kann man öffentlich die Debatte verlassen, am besten jedoch ohne Bitterkeit oder Unterstützung einer Position.
• Der »geräuschvolle Minderheiten« Effekt: Eine Minderheitenposition kann versuchen, durch viele und längliche Mails einen großen Raum in einer Mailingliste einzunehmen, um auf diese Weise ihrer Position Gewicht zu verschaffen. Hier hilft oft nur, die wirkliche Anzahl der Unterstützer zu bestimmen und zu dokumentieren.

Einen relativ großen Raum nimmt der Abschnitt über »schwierige Leute« ein. Das sind für Fogel nicht einfach »grobe« Leute, zu deren Grobheiten man sich klar zurückweisen könne, sondern Menschen, die auf verschiedene Weise die Projektziele unterlaufen und zerstören. Solcher Art von Obstruktion ^[10] ist nicht so einfach zu begegnen, da meistens reale Schwachpunkte des Projektes Ansatzpunkte für die Obstruktion sind. Fogel nimmt an, dass solche Leute nicht bewusst ein Projekt zestören wollen, sondern das ein obstruktives Verhalten aus einer individuellen Wahrnehmung von Ausgeschlossensein bis hin zu paranoiden Formen der Verschwörung gegen sich resultiert.

Ein Reaktion darauf ist schwierig. Toleranz gegenüber solchem Verhalten ist für eine gewisse Zeit eine mögliche Reaktion. Wenn sich aber nichts ändert, dann ist eine Intervention notwendig. Wer öffentlich interveniert, um Obstruktion entgegenzutreten, wird jedoch häufig selbst als destruktiv wahrgenommen und liefert weitere Munition für u.U. eine Verschärfung der Debatte. Lager können sich bilden, die Maßnahmen ablehnen oder befürworten etc.

Fogel gibt kein Patentrezept, sondern berichtet von einem Fall aus seiner Praxis. Hier war es so, dass eine Person durch extrem viele Mails auffiel, auf die andere sich genötigt sahen zu reagieren, was nicht nur von den Projektzielen ablenkte, sondern auch viel Zeit absorbierte. Gleichzeitig trug diese Person nichts praktisch bei (Code, Doku, Fixes, Reports etc.). Der Maintainer versicherte sich über Privatkontakte zunächst bei einer Reihe anderer aktiver Projektmitglieder, ob seine Wahrnehmung geteilt werde. Er erstellte eine Faktenliste (Anzahl der Mails von wem). Die Gruppe rief die betreffende Person an und forderte sie direkt auf, das Mailen einzustellen. Die Person sah die erläuterten Gründe nicht ein, folgte jedoch der Aufforderung. Die Mailingliste wurde wieder benutzbar.

Ein vergleichbarer Fall ereignete sich in der Oekonux ^[11]-Mailingliste. Auch hier verständigte sich eine aktive Gruppe auf Maßnahmen. Eine kollektive Moderation wurde beschlossen und umgesetzt. Destruktive Mails — gleich von wem — wurden nun ausgefiltert. In der Folge ging jedoch insgesamt die Listenaktivität zurück. Damit wurde ein Argument der »schwierigen Person« bestätigt, dass die Liste ohne seine Beiträge nur eine leere Hülle sei. Eine kritische Projektsituation und obstruktives Verhalten überlagerten sich hier. Eine echte Lösung bot die Moderation nicht.

Die nächsten drei Unterabschnitte des Kapitels »Kommunikation« behandeln das Wachstum des Projektes, der Umgang mit Fehlerverfolgungssystemen (»Bugtracker«) und die Publikationspraxis (Releases, Sicherheitsverletzungen, Fehlerbereinigungen etc.). Zusammenfassend: Fogel empfiehlt Offenheit, Transparenz und Dokumentation als Leitlinie für eine gute Praxis. Er gibt viele praktische Tipps vom Format von Log-Einträgen in der Änderungsdatei bis hin zur Ankündigung von Patches. Die Details lasse ich hier weg.

Management von Freiwilligen

Es reicht nicht aus, eine gute Atmossphäre im Projekt zu haben, sondern es ist notwendig, dass sich jemand (eine/r oder mehrere) um die Freiwilligen kümmert. Fogel verwendet hierfür den Begriff »Management«, was auf Menschen angewendet (statt auf Prozesse) in meinen Ohren etwas befremdlich klingt. Der zweite auffällige Begriff ist der des »Politischen«. »Politisch« sind für Fogel alle nichttechnischen Resultate der Projektpraxis. Als Beispiel nennt er die Veränderung von Machtverhältnissen als Konsequenz bestimmter technischer Entscheidungen. Solche Konsequenzen müsse man stets im Blick haben. Gemeint ist der oder die Projektmanager/in (Maintainer).

Folgende Themen werden behandelt:

• Delegation ist primär ein soziales und politisches Werkzeug. Delegieren bedeutet, Vertrauen zu geben. Fogel diskutiert den Unterschied zwischen Anfrage und Beauftragung. Eine willkürliche Beauftragung ist nicht möglich. Es gibt jedoch eine kolletiv nachvollziehbare Erwartung, dass bestimmte Personen eine Aufgabe übernehmen. Als Beispiel nennt Fogel das Beheben eines Problems in einem Stück Code durch den Autor. Solche Erwartungen müssen offen kommuniziert werden. Wenn man jemanden gefragt hat, ob er/sie die Aufgabe übernimmt, ist es wichtig, nach einiger Zeit nachzuhaken. Der Zweck ist nicht, Druck auszuüben, sondern zu zeigen, dass man auf die Reaktionen achtet und wahrnimmt, was geschieht.
• Lob und Kritik sind keine Gegensätze, sondern unterschiedliche Formen der Aufmerksamkeit. Die geeignete Form von Kritik ist die detaillierte und leidenschaftslose Kritik an der Sache — niemals der Person. Lob sollte nicht alltäglichen Aktivitäten gelten, sondern besonderen Leistungen. Gleichwohl sollten alle Aktivitäten ein Feedback oder eine Bestätigung haben, damit klar ist, dass die Aktivität wahrgenommen wurde und nicht unterging.
• Vermeiden von Territorialität bedeutet zu verhindern, dass einzelne Personen Bereiche eines Projektes für sich reklamieren und dazu tendieren, andere von diesem Bereich fernzuhalten. Autorität für einen Bereich kann man sich nicht nehmen, sondern man erhält sie durch den Konsens und die Akzeptanz des Projektes auf der Basis von Kompetenz und Leistungen. Auch wenn die Kompetenz unbestritten vorhanden ist, dürfen andere nicht ausgeschlossen werden. Um Territorialkämpfe zu vermeiden, erlauben viele Projekte keine Entwicklernamen im Quellcode (dafür gibt es eine summarische Credits-Datei).
• Den Automatisierungsgrad möglichst hoch zu treiben, ist bei sich wiederholenden, deterministischen Aufgaben sinnvoll. Als Daumenregel gilt, dass sich eine Automatisierung lohnt, wenn der Aufwand für die Einrichtung der Automatisierung höchstens zehn Mal so groß ist wie die manuelle Ausführung (bei häufigen oder komplexen Aufgaben zwanzig Mal). Ein sehr wichtiger Bereich ist das automatische Testen, insbesondere Regressionstests ^[12].
• Behandle jeden Nutzer als potenziellen Freiwilligen. Fogel wirbt in diesem Abschnitt für ein Einnehmen der Nutzerperspektive. Nutzer wissen in der Regel nicht, wie sie zum Beispiel einen Fehler mitteilen können und schreiben dann nur „läuft nicht“. Er schlägt drei Botschaften vor, die eine Antwort enthalten sollte: (1) Du hast ein Problem, wir empfinden den Frust; (2) Beschreiben, welche Form der Fehlerdokumentation (kopieren der Fehlermeldung, Screenshot etc.) hilfreich wäre; (3) Hinweise geben, wo und wie Fehler in umfassender Form gemeldet werden können (Bugtracking ^[13]-System).

Die nächsten Abschnitte, die ich überspringe, behandeln das Aufteilen des technischen Managements (Patch-, Übersetzungs-, Dokumentations-, Problem-, FAQ-Manager), Verändern von Rollen und Verantwortlichkeiten im Projekt, die Auswahl von Personen mit Commit-Rechten (Einspielen von Quellcode in die Versionsverwaltung) und Credits (Danksagungen). Letztes Thema in dieser Buchsprechung sind Forks.

Forks wurden bereits im Kontext der Projektstruktur genannt — als Möglichkeit. Wie aber mit einem Fork umgehen, wenn er geschieht, oder gar: Wann sollte ein Fork initiiert werden? Fogel stellt zu Beginn klar: Die bloße Existenz eines Forks ist nicht das Problem, das Problem ist der Verlust an Entwicklern und Nutzern. Von dort aus schlägt er eine offensive und konstruktive Umgehensweise mit Forks vor, wenn sie nicht mehr zu vermeiden sind:

• Stelle Entwickler nicht vor Entscheidungen für oder gegen den Fork bzw. das eigene Projekt.
• Sei so kooperativ wie möglich; drücke den Wunsch aus, so kompatibel wie möglich zu sein.
• Entferne keine Commit-Rechte von Entwicklern, die den Fork unterstützen — sie können eine wichtige Brücke bilden.
• Biete den Forkern infrastrukturelle Unterstützung an (etwa eine Kopie der kompletten Versionshistorie).
• Frage, ob die Forker weitere Unterstützung brauchen und biete diese an.

Der Grund für diese — unbedingt öffentlichen — Angebote ist nicht, den Fork zu befördern, sondern die Entwickler durch nicht-rachsüchtiges Verhalten davon zu überzeugen, dass die eigene Projektlinie die sichere ist. Die Logik des Krieges, sich für eine Seite zu entscheiden, gilt für Freie Software nicht, denn es kommt darauf an, Entwickler davon zu überzeugen, in beiden Projekten mitzuarbeiten und für Kompatibilität zu sorgen. Das erhöht die Wahrscheinlichkeit, nützliche Features aus dem Fork in das eigene Projekt zu integrieren und ggf. später einmal wieder zu einem Projekt zu verschmelzen (Beispiel ist der GCC/EGCS-Fork ^[14]).

Das eigene Initiieren eines Forks sollte die absolut letzte Möglichkeit darstellen und nicht als »extremistische Debattiertechnik — Folge mir oder ich spalte das Projekt« verwendet werden. Vor einem Fork gilt es, die Stimmung und aktuellen Kräfteverhältnisse im Projekt zu berücksichtigen. Ohne dass Fogel einen Begriff davon hätte, beschreibt er den Unterschied zwischen einem einfach und doppelt freien ^[15] Softwareprojekt: Zwar garantiere die Lizenz die Freiheit des Codes, aber dennoch kann eine Firma den maßgeblichen Einfluss im Projekt ausüben, wenn sie wichtige Entwickler für ihre Tätigkeit im Projekt bezahlt. Dann nutze es nichts, wenn die Entwickler zwar forken würden, diese Meinung aber zurückhalten, weil es nicht der Firmenpolitik entpricht.

Wenn alle Bedingungen gegeben sind und ein Fork wirklich mehr vermeidbar ist, dann lauten die Empfehlungen analog zur Anti-Fork-Position:

• Kündige den Fork in einem nichtfeindlichen Ton an.
• Begründe leidenschaftslos und sachlich, was dich zu diesem Schritt veranlasste.
• Verdeutliche, dass du den Code forkst und nicht den Namen — wähle einen nicht mit dem ursprünglichen Projekt verwandten neuen Namen.
• Erleichtere den Entwickern den Einstieg in den Fork, in dem du allen bisherigen Committern automatisch Commit-Rechte gibst — auch jenen, die sich öffentlich gegen den Fork aussprachen.
• Die Hauptbotschaft ist: Es gibt Unterschiede in den Auffassungen, doch es gibt keine Feinde, und jeder ist mit seinem Beitrag willkommen.

Hier fällt mir natürlich sofort ein Vergleich mit »Forks« in der linken politischen Szene ein. Ohne Übertreibung kann ich wohl sagen, dass die Linke komplett unfähig ist, mit »Forks« anders als destruktiv umzugehen. Mir ist noch die Krisis-Exit-Spaltung in Erinnerung. Alle »don’t do that« sind hier versammelt: Mache den anderen nieder, schließe andere aus, schade den anderen so effektiv wie möglich, streite um den Namen, suche Schuldige, ziehe vor Gericht usw.

Bewertung — und was fehlt…

In meiner Darstellung habe ich sicherlich viel ausführlichere Begründungen abgekürzt. Ich hoffe dennoch, dass ich die wesentlichen Punkte getroffen habe. Zielgruppe des Buches sind Maintainer von Freien Softwareprojekten. Fogel guckt auf die Handlungsmöglichkeiten aus ihrer Perspektive. Dadurch hatte die Darstellung nach meinem Gefühl etwas Schlagseite, weil die komplexe Dynamik in sozialen Prozessen nur als Umgebung vorkam, die bearbeitet werden will — nicht als Handlungsfeld, in dem ich mich als Maintainer bewege. Obwohl eigentlich klar ist, dass ich eigentlich gar nichts selbst auslösen kann — etwa per Befehl wie in einem Unternehmen –, haben die Ratschläge trotzdem manchmal tendenziell diesen Charakter.

Das Genderthema wird nicht nicht angesprochen, obwohl es Fogel sprachlich durchaus berücksichtigt hat. So wie er zwischen »Open Source« und »Freier Software« einfach abwechselt, um hier einem Streit aus dem Weg zu gehen, so verwendet er im Wechsel »he« oder »she« im Text. Schade, ich unterstelle, dass Fogel auch hier explizit etwas zu sagen hätte.

Was auch fehlt, ist die Bedeutung von Real-Life-Events, also Konferenzen, Code-Sprints, Doc-Sprints, Workcamps etc. Aus meiner Sicht und Erfahrung sind solche Treffen für den sozialen Prozess in einer aktiven Community sehr wichtig.

Insgesamt ist es sehr empfehlenswert, das Buch zu lesen. Als physisches Ding kann man es von O’Reilly ^[16] kaufen oder via Internet als PDF ^[17] herunterladen oder online lesen ^[18].