Nicht mehr Open-Source

Daniel Westheide

Vor kurzem sorgte die Meldung für Unruhe, dass Hashicorp, die Firma hinter weit verbreiteten Produkten wie Vault und Terraform, von IBM übernommen wurde. Sorgen um die Konsequenzen sind verständlich, besonders, wenn man sich gerade aus der Abhängigkeit von IBM befreit hat.

Aber schon ein Jahr zuvor hat Hashicorps Wechsel von Open-Source-Lizenzen zur Business Source License (BSL) zu Unmut und Verunsicherung geführt, denn eine Produktivnutzung der Hashicorp-Produkte ist seitdem nur noch mit einer kommerziellen Lizenz erlaubt.

Dabei ist Hashicorp kein Einzelfall: In den letzten Jahren haben diverse Unternehmen, die jeweils maßgeblich hinter bestimmten Open-Source-Technologien stehen, zu restriktiveren Source-Available-Lizenzen gewechselt, sei es die schon erwähnte BSL oder die Server-side Public License (SSPL).

In der Regel handelt es sich dabei um solche Unternehmen, deren Open-Source-Produkte von Cloud-Anbietern wie Amazon Webservice oder Google Cloud Platform als Managed Service angeboten wurden, zu Lasten des eigenen SaaS-Geschäftsmodells. Prominente Beispiele sind Redis, MongoDB oder Elastic. Andere, wie etwa Lightbend mit Akka, haben schlicht nicht genug Umsatz mit ihrem Subscription-Modell gemacht und wollen deshalb den Kreis der Nutzenden, die zur Kasse gebeten werden, deutlich vergrößern.

Abwägungen bei Technologieentscheidungen

Wenn Open-Source-Technologien plötzlich nicht mehr Open-Source sind, ist der Aufruhr oft groß. Die Entscheidung für eine Open-Source-Technologie und gegen eine proprietäre Alternative deutet darauf hin, dass man sich von ersterer bestimmte Vorteile gegenüber der proprietären Lösung verspricht. Die Grundlage, auf der solche Technologieentscheidungen getroffen werden, ist immer auch eine Frage des Risiko-Managements.

Wie attraktiv eine Entscheidung für eine Technologie ist, bestimmt sich demnach durch:

• den Mehrwert, den die Technologie liefert, z.B. eine schnellere Entwicklungsgeschwindigkeit oder bessere Performance, mit jeweils betriebswirtschaftlich quantifizierbaren Auswirkungen
• den mit der Technologie verbundenen Kosten, z.B. Lizenzkosten, Betriebskosten, Einarbeitung und Training
• den Kosten eines potenziell eintretenden schädlichen Ereignisses, z.B. plötzlich erhöhte Lizenzkosten
• die Eintrittswahrscheinlichkeit des schädlichen Ereignisses

Grundsätzlich gilt es, einen für den individuellen Kontext vernünftigen Trade-off zu finden zwischen Entwicklungsgeschwindigkeit, Entwicklungskosten und Risiken bzw. Unsicherheit.

Sämtliches Risiko zu 100 Prozent auszuschließen, ist nicht nur illusorisch, sondern auch selten zielführend. Wenn man sich dazu entscheidet, eine bestimmte Technologie zu verwenden, die nicht in-house entwickelt wurde, dann sollte dies nicht auf reiner Intuition beruhen, sondern rational begründet sein: Der Mehrwert, den diese Technologie liefert, muss in einem vernünftigen Verhältnis nicht nur zu den in jedem Fall damit verbundenen Kosten stehen, sondern auch zum mit der Technologie verbundenen Risiko.

Risiken proprietärer Technologien

Was sind nun die Risiken, wenn man eine proprietäre, kommerzielle Technologie verwendet? Zum Einen besteht die Möglichkeit, dass der Anbieter den Preis in Zukunft beliebig erhöhen wird. Das kann so weit gehen, dass die Verwendung betriebswirtschaftlich nicht mehr sinnvoll ist.

Zum Anderen ist vorstellbar, dass die eingekaufte Komponente wider Erwarten nicht den Anforderungen genügt oder dass Fehler, deren Behebung für das eigene Projekt essenziell sind, nicht behoben werden.

Auch kann nicht ausgeschlossen werden, dass das Produkt — vielleicht sogar ohne lange Vorwarnzeit — eingestellt wird. Eine Variante davon, die ebenfalls denkbar ist, ist die, dass der Anbieter der Technologie seine On-Premise-Lösung einstellt und das Produkt nur noch als SaaS in einer nicht-europäischen Cloud anbietet. Auch das kann in manchen Fällen aus regulatorischen Gründen ein Problem sein.

Risiken bei Open-Source-Technologien

Einige der genannten Risiken können reduziert werden, wenn man Open-Source-Technologien verwendet.

So kann man etwa die Software selbst betreiben oder in der Regel zwischen verschiedenen Anbietern auswählen, welche diese als Managed Service anbieten. Das Risiko, dass ein On-Premise-Betrieb plötzlich nicht mehr möglich ist oder es zu exorbitanten Preissteigerungen kommt, ist also deutlich abgeschwächt.

Weiterhin ist es möglich, Fehler in der Software selbst zu beheben. Man ist nicht darauf angewiesen, dass der Anbieter die entsprechenden Fehler hoch priorisiert und zeitnah behebt.

Auch das Risiko, dass das Produkt eingestellt wird, ist in der Form bei Open-Source-Technologien nicht gegeben. Im Zweifel kann man das Open-Source-Produkt selbst weiter pflegen, wenn sich nicht ohnehin eine Community findet, die das Projekt übernimmt. Ein Beispiel dafür ist das Play Framework, welches von Lightbend aufgegeben wurde, nun aber, gesponsert von einigen Unternehmen, von der bestehenden Community weiter entwickelt wird.

In erster Linie reduziert man durch die Verwendung von Open-Source-Technologien also die Eintrittswahrscheinlichkeit von schädlichen Ereignissen: Es ist unwahrscheinlicher, dass eine Open-Source-Technologie unerwartet zu hohen Kosten führt als es bei einer proprietären, kommerziellen Technologie der Fall ist. Gleiches gilt für die Wahrscheinlichkeit dass Fehler nicht behoben werden und für die Wahrscheinlichkeit, dass das Produkt eingestellt wird.

Nichtsdestotrotz kann aus Open Source auch Source Available werden, wenn die Technologie in erster Linie von einem Unternehmen entwickelt wird, welches langfristig versucht, mit dieser Technologie Gewinn zu machen. Die Risiken, die für proprietäre, kommerzielle Technologien gelten, lassen sich durch das Setzen auf Open Source also nicht vollständig eliminieren.

Der Segen der Optionalität

Wie also kann man sich gegen die genannten Risiken wappnen? Die Lösung besteht darin sich Optionen zu beschaffen. Wer keine Optionen hat, ist fragil, also besonders anfällig für Veränderungen in der Umgebung [1]: Taleb, 2012.

In seinem Buch Antifragile beschreibt Nassim Nicholas Taleb Optionen als Ersatz für Wissen. So kann etwa das Wissen fehlen, ob eine Technologie, die man nutzen möchte, in Zukunft noch Open-Source verfügbar sein wird.

Eine Option ist das Recht, aber nicht die Pflicht, in Zukunft etwas Bestimmtes zu tun. Taleb beschreibt Optionen mit der einfachen Formel Asymmetrie + Rationalität. Asymmetrie bedeutet, dass die Kosten der Option, wenn sie nicht ausgeübt wird, sich in Grenzen halten, bei Ausüben der Option aber die Vorteile immens sind. Die besten Optionen sind kostenlos. Die meisten Optionen in Softwareprojekten sind allerdings mit Kosten verbunden.

Will man sich bei Technologieentscheidungen Optionen schaffen, stehen einige klassische Werkzeuge der Software-Architektur zur Verfügung: Modularität und Abstraktionen mit robusten Schnittstellen. Technologien, die mit einem gewissen Risiko behaftet sind, sollten möglichst vom Rest des Systems isoliert werden, so dass es möglich ist, die Technologie schnell und günstig durch eine andere zu ersetzen.

Hat man sich beispielsweise entschieden, Redis zu verwenden, weil im Projekt ein Key-Value-Store benötigt wird, würde man eine Abstraktion für Key-Value-Stores einführen, hinter der der Redis-Client versteckt wird. Damit erwirbt man das Recht, aber nicht die Pflicht, von Redis zu einem anderen Key-Value-Store zu wechseln. Idealerweise entwickelt man bereits vorab einen Backup-Plan. Im konkreten Beispiel könnte er darin bestehen, im Notfall Redis durch Memcached zu ersetzen. Die Kosten dieser Option bestehen zum einen in der Umsetzung der Abstraktion. Zum anderen muss man in der Regel auf einige Features des abstrahierten Produkts verzichten. Das kann sich zum Beispiel negativ auf die Entwicklungsgeschwindigkeit auswirken. Auch sollte die durch eine Abstraktionsschicht erhöhte Komplexität des Systems beachtet werden. Diese kann die Wartbarkeit des Systems verschlechtern und zu längeren Einarbeitungszeiten neuer Teammitglieder führen. Die Kosten der Option setzen sich also aus einmaligen und laufenden Kosten zusammen, deren Summe von der erwarteten Lebenszeit des entwickelten Produkts abhängt. Gleichzeitig reduziert sich aber auch das Ausmaß des Schadens, gegen den man mit der Option eine Versicherung abschließt: Sollte die Technologie nicht mehr Open-Source verfügbar sein, kann sie schnell und kostengünstig gegen eine Alternative ausgetauscht werden.

Optionserwerb als Versicherung

Ob es sich lohnt, eine Option zu erwerben, kann nicht allgemeingültig gesagt werden. Ist das oberste Ziel, auf das man optimieren will, etwa die Entwicklungsgeschwindigkeit? Dann kann es sein, dass man möglichst viele Features der konkreten Technologie, für die man sich entschieden hat, auch nutzen will, anstatt sie durch eine Abstraktion unzugänglich zu machen. Hier gilt es den Mehrwert, der durch die schnellere Entwicklungsgeschwindigkeit entsteht, zu quantifizieren. Dieser sollte dann den Kosten der Option, der Eintrittswahrscheinlichkeit und dem Ausmaß des Schadens gegenübergestellt werden.

Nach [2]: Reinertsen (1997) und [3] : Hohpe (2019) sind die Kosten des Risikos die durch die Eintrittswahrscheinlichkeit gewichteten Kosten des Schadens. Taleb (2012) betont die Asymmetrie und Nichtlinearität. So entscheide man nicht aufgrund von Wahrscheinlichkeit, sondern aufgrund von Fragilität — wenn das Ausmaß des Schadens schlimm genug ist, möchte man sich immer dagegen absichern.

Wenn der potenzielle Nutzen einer Option jedoch im Verhältnis zu den Kosten zu gering ist, wenn also keine Asymmetrie zu den eigenen Gunsten vorliegt, handelt es sich nicht um eine gute Option, sondern um einen klassischen Fall von Überversicherung.

Risiken und Kosten rational abwägen

Wie schon beschrieben, kann durch die Verwendung von Open-Source-Technologien häufig die Eintrittswahrscheinlichkeit gewisser Risiken reduziert werden. Aber ist eine Open-Source-Technologie tatsächlich immer die beste Wahl?

Auch bei proprietären, kommerziellen Technologien hängt die Eintrittswahrscheinlichkeit der beschriebenen Risiken von unterschiedlichen Faktoren ab. Hat der Anbieter mit dem Produkt eine Monopolstellung, oder gibt es mehrere ähnliche Produkte, die eine ernsthafte Konkurrenz darstellen? Wie hoch sind die Umstellungskosten? Ist es sehr aufwändig und teuer, von diesem Produkt zu einer Alternative zu wechseln? Wenn die Umstellungskosten hoch sind oder es eine Monopolstellung gibt, ist es wahrscheinlicher, dass der Anbieter die Preise oder Vertragsbedingungen beliebig diktieren wird.

Auch die Wahrscheinlichkeit, dass ein Produkt eingestellt wird, lässt sich zwar nicht exakt berechnen. Vergleicht man zwei vergleichbare Produkte unterschiedlicher Anbieter, lassen sie sich jedoch manchmal in eine Rangordnung bringen. Hat der Anbieter eine Vorgeschichte, was das Einstellen von Produkten angeht? In diesem Fall ist mit einer höheren Wahrscheinlichkeit zu rechnen als bei einem Anbieter, der über viele Jahre noch nie ein Produkt eingestellt hat.

Open-Source-Technologien wiederum unterscheiden sich ebenfalls hinsichtlich ihres Risikoprofils. Steht hinter der Technologie nur ein einzelnes Unternehmen, oder wird es von einer etablierten Non-Profit-Organisation wie der Apache Software Foundation, der Eclipse Foundation oder der Linux Foundation verwaltet? Gibt es eine große, robuste und aktive Community? Ein Beispiel für eine Technologie, die von einem einzigen Unternehmen entwickelt wurde, das auch kein Interesse am Aufbau einer Community hatte, war MongoDB. Hier wurde vor einigen Jahren der Wechsel von einer Open-Source-Lizenz zur SSPL vollzogen, und die Wahrscheinlichkeit, dass es zu diesem Schritt kam, war relativ hoch.

Und schließlich lässt sich auch die Entscheidung für eine Open-Source-Technologie bereits als Schaffen von Optionen betrachten. So schafft man damit die Option, Fehler selbst zu beheben oder das Produkt selbst weiter zu entwickeln, aber auch, selbst den Betrieb zu übernehmen. Hier ist es jedoch essenziell sich ehrlich zu machen: Wie realistisch ist es, dass man diese Option tatsächlich ausüben kann und was sind die Kosten?

Die Tatsache, dass von MongoDB kein Fork entstanden ist, ist etwa darauf zurückzuführen, dass es kaum Personen außerhalb von MongoDB, Inc. gibt, die in der Lage wären, diese Datenbank weiterzuentwickeln. Man muss ich also die Frage stellen, ob man im eigenen Unternehmen die Kompetenz und den Willen hat, die Kosten auf sich zu nehmen, Fehler selbst zu beheben oder ein Open-Source-Projekt gar eigenständig weiterzuführen.

Auch für den Betrieb vieler Open-Source-Technologien ist oft sehr viel Know-how notwendig, das teuer eingekauft werden oder durch Weiterbildung und Erfahrungsaufbau entstehen muss. Oft ist es betriebswirtschaftlich keine sinnvolle Option im Vergleich zu einem SaaS-Modell. Ob der Wechsel eines Open-Source-Produkts zur BSL oder SSPL also tatsächlich für zu einem anderen Ergebnis bei der Bewertung von Kosten und Risiken führt, ist alles andere als sicher. Wägt man Kosten und Risiken rational ab, kann es durchaus sein, dass die kommerzielle, proprietäre Alternative die sinnvollere Wahl ist.

Wenn aus Open Source Source Available wird

Nehmen wir an, es wurde in einem Projekt sorgfältig abgewogen und die rationale Entscheidung getroffen, eine bestimmte Open-Source-Technologie zu verwenden und das Risiko in Kauf zu nehmen, dass diese Technologie eines Tages nur noch unter einer Source-Available-Lizenz kommerziell verfügbar ist. Manche Open-Source-Technologien haben sich im Laufe der Jahre als De-Facto-Standards ohne nennenswerte Konkurrenz etabliert, so dass manchmal die Entscheidungsfreiheit begrenzt ist. Ein gutes Beispiel dafür ist Vault, Hashicorps Secrets-Management-Lösung.

Nun ist der Fall eingetreten, dass die Technologie nur noch kommerziell verfügbar ist und nicht mehr unter einer Open-Source-Lizenz steht. Das ist etwa mit Vault im letzten Jahr passiert.

In der Regel entstehen, wenn ein Unternehmen seine Open-Source-Produkte unter eine restriktivere Lizenz stellt, schnell ein oder mehrere Forks. Auch dies ist mit den zwei verbreiteten Hashicorp-Produkten passiert: So gibt es seit dem von Hashicorp vollzogenen Lizenzwechsel mit OpenTofu und OpenBao jeweils einen Fork von Terraform und Vault — beide unter der Schirmherrschaft der Linux Foundation.

Solche Forks basieren auf der letzten noch unter der alten Open-Source-Lizenz stehenden Version des Produkts. Die nahe liegende Reaktion ist also, auf einen der entstandenen Forks zu migrieren. Aber ist das auch immer die richtige Antwort? Und wenn ja, für welchen Fork entscheidet man sich, falls es mehrere gibt? Zunächst einmal gilt es nicht in Panik zu verfallen. Auch wenn man die Zukunft nicht voraussagen kann, sollten man, wie bei allen Architekturentscheidungen, nicht aus dem Bauch heraus entscheiden, sondern möglichst viele Informationen sammeln, auf deren Grundlage eine rationale Entscheidung getroffen werden kann.

Was sind die Konsequenzen?

In vielen Fällen ändert sich für Unternehmen und Projekte, welche die betroffene Technologie verwenden, unmittelbar nichts. Die Konsequenzen hängen von zwei Faktoren ab:

1. der gewählten Source-Available-Lizenz des Herstellers
2. die Art und Weise der bisherigen Nutzung der Technologie

Eine Übersicht über verbreitete Source-Available-Lizenzen, ihre Eigenschaften und bekannte Vertreter findet sich in Tabelle 1.

Die meisten solchen Lizenzwechsel, die in den letzten Jahren für Unruhe gesorgt haben, richteten sich fast ausschließlich gegen Cloud Provider, die das jeweilige Produkt selbst als Managed Service angeboten haben. In diesen Fällen steht das Produkt in der Regel unter der Server-side Public License (SSPL) oder einer vergleichbaren Lizenz zur Verfügung. Diese Lizenzen erreichen ihr Ziel auf einem von zwei Wegen:

• Sie verbieten es allen Unternehmen außer dem, welches die Technologie entwickelt hat, diese als Managed Service anzubieten
• Sie machen es anderen Unternehmen so unattraktiv, die Technologie als Managed Service anzubieten, dass es faktisch einem Verbot gleich kommt

Ziel ist es, dass Nutzende Redis, Elasticsearch oder MongoDB nicht bei AWS, Azure, GCP oder einem anderen Cloud-Anbieter buchen, sondern eine Subscription beim jeweiligen Hersteller kaufen, der das Produkt ebenfalls als Managed Service anbietet.

Falls die Technologie bislang in der Open-Source-Version selbst betrieben wurde, ändert sich zunächst nichts. Die neue Source-Available-Version darf auch weiterhin selbst betrieben werden — solange man sie nicht als Managed Service Parteien außerhalb des eigenen Unternehmens anbietet.

Hat man die Technologie bisher als Managed Service bei einem der Cloud-Anbieter verwendet, muss man hingegen einen Umzug zum Angebot des Herstellers einplanen. Wenn eine Datenmigration notwendig ist, ist dies durchaus mit einem gewissen Aufwand verbunden.

Falls man hingegen ohnehin schon das SaaS-Angebot des Herstellers verwendet hat, ändert sich, wie bei der selbst betriebenen Open-Source-Version, unmittelbar nichts. Allerdings ändert sich etwas an der Asymmetrie: Indem der Hersteller sämtliche alternativen Hosting-Angebote für seine Technologie ausgeschaltet hat, erhöhen sich die Umstellungskosten deutlich. Es ist nicht mehr möglich einfach zum Managed Service eines Cloud-Anbieters zu wechseln. Man hat nur noch die Wahl, zur selbst betriebenen Community-Version zu wechseln oder die Technologie komplett durch eine andere abzulösen. Der Hersteller sitzt nun also am längeren Hebel und könnte dies ausnutzen, um etwa Preiserhöhungen durchzusetzen, die vorher aufgrund der anderen Anbieter am Markt nicht akzeptiert worden wären.

Anders verhält es sich bei einem Wechsel des Anbieters zur Business Source License (BSL). Dieser betrifft alle Nutzenden, welche für die Technologie bisher keine kommerzielle Lizenz bezahlt haben, sondern die Technologie unter der nun nicht mehr verfügbaren Open-Source-Lizenz verwendet haben. Der Grund ist, dass die BSL generell keine Produktivnutzung der Software erlaubt. Das war etwa der Fall bei Hashicorps Lizenzwechsel für Vault, Terraform und ihre anderen Produkte. Auch Lightbends Actor-Framework Akka steht mittlerweile unter der BSL und erfordert für die produktive Nutzung eine kommerzielle Lizenz, die aber nach aktuellem Stand bei weniger als 25 Mio. Dollar Jahresumsatz kostenlos verfügbar ist.

Weitere Konsequenzen können sein, dass es schwieriger wird, eigene Beiträge einzubringen — unabhängig von der konkreten Source-Available-Lizenz. Einige der Hersteller, die zu einer Source-Available-Lizenz wechselten, zeigten sich gegenüber Beiträgen aus der Community weniger aufgeschlossen als früher, während andere versprachen, weiterhin aktiv mit der Community zusammen zu arbeiten.

Das Projekt selbst zu übernehmen, sollte es eingestellt werden, ist nun aufgrund der restriktiveren Lizenzen auch keine Option mehr.

Auch wenn kein unmittelbarer Handlungsbedarf besteht, ist es wichtig, zu beobachten, welche Forks entstehen und wie sich diese entwickeln. Entstehen mehrere Forks, unterscheiden sich diese meist in ihren Zielen, und die bisherige Community teilt sich in mehrere kleinere auf.

Wie bei anderen Open-Source-Projekten auch gilt für Forks, dass es eine große, robuste und aktive Community geben sollte, idealerweise auch die Möglichkeit, kommerziellen Support einzukaufen und die Schirmherrschaft einer der erwähnten Foundations. Bei welchem der Forks all dies zutrifft, lässt sich naturgemäß nicht unmittelbar nach der Entstehung der Forks feststellen. Es ist also unvermeidlich, lange genug abzuwarten um sich ein Urteil über die Forks und die dahinter stehenden Communities bilden zu können.

Risiken und Kosten von Forks

Durch den Wechsel zu einem Fork entstehen eigene Kosten und Risiken. So muss der eigene Anwendungscode in der Regel angepasst werden, wenn das Original durch den Fork ersetzt wird. Neben diesen einmaligen Kosten ist davon auszugehen, dass Fork und Original immer weiter auseinander driften. Das kann zum Einen zu weiteren Anpassungen im Code führen, aber auch im Laufe der Zeit zu immer höheren Umstellungskosten. In gewisser Weise ist der Wechsel zu einem Fork ab einem bestimmten Zeitpunkt eine Einbahnstraße.

Weiterhin zu beachten ist, dass etwa bei Datenbanken oft nicht die offiziellen Low-Level-Treiber des Herstellers verwendet werden, sondern High-Level-Client-Bibliotheken von Dritten, die unter der Haube die Low-Level-Treiber verwenden. Solche Client-Bibliotheken können schnell nicht mehr mit dem Fork des Projekts kompatibel sein, so dass man darauf angewiesen ist, dass auch diese Client-Bibliotheken geforkt werden — oder man diesen Fork gar selbst umsetzen und warten muss. Natürlich ist auch der umgekehrte Fall möglich: Wenn sich die Community in weiten Teilen vom Original abwendet und für einen Fork entscheidet, werden auch die High-Level-Client-Bibliotheken diesen Schritt machen. Dann kann die Nutzung des nun kommerziellen Originals plötzlich schwieriger und unattraktiver werden.

Schließlich ist darauf zu achten, ob ein Fork eine andere Open-Source-Lizenz verwendet als das ursprüngliche Open-Source-Projekt. Von bestimmten Open-Source-Lizenzen ist ein Wechsel zu bestimmten anderen Open-Source-Lizenzen möglich, die aber für manche Projekte und Unternehmen problematisch sein könnten. Das Risiko, dass ein Projekt zu einer anderen Open-Source-Lizenz wechselt, welche die Nutzung unmöglich macht, besteht nicht nur für Forks, sondern für alle Open-Source-Technologien, die man verwendet. Um dies überhaupt mitzubekommen, bietet es sich an, in die Build-Pipeline einen Lizenz-Checker zu integrieren. In der Java-Welt gibt es beispielsweise das License-Maven-Plugin.

To fork or not to fork?

Wenn der Fork oder die Forks der nun nur noch kommerziell verfügbaren Technologie lange genug existieren und es schon ein oder mehrere neue Releases gibt, steht irgendwann die Entscheidung an, ob man zu einem dieser Forks wechseln soll.

Manchmal kann die Entscheidung einfach sein. Ist etwa nahezu die ganze Community und das entsprechende Ökosystem um die Technologie herum zu einem bestimmten Fork migriert, so spricht wenig dafür, beim ursprünglichen Produkt zu verharren — wenn die Lizenz des Forks kein Problem darstellt. Ist die Entwicklung des oder der Forks nach einer gewissen Zeit wieder eingeschlafen? Dann liegt es nahe, nicht zu diesem zu wechseln, wie man auch sonst keine Open-Source-Technologien verwenden würde, hinter denen keine hinreichend große, robuste und aktive Community steht.

Um eine rationale Entscheidung zu ermöglichen, ist es notwendig, die Kosten und Risiken, die durch den Wechsel zu einem bestimmten Fork entstehen, denen der weiteren Nutzung der Original-Version gegenüber zu stellen. Einige der Kosten lassen sich gut schätzen, etwa die einmaligen Kosten für die Umstellung, oder etwaige anfallende Lizenzkosten bzw. Subscription-Gebühren für die SaaS-Nutzung des Anbieters der kommerziellen Technologie.

Die Eintrittswahrscheinlichkeit der oben beschriebenen Risiken hingegen lässt sich höchstens sehr grob schätzen. Wie wahrscheinlich ist es etwa, dass ein Fork so stark vom Original abweicht, dass die High-Level-Client-Bibliotheken, die es für das Original gab, nicht mehr damit kompatibel sind? Wie wahrscheinlich ist es, dass der Anbieter des Originals seine Subscription-Gebühren drastisch erhöht?

Genau deshalb ist es sinnvoll, die Zeit für sich arbeiten zu lassen. Ist genug Zeit vergangen, stehen deutlich mehr Informationen über die Forks und das Original zur Verfügung. Manche als Risiko identifizierte Ereignisse sind vielleicht eingetreten, oder es ist abzusehen, dass es mittlerweile sehr unwahrscheinlich ist, dass diese eintreten.

In der Zwischenzeit, während man darauf wartet, dass sich der Wissensstand vergrößert, lassen sich Optionen schaffen. So kann man Backup-Pläne erarbeiten, prototypisch den Wechsel zu einem Fork erproben und dort, wo es möglich ist, Abstraktionen einführen und die Nutzung der entsprechenden Technologie isolieren, wie weiter oben bereits erläutert.

Wenn ausreichend Informationen vorhanden sind, um die Lage zu bewerten, lassen sich so die Kosten eines Wechsels reduzieren. Unter Umständen sollte als dritte Option auch geprüft werden, ob die Kosten und Risiken eines Wechsels zu einer anderen Technologie günstiger ausfallen sowohl als der Verbleib beim Original als auch der Wechsel zu einem Fork.

Referenzen