Den Ton angeben

Bis jetzt haben wir Aufgaben behandelt die einmal beim Aufbau des Projekts zu erledigen sind: Eine Lizenz wählen, die Website einrichten, usw. Die wichtigsten Aspekte beim Start eines Projekts sind aber dynamisch. Es ist einfach, eine Adresse für eine Mailingliste zu wählen; aber dafür zu sorgen, dass dort die Kommunikation beim Thema und produktiv bleibt, ist eine ganz andere Sache. Wenn das Projekt nach Jahren der geschlossenen Entwicklung geöffnet wird, verändert sich der Entwicklungsprozess, und Sie werden die bestehenden Entwickler auf diesen Wandel vorbereiten müssen.

Die ersten Schritte sind die schwersten, da es für zukünftiges Verhalten noch keine Beispiele oder Erwartungen gibt nach denen man sich richten könnte. Beständigkeit in einem Projekt entsteht nicht durch formale Richtlinien, sondern durch eine von allen geteilte, schwer greifbare kollektive Weisheit, die sich mit der Zeit entwickelt. Oft gibt es auch geschriebene Regeln, die aber im wesentlichen eine Zusammenfassung der sich fortwährend weiterentwickelnden Vereinbarungen sind, an denen sich das Projekt wirklich orientiert. Die schriftlichen Richtlinien legen die Kultur des Projekts nicht fest, sondern beschreiben sie eher, und selbst das nur näherungsweise.

Dafür gibt es ein paar Gründe. Wachstum und hohe Fluktuation sind keineswegs so schädlich für die Herausbildung sozialer Normen, wie man vielleicht denken würde. So lange Veränderungen nicht zu schnell ablaufen, haben auch Neulinge Zeit, Abläufe zu lernen. Später werden sie diese Regeln selbst anzuwenden und durchsetzen. Bedenken Sie, wie Kinderlieder Jahrhunderte überdauern. Es gibt heute Kinder, die ungefähr die gleichen Lieder singen wie Kinder vor Hunderten von Jahren, auch wenn keines von ihnen heute noch am Leben ist. Jüngere Kinder hören die Lieder, wie sie von den älteren gesungen werden und wenn sie wiederum älter sind, singen sie vor den anderen jüngeren Kindern. Dabei geben sie die Lieder natürlich nicht bewusst weiter, aber die Lieder überleben trotzdem, weil sie regelmäßig und wiederholt weitergegeben werden. Die Lebenszeit freier Software-Projekte wird vielleicht nicht in Jahrhunderten gemessen (zumindest bis jetzt noch nicht), aber die Dynamik der Übertragung ist ziemlich dieselbe. Die Fluktuation ist allerdings viel höher und muss bei der Weitergabe durch eine aktivere und bewusstere Anstrengung ausgeglichen werden.

Diese Anstrengung wird dadurch unterstützt, dass Neuankömmlige für gewöhnlich soziale Normen erwarten und auch suchen. Das liegt einfach in der Natur des Menschen. In einer Gruppe, die durch ein gemeinsames Bestreben vereint ist, sucht man instinktiv nach Verhaltensmustern, um sich als Mitglied dieser Gruppe darzustellen. Sie sollten früh Beispiele setzen, um das Verhalten der Mitglieder so zu beeinflussen, dass es für das Projekt nützlich ist; einmal etabliert, werden sie überwiegend von selbst weiterbestehen.

Es folgen ein paar Beispiele, um gute Präzedenzfälle zu setzen. Es ist keine ausführliche Liste, sondern lediglich eine Veranschaulichung der Idee, dass es hilfreich ist, die Stimmung für die Zusammenarbeit im Projekt bereits frühzeitig zu prägen. Rein physikalisch mögen die einzelnen Entwickler jeder für sich in einem Raum arbeiten, Sie können jedoch eine Menge dafür tun, ihnen das Gefühl zu geben, sie würden alle in einem gemeinsamen Raum arbeiten. Je mehr sie sich so fühlen, desto mehr Zeit werden sie für das Projekt aufwenden wollen. Ich habe diese Beispiele gewählt, da sie in dem Subversion-Projekt aufkamen, (http://subversion.tigris.org/), das ich seit seiner Gründung tätig und beobachtend begleite. Sie gelten aber nicht allein für Subversion; diese Situationen werden in den meisten Open-Source-Projekten aufkommen, und sie sollten als Gelegenheit betrachtet werden, die Dinge auf dem richtigen Fuß zu erwischen.

Private Diskussionen vermeiden

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 Freiwilligen 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:

  • Die Diskussion wird dabei helfen, neue Entwickler auszubilden und zu unterrichten. Sie können nie wissen, wie viele Augen die Diskussion beobachten; selbst wenn die Meisten sich nicht beteiligen, kann es sein, dass viele sie im Stillen mitverfolgen, um Informationen über das Projekt zu sammeln.

  • Bei der Diskussion werden Sie die Kunst erlernen, technische Angelegenheiten für Leute zu erklären die mit der Software nicht so vertraut sind wie Sie. Das ist eine Fähigkeit, die Übung erfordert und nicht durch die Unterhaltung mit Ebenbürtigen erlangt werden kann.

  • Die Diskussion und ihre Ergebnisse werden auf ewig in den öffentlichen Archiven verfügbar sein und es zukünftigen Diskussionen ermöglichen, Wiederholungen zu vermeiden. Siehe „Auffällige Nutzung der Archive“ im KapitelKapitel 6, Kommunikation.

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 man es intuitiv erwarten würde. 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[15] 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 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.

Unhöflichkeit im Keim ersticken

Sie sollten von Anfang an, gleich nachdem Ihr Projekt an die Öffentlichkeit geht, null Toleranz gegenüber unhöflichem oder beleidigendem Verhalten in seinem 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 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 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:

Lasst uns bitte zuerst mit den u.U. ad hominem Bemerkungen aufhören; zum Beispiel, J's Entwurf der Sicherheitsschicht als "naiv und dumm gegenüber allen Grundprinzipien der Informationssicherheit" zu bezeichnen. Ob das so stimmt oder nicht, es ist in jedem Fall nicht die Art, eine Diskussion zu führen. J hat seinen Entwurf in guter Absicht vorgeschlagen. Wenn er Fehler aufweist, weist darauf hin und wir werden sie beheben oder einen neuen Entwurf suchen. Ich bin mir sicher, dass M niemanden persönlich beleidigen wollte, aber er hat sich unglücklich ausgedrückt, und wir wollen versuchen, hier konstruktiv zu bleiben.

Und jetzt zu dem Entwurf. Ich denke M hatte recht als er sagte, ...

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 die 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.

Code Review

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[23] 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. [16]

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.

Der Übergang ehemals geschlossener Projekte zu Open Source

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.



[15] Wir haben zwar noch nicht das Thema der Namensnennung und Anerkennung angesprochen, aber um auch zu praktizieren, was ich später predigen werde: Der Name des Beobachters war Brian Behlendorf; und er war es, der darauf hingedeutet hat, wie wichtig es ist, alle Diskussionen öffentlich zu halten, es sei denn es gibt einen bestimmten Grund für Geheimhaltung.

[16] So wird Review zumindest in Open-Source-Projekten praktiziert. Für zentralisierte Projekte kann "Code Review" auch bedeuten, dass mehrere Personen gemeinsam den ausgedruckten Code durchgehen und nach bestimmten Problemen und Mustern suchen.