Photograph: Mykhailo Hnatiuk – shutterstock.com
Die Vorzüge der Open-Supply-Philosophie sind unbestritten, wenn es darum geht, Code zu schreiben beziehungsweise Software program 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-Supply-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-Supply-Projekten beteiligen. Diese betreffen allerdings weniger die Philosophie selbst, sondern vielmehr die Alltagsrealität.
Viele aktuelle Open-Supply-Lizenzen wurden vor der Einführung der Cloud entwickelt, als die Nutzer noch per Obtain auf die Software program zugriffen und sie auf ihren Desktops ausführten. Seitdem haben Cloud-Unternehmen Wege gefunden, sich den Open-Supply-Ethos zunutze zu machen und gleichzeitig ihre Code-Änderungen proprietär zu halten.
Es gibt Dutzende von Beispielen für Cloud-Anbieter, die particular Versionen von Open-Supply-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-Supply-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.
In Open-Supply-Kreisen legt man viel Wert auf Group. Das bedeutet allerdings nicht, dass die Open-Supply-Kultur eine Artwork Shangri-La ist. Open-Supply-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 Supply bekanntermaßen ein Variety-Drawback. Strukturelle Ungleichheit magazine weniger sichtbar sein, wenn Einzelpersonen in relative Anonymität zu Open-Supply-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.
Viele Unternehmen geben Open-Supply-Versionen ihrer Produkte als “Group Version” heraus. Das ist ein großartiges Advertising and marketing-instrument und auch eine gute Möglichkeit, Ideen und manchmal auch Code zur Verbesserung von Produkten zu sammeln.
Der Aufbau einer “echten”, nachhaltigen Group rund um ein Projekt erfordert jedoch Zeit und Ressourcen. Wenn ein Benutzer und potenzieller Mitwirkender eine Frage an die Group spellt, erwartet er eine Antwort. Viele Beiträge werden im Sinne des Open-Supply-Gedankens unentgeltlich geleistet, aber der Aufbau einer Gemeinschaft braucht trotzdem Zeit. Wenn es intestine 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 Group-Modell durch bezahlte Aufgaben zu finanzieren.
Ähnlich verhält es sich, wenn es darum geht, Code zu teilen: Damit haben viele Entwickler kein Drawback. 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-Supply-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 Drawback, das es zu lösen gilt. Vielen Dank und viel Glück!”
Die meisten Open-Supply-Entwickler sind Idealisten, denen es nicht um Ruhm und Reichtum geht. Dennoch müssen auch sie schlafen und essen. Die reale Welt weist numerous physische Beschränkungen auf, die mit dem Open-Supply-Ethos nicht vereinbar sind. (Ressourcen-)Knappheit magazine in der digitalen Welt ein völlig fremdes Konzept sein, für biologische Lebensformen ist sie allerdings ein sehr reales Drawback.
Open Supply eignet sich intestine 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 Model, kann das gesamte Projekt zusammenbrechen.
Wenn Sie sich lange genug in der Open-Supply-Szene aufhalten, werden Sie wahrscheinlich auf das Akronym TANSTAAFL stoßen, das für “There Ain’t No Such Factor As a Free Lunch” steht.
Nachdem Benutzer Open-Supply-Software program 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.
Ein Datenbankentwickler erzählte mir einmal, dass er nie wirklich daran gedacht hat, sein Projekt als Open Supply anzubieten. Seine Kunden de él waren ein paar große Unternehmen mit riesigen Datenbeständen. Sie hatten das Price range und waren bereit, ihn für die Arbeit zu bezahlen. Wenn ein Kunde den Quellcode lesen wollte, struggle er mehr als bereit, ihn ihm zur Verfügung zu stellen. Aber er wollte sich nicht die Mühe machen, eine officielle, quelloffene Model des Projekts abzuspalten.
Open-Supply-Versionen sind intestine 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 Artwork, die Arbeit an Software program zu organisieren. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.