Kapitel 5. 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.