Kontrollpunkte und Steuerungsmechanismen in Open-Source-Projekten

Die Marktforscher sind sich einig: Open Source ist längst zum integralen Bestandteil von Unternehmen geworden. Spätestens 2012 läuft laut einer Gartner-Studie freie Software bei über 80 Prozent aller Softwarehersteller [1], Forrester Research interpretiert die Ergebnisse seiner Befragungen ähnlich: 2009 gab fast die Hälfte aller Firmen an, freie Software zu verwenden oder zu implementieren [2].

Wie steuern?

Doch diese gestiegene Bedeutung in Unternehmen macht Manager und Controller unruhig. Wie steuert man ein Open-Source-Software-Produkt? Welche Kontrollmechanismen lassen sich von Firmen instrumentalisieren? Wie verhindern sie, dass die freien Komponenten in unerwünschte Richtungen davoneilen und so die Unternehmensziele in Gefahr bringen? Mit zunehmender Bedeutung von freier Software wächst auch das Interesse an der gezielten Lenkung der Community und dem Verständnis für die zugrunde liegenden Prozesse.

Für den folgenden Artikel dienen drei Kategorien von Unternehmen als Maßstab: Traditionelle Softwarefirmen, Single-Vendor-Open-Source-Firmen [3] und Distributoren:

• Closed-Source-Firmen besitzen alle Softwarekomponenten, die ihr Produkt vom Wettbewerb unterscheiden. Die Softwarequellen bleiben unveröffentlicht. Typische Beispiele hierfür sind Microsoft Windows, Oracles Datenbank oder SAPs Business Suite.
• Die Single-Vendor-Open-Source-Firmen besitzen ebenfalls alle Rechte an den zentralen Softwarekomponenten, aber sie haben diese unter Freigabe der Quelltexte öffentlich gemacht [4]. Typische Beispiele dafür sind Alfrescos Contentmanagement-System, Jaspersofts Business Intelligence Tools [5] und (zumindest früher) MySQL.
• Open-Source-Distributoren integrieren eine große Anzahl freier Komponenten und vertreiben das Gesamtpaket gegen Gebühr. Sie besitzen kein Eigentum an den Komponenten. Typische Vertreter dieser Riege sind Suse und Red Hat, aber auch Acquias Drupal [6].

Allen drei Typen gemeinsam ist, dass die Firmen dahinter exklusiv über eine Art von geistigem Eigentum (Intellectual Property) verfügen und es zu Geld machen. Die ersten beiden erzeugen Software, die Distributoren eine vorkonfigurierte Zusammenstellung mit Wiedererkennungswert und eigener Marke.

Eigentum

Auch wenn freie Software gemäß einer Open-Source-Lizenz beliebig verfügbar ist, existieren dennoch Eigentumsrechte daran. Bei Single Vendor Open Source ist die Sachlage sehr einfach: Ein einzelnes Unternehmen ist der rechtliche Eigentümer und wird aggressiv seine Eigentumsrechte verteidigen.

Doch bei Community Open Source liegen die Rechte bei einer diffusen Masse von Einzelpersonen (den Entwicklern und Code-Kontributoren), bestenfalls bei einer Stiftung, die stellvertretend für ihre vielen Mitglieder deren Rechte wahrnimmt ([7], [8], [9]).

Die Lizenzen selbst lassen sich im Wesentlichen in reziproke (virale) und liberale (permissive) Lizenzen kategorisieren. Eine Firma, die Software einbaut, die einer reziproken Lizenz wie der GPL oder der AGPL unterstellt ist, kann sich dazu gezwungen sehen, den eigenen Sourcecode ebenfalls zu offenbaren. Liberalere Lizenzen wie die Apache- oder die BSD-Lizenz gestatten es dagegen, auch proprietäre Closed-Source-Produkte als Derivate zu erstellen.

In der Regel finden sich in jeder modernen Software zahlreiche Einzelkomponenten mit divergierenden Lizenzen, die unterschiedliche Nutzungsvarianten erlauben oder verbieten.