© Yuri Arcurs, 123RF.com

Eine Firma, die auf freie Software setzt, sollte darauf achten, dass sich das Open-Source-Projekt in eine Richtung entwickelt, die dem Unternehmen nutzt. Dieser Artikel zeigt, wie kommerzielle Hersteller freie Communities steuern und beeinflussen können.

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.

Produkttypen und Ziele

Abbildung 1 zeigt schematisch die vier möglichen Typen. Das vereinfacht dargestellte Produkt enthält sowohl einen Closed-Source- als auch einen Open-Source-Anteil. Im ersten Teil finden sich Komponenten, die im vollständigen Besitz der Firma sind. Meist verwenden Entwickler diese in ihren Produkten, die sich im Idealfall dadurch von der Konkurrenz abheben.

Abbildung 1: Open oder Closed Source, Community-eigen oder im vollständigen Besitz der Entwicklerfirma? In modernen Softwarefirmen findet sich all das.

Das Unternehmen hat außerdem Closed-Source-Software von Dritten lizenziert, um das Produkt zu vervollständigen. Bei klassischen Softwarefirmen ist das Produkt damit abgeschlossen, doch bei Open-Source-Herstellern kommen offene Bestandteile hinzu: Der Single-Vendor-Open-Source-Anbieter hat vielleicht auch Closed-Source-Komponenten dabei, vor allem um sein Produkt von einer ebenfalls existierenden freien Community-Version zu differenzieren (Open-Core-Modell). Open-Source-Distributoren haben normalerweise keinerlei proprietären Code in ihren Produkten.

Ein Single-Vendor-Open-Source-Anbieter besitzt seine Software, macht sie aber trotzdem aus strategischen Gründen unter einer freien Lizenz der Welt zugänglich. Community Open Source dagegen ist im Besitz einer Entwicklergemeinschaft, nicht einer einzelnen Rechtsperson. Reine Closed-Source-Firmen erstellen keine freie Software, aber alle drei Firmentypen nutzen sie.

Closed-Source- und Single-Vendor-Hersteller bevorzugen liberale Lizenzen, weil sie so die proprietären Anteile ihres Code nicht gefährden oder offenlegen müssen. Distributoren dagegen nutzen alle Typen von freier Software, unabhängig von der Natur der Lizenz. Das gründet in der Tatsache, dass ihre Stärke im Wettbewerb nicht in der Software selbst liegt, sondern in ihrer (bewährten) Konfigurations- und Integrationsleistung.

Ein gutes Beispiel hierfür ist Jaspersoft [5], eine Open-Source-Firma, die unter anderem Software für Business-Intelligence-Produkte herstellt, zum Beispiel den Reportgenerator Jasper Server. In dessen Enterprise-Produkte integriert sie eigenen Closed-Source-Code. Der wiederum baut auf der Open Source Community Edition auf, die vollständig Jaspersoft gehört, aber auch freie Komponenten wie den relationalen Datenbank-Mapper Hibernate [9] integriert. Als Plattform darunter dient Jaspersoft sowohl Windows als auch Linux.

Es existieren drei typische strategische Ziele für den Einsatz freier Software:

• Minimieren der Entwicklungskosten
• Maximieren der Verbreitung
• Minimieren des Wettbewerbs

Community Open Source und lizenzierte Closed-Source-Produkte helfen die Entwicklungskosten im Griff zu behalten. Die Software als Open-Source-Projekt zu veröffentlichen und zu verbreiten lässt den Hersteller ein besseres Produkt schneller, günstiger und deutlich breiter auf den Markt bringen – was wohl die wesentliche Belohnung dafür ausmacht, dass eine Firma ihr geistiges Eigentum freigibt. Nebenbei erhält das Unternehmen im Idealfall so auch eine aktive self-supporting Community.

Abbildung 2: Bei den Kontrollpunkten und Steuermechanismen ist für die Hersteller von freier Software viel soziale Führung gefragt.

Gleichzeitig kann kein Hersteller, der den Mut zur GPL aufbringt, verhindern, dass die neu geschaffene Öffentlichkeit der Quelltexte auch den Wettbewerbern nützt. Deshalb achten sowohl Single-Vendor-Firmen als auch Distributoren penibel auf die Konkurrenz. Eine aktive Steuerung des neugeschaffenen Open-Source-Projekts wird notwendig.

Kontrollpunkte

Softwarehersteller nutzen eine ganze Reihe von Werkzeugen, um freie Projekte zu managen, von denen ihr Business-Erfolg abhängt. Kontrollpunkte sind dabei Hebel, die helfen, die eigenen Ziele zu erreichen, und die sich über rechtliche Schritte erzwingen lassen. Dem stehen Steuermechanismen gegenüber, die zwar demselben Ziel dienen, aber nicht erzwingbar sind, sondern über soziale Faktoren und entsprechendes Verhalten wirken.

Abbildung 2 stellt die oben genannten Ziele den Kontrollpunkten und Steuermechanismen gegenüber und zeigt, in welchen Firmentypen und Lizenzmodellen sie angebracht sind. Drei Kontrollpunkte garantieren einem Unternehmen signifikante Kontrolle über ein OSS-Projekt:

• Copyright: Während eine Firma einem Dritten Nutzungsrechte über eine Open-Source-Lizenz einräumen kann, mag sie das Eigentum des Copyrights für sich allein reservieren. Als Eigner kann sie so verhindern, dass Dritte die Software unter abweichenden Lizenzen verwenden.
• Marken: Logos, Slogans, Namen – darüber definieren sich viele Softwarepakete auf dem Markt. Faktisch kann der Besitzer einer Marke verhindern, dass Wettbewerber derart geschützte Produkte verwenden. Bei Open-Source-Software etwa lässt sich verhindern, dass Dritte mit der Marke werben. Der Hersteller kann verlangen, alle verwendeten Markenzeichen zu entfernen, was sich durchaus als kostspielige Aktion erweisen kann.
• Eigentum der Domain: Wer die Domain besitzt, auf der Entwickler und Kunden nach Informationen suchen, hat einen klaren Vorteil. Mit dieser Informationshoheit lassen sich Anwender benachrichtigen und ihre Wahrnehmung des Produkts beeinflussen. Marken helfen die Domains zu schützen und halten Wettbewerber davon ab, ähnlich oder gleich klingende Domains zu verwenden.

Überraschenderweise finden sich Patente nicht in der Liste der Kontrollpunkte. Vor Gericht dienen Patente häufig dazu, es anderen Firmen, meist Wettbewerbern, zu untersagen, eine bestimmte Software zu verwenden, weil diese die Rechte des Patentinhabers verletzt.

Abbildung 3: Markenrechte und Patente dienen kommerziellen Herstellern zur Eindämmung der Konkurrenz, meist setzen sie diese erst vor Gericht durch. In OSS-Firmen spielen Patente dagegen keine Rolle.

Patente eignen sich aber in der Regel nicht dazu, ein Open-Source-Projekt zu steuern. Vielmehr finden sich in zahlreichen freien Lizenzen mehr und mehr Klauseln, die Patente und Patentklagen zurückweisen.

So genannte Vergeltungsklauseln (Retaliation Clauses) entziehen dem Kläger dabei schlagartig alle Nutzungsrechte an der freien Software, was mit zunehmender Verbreitung freier Software in Unternehmen beträchtliche finanzielle Folgen mit sich bringen kann.

Copyright

Das Urheberrecht bietet Single-Vendor-Anbietern den besten Hebel, um den Wettbewerb zu minimieren. Zwar haben sie der ganzen Welt Nutzungsrechte an der Software eingeräumt, doch meist nehmen diese Hersteller zentrale Teile der Software, die sie als Vorsprung vor der Konkurrenz ansehen, davon aus und lizenzieren sie unter einer kommerziellen Lizenz. Das dient zum einen der Gewinnmaximierung, zum anderen dem Schutz vor den Wettbewerbern. Dabei gelten für Hersteller zwei gängige Regeln:

• Jeder Beitrag von Dritten zum Sourcecode erfordert zwingend einen Copyright-Transfer an den Hersteller. In der Praxis muss der Contributor ein Copyright Transfer Agreement (CTA) unterzeichnen, das nicht selten auch Patente und andere Rechtsfragen gleich mit abdeckt.
• Die gewählte Open-Source-Lizenz für das freie Projekt sollte aggressiv reziprok sein. Jede Software, die auf dem Projekt aufbaut, muss wiederum OSS sein, damit kein Mitbewerber die Software für eigene, proprietäre Produkte nutzen kann. Gleichwohl kann der Hersteller als Inhaber des Urheberrechts jederzeit eine identische Version unter einer für Closed Source geeigneten Lizenz veröffentlichen und so auch Kunden bedienen, die keine OSS-Produkte einsetzen können oder wollen.

Details der CTAs und die Wahl einer bestimmten Open-Source-Lizenz hängen von den Gegebenheiten der Softwarefirma ab. Meist verwenden diese die GPL, doch auch der Bestand an AGPL-Software wächst derzeit stark.

Closed-Source-Compagnies brauchen sich mit dieser Thematik naturgemäß nicht zu beschäftigen, aber auch Distributoren interessiert das wenig. Die Kontrolle über einzelne Komponenten spielt bei ihnen eine eher untergeordnete Rolle, sie tragen mit ihrer Arbeit einfach zur OSS-Community bei, ohne viel über Copyright nachdenken zu müssen.

Trademark und Domains schützen Produkte

Für Distributoren stehen vielmehr die Markenrechte im Vordergrund, die aber auch Single-Vendor-Firmen helfen können. Auch Closed-Source-Unternehmen nutzen sie, aber nicht in OSS-Projekten. In der Regel dienen eingetragene Markenzeichen dazu, den Wettbewerb im Zaum zu halten. Distributoren investieren viel in ihren “Brand”, weil der das wichtigste Unterscheidungsmerkmal zur Konkurrenz ausmacht.

Zwar bieten häufig Dienstleister Produkte rund um die Open-Source-Produkte aus den Distributionen an, doch Wettbewerber könnten diese nur dann nutzen, wenn sie zuerst die fremden Markenzeichen entfernen. Das wiederum kann der ursprüngliche Hersteller erschweren und so den Markteintritt der Konkurrenz verzögern.

Darüber hinaus stehen Kunden diesem Entfernen der wohlbekannten Symbole häufig skeptisch gegenüber, weil in ihren Augen jetzt nicht mehr der verlässliche, erfahrene Distributor hinter dem Produkt steht. Diesen Effekt suchen Hersteller meist noch mit intelligenten Zertifizierungsprogrammen zu verstärken, die den gefühlten Wert des Originals deutlich über den der Kopie heben. Single-Vendor-Firmen kennzeichnen ihre Produkte mittlerweile in sehr ähnlicher Weise und stärken ihre Position mit der Androhung von Klagen gegen Wettbewerber, die die Markenzeichen nicht entfernen.

Auch der dritte Kontrollpunkt, die Internetdomäne eines Open-Source-Projekts, spiegelt in der Regel das oder die Produkte der Firma dahinter wieder. Hier erreicht der Hersteller das Gros seiner existierenden und potenziellen Kunden. Ähnlich wie die eingetragenen Markenzeichen betrifft dies alle drei Typen von Firmen, aber nur Single-Vendor-Firmen und Distributoren nutzen es, um ihre Intellectual Property zu schützen.

Über ihren Internetauftritt bestimmen sie, welche Aspekte der Software Dritte kennenlernen und in welchem Maß. Im Idealfall spiegeln sich hier die Geschäftsziele wieder. Und Trademarks helfen, den Wettbewerber von ähnlichen Domainnamen fernzuhalten, was wiederum potenzielle Kunden eher zu den eigenen Produkten lenkt.

Steuermechanismen

Neben den Kontrollpunkten stehen einem Unternehmen drei wichtige Steuermechanismen zur Verfügung, mit denen es die Richtung eines Softwareprojekts beeinflussen kann:

• Soziale Führung: Die Leiter eines OSS-Projekts sind ein wichtiger Hebel. Das fängt bei der Lizenzwahl an, erstreckt sich über Projektkultur und Führungsstil bis hin zur Umsetzung von Releaseplänen, Featurelisten und Roadmaps.
• Entwicklungsprozess: Eine Firma, die einen Contributor eines Projekts einstellt, kann damit den Entwicklungsprozess signifikant beeinflussen. Die eigentliche Entwicklung muss dabei nicht öffentlich sein, Codebeiträge lassen sich verzögern und die Software nur in (un)regelmäßigen Snapshots veröffentlichen.
• Strategische Positionierung: Manche Marketingkanäle funktionieren besser als andere. Gerade Open-Source-Stiftungen bieten wichtige Marketing-Gelegenheiten.

Abbildung 4: Das Finetuning der Community erledigt der OSS-Hersteller am besten mit viel Gespür für die Entwicklergemeinde. Soziale Führung, die passende Strategie und die richtigen Entwickler helfen dabei.

Die soziale Führung der Community hat verschiedene Aspekte, je nach Firma und Entwicklungsweise lässt sie sich sehr unterschiedlich instrumentalisieren. Im Single-Vendor-Modell beschäftigt der Hersteller alle oder viele der wichtigsten Entwickler. Zumindest einige von ihnen können auch Führungsrollen in der Community einnehmen und so das Interesse freier Developer anstoßen oder nach dem Geschmack des Herstellers leiten.

Der Sun-Vize Mårten Mickos rechnet vor, dass nur ein kleiner Teil der Entwicklungskosten auf das Konto des eigentlichen Programmierens geht [11]. Mindestens genauso viel, nicht selten mehr Aufwand verursachen Qualitätssicherung und das Testen, also Arbeiten, bei denen die OSS-Community große Hilfestellung leisten kann.

Auch eine Firma, die Entwickler dafür bezahlt, ein Community-Projekt voranzubringen, kann davon profitieren und an Einfluss gewinnen. Indem die Entwickler darauf achten, dass die freie Variante mit den Produkten des Herstellers funktioniert, helfen auch sie Kosten sparen. Je einflussreicher die Entwickler sind, umso mehr sind sie auch in der Lage, das freie Projekt in die von der Firma gewünschte Richtung zu bewegen und durch Community-Code kostspielige Eigenentwicklungen unnötig zu machen.

Alter Adel

Der Einfluss eines Entwicklers wächst aber erst mit der Zeit. Ein wichtiger Erfolgsfaktor mag es sein, einer der Gründer gewesen zu sein. Nach zwanzig Jahren gilt etwa Linus Torvalds immer noch als oberster Schiedsrichter über den Linux-Kernel, seine Stimme hat Gewicht wie wenige andere. Bei weniger hierarchisch organisierten Projekten wie PostgreSQL oder Apache spielt dieser Faktor jedoch eine geringere Rolle.

Die Führungsfiguren in einem Projekt nutzen ihre Position, um eine bestimmte Kultur zu installieren, die im Idealfall Menschen anzieht und motiviert, manchmal aber auch abschreckt, und die sich für ihren Arbeitgeber nutzen lässt. Überraschenderweise ist diese Einflussnahme in der Community nicht verpönt, sondern meist allseitig als unvermeidbarer Interessenkonflikt verstanden.

Die Führungspersönlichkeit stellt sich in den Dienst des Projekts und erwirbt damit auch ein gewichtiges Mitspracherecht bei Entscheidungen, zum Beispiel über die Richtung der weiteren Entwicklung.Über sozial kompetente Leader erweitern Single-Vendor-Firmen und Distributoren auch ihren Kundenkreis.

Prominente Vertreter von Open-Source-Projekten (und gleichzeitig auch der Firma dahinter) stehen nicht selten im Licht der Öffentlichkeit und verfügen über einen guten Draht zu den Anwendern. Ihr Wort zählt und wenn sie die Enterprise-Produkte und deren Interoperabilität mit der freien Variante loben, erhalten sie meist viel Aufmerksamkeit. Quasi Huckepack landen so Informationen vom Hersteller mit gutem Leumund direkt bei den Kunden, egal ob via Mailingliste, Vortrag auf einer Konferenz oder über die Medien.

Der Entwicklungsprozess

Sowohl Single-Vendor-Firmen als auch Distributoren nutzen spezielle Entwicklungsprozesse, um die Konkurrenz auszusperren. Typischerweise findet viel Entwicklung hinter verschlossen Türen statt, sodass Wettbewerber nicht wissen, was für neue Features demnächst kommen – und so hoffentlich länger brauchen, um ihre Codebasis dahingehend anzupassen. Auch das Veröffentlichen von Snapshots anstelle einer vollständigen History oder verzögerte Sourcecode-Releases (erst nach den Binaries) dienen dazu, sich einen Zeitvorsprung vor Wettbewerbern zu erarbeiten.

In vielen Fällen wünschen Firmen nicht, dass die Konkurrenz einen Einblick in die aktuelle Entwicklung erhält. Greg Kroah-Hartman kritisiert beispielsweise in seinem viel diskutierten Blogeintrag [12] die Haltung der Entwickler von Hardwareherstellern, die binäre Kerneltreiber entwickeln, um Konkurrenten keine Firmengeheimnisse preiszugeben. Wie viele Stimmen aus der Community wirbt auch Hartmann für das Linux Kernel Driver Interface und Open-Source-Treiber. Doch offener Code würde allzu viele Rückschlüsse auf die Neuheiten der nächsten Hardwaregeneration geben und so technischen Vorsprung gefährden.

Abbildung 5: Gemeinsam stärker: Eine Stiftung erweist sich häufig als die richtige Partnerschaft für eine Firma, die mit Open-Source-Software Geld verdienen will. Die Foundation hilft dabei nicht nur vor Gericht.

Aber Community-Open-Source-Projekte lassen sich auch vollständig blockieren, wenn eine Firma alle wichtigen Entwickler anstellt und so verhindert, dass neues Personal (Anwender, Entwickler, Committer) in diesen Kreis vordringt. Bisher hat sich solches Verhalten jedoch meist als schädlich für das Projekt erwiesen, außer wenn der Hersteller entscheidende strategische Weichen richtig gestellt hat (siehe unten). Auf jeden Fall ist das Einstellen von Entwicklern aus Schlüsselpositionen von Open-Source-Projekten ein zentraler Faktor für Unternehmen, die einen erfolgreichen und dauerhaften Entwicklungsprozess etablieren wollen, der zu den Firmenzielen passt.

Die richtigen Strategien

Mit den richtigen Strategien lässt sich die Kundenbasis erweitern und gleichzeitig der Wettbewerb verringern. Doch weil Open-Source-Firmen mit der Community-Edition kein Geld verdienen, bedarf es einer anderen, erweiterten oder zusätzlichen Einnahmequelle. Als Beispiel kann da Actuate dienen, der Hersteller des Report-Designers BIRT [13]. Abseits des Eclipse-Projekts verdankt die Firma den Großteil ihrer Einnahmen einem kommerziellen Report-Generator.

Auch ist es eine gute Idee, Community-Open-Source-Projekte unter dem Dach einer etablierten Stiftung zu gründen. Die Stiftung steht für Glaubwürdigkeit und verleiht dem Projekt öffentliches Ansehen. Indem ein Closed-Source- oder Single-Vendor-Hersteller zwei oder drei Erweiterungen ebenfalls als freie Software freigibt, kann er sich die Unterstützung der Foundation sichern und diese als Marketingkanal benutzen.

Wenn die Stiftung erlaubt, kann die Firma auch das Projekt in Beschlag nehmen und die Konkurrenz der Community aussperren. Damit das funktioniert, bedarf es aber der Herrschaft über das Projekt, was wiederum durch das Einstellen aller oder zumindest einer Mehrheit der Core-Developer erfolgen kann. Derartiges Vorgehen liegt natürlich nur selten im Interesse der Foundation, die ihm normalerweise auch entgegenwirken wird. Die Apache Foundation beispielsweise erlaubt konkurrierende Projekte ausdrücklich und erwartet eine ausreichende Diversität unter den Kernentwicklern.

Einer Stiftung beizutreten kann eine Softwarefirma auch schützen, beispielsweise in Gerichtsverfahren. Gehört das Projekt zur Foundation, dann wird diese es und die Hersteller dahinter auch gegen Klagen und vergleichbare Angriffe schützen. Nicht zu verachten ist dabei auch die Wirkung in der Öffentlichkeit und das schlechte Licht, das solche Aktionen auf den Kläger werfen. Nicht selten schrecken da Konkurrenten zurück, wo sie gegen eine Firma hart vorgehen würden.

Fazit

Softwarehersteller, die über Open-Source-Projekte Gewinne erzielen möchten, verfolgen drei Ziele: Sie wollen Entwicklungskosten minimieren, mehr neue Kunden anwerben und die Konkurrenz durch freie Software verringern. Um dies zu erreichen, nutzen sie eine ganze Reihe von Einflussmöglichkeiten, teils mit rechtlichen Mitteln durchsetzbar, teilweise aber eher weiche soziale Steuermechanismen. Sozial kompetente Führungspersonen, Marken, Copyright und die richtigen Domains spielen eine große Rolle, Patente dagegen nicht.