Kapitel 5. Geld

Inhaltsverzeichnis

Arten der Beteiligung
Langzeit-Entwickler
Treten Sie als viele in Erscheinung
Seien Sie offen bezüglich Ihrer Absichten
Liebe kann nicht mit Geld erkauft werden
Auftragsarbeit
Kritik und Annahme von Änderungen
Fallbeispiel: Das CVS-Protokoll zur Passwort-Authentifizierung
Tätigkeiten neben dem Programmieren finanzieren
Qualitätssicherung
Rechtliche Beratung und Schutz
Dokumentation und Benutzerfreundlichkeit
Bereitstellung von Hosting/Bandbreite
Marketing
Denken Sie daran, dass Sie beobachtet werden
Machen Sie konkurrierende Open-Source-Produkte nicht schlecht

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 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 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 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 neuen 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 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 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, mag die Funktion noch lange nicht zu der Vorstellung über die Zukunft der Software der Gemeinschaft passen. Die Arbeit kann nur im Rahmen seiner Leistung und 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 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 mehrerer oder all 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 Szenario die intuitivste für gemeinnützige Organisationen scheint, kann es auch für profitorientierte Konkurrenten Sinn machen.

Beispiele: http://www.openadapter.org/, http://www.koha.org/

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 http://subversion.tigris.org/ 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 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: http://www.openoffice.org/ (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 „Doppelte Lizenzierung“ im Kapitel Kapitel 9, Lizenzen, Urheberrecht und Patente). 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 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 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ä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.