Geld
In diesem Kapitel untersuchen wir die Finanzierung freier
Software. Es richtet sich nicht nur an die Entwickler, die für ihre Arbeit
an freien Software-Projekte bezahlt werden wollen, sondern auch an
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 ersichtlich sein.
Unternehmen finanzieren die Entwicklung freier Software schon seit
langem. Viele Entwicklung wurden schon immer informell subventioniert.
Wenn ein Systemadministrator ein 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 neuen Funktionen,
sodass sich ein neues Konsortium bildet. Die Finanzierung stammt
aus den Gehältern der Administratoren, deren Bürofläche und
Infrastruktur von dem jeweiligen Arbeitgebern, wenn auch ohne deren Wissen,
gespendet werden. 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 und 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 einen Effekt auf die
Art und Weise, wie Projekte organisiert sind 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 willkommen geheißen. Sie kann vor den Folgen vom Chaos
schützen, welche 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, dass auch noch in 6 Monaten 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 selbst
erfüllende Prophezeiung werden.
Finanzierung bringt, wie auch immer 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 neue Funktionen einfach
eine Frage des Geldes sind, werden sie zu einem anderen Projekt
wechseln, in dem 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 werden 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 Entwicklern 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. Die Arbeit kann nur im
Rahmen seiner Leistung und hinsichtlich der Frage, wie gut sie sich in
die Vision der Community für die Software einfügt, angenommen werden.
Sie werden dabei möglicherweise etwas zu der Vision zu sagen haben,
Sie werden aber nicht die einzige Stimme 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 sogar einen Stimmblock.
Wenn sie in dem Projekt respektiert werden, bekommen sie Einfluss über
ihre Stimmen hinaus. Bezahlte Entwickler müssen auch nicht versuchen,
ihre Motive 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 mehrerer oder
all dieser Motivationen sein:
Geteilte Last
Separate Organisationen mit überlappenden Softwarebedarf
bemerken oftmals, 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 aber die Vorteile kommen
allen gleichermaßen zugute. Obwohl dieses Szenario die intuitivste
für gemeinnützige Organisationen scheint, kann es auch für
profitorientierte Konkurrenten strategisch sinnvoll sein.
Beispiele: ,
Verbesserung von Dienstleistungen
Wenn eine Firma Dienstleistungen zu bestimmten
Open-Source-Anwendungen verkauft oder diese durch
Open-Source-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 des Hardware-Absatzes
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äten 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 Konkurrenzprodukt 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 einer weit gefassten Testung
und Entwicklung, die Firma hingegen dennoch Nutzungsgebühren um ihre
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 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
ihrer 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äftsmodell eines Geldgebers ist nicht sein einziger
Einfluss auf eine Open-Source-Gemeinschaft. Seine 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 schwierig. 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 angehäufte 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 also ein neuer Entwickler noch keinen Commit-Zugriff hat, wird er
bis dahin Patches einreichen müssen. Commit-Zugriff ist aber nur der
messbarste Ausdruck 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
Organisation führt; die anderen werden sich vielleicht wundern "ob
die sich denn garn nichts merken können"? Neue Entwickler werden auch
kein politisches Gespür für die Persönlichkeiten im Projekt haben und
nicht in der Lage sein, die Richtung der Entwicklung so schnell
oder reibungslos zu beeinflussen, wie ein alter Hase.
Trainieren Sie Neuankömmlinge mittels eines Programms der
beaufsichtigten Beschäftigung. Der neue Entwickler sollte vom ersten Tag an
in engem Kontakt mit der öffentlichen Entwicklergemeinschaft stehen, angefangen mit
Bugfixes und Aufräumarbeiten, so dass er die Codebasis kennenlernen und sich
einen Ruf in der Gemeinschaft erarbeiten kann, er sollte jedoch keine
langwierige und verstrickte Diskussionen über Codestruktur zünden.
Währenddessen sollten ein Paar erfahrene Entwickler für Fragen
bereitstehen und jede Nachricht des Anfängers an die Verteiler lesen,
sogar bei Threads, denen sie sonst keine Beachtung schenken würden.
Das wird der Gruppe helfen, mögliche Steine auf dem Weg zu erkennen, bevor
der Anfänger darü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 offen stehende
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, bevor er auf dem zentralen Verteiler für Entwickler zu sehen
ist, auch wenn wir es, gäbe es einen Grund dazu, könnten. 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, dass
wir uns Zeit nehmen um 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
dem 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 monolithisches
Firmenwesen. Das liegt nicht an irgend einer negativen Behaftung von
monolithischen Unternehmen (naja, vielleicht schon ein bisschen,
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, dass
ein Gegenpol angebracht wäre, um sie in Schach zu halten.
Es gibt einen Unterschied zwischen einer wirklich
dezentralisierten Organisation und einfach als eine solche 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 einen
gewissen Impuls 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, 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 hinsichtlich der Motive ihrer Organisation so offen, 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 diese als anonyme Beispiele anführen dürfen.
Je mehr die öffentliche Entwicklergemeinschaft darüber weiß,
warum Sie etwas wollen, desto eher wird diese Ihre
Vorschlage akzeptieren.
Das widerspricht dem Instinkt – einfach anzueignen, aber
schwer loszuwerden –, dass Wissen gleich Macht ist und dass je mehr
anderen ihre Ziele bekannt sind, je mehr Kontrolle diese über Sie haben.
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 aufzeigen, 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, welche 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 dementsprechend durch
Mangel an Daten über echte Nutzung weder verkürzt noch verlängert,
sondern driften immer weiter von der Praxis ab. Ohne irgend eine
ausgleichende Kraft wird das Endergebnis eher von dem Wortgewandtesten,
dem Hartnäckigsten oder dem Ranghöchsten bestimmt.
Ihre Position als Organisation 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 bewusst. Durch
glaubwürdige Daten einer nicht unwesentlichen Anzahl an Nutzern geben
Sie der Entwicklergemeinschaft etwas 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 einer 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 zu spekulieren beginnen, 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
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 dem öffentlichen
Verteilern wiederholt wird. Schreiben Sie nicht etwas 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 die 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 im Gespräch mit ihnen wohl fühlen,
selbst wenn sie anderer Meinung sind. 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 auch nicht von Ihnen erwarten. Alle Organisationen haben Geheimnisse;
vielleicht haben profitorientierte Organisationen 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 bestmöglichen
Argumente. 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 ein bezahlter Entwickler in einem Projekt sind, dann
stellen Sie frühzeitig Richtlinien auf, die festlegen, 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 es das
Potential dazu gibt.
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 hatten schon mit
dem Programmieren angefangen und 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, in der er ihm 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 Programmierer 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 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 er wurde
akzeptiert, wie von uns erwartet.
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äterer Infragestellung der eigenen Motive. Bei einer hitzigen Debatte
greifen Leute manchmal auf Angriffe ohne technischische Bedeutung zurück, um die
Schlacht für sich zu entscheiden. Der Haupt-Geldgeber bietet durch seine
tiefe Beteiligung und offensichtliche Sorgen um die Richtung, welche 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, die gleichen Richtlinien
für Commit-Zugriff für seine eigenen Entwickler zu befolgen wie
für die Entwickler außerhalb von Sun.)
Weil Geldgeber nach denselben 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, diesen
in die Software hineinzubekommen. Das Schwierige ist, dass es als komplett
Fremder sehr mühevoll 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 Problem zu umgehen. Der bevorzugte
Weg ist, eine fundierte Vermutung über die Dauer der Diskussion, beruhend
auf der bisherigen Erfahrung, zu machen, mit einem Puffer für Fehler,
und den Vertrag darauf fußen lassen. Es hilft auch, das Problem in möglichst
viele, unabhängige Einzelteile zu spalten, um die einzelnen Teile 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, auch beim bevorzugten Weg kann der Vertrag selbst nicht verlangen,
dass die Aufnahme des Patches in den Code akzeptiert wird, weil das den
Verkauf von etwas bedeuten würden, das 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 und sie danach im Projektarchiv eingespielt
zu bekommen. Wenn das Projekt beispielsweise Normen über Codeänderungen
festgelegt hat, kann der Vertrag auf diese verweisen und festlegen, das
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 auf Dauer angelegte Position in einem Projekt nicht
für die Unterstützung einer weitestgehend unbeliebten Funktion riskieren.
Tatsächlich sollte ein Teil von dem, was Sie erhalten, wenn Sie einen
solchen Entwickler einstellen, Ratschläge darüber sein, welche
Änderungen wahrscheinlich von der Gemeinschaft angenommen werden. Sie
erzielen auch eine gewisse Umstellung der Prioritäten im Projekt.
Weil die Priorisierung oft aus der Frage resultiert, wer an welchem Teil
Zeit hat zu arbeiten, wird, da Sie jemandes Zeit bezahlen, dessen Arbeit
in der Prioritätenlist ein wenig nach oben wandern. Unter erfahrenen
Open-Source-Entwicklern ist diese Tatsache wohlbekannt und zumindest manche
werden der Arbeit eines Auftragnehmers Aufmerksamkeit widmen, einfach nur
weil zu vermuten ist, dass es fertig wird, 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
anderen?
Verträge sollten wo möglich offen sein. Sonst kann das
Verhalten des Beauftragten anderen in der Gemeinschaft komisch
vorkommen – vielleicht gibt er bestimmten Funktionen plötzlich
eine unerklärlich hohe Priorität, die ihn früher aber nicht
interessierten. 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 auftraten, 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 vermittelt 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. Egal 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.
Das folgende Beispiel zeigt einen weiteren Grund für das Offensein
über Verträge auf: 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 Finanzierer (CollabNet) in keinster Weise an diesen
Einzelverträgen beteiligt. Aber mit dem Wissen, dass jemand anderes
bestimmte Bugfixes fördert, wird es CollabNet ermöglicht, sich auf andere
Fehler zu konzentrieren, und dadurch insgesamt die Effizienz im Projekt erhöht.
Nehmen andere Entwickler es den beauftragten Mitgliedern übel,
dass sie für die Arbeit am Projekt bezahlt werden? Im allgemeinen nicht,
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 deshalb ganz natürlich, ein-zwei Leute in der
Gemeinschaft zu haben, an die man sich wenden kann, anstatt die Arbeit
gleichmäßig aufzuteilen.
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 den 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 sein, die Investitionen
der Firma sollten von der Gemeinschaft anerkannt werden, ohne dass
das Gefühl entsteht unangemessen durch die Firma beeinflusst
zu werden.
Qualitätssicherung
Bei der Entwicklung proprietärer Softwareist es üblich dass sich
eine gesonderte Abteilung 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 daran dass man annimmt, dass eine große Nutzergemeinschaft
auch eine gute Test-Abdeckung mit sich bringt. Performance und
Skalierbarkeit sind sogar ein Gebiet wofür Freiwilligen 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 die Grundfunktionen der Software
auf den ü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,
begegeben Sie sich nicht bewusst auf
die Suche nach ungewöhnliche Grenzfällen in der Funktionalität der
Software 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, die statistisch ganz anders
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 wenn diese Daten nicht vertraulich
sind, sind diese für das öffentliche Projekt uninteressant und
deshalb sollte die Öffentlichkeit 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 interessieren. Angesichts der Tatsache, dass Sie
diese Fehler aus keiner anderen Quelle erfahren werden, sollten sie
die Fehler unbedingt aufbewahren, und es dem öffentlichen Projekt
zur Verfügung stellen.
Entweder kann 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 Organisation bei wie
jeder andere technische Beitrag. Es gibt freiwilligen 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 die
von der übrigen Gemeinschaft, hat es keinen Sinn, dass sie direkt mit
den Entwicklern zusammenwirken.
So oder so, sollte sobald es ein öffentliches Ticket gibt sollte
das interne Ticket im Bezug auf technische Inhalte nur noch auf das
öffentliche 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 das 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, wird 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 beiden
Seiten steht und übersetzt.
Dokumentation und Benutzerfreundlichkeit
Die Dokumentation und Benutzerfreundlichkeit sind beides
wohlbekannte Schwachstellen in Open-Source-Projekten, obwohl ich denke,
dass der Unterschied zu proprietärer Software in Bezug auf die
Dokumentation oftmals hochgespielt wird. Die Erfahrung zeigt trotzdem,
dass es Open-Source-Software meistens an einer erstklassigen
Dokumentation, sowie Untersuchungen bezüglich ihrer
Benutzerfreundlichkeit mangelt.
Wenn Ihre Firma helfen will, diese Lücken für ein Projekt
zu füllen, dann sollten Sie wahrscheinlich am ehesten Leute einstellen,
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 sollten diejenigen
die der Software am nächsten sind 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 trotzdem immer 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 Dingen die er nicht richtig aufgefasst hatte. Trotzdem
konnte er das 'Offensichtliche' abdeckten, dass die Entwicklern
übersehen hätten.
In seinem Fall war es sogar 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 Firma 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önnen wahrscheinlich einen Banner oder eine Anerkennung auf
der Projekt-Seite erwarten, auf dem man Ihrer Firma für das Hosting dankt.
Wenn Sie das Hosting so einrichten, dass die Webseite des Projekts auf
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 hosten, 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 diese 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 niemand Firmen raten, 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 voneinander 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 Organisation 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 langer Zeit sah ich eine Meldung von einer sehr
bekannten Computer-Firma, welche behauptete, dass Sie ein wichtiges
Software-Paket 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. Dabei behaupteten
sie folgendes (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 produktiven 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
bereits seit mehreren Monaten offen gewesen waren.
Das ist so natürlich kaum glaubwürdig. Wenn Tester auf einem
großen und komplexen Stück Software für einige Zeit einhämmern,
werden sie Fehler finden. Selbst wenn die
Fixes für diese Bugs es nicht in die nächste Version schaffen, sollte
man annehmen, dass durch das Testen irgendwelche 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 dies 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 beinhaltete,
hätte die Firma entweder von vorn herein die Behauptung nicht machen
sollen oder einen klaren Verweis auf irgendein greifbares Ergebnis
dieser Tests ("Wir haben 278 Bugs gefunden; klicken Sie hier für
weitere Details") geben sollen.
Letzteres hätte jedem die Möglichkeit gegeben, sich sehr schnell ein
Bild über die Aktivität der Gemeinschaft zu machen. So wie es war,
brauchte 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
einige 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 Anwendungs und Geschäftsbereich
(deshalb stehen sie zu einander in Konkurrenz). So kann es passieren,
dass die 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 verwandten Projekten vertraut sind. Ihre Möglichkeiten konstruktive
persönliche Bekanntschaften zu pflegen könnten durch übermäßig
negative Marketing-Botschaften eingeschränkt werden.
Auf konkurrierenden proprietären Produkten herumzuhacken 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 auch in diesem Fall nichts gegen sachliche Vergleiche
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, inwiefern 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 soetwas 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.