Selbst nachdem Sie ein Projekt an die Öffentlichkeit gebracht haben, werden Sie und die anderen Gründungsmitglieder manchmal damit konfrontiert werden, schwierige Fragen innerhalb eines kleineren Kreises durch private Kommunikation lösen zu müssen. Das gilt besonders am Anfang des Projekts, wo viele wichtige Entscheidungen zu treffen sind und es meist nur wenige Freiwillige gibt, die qualifiziert wären, sie zu treffen. All die offensichtlichen Nachteile öffentlicher Diskussionen auf Mailinglisten werden greifbar vor Ihnen liegen: Die bei E-Mail-Diskussionen unvermeidbare Verzögerung, die für einen Konsens erforderliche Zeit, die Mühe, sich mit naiven Neulingen auseinandersetzen zu müssen, die meinen, alles zu verstehen (solche gibt es in jedem Projekt; manchmal bringen sie im nächsten Jahr die besten Beiträge, manchmal bleiben sie ewig naiv), die Person, die nicht versteht, warum Sie nur das Problem X lösen wollen, wenn es offensichtlich eine Untermenge des größeren Problems Y ist, usw. Die Verlockung, diese Unterhaltungen hinter verschlossenen Türen zu führen und sie als vollendete Tatsache zu präsentieren oder zumindest als nachdrückliche Empfehlung einer vereinigten und einflussreichen Wählergruppe, ist tatsächlich groß.

Tun Sie's nicht.

So langsam und mühselig öffentliche Diskussionen auch sein mögen, sie sind auf lange Sicht trotzdem vorzuziehen. Wichtige Entscheidungen privat zu treffen ist Gift für Freiwillige. Kein Freiwilliger, der seine Sache ernst meint, würde es lange in einer Umgebung aushalten, in dem alle wichtigen Entscheidungen von einer geheimen Versammlung getroffen werden. Desweiteren hat die öffentliche Diskussion den Vorteil, dass ihre positiven Nebenwirkungen viel länger fortbestehen als die kurzlebige technische Frage, um die es geht:

Schließlich besteht die Möglichkeit, dass jemand auf der Mailingliste einen echten Beitrag zu der Diskussion leisten könnte, indem er eine Idee aufbringt, an die Sie nie gedacht hätten. Es ist schwer zu sagen, wie wahrscheinlich das ist; es hängt schlicht von der Komplexität des Problems und dem erforderlichen Grad der Spezialisierung ab. Wenn ich aber ein Beispiel anführen darf, wage ich zu behaupten, dass es viel wahrscheinlicher ist, als sie es intuitiv erwarten würden. Im Subversion-Projekt glaubten wir (die Gründer), mit einer tiefen und komplexen Problematik konfrontiert zu sein, über die wir uns seit ein paar Monaten viele Gedanken gemacht hatten; und offen gesagt zweifelten wir daran, dass irgendjemand auf der kürzlich eingerichteten Mailingliste etwas Wertvolles zu der Diskussion beizutragen hätte. Wir nahmen also den einfachen Weg und begannen, unsere technischen Ideen in privaten E-Mails untereinander auszutauschen, bis ein Beobachter des Projekts^[27] davon Wind bekam und uns bat, die Diskussion auf die öffentliche Mailingliste zu verlegen. Wir verdrehten zwar ganz schön die Augen, taten es aber – und waren ganz erstaunt über die Anzahl aufschlussreicher Kommentare und Vorschläge, die sich recht schnell ergaben. In vielen Fällen boten Leute Ideen an, die uns nie in den Sinn gekommen wären. Es stellte sich heraus, dass ein paar sehr kluge Köpfe auf dieser Liste waren; sie hatten nur auf den richtigen Köder gewartet. Es ist wahr, dass die resultierenden Diskussionen länger dauerten, als wenn wir sie privat gehalten hätten, allerdings waren sie um vieles produktiver, was die zusätzliche Zeit in jedem Fall wert war.

Ohne in allzu verallgemeinernde Aussagen wie "Die Gruppe ist immer schlauer als der Einzelne" abzugleiten (wir kennen alle genügend Gruppen, die daran zweifeln lassen), muss man doch anerkennen, dass es bestimmte Aktivitäten gibt, für die Gruppen besonders geeignet sind. Ausführliche Gutachten sind eine; schnell auf viele Ideen zu kommen eine weitere. Die Qualität dieser Ideen hängt natürlich davon ab, wie hochwertig die Gedanken waren, die man hineingesteckt hat. Sie werden aber nie erfahren, was für geistreiche Denker da draußen sind, solange Sie ihnen keine echten Herausforderungen bieten.

Es gibt natürlich auch Diskussionen, die man im Privaten führen muss; im Verlauf des Buches werden wir Beispiele dafür sehen. Das leitende Prinzip sollte aber sein: Solange es keinen Grund gibt, etwas privat zu regeln, sollte es öffentlich geschehen.

Dies in Gang zu setzen erfordert Ihre Einflussnahme. Es reicht nicht, lediglich sicherzustellen, dass Ihre eigenen Nachrichten an die öffentliche Mailingliste gehen; Sie müssen auch andere dazu bewegen, ihre unnötig privaten Unterhaltungen öffentlich zu halten. Wenn jemand versucht, eine private Diskussion mit ihnen anzufangen und es keinen Grund gibt, sie privat zu halten, sollten Sie sich verpflichtet fühlen, sofort eine angemessene übergeordnete Diskussion zu eröffnen. Sie sollten nicht einmal direkt auf das Thema eingehen, bevor Sie nicht entweder die Diskussion erfolgreich an einem öffentlichen Ort gelenkt haben oder deutlich erkannt haben, dass sie tatsächlich besser privat gehalten werden sollte. Wenn Sie sich konsequent so verhalten, werden die Beteiligten es ziemlich schnell mitbekommen und gleich die öffentlichen Foren benutzen.

Sie sollten von Anfang an, gleich nachdem Ihr Projekt an die Öffentlichkeit geht, null Toleranz gegenüber unhöflichem oder beleidigendem Verhalten in ihren Foren zeigen. Null Toleranz heißt nicht unbedingt, diese technisch durchzusetzen. Sie sollten diese Leute nicht aus der Liste entfernen, wenn sie einen anderen Teilnehmer "flamen", oder ihnen wegen abfälligen Bemerkungen den Commit-Zugriff entziehen. (Theoretisch müssten Sie eventuell auf solche Mittel zurückgreifen, aber erst nachdem alle anderen erschöpft sind – was am Anfang eines Projekts per Definition noch nicht der Fall ist.) Null Toleranz bedeutet, schlechtes Benehmen niemals einfach unbemerkt geschehen zu lassen. Wenn jemand zum Beispiel eine technische Bemerkung zusammen mit einem argumentum ad hominem gegen einen anderen Entwickler koppelt, ist es zwingend notwendig, dass Ihre Reaktion den persönlichen Angriff anspricht, als separate Angelegenheit, und erst dann auf den technischen Inhalt eingeht.

Leider ist es sehr leicht und allzu üblich, dass konstruktive Diskussionen in destruktive "flame wars" ausarten. Menschen werden Dinge sagen, die sie nie von Angesicht zu Angesicht sagen würden. Die Themen dieser Diskussionen verstärken nur diesen Effekt: Bei technischen Angelegenheiten glauben Menschen oftmals, dass es nur eine richtige Antwort zu den meisten Fragen gibt und dass eine Abweichung von ihrer Antwort nur durch Ignoranz oder Dummheit des Anderen erklärt werden kann. Den Vorschlag einer Person als dämlich zu bezeichnen ist oft nur einen winzigen Schritt davon entfernt, die Person selbst als dämlich zu bezeichnen. Tatsächlich ist es oft schwer zu unterscheiden, wo die technische Diskussion aufhört und die persönliche Beleidigung anfängt, was auch ein Grund ist warum drastische Maßnahmen oder Bestrafungen nicht angebracht sind. Sie sollten stattdessen, sobald Ihnen derartiges auffällt, eine Nachricht schreiben, die nachdrücklich darauf hinweist, wie wichtig es ist, die Unterhaltung in einem freundlichen Ton zu führen, ohne dabei jemanden zu beschuldigen, absichtlich giftig gewesen zu sein. Leider hören sich diese "Netter-Polizist"-Nachrichten meist an wie die Predigt einer Vorschullehrerin, die ihre Klasse über gutes Benehmen belehrt:

So gestelzt sich solche Antworten auch anhören, sie haben doch eine messbare Wirkung. Wenn Sie immer wieder auf solches Verhalten hindeuten, aber keine Entschuldigung von der angreifenden Partei fordern, lassen Sie ihr die Möglichkeit, sich abzuregen und ihre bessere Seite zu zeigen, indem sie sich beim nächsten mal anständiger benimmt — und das wird sie.

Eines der Geheimnisse, erfolgreich gegen solches Verhalten vorzugehen, ist niemals die untergeordnete Diskussion zum Hauptthema werden zu lassen. Es sollte immer nur nebenbei erwähnt werden, ein kurzes Vorwort zu der eigentlichen Antwort. Weisen Sie im Vorbeigehen darauf hin, dass "wir hier so nicht arbeiten", aber gehen Sie dann weiter zum echten Inhalt, damit die Beteiligten immer etwas zum Thema haben, worauf sie antworten können. Wenn jemand protestiert, dass er unrechtmäßig zurechtgewiesen wurde, sollten Sie sich nicht in einen Streit verzetteln. Antworten Sie entweder gar nicht (wenn Sie denken, dass die Person nur Dampf ablassen will und nicht wirklich eine Antwort erwartet), oder entschuldigen Sie sich für die übertriebene Reaktion und schreiben Sie, dass es schwer ist, Nuancen aus einer E-Mail herauszulesen. Gehen Sie danach aber wieder zum eigentlichen Thema über. Bestehen Sie niemals auf ein Eingeständnis, privat oder öffentlich, von jemandem, der sich unangemessen verhalten hat. Wenn er sich von sich aus entschuldigt, ist das großartig, aber es von ihm zu verlangen, würde nur Verbitterung heraufbeschwören.

Das übergeordnete Ziel ist, dass gute Umgangsformen zu einem wesentlichen Merkmal in der Kerngruppe werden. Das hilft dem Projekt, da Entwickler durch "flame wars" vertrieben werden können (sogar von Projekten, welche sie mögen und unterstützen). Es kann passieren, dass sie ihre Vertreibung nicht einmal mitbekommen; Mancher könnte sich die Liste anschauen, erkennen dass er ein dickeres Fell bräuchte, um an diesem Projekt teilzunehmen, und verzichtet daraufhin besser gleich ganz auf die Teilnahme. Foren freundlich zu halten ist auf lange Sicht eine Überlebenstaktik und das ist einfacher, wenn das Projekt noch klein ist. Ist es erst zu einem Teil der Kultur geworden, werden Sie nicht mehr der einzige sein, der sich darum bemüht. Jeder wird daran mitwirken.

In der Dekade seit der ersten Ausgabe dieses Buches von 2006 ist es gewissermaßen üblicher für Open-Source-Projekte geworden, gerade auch für die Größeren, explizite Verhaltensregeln zu verabschieden. Ich denke dies ist ein guter Trend. Da Open-Source-Projekte nach langer Zeit endlich auch vielfältiger werden, kann das Vorhandensein eines Verhaltenskodex die Teilnehmer daran erinnern, zweimal darüber nachzudenken, ob ein Witz für manche Menschen verletzlich sein könnte oder ob es  — um ein zufälliges Beispiel zu nehmen —  zu einer willkommenden und einbindenden Atmosphäre beiträgt wenn eine Dokumentation einer Open-Source Bildbearbeitungsbibliothek abermals ein weiters Bild einer hübschen jungen Frau verwendet um das Verhalten eines bestimmten Algorithmus zu illustrieren. Verhaltensregeln erinnern Teilnehmende daran, dass die Pflege einer respektvollen und willkommenden Umgebung eines jeden Verantwortung ist.

Eine Internetsuche wird leicht viele Beispiele von Verhaltensregeln für Open-Source-Projekte finden. Die Populärste ist möglicherweise die bei https://contributor-covenant.org/, so ist dort natürlicherweise eine positive Rückkoppelungsdynamik wenn Sie diese wählen: Mehrere Entwickler werden diese bereits kennen, zusätzlich bekommen sie ihre Übersetzung in andere Sprachen kostenlos usw.

Ein Verhaltenskodex wird nicht alle zwischenmenschlichen Probleme in ihrem Projekt lösen. Weiter gilt, wenn er missbraucht wird, dass er das Potential hat, neue Probleme zu erzeugen — es ist immer möglich, Menschen zu finden, die sich darauf spezialisiert haben, soziale Normen und Regeln zu manipulieren, um einer Gemeinschaft Schaden zuzufügen, anstatt ihr zu helfen (siehe „Schwierige Leute“), und wenn sie selbst zum Teil unglücklich sind, mögen einige dieser Menschen ihren Weg in ihr Projekt finden. Es liegt immer an der Führung des Projektes, wobei ich diejenigen meine, denen die meisten anderen des Projektes am meisten bereitwillig zuhören, einen Verhaltenskodex durchzusetzen und darauf zu achten, dass er weise benutzt wird (Siehe auch „Unhöflichkeiten erkennen“).

Einige Teilnehmer werden tatsächlich nicht mit der Notwendigkeit, überhaupt einen Verhaltenskodex einzuführen, übereinstimmen und argumentieren gegen ihn mit der Begründung, dass er mehr Schaden als Gutes anrichten könnte. Auch wenn sie den Eindruck hast, dass diese falsch liegen, ist es zwingend, dass sie sicherzustellen helfen, dass diese ihre Meinung äußern können ohne dafür angegriffen zu werden. Nach allem nicht mit der Notwendigkeit eines Verhaltenskodex übereinzustimmen ist nicht das Selbe wie — es ist faktisch komplett unabhängig davon — sich in einem Verhalten zu engagieren, welches eine Verletzung des angestrebten Verhaltenskodex darstellt. Manchmal bringen Menschen diese Dinge durcheinander und müssen an diesen Unterschied erinnert werden.^[28]

Eine der besten Möglichkeiten, eine produktive Entwicklergemeinschaft zu fördern ist es, Leute zu überreden, sich gegenseitig Ihren Code anzuschauen. Das effektiv zu gewährleisten, erfordert ein wenig technische Infrastruktur – insbesondere sollten Commit-E-Mails angeschaltet werden; siehe „Commit-E-Mails“ für Details hierzu. Commit-E-Mails sorgen dafür, dass jede Änderung am Quellcode eine E-Mail zur Folge hat mit dem zugehörigen Kommentar des Autors und den Diffs (siehe Diff im Kapitel „Vokabular der Versionsverwaltung“). Code Review heißt, diese Commit-E-Mails beim Eintreffen auch durchzulesen und nach Fehlern und möglichen Verbesserungen zu suchen. ^[29]

Code Review dient mehreren Zwecken gleichermaßen. Er ist das offensichtlichste Beispiel für "Peer Review" in der Open-Source-Welt und hilft unmittelbar, die Qualität der Software zu erhalten. Jeder Fehler, der in einer Software ausgeliefert wird, kam durch einen Commit zustande der übersehen wurde; es werden umso weniger Fehler in einer veröffentlichten Version sein, je mehr Augen auf jeden Commit gerichtet sind. Code Review dient aber auch einem indirekten Zweck: Es bestätigt Menschen, dass ihre Arbeit Bedeutung hat, man würde sich schließlich nicht die Zeit nehmen über einen Commit zu schauen, wenn es einen nicht interessieren würde, welche Auswirkungen er hat. Menschen leisten dann die beste Arbeit wenn sie wissen, dass andere sich die Zeit nehmen diese zu prüfen.

Jeder Review sollte öffentlich durchgeführt werden. Selbst wenn ich im selben Raum mit anderen Entwicklern bin und einer von uns einen Commit macht, achten wir darauf, den Review nicht verbal im Raum zu führen, sondern ihn über die Entwickler-Liste zu schicken. Jeder profitiert davon, wenn der Review sichtbar ist. Leute folgen den Erläuterungen und finden darin manchmal Mängel und selbst wenn nicht, erinnert es sie zumindest daran, dass Code Review eine zu erwartende regelmäßige Aktivität ist, wie Geschirrspülen oder Rasenmähen.

Im Subversion-Projekt hatten wir am Anfang nicht diese Gewohnheit. Es gab keine Garantie, dass jeder Commit überprüft wurde, wir schauten zwar manchmal über bestimmte Änderungen, wenn ein bestimmter Bereich im Quellcode besonders interessant schien. Es schlichen sich Fehler ein, die man eigentlich hätte sehen sollen und müssen. Ein Entwickler namens Greg Stein, der aus seiner vorherigen Arbeit den Wert von Code Review kannte, entschied sich, ein Beispiel zu setzen, indem er sich jede Zeile von jedem einzelnen Commit anschaute. Auf jeden Commit, den irgendjemand machte, folgte bald eine E-Mail von Greg an die Entwickler-Liste, indem er den Commit sezierte, mögliche Probleme analysierte und ab und zu, für besonders cleveren Code, ein Lob aussprach. Sofort begann er, Fehler und problematische Programmierpraktiken zu entdecken, die ansonsten durchgerutscht wären, ohne je bemerkt zu werden. Er beschwerte sich wohlgemerkt nie, dass er der einzige sei, der Code Review betrieb, auch wenn es keinen unwesentlichen Teil seiner Zeit in Anspruch nahm, er lobte bei jeder Gelegenheit die Vorteile von Code Review. Ziemlich bald fingen andere an, mich eingeschlossen, regelmäßig Commits zu überprüfen. Was war unsere Motivation? Greg hatte uns nicht bewusst durch Beschämung dazu gebracht. Er hatte bewiesen, dass Code Review eine wertvolle Investition von Zeit ist und dass man durchaus auch zum Projekt beitragen kann, wenn man die Änderungen anderer durchsieht, anstatt selbst neuen Code zu schreiben. Nachdem er das demonstriert hatte, wurde es zum erwarteten Verhalten. Das ging sogar soweit, dass man sich, wenn auf einen Commit keine Reaktion folgte, als Committer Sorgen machte und sogar auf der Liste nachfragte, ob denn niemand die Zeit gefunden hätte, es sich anzuschauen. Später bekam Greg eine Arbeit, die ihm nicht so viel Zeit für Subversion ließ, und er musste mit dem regelmäßigen Code Review aufhören. Aber inzwischen war die Angewohnheit unter uns anderen bereits so weit verbreitet, als sei es nie anders gewesen.

Beginnen Sie mit Code Reviews vom allerersten Commit an. Probleme, die man am einfachsten bei der Durchsicht von Diffs erkennt, sind Sicherheitslücken, Speicherlecks, ungenügende Kommentare oder Dokumentation von Schnittstellen, Eins-daneben-Fehler, Aufrufer-Aufgerufener-Divergenzen und andere Probleme, deren Entdeckung keinen großen Kontext erfordern. Selbst Angelegenheiten größeren Umfangs, wie z.B. häufig auftauchende Muster, nicht an einer gemeinsamen Stelle zu abstrahieren, werden leichter erkennbar, wenn man Code Review regelmäßig betreibt, weil man sich an vergangene Diffs erinnert.

Machen Sie sich keine Sorgen, dass Sie nichts finden, worüber es etwas zu sagen gäbe, oder dass Sie nicht genug über alle Bereiche im Code wissen. Es gibt meistens irgendetwas über so ziemlich jeden Commit zu sagen; selbst wenn Sie nichts Bedenkliches finden, kann es sein, dass Sie etwas Lobenswertes finden. Wichtig ist, jedem der Committer klar zu machen, dass ihre Arbeit gesehen und verstanden wird. Natürlich befreit Code Review die Programmierer nicht von der Verantwortung, ihre Änderungen vor dem Commit zu überprüfen und zu testen; niemand sollte sich auf Code Review verlassen, um Fehler zu finden, die er eigentlich selbst hätte finden sollen.

Wenn Sie ein bestehendes Projekt mit aktiven Entwicklern, die eine Umgebung mit geschlossenem Code gewohnt sind, öffnen, sorgen Sie dafür, dass Klarheit über den Umfang der Änderungen besteht, die auf die Entwickler zukommen – und versuchen Sie sich so gut wie möglich in ihre Lage zu versetzen.

Versuchen Sie sich die Situation aus ihrer Sicht vorzustellen: vorher wurden Entscheidungen über Code und Architektur in einer Gruppe von Programmierern getroffen, die sich alle mehr oder weniger gleich gut mit der Software auskannten, die alle den gleichen Druck von oben zu spüren bekamen und die sich alle gegenseitig in ihren Stärken und Schwächen kannten. Jetzt verlangen Sie von ihnen, ihren Code freizugeben, nur damit irgendwelche Fremden ihn auseinandernehmen, untersuchen und sich Meinungen über ihn allein anhand des Quellcodes bilden, ohne zu wissen, welcher geschäftliche Druck Sie zu bestimmten Entscheidungen gezwungen hat. Diese Fremden werden viele Fragen stellen, Fragen die vorhandene Entwickler aufrütteln werden, wenn Sie feststellen müssen, dass die Dokumentation, an der sie so hart gearbeitet haben, immer noch lückenhaft ist (das ist unvermeidbar). Um dem ganzen noch ein Sahnehäubchen aufzusetzen: die Neulinge sind unbekannte, gesichtslose Wesen. Wenn einer Ihrer Entwickler sich seiner Fähigkeiten als Programmierer unsicher ist, stellen Sie sich vor, wie es ihn erst verbittern wird, wenn die Neulinge auf Mängel in seinem Code hinweisen, noch dazu vor seinen Kollegen. Wenn Sie kein Team von perfekten Programmierern haben, ist sowas unvermeidlich – tatsächlich wird es am Anfang wahrscheinlich allen passieren. Nicht weil sie schlechte Programmierer sind; sondern weil jedes Projekt oberhalb einer bestimmten Größe zwangsläufig Fehler beinhaltet, und die Überprüfung durch eine Gemeinschaft manche dieser Fehler aufdecken wird (siehe „Code Review“ früher in diesem Kapitel). Gleichzeitig werden die neuen Freiwilligen selber nicht so sehr dieser Prüfung unterliegen, da sie selber noch keinen Code beisteuern können, bis sie mehr mit dem Projekt vertraut sind. Für Ihre Entwickler kann das erscheinen, als ob die ganze Kritik immer nur auf sie gerichtet ist und nie nach außen geht. Es besteht deshalb die Gefahr, dass sich unter den alten Hasen eine Belagerungsmentalität einstellt.

Am besten kann man das verhindern, indem man alle vorwarnt, was auf Sie zukommt; es ihnen erklärt, ihnen sagt, dass ein anfängliches Unbehagen völlig normal ist, und ihnen versichert, dass es mit der Zeit besser wird. Manche dieser Warnungen sollten privat geschehen, bevor das Projekt geöffnet wird. Es könnte aber auch hilfreich sein, die Leute auf der Mailingliste zu erinnern, dass es für das Projekt eine neue Art der Entwicklung ist und dass die Anpassung eine gewisse Zeit brauchen wird. Das beste was Sie machen können, ist als gutes Beispiel voranzugehen. Wenn Sie sehen, dass Ihre Entwickler nicht genügend Fragen der neuen Freiwilligen beantworten, nützt es nichts, ihnen zu sagen, dass sie mehr antworten sollten. Es mag sein, dass sie kein gutes Gefühl dafür haben, wann eine Reaktion gerechtfertigt ist, oder es kann sein, dass sie nicht wissen, welche Priorität die eigentliche Arbeit am Code gegenüber der neuen Bürde einnimmt, mit Außenstehenden zu kommunizieren. Man kann sie am ehesten dazu überreden, sich zu beteiligen, indem man sich selbst beteiligt. Beobachten Sie die öffentliche Mailingliste und beantworten Sie ein paar Fragen. Wenn Sie nicht genügend Erfahrung haben, um die Fragen zu beantworten, sollten Sie es für alle sichtbar an einem anderen Entwickler weitergeben, der die nötige Erfahrung hat – und achten Sie darauf, dass er eine Antwort oder zumindest eine Reaktion gibt. Natürlich wird es für die älteren Entwickler verlockend sein, in private Diskussionen zu verfallen, schließlich sind sie daran gewöhnt. Beobachten Sie deshalb auch die interne Mailingliste und bitten Sie ggf. darum, bestimmte Diskussionen besser gleich auf die öffentliche Liste zu verlegen.

Es gibt andere, langfristigere Bedenken beim Öffnen vormals geschlossener Projekte. Kapitel 4, Soziale und politische Infrastruktur untersucht Techniken um bezahlte und unbezahlte Entwickler erfolgreich zu mischen und Kapitel 9, Lizenzen, Urheberrecht und Patente behandelt die nötige rechtliche Sorgfalt beim Öffnen von privatem Code, mit bestimmten Komponenten, die einer anderen Partei "gehört", bzw. von ihnen geschrieben wurde.