Die Vorzüge der Open-Source-Philosophie sind unbestritten, wenn es darum geht, Code zu schreiben beziehungsweise Software zu produzieren. Viele essenzielle Softwarepakete der modernen Computertechnik - vom Linux-Betriebssystem bis hin zu MySQL - wurden in offenem Austausch gemeinschaftlich entwickelt.

Dennoch ist die Open-Source-Kultur nicht frei von Makeln. Wir werfen einen Blick auf sieben Schattenseiten der Quelloffenheit, angesichts derer sich Entwickler zweimal überlegen sollten, ob sie sich an Open-Source-Projekten beteiligen. Diese betreffen allerdings weniger die Philosophie selbst, sondern vielmehr die Alltagsrealität.

1. Open Source funktioniert nicht mit der Cloud

Viele aktuelle Open-Source-Lizenzen wurden vor der Einführung der Cloud entwickelt, als die Nutzer noch per Download auf die Software zugriffen und sie auf ihren Desktops ausführten. Seitdem haben Cloud-Unternehmen Wege gefunden, sich den Open-Source-Ethos zunutze zu machen und gleichzeitig ihre Code-Änderungen proprietär zu halten.

Es gibt Dutzende von Beispielen für Cloud-Anbieter, die spezielle Versionen von Open-Source-Projekten erstellen, um sie in der Cloud weiterzuverkaufen. Ein öffentlichkeitswirksames Zerwürfnis gab es in diesem Bereich etwa zwischen AWS und den Entwicklern von Elasticsearch. Nachdem sich beide Seiten nicht einigen konnten, trennten sie sich - die Folge waren zwei Versionen der Elasticsearch-Codebasis.

Einige Open-Source-Befürworter wehren sich gegen die Vereinnahmung durch die Cloud - etwa mit strengeren Lizenzen oder Änderungen wie der Commons-Klausel. Das könnte für die Zukunft Verbesserungen bringen, wird aber nicht dagegen helfen, dass Legacy-Systeme mit den ursprünglichen Lizenzen ausgeliefert werden.

2. Diversity-Probleme

In Open-Source-Kreisen legt man viel Wert auf Community. Das bedeutet allerdings nicht, dass die Open-Source-Kultur eine Art Shangri-La ist. Open-Source-Entwickler können mitunter "edgy" sein - das Spektrum reicht dabei von schroff und zerstreut über rechthaberisch bis hin zu bösartig.

Darüber hinaus hat Open Source bekanntermaßen ein Diversity-Problem. Strukturelle Ungleichheit mag weniger sichtbar sein, wenn Einzelpersonen in relativer Anonymität zu Open-Source-Projekten beitragen und nur über E-Mails oder Bulletin Boards kommunizieren. Diese Anonymität kann jedoch auch dazu führen, dass sich Einzelne abkapseln - was dem gemeinschaftlichen, inklusiven Prozess widerstrebt.

3. Community braucht Zeit

Viele Unternehmen geben Open-Source-Versionen ihrer Produkte als "Community Edition" heraus. Das ist ein großartiges Marketing-instrument und auch eine gute Möglichkeit, Ideen und manchmal auch Code zur Verbesserung von Produkten zu sammeln.

Der Aufbau einer "echten", nachhaltigen Community rund um ein Projekt erfordert jedoch Zeit und Ressourcen. Wenn ein Benutzer und potenzieller Mitwirkender eine Frage an die Community stellt, erwartet er eine Antwort. Viele Beiträge werden im Sinne des Open-Source-Gedankens unentgeltlich geleistet, aber der Aufbau einer Gemeinschaft braucht trotzdem Zeit. Wenn es gut funktioniert, kann das Ergebnis eine wachsende Gemeinschaft sein, die großartigen Code hervorbringt. Um dahin zu gelangen ist jedoch jede Menge Arbeit nötig.

Eine Folge dieses Zielkonflikts: Größere Unternehmensprojekte neigen dazu, das Feld zu dominieren. Sie können es sich im Gegensatz zu kleineren Unternehmen leisten, das Community-Modell durch bezahlte Aufgaben zu finanzieren.

4. Mentoring als Seltenheit

Ähnlich verhält es sich, wenn es darum geht, Code zu teilen: Damit haben viele Entwickler kein Problem. Wenn es darum geht, anderen beim Lernen zu helfen, sieht es oft anders aus. Schließlich dauert es nur ein paar Minuten, jemanden Zugang zu einem Git Repositopry zu verschaffen - andere Entwickler und Mitwirkende nachhaltig zu unterstützen, stellt hingegen eine erhebliche Verpflichtung dar.

Das führt dazu, dass einige Open-Source-Projekte sogar Klauseln enthalten, die den Mitwirkenden ausdrücklich nicht garantieren, unterstützt zu werden oder Antworten auf ihre Fragen zu bekommen. Das kann dazu führen, dass sich die Beteiligung an einem quelloffenen Projekt wie ein Sprung ins kalte Wasser anfühlt. Getreu dem Motto: "Hier eine Billion Codezeilen und ein Problem, das es zu lösen gilt. Vielen Dank und viel Glück!"

5. Auch Idealisten brauchen Geld

Die meisten Open-Source-Entwickler sind Idealisten, denen es nicht um Ruhm und Reichtum geht. Dennoch müssen auch sie schlafen und essen. Die reale Welt weist diverse physische Beschränkungen auf, die mit dem Open-Source-Ethos nicht vereinbar sind. (Ressourcen-)Knappheit mag in der digitalen Welt ein völlig fremdes Konzept sein, für biologische Lebensformen ist sie allerdings ein sehr reales Problem.

Open Source eignet sich gut für kleine Stacks und Herzensprojekte, bei denen niemand erwartet, für seine Arbeit bezahlt zu werden. Im Fall von größeren Codebasen, die von hauptberuflichen Programmierern unterstützt werden, kann daraus hingegen eine unangenehme Angelegenheit erwachsen: Entscheiden sich zu viele Nutzer für die kostenlose Version, kann das gesamte Projekt zusammenbrechen.

6. Nichts ist wirklich kostenlos

Wenn Sie sich lange genug in der Open-Source-Szene aufhalten, werden Sie wahrscheinlich auf das Akronym TANSTAAFL stoßen, das für "There Ain't No Such Thing As a Free Lunch" steht.

Nachdem Benutzer Open-Source-Software heruntergeladen und benutzt haben, werden sie anfangen, ihre Grenzen zu entdecken. Manchmal muss der Code nur ein wenig verfeinert werden. Manchmal hat er aber auch gar nicht die richtigen Funktionen. Selbst wenn man mit dem kostenlosen Code 99 Prozent des Weges zum Ziel zurücklegt, kann das letzte Prozent eine echte Plackerei sein.

7. Open Source macht nicht immer Sinn

Ein Datenbankentwickler erzählte mir einmal, dass er nie wirklich daran gedacht hat, sein Projekt als Open Source anzubieten. Seine Kunden waren ein paar große Unternehmen mit riesigen Datenbeständen. Sie hatten das Budget und waren bereit, ihn für die Arbeit zu bezahlen. Wenn ein Kunde den Quellcode lesen wollte, war er mehr als bereit, ihn ihm zur Verfügung zu stellen. Aber er wollte sich nicht die Mühe machen, eine offizielle, quelloffene Version des Projekts abzuspalten.

Open-Source-Versionen sind gut für Code, der von einer breiten Schicht von Entwicklern verwendet wird, die gemeinsam an der Entwicklung des Codes arbeiten können. In manchen Fällen ist jedoch der Austausch von Geld eine einfachere und letztlich nachhaltigere Art, die Arbeit an Software zu organisieren. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.