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 mehrere Gruppen 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 den E-Mail Verteilern 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.