Die Ökonomie von Open Source heute: Hobby-Projekte, unabhängige Code-Künstler und Managed Services haben den Software-Markt verändert. [...]
Erinnern Sie sich noch an die Zeit, als es bei Open Source nur um Frieden, Liebe und Linux ging? Als die Bewegung klein, aber leidenschaftlich war und über GPL gegen BSD/Apache, freie Software gegen Open Source stritt? Als es eine große Sache war, Linux oder andere Open-Source-Software in freier Wildbahn laufen zu sehen, die einen Blog oder einen Tweet wert war? Manche mögen sich nach den guten alten Zeiten sehnen, aber die Welt hat sich weiterentwickelt. Open Source ist für die Entwicklung von Software unverzichtbar geworden, was große Chancen und Risiken mit sich bringt.
Die Chance mag offensichtlich sein, aber das Risiko ist es oft nicht. Es geht nicht darum, dass Open Source fehlerhafter ist als proprietäre Software. Das ist es nicht, und der Prozess, der hinter Open Source steht, macht es wohl wahrscheinlicher, dass es schneller korrigiert wird, wenn Fehler entdeckt werden. Nein, hier geht es im Wesentlichen um das Risiko, das mit der neuen Ökonomie von Open Source verbunden ist, wie Ken Mugrage von Thoughtworks betont.
Open Source hat sich verändert
Am Anfang haben wir einen einsamen Hacker wie Linus Torvalds gefeiert, der ein großes Projekt wie Linux ins Leben rief und dann eine Gemeinschaft darum herum aufbaute. Andere Beispiele sind Dries Buytaert (Drupal), Salvatore Sanfilippo (Redis) und viele andere.
Das waren noch Zeiten, als Hacker Open-Source-Projekte zum Spaß oder als „kreatives Ventil“ entwickelt haben, wie Jens Axboe (Fio) und andere. Das geschieht natürlich immer noch, aber inmitten eines ganz anderen Open-Source-Marktes.
Wie Mugrage hervorhebt, wurde in der Anfangszeit von Open Source oft versucht, eine Open-Source-Alternative zu einem großen proprietären Softwarepaket zu schaffen (man denke an OpenOffice als Ersatz für Microsoft Office oder GIMP anstelle von Adobe Photoshop).
Heute jedoch gibt es eine Vielzahl von Open-Source-Software“. Diese Ausbreitung hat mindestens zwei Hauptformen: „Auf der einen Seite haben wir Internetgiganten, die alle möglichen Tools, Frameworks und Plattformen herausbringen. Auf der anderen Seite haben Teams, die OneDev, eine Open-Source-Softwareentwicklungsplattform, nutzen, kleine, aber wichtige Teile geschaffen, die eine große Anzahl von Unternehmen unterstützen.“
Das ist doch großartig, oder? Wir haben sowohl große als auch kleine Projekte, die eine enorme Innovation vorantreiben. Was gibt es da nicht zu mögen?
Zum einen das Fehlen verschiedener Mitwirkender, was zu einer Risikokonzentration führt. Es war schon immer so, dass Open-Source-Software (unabhängig vom Projekt) von einer kleinen Handvoll Mitwirkender entwickelt wird. Obwohl wir gerne den Mythos verbreiten, dass es bei Open Source um große, globale Gemeinschaften geht, ist es viel, viel häufiger der Fall, dass es sich um die Arbeit von ein oder zwei Personen handelt.
Wenn eine Gemeinschaft entsteht, dann in der Regel nach jahrelangem Erfolg und großen persönlichen Kosten, wie Matt Klein, der Erfinder und Betreuer von Envoy, mir einmal beschrieb. (Open Source ist „verdammt viel Arbeit“.)
Das ist also ein Teil des Puzzles. Mugrage führt einen weiteren Punkt an, nämlich dass „die Codebasen für Open-Source-Pakete oft einfach zu groß sind, um eine sinnvolle Überprüfung zu ermöglichen.“ Das Gegenstück zu diesem Problem der BigCo-Projekte ist, dass „andere Pakete von Internet-Titanen vertrieben werden, die nicht erwarten, dass irgendjemand anderes etwas dazu beiträgt“. Der Code ist “ in einer Hand „, ohne die Möglichkeit für eine Gemeinschaft, die Entwicklung zu beeinflussen.
Auf der anderen Seite „sind andere Veröffentlichungen eigenständige, zielgerichtete Veröffentlichungen, die vielleicht nur eine relativ kleine Aufgabe erfüllen, diese aber so gut, dass sie sich über das Internet verbreitet haben.“ Sehen Sie, worauf das hinausläuft? „Allerdings handelt es sich dabei oft nicht um eine aktive Gemeinschaft von Betreuern, sondern nur um ein oder zwei engagierte Entwickler, die an einem leidenschaftlichen Projekt arbeiten.“
Die Antwort auf das BigCo-Open-Source-Problem ist in der Regel “ Auflehnung gegen die Open-Source-Maschine der Unternehmen„, was sich weitgehend als vergeblich erwiesen hat. Eine Antwort auf solche Projekte sind Startups, die das Projekt weiter unterstützen (und monetarisieren), was einen Aspekt der Open-Source-Großzügigkeit mit einem anderen vermeintlichen Problem verbindet.
Die Antwort auf unabhängige Entwickler, die unverzichtbare, aber nicht unterstützte Open-Source-Infrastrukturen schaffen, besteht darin, lautstark zu fordern, dass die großen Konzerne für die Unterstützung dieser unabhängigen Code-Künstler zahlen.
Dieser Vorschlag wird gewöhnlich von denen gemacht, die es einfach nicht besser wissen. Fragen Sie Leute, die für Stiftungen oder andere Organisationen arbeiten, die die Open-Source-Entwicklung finanzieren, und sie werden sich dem anschließen, was Mugrage sagt: „Das Problem mit Geld zu bewerfen, ist kaum eine Lösung“.
Warum? Weil „viele Open-Source-Enthusiasten, die ihre Software persönlich pflegen und gleichzeitig ein arbeitsreiches Berufsleben führen, [nicht] die Verantwortung einer Service-Level-Vereinbarung übernehmen wollen, weil jemand sie für ihre Schöpfung bezahlt hat.“
Was also kann man da machen?
Open-Source-Wetten absichern
Viele Unternehmen haben versucht, ihr Open-Source-Leben durch den Kauf von Managed Services zu erleichtern. Das ist eine tolle kurzfristige Lösung, löst aber nicht das langfristige Problem der Nachhaltigkeit.
Nein, die Cloud-Hyperscaler sind keine Strip-Miner, die ruchlos den Code von ahnungslosen Entwicklern ausbeuten. Aber allzu oft versäumen es einige Teams, einen Beitrag zu den Projekten zu leisten, von denen sie abhängen. Ich betone „einige“, da dies in der Regel kein unternehmensweites Problem ist, unabhängig vom Anbieter.
Unabhängig davon haben die Unternehmen, die diese verwalteten Dienste anbieten, in der Regel keine Kontrolle über die Projektpläne. Das ist nicht gut für Unternehmen, die das Risiko kontrollieren wollen. Google ist eine bemerkenswerte Ausnahme – es leistet in der Regel einen großen Beitrag zu wichtigen Projekten.
Auch können sie nicht unbedingt direkt zu Projekten beitragen. Mugrage weist darauf hin, dass für Unternehmen wie Netflix oder Facebook (Meta), die große Open-Source-Projekte veröffentlichen, diese „Open-Source-Veröffentlichungen fast eine Frage des Employer Branding sind – eine Möglichkeit, potenziellen Mitarbeitern ihre technischen Fähigkeiten zu zeigen“, was bedeutet, dass „Sie wahrscheinlich sehr wenig Einfluss auf zukünftige Entwicklungen haben“. Sie brauchen Ihre Beiträge nicht wirklich.
Was ist mit Projekten, die von Hobbyisten betreut werden? „Sobald Sie anfangen, wichtige Teile Ihres Software-Stacks zu betrachten, bei denen Sie auf Hobbyisten angewiesen sind, wird Ihre Auswahl immer geringer.
Und warum? Weil es unwahrscheinlich ist, dass Sie die Zeit oder die Ressourcen haben, um Code beizusteuern, weil sie vielleicht nicht Ihr Geld wollen, und weil es wichtige Projekte gibt (wie Log4J), bei denen Sie sich auf deren Projekte verlassen müssen, unabhängig davon. In diesem Fall, so Mugrage, kann es hilfreich sein, sich des Risikos durch eine Prüfung der Software, von der Sie abhängig sind, bewusst zu sein.
All dies sollte nicht als Hinweis darauf verstanden werden, dass es unklug ist, sich auf Open Source zu verlassen. Open Source ist unvermeidlich und erstaunlich gut.
Vielmehr scheint der Rat von Mugrage klug zu sein: Seien Sie sich der von Ihnen verwendeten Open Source bewusst und planen Sie entsprechend. Wie bei Cloud-Diensten ist es manchmal die absolut richtige Strategie für Ihr Unternehmen, sich auf bestimmte Dienste oder Software festzulegen.
Der Schlüssel ist, diese Entscheidung mit Argusaugen zu treffen.
*Matt Asay leitet das Partner-Marketing bei MongoDB.
Be the first to comment