Geld In diesem Kapitel, untersuchen wir die Finanzierung freier Software. Es geht nicht nur die Entwickler, die für ihre Arbeit an freie Software-Projekte, bezahlt werden wollen, sondern auch um Projektleiter, die ein Verständnis über die soziale Dynamik der Entwicklungsumgebung haben müssen. In den folgenden Abschnitten, gehe ich davon aus, dass Sie entweder ein bezahlter Entwickler, oder ein Leiter solcher Entwickler sind. Die Ratschläge werden für beide oft die gleichen sein; wenn nicht, wird die angesprochene Gruppe aus dem Kontext klar sein. Unternehmen finanzieren die Entwicklung freier Software schon seit langem. Viele Entwicklung wurden schon immer informell subventioniert. Wenn ein Systemadministrator eine Programm zur Netzwerkanalyse schreibt, um seine Arbeit zu erleichtern, stellt er es online und erhält Beiträge von anderen Administratoren, in Form von Bugfixes und neue Funktionen, sodass sich sich ein neues Konsortium bildet. Die Finanzierung stammt aus den Gehältern der Administratoren, seine Bürofläche und Infrastruktur werden, wenn auch ohne ihr Wissen, von dem jeweiligen Arbeitgeber gespendet. Diese Organisationen profitieren natürlich von der Investition, auch wenn sie zunächst, aus institutioneller Sicht, nichts davon wissen. Der Unterschied heute ist, dass viele dieser Anstrengungen formalisiert werden. Firmen sind sich der Vorteile von Open-Source-Software bewusst geworden und fangen an sich direkter an ihrer Entwicklung zu beteiligen. Entwickler erwarten mittlerweile, dass wirklich wichtige Projekte zumindest Spenden, oder sogar längerfristige Sponsoren anlocken. Geld hat zwar nicht sonderlich viel an der Dynamik der Entwicklung freier Software geändert, der Maßstab der Abläufe ist aber doch größer geworden, sowohl hinsichtlich der Anzahl der Entwickler, als auch der Zeit pro Entwickler. Es hat auch die Organisation der Projekte beeinflusst und wie die beteiligten Parteien miteinander umgehen. Es geht nicht nur darum, wie das Geld ausgegeben wird oder wie Rendite gemessen wird, sondern auch um Verwaltung und Ablauf: Wie kann die hierarchische Befehlsstruktur einer Firma, mit einer halb dezentralisierten Gemeinschaften von Freiwilligen im Einklang gebracht werden? Werden die Entwickler dieser beiden Gruppen, sich überhaupt darauf einigen können, was "Produktivität" bedeutet? Finanzielle Rückendeckung wird allgemein von Open-Source-Gemeinschaften gerne angenommen. Sie kann vor den Folgen vom Chaos schützen, die so viele Projekte wegfegen, bevor sie es wirklich schaffen, vom Boden abzuheben. Leute sind eher bereit, der Software eine Chance zu geben, wenn sie das Gefühl haben, ihre Zeit in etwas zu investieren, was auch noch in 6 Monate da sein wird. Schließlich ist Glaubwürdigkeit zu einem gewissen Grad ansteckend. Wenn sagen wir IBM ein Projekt unterstützt, kann man davon ausgehen, dass ein Scheitern des Projekts nicht zugelassen wird, und ihre sich daraus ergebende Bereitschaft selbst Mühe aufzubringen kann zu einer zu einer selbst erfüllende Prophezeiung werden. Finanzierung bringt jedoch auch ein Gefühl von Kontrolle. Ohne sorgfältige Handhabung kann Geld die Entwicklergemeinschaft in Lager spalten. Wenn die unbezahlten Entwickler das Gefühl bekommen, dass Entscheidungen über die Architektur oder neu Funktionen, einfach eine Frage des Geldes sind, werden sie zu einem anderen Projekt wechseln, indem sie eher das Gefühl haben, dass Leistung das Ausschlaggebende ist. Unbezahlte Arbeit für Funktionen, die alleine im Interesse einer Firma sind, wird kein freiwilliger Entwickler machen. Sie werden sich vielleicht nicht auf der Mailingliste beschweren, mit der Zeit, wird es aber immer weniger von außen zu hören geben, während Freiwillige sich immer weniger bemühen ernst genommen zu werden. Das Surren der kleineren Aktivitäten, in Form von Bug-Reports und gelegentlichen kleinen Fixes wird weitergehen. Es wird aber von außen keine größeren Beiträge oder Beteiligung an wichtigen Diskussionen geben. Leute spüren, was man von ihnen erwartet (bzw. nicht erwartet), und diesen Erwartungen gerecht werden. Geld muss zwar vorsichtig benutzt werden, Einfluss ist aber deswegen noch lange nicht käuflich. Der Haken ist, dass man ihn nicht direkt erkaufen kann. Bei einem einfachen Kommerziellen Geschäft, tauschen Sie Geld gegen ein Gut. Wenn Sie eine zusätzliche Funktion benötigen, unterschreiben Sie einen Vertrag, zahlen dafür und es wird umgesetzt. In einem Open-Source-Projekt, geht das nicht so einfach. Sie werden vielleicht mit ein paar Entwickler Verträge abschließen, aber diese würden sich – und Sie – täuschen, wenn sie garantieren, dass die von Ihnen finanzierte Arbeit von der Entwicklergemeinschaft angenommen wird. Nur weil Sie dafür bezahlen, passt die Funktion noch lange nicht, zu der Vorstellung der Gemeinschaft passen, über die Zukunft der Software. Die Arbeit kann nur im Rahmen seiner Leistung angenommen werden und wie gut es sich in diese Vorstellung einfügt Sie werden dabei möglicherweise etwas zu sagen haben, Sie werden aber nicht die einzige sein. Einfluss ist also nicht käuflich, Sachen die zu Einfluss führen sind es aber sehr wohl. Das offensichtlichste Beispiel sind Programmierer. Wenn gute Programmierer eingestellt werden, und sie lange genug bleiben um Erfahrung mit der Software und Glaubwürdigkeit in der Gemeinschaft zu sammeln, können Sie das Projekt gleichermaßen beeinflussen wie jedes andere Mitglied. Sie haben bei Wahlen eine Stimme, mehreren Entwickler geben Ihnen sogar ein Stimmblock. Wenn Sie in dem Projekt respektiert werden, bekommen sie Einfluss über ihre Stimmen hinaus. Bezahlte Entwickler müssen auch nicht ihre Motive versuchen zu verschleiern. Schließlich will jeder der eine Änderung macht es aus irgend einem Grund. Die Motive Ihrer Firma sind in keiner weise weniger berechtigt, als die von irgendjemand anderem. Das Stimmgewicht ihrer Firma, hängt jedoch von dem Status ihrer Stellvertreter im Projekt ab, nicht von ihrer Größe, ihrem Budget oder Geschäftsplan. Arten der Beteiligung Es gibt viele verschiedene Gründe Open-Source-Projekte zu Finanzieren. Die Punkte auf dieser Liste schließen sich nicht gegenseitig aus; oftmals wird die Finanzielle Rückendeckung das Resultat mehrere oder alle dieser Motivationen sein: Geteilte Last Separate Organisationen mit überlappenden Softwarebedarf merken, dass sie die gleiche Arbeit machen, entweder schreiben sie redundant den gleichen Code in der selben Firma, oder sie kaufen ähnliche Produkte von proprietären Anbietern. Wenn sie bemerken, was vor sich geht, werden sie vielleicht ihre Ressourcen zusammenlegen und ein Open-Source-Projekt gründen (oder beitreten) welches an ihren Bedarf angepasst ist. Die Vorteile sind offensichtlich: Die Kosten der Entwicklung werden geteilt, die Vorteile kommen aber allen gleichermaßen zugute. Obwohl dieses Scenario die intuitivste für gemeinnützige Organisationen scheint, kann es auch für profitorientierte Konkurrenten Sinn machen. Beispiele: , Verbesserung von Dienstleistungen Wenn eine Firma Dienstleistungen zu bestimmten Open-Source-Anwendungen verkauft oder durch die Software attraktiver gemacht werden, liegt es natürlich im Interesse der Firma sicherzustellen, dass diese Anwendungen auch gepflegt werden. Beispiel: Die Unterstützung von durch CollabNet (Haftungsauschluss: Das ist meine tägliche Arbeit, es ist aber auch ein perfektes Beispiel für dieses Modell). Unterstützung vom Hardware-Absatz Der Wert von Computern und Hardware ist direkt von der dafür zur Verfügung stehenden Software abhängig. Hardware-Verkäufer – nicht nur Verkäufer kompletter Maschinen, sondern auch die Hersteller von Peripheriegeräte und Mikrochips – haben herausgefunden, dass es ihren Kunden wichtig ist, hochwertige freie Software für ihre Hardware zu haben. Untergrabung der Konkurrenz Manche Firmen unterstützen ein bestimmtes Open-Source-Projekt um ein Produkt der Konkurrenz zu untergraben, welches unter Umständen auch selber Open-Source sein kann. Den Marktanteil des Konkurrenten wegzufressen ist selten der einzige Grund ein Open-Source-Projekt zu unterstützen, kann aber eine Rolle spielen. Beispiel: (nein, das ist nicht der einzige Grund für die Existenz der Software, es ist aber zumindest teilweise eine Reaktion auf Microsoft Office). Marketing Ihre Firma mit einer bekannten Open-Source-Anwendung zu assoziieren kann einfach gute Markenpflege sein. Doppelte Lizenzierung Doppelte Lizenzierung bedeutet, Software unter einer traditionellen proprietären Lizenz für Kunden anzubieten, die es als Teil ihrer proprietären Anwendung verkaufen wollen. Gleichzeitig veröffentlicht man es unter einer freien Lizenz für diejenigen, die bereit sind, es unter den Open-Source-Bedingungen zu benutzen (siehe im Kapitel ). Wenn die Open-Source-Entwicklergemeinschaft aktiv ist, bekommt die Software die Vorteile vieler Anwender um die Entwicklung zu testen, die Firma bekommt dennoch Nutzungsgebühren um ihrer Vollzeitentwickler zu unterstützen. Zwei bekannte Beispiele sind MySQL, die Hersteller der gleichnamigen Datenbank-Software, und Sleepycat, welche Distributionen und Support für die Berkeley-Datenbank anbietet. Beide sind nicht zufällig Datenbank-Firmen. Datenbank-Software neigt dazu eher in anderen Anwendungen integriert zu werden als direkt an Kunden vermarktet zu werden, also ist es sehr gut für das Modell der doppelten Lizenzierung geeignet. Spenden Ein erfolgreiches Projekt kann manchmal wesentliche Beiträge, sowohl von Einzelpersonen als auch von Organisationen bekommen, allein durch einen Spendenknopf, oder den Verkauf von Waren mit ihre Marke wie Tassen, T-shirts Mousepads, usw. Hierbei sollte man vorsichtig sein: Wenn ihr Projekt Spenden annimmt, sollten Sie planen wie das Geld benutzt werden soll, bevor es auftaucht, und schreiben Sie ihre Pläne auf die Webseite des Projekts. Diskussionen über die Aufteilung von Geld verlaufen meistens friedlicher wenn es noch keins gibt; sollte es doch bedeutende Streitigkeiten über die Verwendung geben, ist es trotzdem besser es in einer eher akademischen Diskussion herauszufinden. Das Geschäftsmodel eines Geldgebers ist nicht sein einziger Einfluss auf eine Open-Source-Gemeinschaft. Ihre historische Beziehung spielt auch eine wesentliche Rolle: Hat die Firma das Projekt gegründet, oder tritt es einer bereits laufenden Entwicklung bei? So oder so muss sich der Geldgeber Glaubwürdigkeit verdienen, es ist deswegen auch nicht verwunderlich, dass letzteres etwas mehr Mühe erfordert. Die Organisation muss klare Ziele im Bezug auf das Projekt haben. Versucht sie eine Führungsposition zu behalten, oder will sie einfach eine Stimme in der Gemeinschaft, um diese zu führen aber nicht unbedingt die Richtung des Projekts vorzugeben? Vielleicht will die Firma auch einfach nur ein paar Entwickler parat haben, um Fehler für ihre Kunden beheben und Änderungen ohne große Umstände in die öffentliche Distribution einbinden zu können? Behalten Sie diese Fragen beim lesen der nachfolgenden Richtlinien im Hinterkopf. Sie sollen für jede organisatorische Beteiligung an einem freien Software-Projekt gelten, da Sie es aber mit Menschen zu tun haben ist jedes Projekt einzigartig. Zu einen gewissen Grad werden Sie immer nach Gehör spielen müssen, die Entwicklung wird aber eher nach ihren Vorstellungen verlaufen, wenn Sie diese Prinzipien befolgen. Langzeit-Entwickler Behalten Sie Ihre Open-Source-Programmierer lange genug bei einem Projekt um sich sowohl technische als auch politische Kompetenzen aneignen können – mindestens einige Jahre. Natürlich profitiert kein Projekt, ob Open-Source oder nicht vom häufigen Wechsel unter den Programmierern. Sich jedes mal neu einarbeiten zu müssen wäre in jeder Umgebung für Neulinge abschreckend. Für Open-Source-Projekte ist die Strafe aber noch größer, da Entwickler die ein Projekt verlassen nicht nur ihre Kenntnisse über den Code mitnehmen, sondern auch ihre Position in der Gemeinschaft sowie die dort aufgebauten menschlichen Beziehungen. Die von einem Entwickler angeignete Glaubwürdigkeit, kann nicht übertragen werden. Das offensichtlichste Beispiel wäre wohl, dass Commit-Zugriff nicht von einem Entwickler zum Anderen vererbt werden kann (siehe später in diesem Kapitel), wenn ein neuer Entwickler also noch keinen Commit-Zugriff hat, wird er bis dahin Patches einreichen müssen. Commit-Zugriff ist aber nur die messbarste Erscheinung für den verlorenen Einfluss. Ein langjähriger Entwickler kennt auch alle alten Streitigkeiten die immer wieder in Diskussionen in den Foren aufgeflammt sind. Ein neuer Entwickler ohne Erinnerung an solche Unterhaltungen, könnte versuchen diese Themen erneut anzusprechen, was zum Verlust der Glaubwürdigkeit Ihrer Organization führt; die anderen werden sich vielleicht wundern "ob die sich den Garnichts behalten können"? Neue Entwickler werden auch kein politisches Gespür für die Persönlichkeiten im Projekt haben und werden nicht in der Lage sein die Richtung der Entwicklung so schnell oder reibungslos zu beeinflussen, wie ein alter Hase. Lassen Sie Anfänger sich zur Einweisung, unter Beaufsichtigung, an dem Projekt beteiligen. Der neue Entwickler sollte vom ersten Tag sehr eng mit der öffentlichen Entwicklergemeinschaft arbeiten, angefangen mit Bugfixes und Aufräumarbeiten, um den Codebase kennenzulernen und sich einen Ruf in der Gemeinschaft zu erarbeiten, er sollte jedoch keine langwierige und verstrickte Diskussionen über Codestruktur zünden. Währendessen sollten ein Paar erfahrene Entwickler für Fragen zur bereitstehen, die jede Nachricht des Anfängers an die Verteiler, lesen sollten, sogar bei Threads der sie sonst keine Beachtung schenken würden. Das wird die Gruppe helfen mögliche Steine auf dem Weg zu erkennen, bevor der Anfänger drüber stolpert. Private Anregung und Hinweise im Hintergrund können auch eine große Hilfe sein, besonders wenn der Anfänger es nicht gewohnt ist, dass sein Code der Kritik durch die Gemeinschaft unterworfen ist. Wenn CollabNet einen neuen Entwickler einstellt, um an Subversion zu arbeiten, setzen wir uns zusammen und wählen ein paar offenestehende Fehler für die neue Person, um sich erst einmal die Krallen zu schärfen. Wir diskutieren den technischen Rahmen der Lösungen und weisen dann mindestens einen erfahrenen Entwickler an (öffentlich) den vom neuling eingereichten Patch, kritisch unter die Lupe zu nehmen (alles für die Öffentlichkeit sichtbar). Normalerweise schauen wir uns den Patch nicht einmal an, vor es auf dem zentralen Verteiler für Entwickler zu sehen ist, auch wenn wir es könnten, gäbe es dazu einen Grund. Das wichtige für den neuen Entwickler ist die öffentliche Überprüfung durchzulaufen, dabei den Codebase kennenzulernen und sich an Kritik von völlig Fremden zu gewöhnen. Wir versuchen es aber so abzustimmen, dass unsere Bewertung möglichst bald nach dem Patch kommt. Dadurch ist unsere Bewertung die erste auf dem Verteiler, was helfen kann, den Ton der nachfolgenden Bewertungen zu setzen. Es trägt auch zu der Idee bei, dass diese neue Person ernst genommen werden soll: Wenn andere sehen wie wir uns Zeit nehmen ausführliche Bewertungen zu schreiben, mit gründlichen Erklärungen und wenn angemessen Verweise auf die Archive, werden sie es als Schulungsform erkennen, was wahrscheinlich eine längerfristige Investition andeutet. Das kann sie positiver gegenüber den Entwickler stimmen, zumindest soweit, dass sie sich ein wenig mehr Zeit nehmen, um Fragen zu beantworten und Patches zu bewerten. Treten Sie als viele in Erscheinung Ihre Entwickler sollten anstreben in den öffentlichen Foren als einzelne Beteiligte aufzutreten und nicht als monolitisches Firmenwesen. Das liegt nicht an irgend einer negative Behaftung (naja, vielleicht schon ein bisschien, aber darum geht es nicht in diesem Buch). Einzelpersonen sind schlicht das einzige wofür Open-Source-Projekte strukturell gewappnet sind. Ein einzelner Beteiligter kann sich an Diskussionen beteiligen, Patches einreichen, sich Glaubwürdigkeit verschaffen, an Abstimmungen teilnehmen usw. Eine Firma kann das nicht. Desweiteren, verhindert man durch dezentralisiertes Verhalten die Bildung einer zentralisierten Opposition. Lassen Sie Ihre Entwickler sich auf der Mailingliste untereinander streiten. Ermutigen Sie häufige und öffentliche gegenseitig Überprüfung und Bewertung des Codes. Raten Sie davon ab, immer als Block abzustimmen, denn wenn sie das machen, werden andere das Gefühl bekommen allein aus Prinzip, einen Gegenpol organisieren zu müssen, um sie in Schach zu halten. Es gibt einen Unterschied zwischen einer wirklich dezentralisierten Organisation und einfach als solches erscheinen zu wollen. In bestimmten Fällen kann es durchaus nützlich sein, ihre Entwickler an einem Strang ziehen zu lassen und sie sollten vorbereitet sein falls nötig, im Hintergrund zu koordinieren. Wenn beispielsweise ein Vorschlag gemacht wird, kann ihm durch frühzeitige Zustimmung anderer Entwickler auf die Sprünge geholfen werden, indem sie den Eindruck von zunehmenden Konsens vortäuschen. Andere spüren ein gewisses Momentum für den Vorschlag, der durch einen Einspruch ihrerseits aufgehalten würde. Deshalb werden Leute nur dann Einsprechen, wenn sie dazu einen guten Grund haben. Es gibt im Übrigen nichts verwerfliches daran, Zustimmung auf diese Art zu koordinieren, solange Einsprüche weiterhin ernst genommen werden. Wie sich diese private Übereinkunft öffentlich offenbart ist nicht unaufrichtig oder für das Projekt schädlich, nur weil sie vorher koordiniert wurde, so lange sie nicht dazu benutzt wird um Gegenargumente frühzeitig und abträglich auszustechen. Der Hintergrund ist lediglich bestimmte Personen aufzuhalten, die einfach nur Einwände machen um Fit zu bleiben; siehe im Kapitel für weiteres. Seien Sie offen bezüglich Ihrer Absichten Seien Sie so offen hinsichtlich Ihrer Motive, wie Sie es können, ohne hierbei Geschäftsgeheimnisse offenzulegen. Wenn Sie in Ihrem Projekt eine bestimmte Funktion haben wollen, sagen wir, weil Ihre Kunden danach schreien, sprechen Sie auf den Mailinglisten offen darüber. Wenn die Kunden anonym bleiben wollen, was manchmal vorkommt, fragen Sie wenigstens, ob Sie sie als anonyme Beispiele anführen dürfen. Je mehr die öffentliche Entwicklergemeinschaft darüber weiß, warum Sie etwas wollen, desto eher werden sie Ihre Vorschlage akzeptieren. Das widerspricht dem Instinkt – einfach anzueignen, aber schwer loszuwerden –, dass Wissen gleich Macht ist und Ihre Ziele anderen gegenüber bekannt zu geben, diesen mehr Kontrolle über Sie gibt. Der Instinkt wäre hier aber falsch. Indem Sie sich öffentlich für eine Funktion (oder ein Bugfix, oder was auch immer) aussprechen, haben Sie ja schon Ihre Karten auf den Tisch gelegt. Die einzige Frage ist, ob Sie die Gemeinschaft überzeugen können Ihr Ziel mit Ihnen zu teilen. Wenn Sie einfach sagen, dass Sie die Funktion haben wollen, aber keine konkreten Gründe dafür nennen wollen, stehen Sie auf schwachem Boden und Leute werden anfangen verborgene Absichten zu vermuten. Aber auch nur ein paar echte Szenarien zu nennen, die zeigen warum die vorgeschlagene Funktion wichtig ist, kann sich dramatisch auf die Debatte auswirken. Um den Grund dafür zu erkennen, sollten Sie die alternative bedenken. All zu oft sind Debatten über neue Funktionen oder Richtungen langwierig und ermüdend. Die Argumente die angebracht werden reduzieren sich meistens auf "Ich persönlich will X", oder das immer wieder beliebte "Meine langjährigen Erfahrung als Software-Entwickler hat gezeigt, dass X für Nutzer äußerst wichtig ist / eine nutzlose Krause ist, die keinen zufrieden stellen wird". Solche Debatten werden dementsprechen durch Mangel an Daten über echter Nutzung, weder verkürzt noch verlängert, sondern treiben immer weiter von der Praxis ab. Ohne irgend eine ausgleichende Kraft, wird das Endergebnis eher von dem Wortgewandtesten, den Hartnäckigsten oder dem Ranghöchsten bestimmt. Ihre Position als Organization mit reichlich Kundendaten, ermöglicht Ihnen genau solch eine ausgleichende Kraft bereitzustellen. Sie können ein Kanal für Informationen sein, die sonst keine Möglichkeit hätten zu der Gemeinschaft zu gelangen. Sie müssen sich nicht dafür schämen, dass diese Informationen Ihre Wünsche untermauern. Die meisten Entwickler haben für sich keine breite Erfahrung über die Nutzung Ihrer Software. Jeder Entwickler benutzt die Software auf seine eigene Art; über das Nutzungsverhalten anderer spekuliert er lediglich und verlässt sich auf seine Intuition. Tief im inneren ist ihm das auch bewust. Durch glaubwürdige Daten einer nicht unwesentlichen Anzahl an Nutzern, geben Sie der Entwicklergemeinschaft sowas wie Sauerstoff. So lange Sie es richtig auslegen, wird sie es mit Begeisterung annehmen und der Wind wird zu Ihrem Gunsten wehen. Der Schlüssel ist natürlich, es richtig zu präsentieren. Es reicht auf keinen Fall aus, nur weil Sie mit eine Menge Nutzern zu tun haben und weil diese eine gegebene Funktion brauchen (oder meinen zu brauchen), darauf zu bestehen Ihre Lösung zu implementieren. Statt dessen, sollten sich Ihre ersten Nachrichten eher auf das gegebene Problem konzentrieren, als auf eine bestimmte Lösung. Beschreiben Sie sehr ausführlich, die Erfahrungen Ihrer Kunden, bieten Sie die Ihnen bestmögliche Auswertung, sowie möglichst viele Lösungsansätze. Wenn Leute anfangen zu spekulieren, wie effektiv die verschiedenen Lösungen sind, können Sie mit Ihren Daten die verschiedenen Antworten untermauern oder entkräften. Sie werden vielleicht die ganze Zeit über eine bestimmte Lösung im Hinterkopf haben, heben Sie es am Anfang aber nicht hervor. Das ist keine Täuschung, sondern das übliche Verhalten, eines ehrlichen Vermittlers. Schließlich ist Ihr wahres Ziel die Lösung des Problems; eine Lösung ist lediglich das Mittel zum Zweck. Wenn Ihre bevorzugte Lösung wirklich die überlegene ist, werden andere Entwickler das irgendwann auch erkennen – und Sie von sich aus unterstützen, was viel besser ist, als die Implementierung durch Einschüchterung zu erzwingen. (Es besteht natürlich auch die Möglichkeit, dass jemand anderem eine bessere Lösung einfällt als Ihnen). Das soll nicht heißen, dass Sie sich niemals zugunsten einer Bestimmten Lösung äußern können. Sie müssen aber Geduld haben, damit die Analyse die Sie bereits intern gemacht haben, auf den öffentlichen Verteilern wiederholt wird. Schreiben Sie nicht sowas wie "Ja, wir haben das alles hier schon gehabt, aber das Funktioniert so nicht und zwar aus diesen Gründen... Wenn man der Sache auf den Grund geht, dann ist die einzige Lösung..." Das Problem ist weniger der arrogante Ton, als vielmehr der Eindruck, dass Sie bereits eine unbestimmte (aber vermutlich große) Menge analytischer Ressourcen dem Problem, hinter verschlossenen Türen, gewidmet haben. Es lässt die Sache so erscheinen, als ob Anstrengungen unterwegs gewesen sind, und Entscheidungen vielleicht getroffen wurden, ohne einweihung der Öffentlichkeit, und das, führt unweigerlich zu Verbitterung. Sie wissen natürlich, wieviel Mühe Sie dem Problem intern gewidmet haben, und dieses Wissen ist in gewisser Hinsicht ein Nachteil. Ihre Entwickler haben dadurch eine etwas andere Einstellung als alle anderen auf den Mailinglisten, wodurch ihre Fähigkeit eingeschränkt wird, die Dinge aus der Sicht derjenigen zu sehen, die noch nicht über das Problem nachgedacht haben. Je früher Sie alle anderen dazu bringen können ihre Sicht einzunehmen, desto geringer werden die resultierende Auswirkungen sein. Diese Logik gilt nicht nur für einzelne technische Situationen, sondern auch für das breitere Mandat Ihre Ziele so klar wie möglich darzulegen. Das Unbekannte verursacht immer mehr Unruhe als das Bekannte. Wenn Menschen verstehen, warum Sie etwas wollen, werden sie sich dabei wohl fühlen mit Ihnen zu reden, selbst wenn sie anderer Meinung sind als Sie. Wenn sie nicht herausbekommen was Sie bewegt, werden sie zumindest Zeitweise vom Schlimmsten ausgehen. Sie werden natürlich nicht alles veröffentlichen können, und man wird es nicht von Ihnen erwarten. Alle Organisationen haben Geheimnisse; vielleicht haben Profit orientierte mehr davon, aber gemeinnützige haben sie auch. Wenn Sie einen bestimmten Kurs verfechten müssen, aber nichts über Ihre Gründe offenbaren können, dann bieten Sie einfach die Ihnen mit dieser Behinderung bestemöglichen Argumente und finden Sie sich mit der Tatsache ab, dass Sie vielleicht nicht den gewünschten Grad an Einfluss bei der Diskussion haben. Das ist einer der Kompromisse die Sie eingehen, wenn die Entwicklergemeinschaft nicht auf Ihrer Gehaltsliste steht. Liebe kann nicht mit Geld erkauft werden Wenn Sie in einem Projekt ein bezahlter Entwickler sind, dann legen Sie frühzeitig die Richtlinien fest, was für Geld käuflich ist, und was nicht. Das bedeutet nicht, dass Sie es zweimal täglich in den Foren wiederholen müssen, um Ihre noble und unbestechliche Natur zu verdeutlichen. Es bedeutet lediglich, dass Sie auf Gelegenheiten achten sollten, um Spannungen zu entschärfen, die durch Geld entstehen könnten. Sie müssen nicht von vorhandenen Spannungen ausgehen; Sie müssen allerdings zeigen, dass Sie des Potentials dazu bewusst sind. Ein perfektes Beispiel hierfür hat das Subversion-Projekt zu bieten. Subversion wurde im Jahr 2000 von CollabNet gestartet, das von Anfang an als Arbeitgeber für mehrere Entwickler und der größte Geldgeber für das Projekt gewesen ist (Anmerkung: Ich bin einer davon). Bald nach Beginn des Projekts stellten wir einen weiteren Entwickler ein, Mike Pilato, um dem Projekt beizutreten. Wir hatte dann schon mit dem Programmieren angefangen. Obwohl Subversion sicherlich noch in seiner Anfangsphase war, hatte es bereits eine Entwicklergemeinschaft mit wenigen einfachen Grundregeln. Die Ankunft von Mike warf eine interessante Frage auf. Subversion hatte bereits ein Verfahren, nach dem neue Entwickler Commit-Zugriff bekamen. Zuerst reicht man ein paar Patches auf der Entwickler-Liste ein. Nachdem genügend Patches eingetroffen sind, damit anderen Committer sehen können, dass der neue Mitwirkende weiß was er macht, schlägt jemand vor, ihm den direkten Zugriff zu gewähren (dieser Vorschlag findet im Privaten statt, wie in beschrieben). Angenommen die Committer stimmen überein, schreibt einer von ihnen dem neuen Entwickler eine Mail indem er den direkten Commit-Zugriff auf das Projektarchiv des Projekts anbietet. CollabNet hatte Mike ausdrücklich eingestellt, um an Subversion zu arbeiten. Bei denen die ihn kannten, zweifelte keiner an seinen Fähigkeiten als Programmier oder seiner Bereitschaft, an dem Projekt zu arbeiten. Desweiteren hatten die freiwilligen Entwickler eine sehr gute Beziehung zu den Mitarbeitern von CollabNet und hätten wahrscheinlich keine Einwände, Mike einfach gleich am ersten Arbeitstag Commit-Zugriff zu geben. Wir wussten aber, dass dies einen Präzedenzfall sein würde. Wenn wir Mike von oben herab Zugriff auf das Projektarchiv gegeben hätten, käme das der Aussage gleich, dass CollabNet das Recht hätte, die Richtlinien des Projekts zu ignorieren, einfach nur weil es der größte Geldgeber war. Obwohl dieser Schaden nicht unbedingt gleich ersichtlich gewesen wäre, hätte es langsam dazu geführt, dass unbezahlte Entwickler sich ihrer Rechte beraubt fühlen: Andere müssen sich ihren Commit-Zugriff erarbeiten – CollabNet kann ihn sich kaufen. Mike willigte also ein seine Arbeit bei CollabNet wie jeder andere freiwillige Entwickler anzufangen, ohne Commit-Zugriff. Er schickte Patches an die öffentlichen Foren, wo sie von allen überprüft und kritisch beurteilt werden konnten und wurden. Wir erklärten auch öffentlich unser unser explizites Vorgehen, um Missverständnisse zu vermeiden. Nach ein paar Wochen solider Aktivität von Mike, schlug jemand (ich kann mich nicht mehr erinnern ob es ein Entwickler von CollabNet war oder nicht) vor, ihm Commit-Zugriff zu gewähren und wurde wie von allen erwartet angenommen. Diese konsequente Durchsetzung verschafft einem Glaubwürdigkeit, die man mit Geld nicht kaufen kann. Und Glaubwürdigkeit ist eine wertvolle Währung bei technischen Diskussionen: Es schützt einem vor spätere Angriffe auf seine Motive. Bei einer hitzigen Debatte, greifen Leute manchmal auf Angriffe zürück ohne technischniche Bedeutung, um die Schlacht für sich zu entscheiden. Der Haupt-Geldgeber bietet durch seine tiefe Beteiligung und offensichtliche Sorgen über die Richtung die das Projekt nimmt, eine breiteres Ziel als die Meisten. Indem er gewissenhaft alle Richtlinien des Projekts von Anfang an wahrnimmt, stellt der Finanzier sich auf derselben Ebene wie alle anderen. (Siehe auch den Blog von Danese Cooper bei für eine ähnliche Geschichte um Commit-Zugriff. Cooper war damals die "Open-Source-Diva" von Sun Microsystem's – ich glaube das war ihr offizieller Titel – und sie beschreibt in ihrem Blog, wie die Entwicklergemeinschaft von Tomcat Sun dazu brachte, seine eigenen Entwickler die gleichen Richtlinien für Commit-Zugriff zu befolgen, wie die Entwickler außerhalb von Sun.) Weil Geldgeber nach den selben Regeln spielen müssen, wie alle anderen, lässt sich das Modell der gütigen Diktatur (siehe im Kapitel ) nur schwer anwenden, wenn Geld im Spiel ist, insbesondere wenn der Diktator für den Geldgeber arbeitet. Da eine Diktatur wenig Regeln hat, ist es schwierig für einen Geldgeber zu beweisen, dass er die Normen der Gemeinschaft befolgt, selbst wenn das der Fall ist. Es ist sicherlich nicht unmöglich, es erfordert aber einen Projektleiter, der in der Lage ist, die Dinge sowohl aus der Sicht der externen Entwickler als auch derer die für den Geldgeber arbeiten, zu sehen und sich entsprechend zu verhalten. Selbst dann, ist es wahrscheinlich eine gute Idee ein nicht diktatorisches Modell bereit zu halten, welches man bei Anzeichen von breiter Unzufriedenheit in der Gemeinschaft vorschlagen kann. Auftragsarbeit Mit Auftragsarbeit muss in freien Software-Projekten vorsichtig umgehen. Im Idealfall wollen Sie, dass die Arbeit des Auftragnehmers von der Gemeinschaft angenommen wird und in die veröffentlichte Version aufgenommen wird. Theoretisch würde es keinen Unterschied machen, wer der Auftragnehmer ist, solange er gute Arbeit macht und die Richtlinien des Projekts beachtet. Theorie und Praxis kann manchmal auch zusammenpassen: Ein komplett Fremder der mit einem guten Patch auftaucht, wird es im Allgemeinen schaffen, diese in die Software zu bekommen. Das Schwierige ist, dass es als komplett Fremder sehr schwer ist, einen guten Patch für eine nicht triviale Erweiterung oder Funktion zu produzieren; man muss es zuerst mit dem übrigen Teilnehmern diskutieren. Die Dauer dieser Diskussion, kann man nicht genau voraussehen. Wenn der Auftragnehmer nach Arbeitszeit bezahlt wird, werden Sie vielleicht mehr Bezahlen, als Sie erwartet haben; wenn er Pauschal bezahlt wird, kann es passieren, dass er länger arbeitet, als er es sich leisten kann. Es gibt zwei Möglichkeiten das zu Umgehen. Man sollte vorzugsweise eine fundierte Vermutung über die Dauer der Diskussion machen, beruhend auf vergangene Erfahrung und einen Puffer für Fehler, was dem Vertrag zugrundeliegt. Es hilft auch das Problem in möglichst viele einzelteile zu spalten, um die einzelnen Brocken eher einschätzen zu können. Der andere Weg ist den Auftrag auf den eigentlichen Patch zu beschränken, unabhängig von seiner Aufnahme im Projekt. Es ist dadurch viel einfacher den Vertrag zu schreiben, hat aber den Nachteil, dass Ihnen dann der Klotz am Bein hängt, den Patch so lange zu pflegen, wie Sie auf die Software angewiesen sind, oder zumindest so lange bis Sie es schaffen eine gleichwertige Funktion in den Hauptzweig zu bekommen. Natürlich kann man selbst beim ersten Vorgehen nicht darauf bestehen im Vertrag, etwas über die Aufnahme im Projekt festlegen, weil das den Verkauf von etwas bedeuten würden, was nicht zum Verkauf steht. (Was passiert wenn die Übrigen im Projekt sich entscheiden, die Funktion nicht zu unterstützen)? Der Vertrag kann allerdings eine gewisse angemessen und glaubwürdige Anstrengung beinhalten, um die Änderung von der Gemeinschaft angenommen zu bekommen, und sie danach im Projektarchiv einzuspielen. Wenn das Projekt Normen über Änderungen am Code festgelegt hat, kann der Vertrag auf diese Verwiesen und festlegen, dass die Arbeit, sich danach richten muss. In der Praxis verläuft das meistens positiv für alle Parteien. Die beste Taktik für erfolgreiche Auftragsarbeit ist, einen der Entwickler des Projekts – vorzugsweise einen etablierten Beteiligten – als Auftragnehmer anzustellen. Das mag sich nach erkauftem Einfluss anhören, und nun ja, dass ist es auch. Es ist aber nicht so korrupt, wie es sich anhört. Der Einfluss den ein Entwickler innerhalb eines Projekts hat, hängt vorrangig von der Qualität seiner Arbeit, sowie seinen Umgang mit anderen Entwicklern ab. Die Tatsache, dass er ein Vertrag hat, um bestimmte Sachen erledigt zu bekommen, hebt seinen Status in keiner weise und es senkt ihn auch nicht, auch wenn Leute ihn vielleicht etwas vorsichtiger hinterfragen werden. Die meisten Entwickler würden ihre längerfristige Position in einem Projekt nicht riskieren um eine weitestgehend unbeliebte Funktion zu unterstützen. Tatsächlich sollte ein Teil von dem was Sie bekommen, wenn Sie einen solchen Entwickler einstellen, Ratschläge darüber sein, welche Änderungen wahrscheinlich von der Gemeinschaft angenommen werden. Sie bekommen auch eine gewisse Umstellung der Prioritäten im Projekt. Da die Prioritäten lediglich davon abhängen, wer Zeit hat an etwas zu arbeiten, sorgen Sie, durch Entlohnung bestimmter Arbeiten dafür, dass diese eine etwas höhere Priorität bekommt. Unter erfahrenen Open-Source-Entwicklern ist diese Tatsache wohlbekannt, und zumindest manche werden der Arbeit eines Auftragnehmers Aufmerksamkeit widmen, einfach nur weil es den Anschein hat fertig zu werden, also wollen sie dabei helfen, dass es richtig gemacht wird. Sie schreiben dabei zwar vielleicht keinen Code, werden aber Entwürfe diskutieren und Kritik am Code üben, was alles sehr nützlich sein kann. Aus all diesen Gründen, sollte der Auftragnehmer am ehesten aus den Reihen der bereits am Projekt Beteiligten gezogen werden. Dadurch stellen sich zwei Fragen: Sollten Verträge jemals privat sein? Und wenn sie es nicht sind, sollten Sie sich darüber sorgen machen, Spannungen in der Gemeinschaft zu verursachen indem Sie mit manchen der Entwickler Verträge geschlossen haben, und nicht mit andere? Verträge sollten wo möglich offen sein. Sonst kann das Verhalten des Beauftragten anderen in der Gemeinschaft komisch vorkommen – vielleicht gibt er bestimmte Funktionen, die ihn früher nicht interesierten, plötzlich eine unerklärlich hohe Priorität. Wenn Leute ihn darauf ansprechen, wie soll er überzeugend antworten, wenn er nicht darüber reden kann, dass er beauftragt wurde, sie zu schreiben? Gleichzeitig sollten weder Sie noch der Auftragnehmer, so tun als ob andere ihre Vereinbarung als etwas besonderes behandeln sollten. All zu oft habe ich Auftragnehmer erlebt, die auf der Mailingliste mit der Einstellung auftreten, dass ihre Nachrichten ernster genommen werden sollten, einfach nur weil sie bezahlt werden. Diese Einstellung zeigt den anderen Teilnehmern, dass der Auftragnehmer den Vertrag an sich als das Wesentliche erachtet – im Gegensatz zu dem aus dem Vertrag resultierenden Code. Aus Sicht der anderen Entwickler ist der Code das einzig Wichtige. Technische Probleme sollten immer im Mittelpunkt stehen, nicht die Details darüber, wer von wem bezahlt wird. Einer der Entwickler in der Subversion-Gemeinschaft geht mit Auftragsarbeit besonders elegant um. Während er seine Änderungen am Code im IRC bespricht, macht er nebenbei Anmerkungen (oftmals in einer privaten Nachricht, also privmsg im IRC, an andere Entwickler), dass er für die Arbeit an diesem bestimmten Fehler oder Funktion bezahlt wird. Er gibt aber durchweg den Eindruck, dass er an dieser Änderung auch so arbeiten wolle, und dass er froh ist, dass das Geld es ihm ermöglicht. Ob er sagt für wen er arbeitet oder nicht, den Vertrag macht er nie zum eigentlichen Thema. Seine Anmerkungen darüber sind lediglich eine Zierde einer ansonsten technische Diskussion über die Lösung eines Problems. Dieses Beispiel zeigt einen weiteren Grund offen über Verträge zu reden. Es mag mehrere Organisationen geben, die bei einem Open-Source-Projekt Verträge beisteuern, und wenn jeder über die Arbeit des anderen bescheid weiß, können sie vielleicht ihre Ressourcen bündeln. Im obigen Fall, ist der größte Finanzier (CollabNet) in keinster weise an diesen Einzelverträgen beteiligt, aber mit dem Wissen, dass jemand anderes bestimmte Bugfixes fördert, wird CollabNet ermöglicht sich auf andere Fehler zu konzentrieren, und insgesamt die Effizienz im Projekt zu erhöhen. Nehmen es andere Entwickler es den beauftragten Mitgliedern übel, dass sie für die Arbeit am Projekt bezahlt werden? Im allgemeinen nein, insbesondere wenn diejenigen die bezahlt werden sowieso anerkannte, geachtete Mitglieder der Gemeinschaft sind. Keiner erwartet, dass Auftragsarbeit gleichmäßig auf die Beteiligten aufgeteilt wird. Leute verstehen wie wichtig dauerhafte Beziehungen sind: Die Ungewissheiten bei Auftragsarbeit sind derart, dass wenn man einen zuverlässigen Geschäftspartner gefunden hat, man nur widerwillig zu jemand anderen wechselt, nur der Gerechtigkeit halber. Sie können es sich so vorstellen: Wenn Sie das erste mal jemand wählen wird es bestimmt keine Beschwerden geben, denn schließlich mussten Sie ja irgendjemand wählen – Sie können schließlich nicht alle beauftragen. Wenn Sie später dieselbe Person ein zweites mal beauftragen, ist das nur vernünftig: Sie kennen ihn schon, der letzte Auftrag verlief erfolgreich, warum sollten Sie ein unnötiges Risiko eingehen? Es ist deßhalb ganz natürlich ein-zwei Leute in der Gemeinschaft zu haben an denen man sich wenden kann, anstatt die Arbeit gleichmäßig aufzuteilen. Kritik und Annahme von Änderungen Die Gemeinschaft ist trotzdem wichtig für den Erfolg der Auftragsarbeit. Ihre Beteiligung beim Entwurf und der Beurteilung der Änderung, darf nicht beiläufig geschehen. Sie müssen es als Teil der Arbeit aufgefassen und vollständig im Auftrag einbeziehen. Betrachten Sie die Kritik der Gemeinschaft nicht als ein Hindernis, das es zu überwinden gilt – sondern als kostenlose Platform für Entwürfe, Fragen und Antworten. Es ist ein Vorteil, den Sie entschlossen nutzen sollten, anstatt ihn lediglich hinzunehmen. Fallbeispiel: Das CVS-Protokoll zur Passwort-Authentifizierung 1995 war ich an einer Partnerschaft für technische Unterstützung und Erweiterungen an CVS (das Concurrent Versions System; siehe ) beteiligt. Mein Partner Jim und ich waren damals informell für die Instandhaltung von CVS zuständig. Wir hatten aber nie sorgfältig darüber nachgedacht, wie wir mit der vorhandenen, größtenteils freiwilligen Entwicklergemeinschaft von CVS umgehen sollten. Unsere Erwartung war einfach Patches zu bekommen, die wir anwenden würden, und so war auch weitestgehend der Ablauf. Damals konnte man CVS im Netzwerk nur über ein Fernzugriff Programm wie rsh betreiben. Man brauchte dasselbe Passwort für CVS wie für den Fernzugriff, was ein offensichtliches Sicherheitsrisiko darstellte und viele Organisationen abschreckte. Eine bedeutende Anlagebank beauftragte uns einen neuen Authentifizierungsmechanismuss zu implementieren, damit sie vernetztes CVS sicher mit ihren Außenstellen benutzen konnten. Jim und ich nahmen den Vertrag fingen an ein Entwurf für das neue Authentifizierungssystem auszuarbeiten. Unser Entwurf war relativ einfach (die Vereinigten Staaten hatten damals Einschränkungen auf den Export von Kryptographischem Code, also hatte der Kunde Verständnis dafür, dass wir keine Starke Authentifizierung implementieren konnten), da wir aber keine Erfahrung mit derartigen Protokollen hatten, machten wir dennoch einige grobe Fehler, die einem Experten sofort aufgefallen wären. Diese Ausrutscher wären mit Leichtigkeit erkannt worden, hätten wir uns die Zeit genommen einen Vorschlag zu verfassen und die anderen Entwickler zur Überprüfung gereicht hätten. Uns kam es nie in den Sinn, die Entwickler auf dem Verteiler als Ressource zu betrachten und machten alleine weiter. Wir wussten, dass unsere Arbeit, egal wie sie aussah, wahrscheinlich angenommen werden würde, und – da wir nicht wussten was wir nicht wussten – machten uns nicht die Mühe, unsere Arbeit für alle sichtbar offenzulegen, d.h. häufig Patches ab zu schicken, kleine, leicht verdauliche Änderungen an einem bestimmten Branch, usw. Das entstandenen Authentifizierungsprotokoll war nicht sonderlich gut, und nach seiner etablierung, ließ es sich es natürlich, aufgrund von Sorgen um die Kompatibilität, nur sehr schwer verbessern. Im Kern lag das Problem nicht an unser Mangel an Erfahrung; wir hätten das Nötige mit Leichtigkeit lernen können. Das Problem lag an unsere Einstellung zur Entwicklergemeinschaft. Wir betrachteten die Annahme der Änderungen als eine Hürde die es zu überwinden galt, nicht als Ablauf um die Qualität der Änderungen zu verbessern. Wir waren zuversichtlich, dass jedweder Arbeit von uns angenommen würde (was auch geschah), und machten uns deshalb wenig mühe um äußere Beteiligung. Bei der Suche nach einem Auftragnehmer, sollten Sie offensichtlich auf die richtigen technischen Fähigkeiten und Erfahrung achten. Es ist aber auch wichtig jemanden zu wählen, der nachweislich mit den anderen Entwicklern in der Gemeinschaft eine konstruktive Zusammenarbeit pflegt. Sie bekommen dadurch mehr als nur eine Person; Sie bekommen einen Agenten, der in der Lage sein wird aus einem Netzwerk von Fachwissen zu schöpfen, um robuste und wartbare Arbeit sicherzustellen. Tätigkeiten neben dem Programmieren finanzieren Programmieren ist nur ein Teil der Arbeit in einem Open-Source-Projekt. Für Freiwillige im Projekt, ist es der sichtbarste und glorreichste Teil. Leider können dadurch andere Tätigkeiten wie die Dokumentation, formale Tests, usw. manchmal vernachlässigt werden, zumindest im Vergleich zu der Aufmerksamkeit die sie bei proprietärer Software oftmals erhalten. Unternehmen können das manchmal auszugleichen, indem Sie einen Teil ihrer internen Infrastruktur für die Software-Entwicklung, Open-Source-Projekten widmen. Das Wesentliche für den Erfolg dieser Arbeit, ist die Übersetzung zwischen den Abläufen in der Firma und denen in der Gemeinschaft. Sie ist nicht Mühelos: Oft passen beide nicht gut zusammen, und die Unterschiede können nur durch menschliche Eingriffe überwunden werden. Die Firma kann beispielsweise einen anderen Bugtracker verwenden, als das öffentliche Projekt. Selbst wenn beide die gleiche Software benutzen, werden die darin gespeicherten Daten sehr unterschiedlich sein, da die Anforderungen einer Firma am Bugtracking ganz andere sind, als die einer freien Software-Gemeinschaft. Eine Information die in einem Bugtracker anfängt, muss vielleicht auf den anderen übertragen werden, wobei vertrauliche Teile entfernt, oder in umgekehrter Richtung hinzugefügt werden müssen. Die folgenden Abschnitte drehen sich um den Aufbau und die Instandhaltung solcher Brücken. Das Endergebnis sollte ein reibungsloser Betrieb im Open-Source-Projekt, die Anerkennung der Investition der Firma durch die Gemeinschaft, ohne das das Gefühl unangemessen durch die Firma beeinflusst zu werden. Qualitätssicherung Bei der Entwicklung proprietärer Software, hat man üblicherweise eine gesonderte Abteilung die sich der Qualitätssicherung widmet: Nach Fehlern sucht, die Performance und Skalierbarkeit evaluiert, Schnittstellen, Dokumentation usw. überprüft. Diese Aktivitäten werden üblicherweise nicht so energisch von freiwilligen in einem freien Software-Projekt verfolgt. Das liegt teilweise an der Schwierigkeit Freiwillige für unrühmliche Tätigkeiten wie das Testen zu finden und zum Anderen weil Leute annehmen, dass eine große Nutzergemeinschaft auch eine gute Test-Abdeckung mit sich bringt. Performance und Skalierbarkeit sind sogar ein Gebiet wofür Freiwillige oftmals sowieso nicht die nötige Hardware zur Verfügung steht. Die Annahme, dass viele Nutzer auch viele Tester sind, ist nicht ganz ohne Grundlage. Es macht sicherlich wenig Sinn, Personen einzustellen die Grundfunktionen auf der üblichen Zielumgebungen überprüfen: Die dortigen Fehler werden ohnehin beim normalen Betrieb, schnell von gewöhnlichen Nutzern gefunden. Da Nutzer aber lediglich versuchen ihre Arbeit zu erledigen, setzen Sie sich nicht bewusst auf der Suche nach ungewöhnliche Grenzfälle in der Funktionalität der Software zu entdecken, und werden wahrscheinlich bestimmte Fehler unentdeckt lassen. Bei einem Fehler der sich leicht umgehen lässt, werden Sie sogar eher im Stillen diese Abhilfe implementieren ohne sich die Mühe zu machen den Fehler zu melden. Am heimtückischsten kann der Umgang Ihrer Kunden (die Quelle von Ihrem Interesse) mit der Software sein, dass statistisch ganz anderers aussehen kann als das Verhalten eines beliebig anderen Nutzers. Eine professionelle Testgruppe kann solche Fehler genau so gut in freier, wie in proprietärer Software aufdecken. Die Herausforderung ist, die Ergebnisse der Tester, der Öffentlichkeit in einer nützlichen Form mitzuteilen. Die Test-Abteilungen haben im Betrieb meistens ihre eigene Art Ergebnisse zu melden, mit firmenspezifischem Jargon, oder speziellem Fachwissen über bestimmte Kunden und ihre Datensätze. Solche Berichte wären auf einen öffentlichen Bugtracker unangemessen, sowohl wegen ihrer Form als auch aus Datenschutz Gründen. Selbst wenn die interne Bugtracking-Software Ihrer Firma die gleiche wäre wie im öffentlichen Projekt, kann es sein, dass die Betriebsverwaltung firmenspezifische Kommentare sowie Änderungen an den Metadaten der Vorfälle machen muss (zum Beispiel um die interne Priorität eines Vorfalls anzuheben, oder seine Lösung für einen bestimmten Kunden anzusetzen). Für gewöhnlich sind solche Anmerkungen vertraulich – manchmal werden sie nicht einmal dem Kunden gezeigt. Aber selbst diese Daten nicht vertraulich sind für das öffentliche Projekt uninteresant und sollte deshalb nicht von ihnen abgelenkt werden. Die Meldung des eigentlichen Fehlers, ist für die Öffentlichkeit dennoch wichtig. Tatsächlich ist eine Bug-Meldung von Ihrer Test-Abteilung in mancherlei Hinsicht wertvoller als die der üblichen Benutzer, da die Test-Abteilung nach Sachen Ausschau hält, die andere Nutzer nicht interesieren. Angesichts der Tatsache, dass Sie diese Fehler aus keiner anderen Quelle erfahren werden, sollten sie es unbedingt aufbewahren, und es dem öffentlichen Projekt zur Verfügung stellen. Um das zu erreichen, kann entweder die Abteilung zur Qualitätssicherung die Meldungen direkt in den öffentlichen Bugtracker eintragen, wenn sie sich dabei wohl fühlen, oder ein Vermittler (gewöhnlich einer der Entwickler) kann die internen Meldungen der Test-Abteilung zu dem Öffentlichen Tracker "übersetzen". Übersetzen bedeutet in diesem Zusammenhang den Bug so zu beschreiben, dass es keine Bezüge auf kundenspezifische Informationen hat (sofern der Kunde dem Zustimmt, kann die Anleitung um den Fehler zu reproduzieren natürlich auch Kundendaten beinhalten). Der Eintrag in den Tracker sollte vorzugsweise von der Abteilung zur Qualitätssicherung gemacht werden. So kann die Öffentlichkeit die Beteiligung Ihrer Firma besser sehen und würdigen: Nützliche Bug-Meldungen tragen ebenso zum guten Ruf Ihrer Organization bei, wie jeder andere technische Beitrag. Es gibt freiwillige Entwickler auch einen direkten Draht um mit der Test-Abteilung zu kommunizieren. Wenn diese Abteilung den Bugtracker beobachtet, kann ein Entwickler eine Änderung machen um z.B. einen Skalierbarkeits-Bug zu beheben (der Entwickler selber kann die Korrektur nicht überprüfen, da er nicht die nötigen Ressourcen hat), und anschließend dem Ticket eine Anmerkung anhängen, mit der Bitte an die Qualitätssicherung, zu überprüfen, ob es die gewünschte Wirkung hatte. Stellen Sie sich auf den Widerstand einiger Entwickler ein; Programmierer haben die Angewohnheit Qualitätssicherung, allerhöchstens als ein notwendiges übel zu erachten. Die Test-Abteilung kann das leicht überwinden, indem sie schwerwiegende Fehler findet und nachvollziehbare Tickets schreibt; wenn ihre Tickets andererseits nicht mindestens so gut sind, wie denen von der übrigen Gemeinschaft, hat es keinen Sinn, dass sie direkt mit den Entwicklern zusammenwirken. So oder so, sollte sobald es den Öffentlichen Ticket gibt, der interne Ticket im Bezug auf technische Inhalte, nur noch auf den öffentlichen Verweisen. Der Betrieb kann weiterhin Anmerkungen firmenspezifischer Angelegenheiten bei Bedarf beifügen, sollte aber Informationen, die allen zur Verfügung stehen sollten, in das öffentliche Ticket schreiben. Sie sollten sich bei diesem Verfahren auf einen höheren Aufwand einstellen. Die Pflege von zwei Tickets für einen Bug, bedeutet natürlich mehr Arbeit als eins. Der Vorteil ist, dass viel mehr Programmierer den Ticket sehen werden und ihre Lösungen beitragen können. Rechtliche Beratung und Schutz Gesellschaften, ob profitorientiert oder nicht, sind fast die einzigen, die bei einem freien Software-Projekt, für komplexe rechtliche Angelegenheiten, irgendwelche Aufmerksamkeit aufbringen. Einzelne Entwickler verstehen oft die Nuancen verschiedener Open-Source-Lizenzen, haben im allgemeinen aber weder Zeit noch Ressourcen um Urheber-, Marken- und Patentrecht, im Detail zu verfolgen. Wenn Ihre Firma eine Rechtsabteilung hat, kann sie einem Projekt helfen, indem sie den urheberrechtlichen Stand des Quellcodes überprüft und den Entwicklern hilft, mögliche Patent und Markenrechtliche Angelegenheiten zu verstehen. Die genauen Ausprägungen die diese Hilfe annehmen kann werden in diskutiert. Die Hauptsache ist bei einer Kommunikation zwischen der Rechtsabteilung und der Entwicklergemeinschaft sicherzustellen, dass sie die äußerst unterschiedlichen Welten, aus denen beide Parteien kommen gegenseitig, Anerkennen. Gelegentlich können diese beiden Gruppen aneinander vorbeireden, wenn sie von fachspezifischem Wissen ausgehen, welches die anderen Partei nicht hat. Es ist eine gute Strategie, eine Verbindungsperson zu haben (meistens ein Entwickler, oder ein Anwalt mit technische Fachkenntnisse) die so lange wie nötig zwischen beide steht und übersetzt. Dokumentation und Benutzerfreundlichkeit Die Dokumentation und Benutzerfreundlichkeit sind beides wohl bekannte Schwachstellen in Open-Source-Projekten, obwohl ich denke, dass der Unterschied zu proprietärer Software, im Falle der Dokumentation, oftmals hochgespielt wird. Die Erfahrung zeigt trotzdem, dass es Open-Source-Software meistens an einer erstklassigen Dokumentation, sowie einer Untersuchung ihrer Benutzerfreundlichkeit mangelt. Wenn Ihre Gesellschaft helfen will, diese Lücken für ein Projekt zu füllen, sollten Sie wahrscheinlich am ehesten Leute einzustellen, die üblicherweise nicht am Projekt mitentwickeln, aber dennoch in der Lage sein werden mit den Entwicklern produktiv zusammenzuarbeiten. Leute einzustellen die keine gewöhnlichen Entwickler sind, ist aus zwei Gründen gut: Erstens, entziehen Sie dem Projekt dadurch keine Entwicklerzeit; zweitens, diejenigen die der Software am nächsten sind, sollten im allgemeinen sowieso nicht die Dokumentation schreiben oder die Benutzerfreundlichkeit untersuchen, da sie Schwierigkeiten haben die Software aus der Sicht eines Außenstehenden zu betrachten. Eine Kommunikation zwischen diesen beiden parteien wird allerdings immer noch nötig sein. Finden Sie Leute, die genügend technische Kenntnisse haben, um mit den Entwicklern zu kommunizieren, aber nicht so weit experten mit der Software sind, dass sie kein Einfühlungsvermögen für gewöhnliche Benutzer haben. Ein halbwegs erfahrener Benutzer ist wahrscheinlich die richtige Person um eine gute Dokumentation zu schreiben. Ich bekam nach der ersten Veröffentlichung dieses Buchs, sogar eine E-Mail von einem Open-Source-Entwickler namens Dirk Reiners: Eine Anmerkung im Bezug auf Geld::Dokumentation und Benutzerfreundlichkeit: Als wir etwas Geld übrig hatten und uns entschieden, dass eine Einleitung für Anfänger das wichtigste war, stellten wir einen halbwegs erfahrenen Benutzer ein. Er war erst kürzlich in das System eingewiesen worden, sodass er sich an seine Probleme erinnern konnte, er hatte es aber daran vorbei geschafft und konnte sie dementsprechend beschreiben. Er konnte dadurch etwas schreiben, dass von den Hauptentwicklern nur wenige Korrekturen bedurfte, bei Sachen die er nicht richtig aufgefasst hatte. Trotzdem konnte er das 'Offensichtliche' abdeckten, dass die Entwicklern übersehen hätten. Sein Fall war noch besser, da es seine Aufgabe gewesen war einen Haufen anderer Personen (Studenten) in das System einzuführen, also kombinierte er die Erfahrung vieler Personen, was etwas ist, dass einfach nur ein glücklicher Zufall war und wahrscheinlich schwer in den meisten Fällen zu erreichen ist. Bereitstellung von Hosting/Bandbreite Bei einem Projekt, welches nicht einer der freien Hosting-Pakete benutzt (siehe im Kapitel ), kann die Bereitstellung von Server und Netzwerkverbindung – und besonders die Hilfe bei der System-Administration – eine wesentliche Unterstützung sein. Selbst wenn das alles ist was Ihre Gesellschaft für das Projekt macht, kann es eine halbwegs effektive Art sein Karma in der Öffentlichkeit zu sammeln, auch wenn es Ihnen keinen Einfluss auf die Richtung des Projekts bringen wird. Sie könne wahrscheinlich einen Banner oder eine Anerkennung auf der Projekt-Seite erwarten, welches Ihre Firma für das Hosting bedankt. Wenn Sie das Hosting so einrichten, dass die Webseite des Projekts bei Ihrer Domain ist, werden Sie alleine schon durch die URL eine etwas größere Assoziierung bekommen. Das wird die meisten Benutzer dazu bringen, zu denken, dass das Projekt irgendetwas mit Ihrer Firma zu tun hat, selbst wenn Sie gar nicht zu der Entwicklung beitragen. Das Problem ist, dass die Entwickler sich dieser Assoziation auch bewusst sind, und werden sich nicht sonderlich wohl dabei fühlen, das Projekt unter Ihrer Domain zu haben wenn Sie nicht mehr Ressourcen als lediglich Bandbreite zu dem Projekt beitragen. Schließlich gibt es heutzutage viele Orte für Hosting. Die Gemeinschaft mag irgendwann der Meinung sein, dass die angedeutete falsche Anerkennung nicht dem Komfort vom Hosting wert ist und das Projekt anderswo unterbringen. Wenn Sie also Hosting anbieten wollen, machen Sie es – planen Sie aber entweder sich eingehender zu beteiligen oder seien sie umsichtig darüber wieviel Beteiligung sie sich Zusprechen. Marketing Auch wenn die meisten Open-Source-Entwickler es nur ungern zugeben würden, funktioniert Marketing. Eine gute Marketingkampagne kann Aufmerksamkeit um ein Open-Source-Projekt entstehen lassen, selbst zu dem Grad, dass starrköpfige Entwickler unklare positive Gedanken über die Software haben, aus Gründen, die sie sich nicht ganz erklären können. Es ist nicht an mir die Dynamik des Wettrüstens beim Marketing um Allgemeinen zu untersuchen. Jede Gesellschaft die mit freier Software zu tun hat, wird irgendwann sich dabei vorfinden zu bedenken, wie sie sich, die Software, oder ihre Beziehung zu der Software vermarkten sollen. Die folgenden Ratschläge handeln darüber, wie Sie bei solch einer Bemühung häufige Stolpersteine vermeiden können; siehe auch im Kapitel . Denken Sie daran, dass Sie beobachtet werden Um die Entwicklergemeinschaft auf Ihre Seite zu behalten, ist es sehr wichtig nichts zu sagen, was nicht nachweislich wahr ist. Überprüfen Sie vorsichtig alle Behauptungen, bevor Sie sie in den Raum stellen, und geben Sie der Öffentlichkeit einen Weg Ihre Behauptungen zu überprüfen. Unabhängige Überprüfung von Tatsachen ist ein bedeutender Teil von Open Source, und es gilt für mehr als nur den Code. Natürlich würde eh keiner Firmen anweisen nicht überprüfbare Behauptungen aufzustellen. Bei Open-Source-Aktivitäten gibt es für gewöhnlich eine hohe Anzahl an Personen mit dem nötigen Wissen um Behauptungen zu verifizieren – Personen die wahrscheinlich auch einen breitbandigen Internetzugang haben und die richtigen sozialen Kontakte um Ihre Ergebnisse auf eine schädliche Art zu verbreiten, wenn Sie es wollen. Wenn Global Megacorp Chemical Industries einen Fluss verunreinigt, kann das nachgewiesen werden, aber nur von ausgebildeten Wissenschaftlern, die wiederum von den Wissenschaftlern von Global Megacorp angefochten werden können, wodurch die Öffentlichkeit verwirrt wird und sich nicht sicher ist, was sie denken soll. Im Gegensatz dazu ist Ihr Verhalten in der Open-Source-Welt nicht nur sichtbar und aufgezeichnet; es ist auch ein Leichtes für viele Leute es unabhängig von einander zu überprüfen, ihre eigene Schlussfolgerungen zu ziehen und diese mittels Mundpropaganda zu verbreiten. Diese Kommunikationsnetzwerke sind bereits gelegt; sie sind das Wesentliche wodurch Open Source funktioniert, und sie können benutzt werden, um jede Information zu übertragen. Widerlegung ist für gewöhnlich schwer, wenn nicht sogar unmöglich, insbesondere wenn das was die Leute sagen war ist. Es ist zum Beispiel in Ordnung von Ihrer Organization zu sagen, dass Sie "Projekt X gegründet" hat wenn das tatsächlich der Fall ist. Bezeichnen Sie sich aber nicht als die "Hersteller von X" wenn der meiste Code von fremden geschrieben wurde. Umgekehrt, sollten Sie nicht behaupten, dass Sie eine zutiefst beteiligte Gemeinschaft freiwilliger Entwickler haben, wenn jeder in Ihr Projektarchiv hineinschauen und sehen kann, dass es wenige oder gar keine Änderungen gibt, die von außerhalb Ihrer Gesellschaft kommen. Vor nicht all zu lange, sah ich eine Meldung von einer sehr bekannten Computer-Firma, welche behaupteten, dass Sie ein wichtiges Software-Packet unter einer Open-Source-Lizenz veröffentlichten. Als die ursprüngliche Ankündigung herausgegeben wurde, sah ich mir ihr nunmehr öffentliches Projektarchiv an und erkannte, dass es nur drei Revisionen beinhaltete. Mit anderen Worten, hatte sie den ersten Import des Quellcodes gemacht, seit dem war aber fast nichts geschehen. Das alleine für sich war nicht beunruhigend – schließlich hatten sie eben erst die Ankündigung gemacht. Es gab keinen Grund gleich vorne weg eine Menge Aktivität zu erwarten. Etwas später, machten Sie eine weitere Meldung. Hier ist es, was sie sagten, wobei der Name und die Versionsnummer durch Pseudonyme ausgetauscht wurden:
Wir freuen uns bekannt zu geben, dass nach rigorosen Tests durch die Singer-Gemeinschaft, Singer 5 für Linux und Windows für den Einsatz in produktiv Umgebungen bereit ist.
Neugierig was die Community bei ihren "rigorosen Tests" aufgedeckt hatte, ging ich danach zurück zum Projektarchiv um seine Historie kürzlicher Änderung an zu sehen. Das Projekt war immer noch bei der Revision 3. Scheinbar hatten sie keinen einzigen Bug gefunden der es vor dem Release wert gewesen wäre behoben zu werden! In der Annahme, dass die Ergebnisse der Tests durch die Gemeinschaft anderswo aufgezeichnet worden sein müssen, untersuchte ich als nächstes den Bugtracker. Es gab genau sechs offene Meldungen, von denen vier seit mehreren Monaten bereits offen gewesen waren. Das ist so natürlich kaum glaubwürdig. Wenn Tester auf einem großen und komplexen Stück Software für irgend eine beliebige Zeitspanne einhämmern, werden sie Fehler finde. Selbst wenn die Fixes für diese Bugs es nicht in die nächste Version schaffen, sollte man annehmen, dass durch das Testen irgend welche Aktivität auf dem Versionsverwaltungssystem resultieren würde oder zumindest ein paar neue Bug-Meldungen. Allem Anschein nach war jedoch nichts seit der Ankündigung der Open-Source-Lizenzierung und der ersten Open-Source-Version passiert. Die Sache ist nicht, dass die Firma über die Tests durch die Gemeinschaft gelogen hatte. Ich habe keine Ahnung ob das der Fall war oder nicht. Sie waren aber völlig nachlässig darüber, wie sehr es danach aussah als ob sie am lügen waren. Da weder das Versionsverwaltungssystem noch der Bugtracker irgend eine Andeutung über die angeblichen rigorosen Tests gab, hätte die Firma entweder von vorn herein, die Behauptung nicht machen sollen, oder einen klaren Verweis auf irgend ein greifbares Ergebnis dieser Tests ("Wir haben 278 Bugs gefunden; klicken Sie hier für weitere Details"). Letzteres hätte jeden die Möglichkeit gegeben, sich sehr schnell ein Bild über die Aktivität der Gemeinschaft zu machen. So wie es war, braucht ich nur ein paar Minuten um heraus zu finden, dass was auch immer diese Gemeinschaft am testen war, es hatte keine Spuren an den üblichen Stellen zurück gelassen. Das ist keine große Mühe, und ich bin mir sicher, dass ich nicht der einzige war der sich diese gemacht hat. Transparenz und Überprüfbarkeit sind natürlich auch ein wichtiger Teil der rechten Würdigung. Siehe im Kapitel für weiteres hierüber. Machen Sie konkurrierende Open-Source-Produkte nicht schlecht Unterlassen Sie es, negative Ansichten über konkurrierende Open-Source-Software zu verkünden. Es ist völlig in Ordnung, negative Tatsachen zu benennen – also leicht überprüfbare Behauptungen von der Art, wie man sie oft in Vergleichstabellen sieht. Negative Beschreibungen, von weniger rigoroser Natur sollte man aus zwei Gründen lieber vermeiden. Erstens machen Sie sich damit schuldig Flamewars anzufangen, welche von produktiven Diskussionen ablenken. Zweitens und noch wichtiger, kann es sich herausstellen, dass einiger der freiwilligen Entwickler in Ihrem Project, auch an dem konkurrierenden Projekt arbeiten. Das ist wahrscheinlicher als es zunächst den Anschein haben mag: Die Projekte sind bereits in dem selben Gebiet (deßhalb stehen sie zu einander in Konkurrenz), und es kann passieren, dass Entwickler die Fachwissen auf diesem Gebiet haben überall dort Beiträge leisten wo es anwendbar ist. Selbst wenn es keine direkte Überlappung bei den Entwicklern gibt, ist es wahrscheinlich, dass Entwickler in Ihrem Projekt zumindest mit denen aus verwandter Projekten vertraut sind. Ihre Möglichkeiten konstruktive persönliche Bekanntschaften zu bewahren könnten durch übermäßig negative Marketing-Botschaften eingeschränkt werden. Auf konkurrierende proprietäre Produkte herum zu hacken scheint eher in der Open-Source-Welt akzeptiert zu sein, insbesondere wenn diese Produkte von Microsoft stammen. Ich persönlich verabscheue diese Neigung (obwohl es in diesem Fall auch nichts an Vergleiche die auf Tatsachen beruhende, auszusetzen gibt), nicht nur weil es unhöflich ist, sondern weil es gefährlich für ein Projekt ist, anzufangen ihren eigenen Hype zu glauben und dadurch zu ignorieren, in wie fern die Konkurrenz vielleicht tatsächlich überlegen sein mag. Im allgemeinen sollten Sie darauf aufpassen, welche Auswirkungen Marketing-Botschaften auf Ihre eigene Entwicklergemeinschaft haben mag. Manche mögen derart aufgeregt darüber sein, durch Marketing Rückenwind zu bekommen, dass sie ihre Objektivität über die wahren Stärken und Schwächen ihrer Software verlieren. Es ist normal, und sogar zu erwarten, dass die Entwickler einer Firma zu einem gewissen Grad Unberührtheit von Marketing-Behauptungen ausdrücken, selbst in den öffentlichen Foren. Sie sollten ganz klar diesen Marketing-Botschaften nicht direkt widersprechen (es sei denn sie sind tatsächlich falsch, obwohl man hoffen mag, dass sowas vorher abgefangen werden sollte). Von Zeit zu Zeit kann es aber passieren, dass sie sich darüber lustig machen, um die restliche Entwicklergemeinschaft wieder auf den Teppich zu bringen.