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 weitergegeben werden. Die Lebenszeit freier Software-Projekte wird vielleicht nicht in Jahrhunderten gemessen (zumindest bis 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 Anstrengungen 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.
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 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 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:
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 lernen, 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.
Zuletzt gibt es noch 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 hatte. Wir nahmen also den einfachen Weg und begannen, unsere technischen Ideen in privaten E-Mails untereinander auszutauschen, bis ein Beobachter des Projekts[16] davon Wind bekam und uns bat, die Diskussion auf die öffentliche Mailingliste 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 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 eines; schnell auf viele Ideen zu kommen 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, solange Sie ihnen keine 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.
Um das in Gang zu setzen, müssen Sie aber Einfluss üben. 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 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 Sie nicht aus der Liste entfernen, wenn sie einen anderen Teilnehmer "flamen", oder ihnen wegen abfällige 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, niemals schlechtes Benehmen einfach 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 sagen 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:
Lasst uns bitte zuerst mit den u.U. ad hominem Bemerkungen aufhören; den Entwurf der Sicherheitsschicht von J als "naiv und ignorant gegenüber allen Grundprinzipien der Sicherheit in der Informatik" zu bezeichnen. Ob das so stimmt oder nicht, es ist in jedem Fall keine Art eine Diskussion zu führen. J hat seinen Entwurf mit guter Absicht vorgeschlagen. Wenn es Fehler aufweist, weise darauf hin und wir werden sie beheben oder einen neuen Entwurf suchen. Ich bin mir sicher, dass M niemand 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 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 aus einer E-Mail herauszulesen. Gehen Sie danach aber wieder zum eigentlichen Thema über. Bestehen Sie niemals auf einer Antwort, privat oder öffentlich, von jemand der sich unangemessen verhalten hat. Wenn er sich von allein entschuldigt, ist das großartig, aber es von ihm 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; Mancher könnte sich die Liste anschauen, erkennen dass er ein dickes 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 arbeiten.
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 auf jede Änderung am Quellcode eine E-Mail folgt mit dem zugehörigen Kommentar des Autors und den Diffs (siehe Diff[24] im Kapitel „Vokabular der Versionsverwaltung“). Code Review heißt diese Commit-E-Mails beim Eintreffen auch durchzulesen und nach Fehlern sowie möglichen Verbesserungen zu suchen. [17]
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 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 Leuten, dass ihre Arbeit Bedeutung hat, man würde sich schließlich nicht die Zeit nehmen über einen Commit zu schauen, wenn es einem nicht interessieren würde, welche Auswirkungen er hat. Menschen leisten dann die beste Arbeit wenn sie wissen, dass andere sich die Zeit nehmen sie zu bewerten.
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 den 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 erwartete regelmäßige Aktivität ist, wie Geschirrspülen oder Rasenmä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-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 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 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, off-by-one Fehler, Caller/Callee-Divergenzen und andere Probleme, deren Entdeckung keinen großen umgebenden Kontext erfordern. Selbst Angelegenheiten größeren Umfangs, 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 meistens 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 er selbst hätte finden müssen.
Sorgen Sie beim Öffnen eines bestehenden Projekts mit aktiven Entwicklern, die eine Umgebung mit geschlossenem Code gewohnt sind, für Klarheit über den Umfang der Änderungen, die auf die Entwickler 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 irgendwelche Fremden ihn auseinandernehmen, untersuchen und sich eine Meinungen über ihn bilden, allein anhand des Quellcodes den sie sehen, ohne zu wissen, welcher geschäftlicher 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 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, 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 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 der Mailingliste 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 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 mit Außenstehende zu kommunizieren einnimmt. 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 gewohnt. Beobachten Sie deshalb auch die interne Mailingliste und bitten Sie ggf. darum, bestimmte Diskussionen besser gleich auf die öffentliche Liste 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.
[16] 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.
[17] 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.