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 wollen. 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 E-Mail Verteiler, 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 Freiwilligen auseinandersetzen zu müssen, die meinen alles zu verstehen (diese 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, wird gewiss groß sein.

Mache Sie es 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 lange in einer Umgebung bleiben, 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:

Zuletzt gibt es noch die Möglichkeit, dass jemand auf dem Verteiler einen echten Beitrag zu der Diskussion leisten könnte, indem er eine Idee aufbringt, an der Sie nie gedacht hätten. Es ist schwer zu sagen, wie wahrscheinlich das ist; es hängt schlicht und einfach davon ab, wie komplex das Problem ist und den erforderlichen Kenntnissen ab. Wenn ich aber ein Beispiel heranführen darf, wage ich zu behaupten, dass es viel wahrscheinlicher ist, als man es intuitiv erwarten würde. Im Subversion Projekt, glaubten wir (die Gründer) mit einer tiefen und komplexen Reihe von Problemen konfrontiert zu sein, über die wir uns seit ein paar Monaten viele Gedanken gemacht hatten, und offen gesagt zweifelten wir daran, dass irgendjemand auf dem kürzlich eingerichteten E-Mail Verteiler etwas wertvolles zu der Diskussion beizutragen hatte. Wir nahmen also den einfachen Weg und fingen an unsere technischen Ideen in private E-Mails untereinander auszutauschen, bis ein Beobachter des Projekts^[17] davon Wind bekam, und uns bat, die Diskussion auf den öffentlichen Verteiler zu verlagern. Wir verdrehten zwar ein bisschen die Augen, taten es aber—und waren völlig erstaunt, über die Anzahl aufschlussreicher Kommentare und Vorschläge die schnell daraus resultierten. In vielen Fällen boten Leute Ideen an die uns nie in den Sinn gekommen waren. Es stellte sich heraus, dass ein paar sehr kluge Köpfe auf diesem Verteiler 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 derart produktiver, dass es die zusätzliche Zeit in jedem Fall wert war.

Ohne in allzu verallgemeinernde Aussagen, wie "Die Gruppe ist immer schlauer als der Einzelne" abzuleiten (wir kennen alle genügend Gruppen, um es besser zu wissen), muss man doch anerkennen, dass es bestimmte Aktivitäten gibt, für die Gruppen besonders geeignet sind. Ausführliche Gutachten sind eines; schnell auf viele Ideen zu kommen ist ein Weiteres. 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, ohne ihnen eine Herausforderung zu geben.

Es gibt natürlich auch Diskussionen die man im privaten führen muss; hierfür gibt es im ganzen Buch Beispiele. Das leitende Prinzip sollte aber sein: Wenn es kein Grund gibt die Diskussion privat zu halten, sollte sie öffentlich geführt werden.

Um das in Gang zu setzen, müssen Sie aber Einfluss üben. Es reicht nicht lediglich sicherzustellen, dass Ihre eigenen Nachrichten an den öffentlichen Verteiler gehen; Sie müssen auch andere dazu bewegen ihre unnötig private Unterhaltungen öffentlich zu halten. Wenn jemand versucht eine private Diskussion 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 sichergestellt haben, dass sie doch privat gehalten werden sollte. Wenn Sie sich konsequent so verhalten, werden Leute es ziemlich schnell mitbekommen und gleich die öffentlichen Foren benutzen.

Sie sollten von Anfang an, gleich nachdem Ihr Projekte an die öffentlichen geht, null Toleranz gegenüber unhöfliches oder beleidigendes Verhalten in ihren Foren zeigen. Keine Toleranz heißt nicht unbedingt diese technisch durchzusetzen. Diese Leute sollten nicht von dem Verteiler entfernen werden, wenn Sie einen anderen Teilnehmer "flamen", oder ihnen wegen abfällige Bemerkungen den Commit-Zugriff zu 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 einfach niemals schlechtes Benehmen unbemerkt vorbeiziehen zu lassen. Wenn jemand zum Beispiel eine technische Bemerkung, zusammen mit einem argumentum ad hominem gegen einem anderen Entwickler macht, ist es zwingend notwendig, dass Ihre Reaktion als erstes 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 Sachen sagen die sie nie von Angesicht zu Angesicht sage würden. Die Themen dieser Diskussionen verstärken nur diesen Effekt: Bei technischen Angelegenheiten, fühlen Menschen oft, dass es nur eine richtige Antwort zu den meisten Fragen gibt und dass eine Meinungsverschiedenheit zu ihrer Antwort, nur durch die Ignoranz oder Dummheit des Anderen erklärt werden kann. Es ist ein kurzer Weg den technischen Vorschlag einer Person als bescheuert zu bezeichnen, bis man die Person selber bescheuert nennt. 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 statt dessen wenn Sie darauf stoßen, eine Nachricht schreiben die nachdrücklich darauf hinweist wie wichtig es ist die Unterhaltung in einem freundlichen Ton zu führen, ohne dabei jemand zu beschuldigen absichtlich giftig gewesen zu sein. Leider hören sich diese "Guter Bulle" Nachrichten meistens wie die Predigt einer Lehrerin aus der Vorschule an, 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 ihnen die Möglichkeit sich abzuregen und ihre bessere Seite zu zeigen, indem sie sich beim nächsten mal anständiger benehmen—und das werden sie. Einer 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 "so arbeiten wir hier nicht", aber gehen Sie dann weiter zum echten Inhalt, damit Leuten immer zum Thema haben, worauf sie Antworten können. Wenn jemand Protest einlegt, dass sie die zu Unrecht zurechtgewiesen wurde, sollten Sie sich nicht in ein Streit verzetteln lassen. Antworten Sie entweder garnicht (wenn Sie denken, die Person will nur Dampf ablassen und es ist keine Antwort erforderlich), oder entschuldigen Sie sich für die Übertriebene Reaktion und schreiben Sie, dass es schwer ist Nuancen in einer E-Mail herauszulesen. Gehen Sie danach aber wieder auf zum eigentlichen Thema über. Bestehen Sie niemals auf eine Antwort, privat oder öffentlich, von jemand der sich unangemessen verhalten hat. Wenn sie sich von alleine entschuldigen, ist das großartig, aber es von ihnen zu verlangen würde nur Verbitterung heraufbeschwören.

Das übergeordnete Ziel ist, gute Umgangsformen zu einem wesentlichen Merkmal in der Kerngruppe wird. Das hilft dem Projekt, da Entwickler durch "flame wars" vertrieben werden können (sogar von Projekten die sie mögen und unterstützen). Es kann passieren, dass Sie ihre Vertreibung nicht einmal mitbekommen; wenn sich jemand auf dem Verteiler umschaut und mitkriegt was für eine dicke Haut man braucht um an dem Projekt teilzunehmen, wird er sich vielleicht entscheiden, sich garnicht erst zu beteiligen. Foren freundlich zu halten ist auf lange Sicht eine Überlebenstaktik und es ist einfacher zu machen, solange das Projekt noch klein ist. Sobald es zu einem Teil der Kultur geworden ist, werden Sie nicht die einzige sein die sich darum bemüht. Das Verhalten wird von allen gepflegt werden.

Einer der besten Möglichkeiten eine produktive Entwicklergemeinschaft zu fördern, ist Leute zu überreden sich gegenseitig Ihren Code anzuschauen. Das effektiv zu gewährleisten, erfordert einwenig technische Infrastruktur—insbesondere sollten Commit E-Mails angeschaltet werden; siehe „Commit E-Mail“ für weiteres darüber. Commit E-Mails sorgen dafür, dass auf jede Änderung an dem Quellcode, eine E-Mail folgt, mit dem zugehörigen Kommentar des Autors und den Diffs (siehe Diff^[25] im Kapitel „Vokabular der Versionsverwaltung“). Code Review heißt diese Commit E-Mails beim Eintreffen auch durchzulesen und nach Fehler sowie mögliche Verbesserungen zu suchen. ^[18]

Code Review dient mehreren Zwecken gleichzeitig. Es 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 und ü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 gibt Leute die Bestätigung, dass ihre Arbeit etwas bedeutet, denn man würde sich nicht die Zeit nehmen über einen Commit zu schauen, wenn es einem nicht interessiert, welche Auswirkungen er hat. Menschen geben sich bei ihrer Arbeit am meisten Mühe wenn sie wissen, dass Andere sich die Zeit nehmen es auszuwerten.

Jeder Review sollte öffentlich durchgeführt werden. Selbst wenn ich im selben Physikalischen 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 es an den Entwickler Verteiler 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 erwartete regelmäßige Aktivität ist, wie Geschirrspülen oder den Rasen zu mähen.

Im Subversion Projekt hatten wir am Anfang nicht diese Angewohnheit. Es gab keine Garantie, dass jeder Commit überprüft wurde, wir schauten zwar manchmal über bestimmte Änderungen, wenn ein bestimmter Bereich im Quellcode einen besonders interessierte. 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 jedem Commit, den irgendjemand machte, folgte bald eine E-Mail von Greg an den Entwickler Verteiler, indem er den Commit sezierte, mögliche Probleme analysierte und ab und zu, für besonders cleveren Code, Lob aussprach. Auf der Stelle fing er an Fehler und nicht optimale Programmierpraktiken zu entdecken, die ansonsten durchgerutscht wären, ohne je bemerkt zu werden. Er beschwerte sich Wohlgemerkt nie, dass er der einzige war 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, ich eingeschlossen, regelmäßig Commits zu überprüfen. Was war unsere Motivation? Greg hatte uns nicht bewusst durch Schande dazu gebracht. Er hatte bewiesen, dass Code Review eine wertvolle Investition von Zeit ist und dass man genau soviel zu einem Projekt beitragen kann, indem man die Änderungen anderer durchsieht, wie wenn man selber neuen Code schreibt. Als er das demonstriert hatte, wurde es zum erwarteten Verhalten. Das ging sogar soweit, dass wenn auf einem Commit keine Reaktion folgte, man sich als Committer sorgen machte und sogar auf dem Verteiler nachfragte, ob nicht jemand die Zeit gefunden hatte 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 bis dahin, war die Angewohnheit so weit integriert, als ob es nie anders gewesen wäre.

Fangen Sie Code Review ab dem allerersten Commit an. Die Probleme die man am einfachsten beim Durchsehen der Diffs erkennen kann, sind Sicherheitslücken, Speicherlecks, ungenügende Kommentare oder Dokumentation von Schnittstellen, off-by-one Fehler, caller/callee Ungleichgewichte und andere Probleme, deren Entdeckung keinen großen umgebenden Kontext erfordern. Selbst Angelegenheiten von größerem Umfange, wie z.B. häufig auftauchende Muster nicht an einer gemeinsamen Stelle zu abstrahieren, werden leichter erkennbar, nachdem man Code Review regelmäßig betreibt, da 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 meißtens irgendetwas über jeden beliebigen Commit zu sagen; selbst wenn Sie nichts bedenkliches finden kann es sein, dass Sie etwas Lobenswertes finden. Das wichtige 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 sie selbst hätte finden müssen.

Beim öffnen von einem bestehenden Projekt, mit aktiven Entwicklern, die an einer Umgebung mit geschlossenem Code gewohnt sind, sorgen Sie für Klarheit über den Umfang der Änderungen, die auf sie zukommen—und versuchen Sie sich so weit 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 alle ihre gegenseitigen Stärken und Schwächen kannten. Jetzt verlangen Sie von ihnen, ihren Code freizugeben nur damit irgend welche Fremde es auseinandernehmen, es untersuchen und ihre Meinungen darüber bilden, allein anhand vom Quellcode den sie sehen, ohne zu wissen welcher geschäftlicher Druck Sie zu bestimmten Entscheidungen gezwungen hat. Diese Fremde 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 zu geben, sind die Neulinge 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, schlimmer noch vor seinen Kollegen. Wenn Sie keine Mannschaft perfekter Programmierer haben, ist sowas unvermeidlich—tatsächlich wird es am Anfang wahrscheinlich allen passieren. Nicht weil sie schlechte Programmierer sind; sondern weil jedes Projekt über einer bestimmten Größe, zwangsläufig Fehler beinhaltet und die Überprüfung durch eine Gemeinschaft wird manche dieser Fehler aufdecken (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, vor das Projekt geöffnet wird. Es könnte aber auch hilfreich sein, die Leute auf dem E-Mail Verteiler zu erinnern, dass es für das Projekt eine neue Art der Entwicklung ist und dass die Anpassung eine gewisse Zeit brauchen werden. 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 sollen. 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 mit Außenstehende zu kommunizieren einnimmt. Man kann sie am ehesten dazu überreden sich zu beteiligen, indem man sich selbst beteiligt. Beobachten Sie den öffentlichen Verteiler 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 gewohnt. Beobachten Sie deßhalb auch den Verteiler im Betrieb und bitten Sie ggf. darum, bestimmte Diskussionen gleich auf den öffentlichen Verteiler zu verlagern.

Es gibt andere, langfristige Bedenken beim öffnen vorher 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.