Rug Pulls, Forks und Open-Source-Feudalismus

• Eine Einordnung, wie die Machtverhältnisse im Open-Source-Ökosystem zwischen Unternehmen, Entwickler:innen und Nutzer:innen funktionieren und welche Auswirkungen die Taktiken Rug Pull (Relizenzierung) und Fork haben, die diese Verhältnisse erschüttern
• Während große Cloud-Anbieter erheblichen Einfluss ausüben, können von einem einzelnen Unternehmen dominierte Projekte durch Relizenzierung Macht neu verteilen; als Reaktion darauf entstehen Forks
• Die Fallanalysen zu Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey und Puppet→OpenVox zeigen jeweils unterschiedliche Muster der Neuordnung von Communities und der Verschiebung von Mitwirkenden
• Die Einführung von CLAs, die Dominanz eines einzelnen Unternehmens und der Zeitpunkt einer Überführung an eine Stiftung werden als Warnsignale für ein Rug-Pull-Risiko genannt; als Gegenstrategie werden neutrale Governance und eine breitere Basis aus beitragenden Organisationen empfohlen
• Fazit: Relizenzierung kann ein Mittel zur Einhegung von Cloud-Anbietern sein, schwächt aber zugleich die Rechte der Mitwirkenden; die Möglichkeit eines Forks wirkt als hemmender Faktor auf Unternehmensentscheidungen

---

Machtstrukturen in Open Source sowie Rug Pulls und Forks

• Im Open-Source-Software-Ökosystem üben Großunternehmen, kleine und mittlere Unternehmen, Mitwirkende und Nutzer:innen jeweils Macht aus, um Einfluss auf die Ausrichtung der Software und die Erlösstruktur zu nehmen
• Insbesondere große Cloud-Anbieter verfügen über erhebliche Macht und neigen dazu, gegenüber kleineren Unternehmen oder Communities im Vorteil zu sein
• In dieser Situation kommt es zu Machtverschiebungen, wenn Entwicklungsfirmen oder projektbesitzende Unternehmen die Softwarelizenz ändern (Rug Pull) oder umgekehrt Communities bzw. andere Unternehmen einen Fork vorantreiben

Überblick über Machtverhältnisse und Taktiken

• In der Open-Source-Welt üben große Cloud-Anbieter die stärkste Kanal- und Distributionsmacht aus und schaffen damit eine Struktur, in der kleine Unternehmen, Mitwirkende und Nutzer:innen ausgebeutet werden
  • Ähnlich wie im Feudalismus durch die Kontrolle von Land umgehen Cloud-Anbieter Beiträge, indem sie Open-Source-Software als Service anbieten
  • Kleine Unternehmen leisten den Großteil der Entwicklungsarbeit, geraten aber durch die kostenlose Nutzung durch Cloud-Anbieter in eine benachteiligte Position
• Mit der Taktik des Rug Pulls begegnen kleine Unternehmen Cloud-Anbietern durch Relizenzierung der Software, was jedoch Mitwirkenden und Nutzer:innen größeren Schaden zufügen kann
  • Wenn Cloud-Anbieter Projekte als Service anbieten, ohne beizutragen, schwächt das die Macht kleiner Unternehmen
  • Die Relizenzierung bringt Nachteile für Nutzer:innen mit sich, doch über Forks lässt sich das Machtgleichgewicht neu austarieren
• Bei von einem einzelnen Unternehmen geführten Projekten ist das Rug-Pull-Risiko hoch; eine Bewertung der Reputation des Unternehmens ist nötig, kann aber durch Übernahmen oder Insolvenzen hinfällig werden
  • Unter Druck von Investor:innen kommt es zur Relizenzierung, um den Umsatz zu steigern, besonders häufig im Wettbewerb mit Cloud-Anbietern
  • Durch restriktivere Lizenzen soll die Monetarisierung durch Dritte erschwert und so Macht verlagert werden
• Durch Rug Pulls ausgelöste Forks sind eine aufständische Form kollektiven Handelns zur Wiederherstellung von Macht, tragen aber ein hohes Scheiterrisiko wegen Mangels an Personal und Ressourcen
  • Große Unternehmen oder Cloud-Anbieter können Forks mit ihren Ressourcen unterstützen, doch selbst populäre Forks sind nicht immer erfolgreich
  • Wie bei MongoDB oder Sentry gibt es Fälle ohne Fork; nach der Übernahme von Puppet durch Perforce führte die Schließung der Entwicklung zu dem Fork OpenVox

Vergleich wichtiger Fälle

Dawn Foster analysierte verschiedene Rug Pulls, Forks und deren Auswirkungen im Anschluss anhand von Daten. (Ein Teil der Ergebnisse wurde als Datensatz in einem Jupyter-Notebook veröffentlicht.)

• Elasticsearch → OpenSearch
  • Nach der SSPL-Relizenzierung durch Elastic im Jahr 2021 organisierte AWS den OpenSearch-Fork
  • Bei Elastic blieb der Anteil interner Mitwirkender vor und nach dem Fork weitgehend unverändert, während OpenSearch weiterhin ein Muster Amazon-dominierter Beiträge zeigt
  • Der Analyse zufolge war auch nach der Überführung an die Linux Foundation im Jahr 2024 kein sprunghafter Anstieg externer Beiträge zu beobachten
• Terraform → OpenTofu
  • Unmittelbar nach dem Wechsel auf die BSL durch HashiCorp im Jahr 2023 wurde OpenTofu unter dem Dach der Linux Foundation gestartet
  • Terraform blieb weiterhin von internen Beiträgen geprägt, während bei OpenTofu rasch neue Mitwirkende aus mehreren Unternehmen hinzukamen
  • Dieser Fall legt nahe, dass ein nutzergetriebener Fork + Start unter einer neutralen Stiftung für die Bildung einer aktiven Community vorteilhaft ist
• Redis → Valkey
  • Unmittelbar nach dem Wechsel von Redis auf SSPL im Jahr 2024 wechselte ein großer Teil der bisherigen externen Mitwirkenden zu Valkey
  • Redis war vor dem Fork ein Ausnahmefall mit hohem Anteil externer Beiträge; nach dem Fork fiel dieser Wert abrupt auf 0 externe Beiträge, während Valkey als Community mehrerer Unternehmen startete
• Puppet → OpenVox
  • Nach der Übernahme durch Perforce (2022) wurden Entwicklung und Releases geschlossen und die Release-Frequenz reduziert; als Reaktion darauf trieb die Community den OpenVox-Fork voran

Datenbeobachtungen und Metriken

• Nach einem Rug Pull ist häufig ein sprunghafter Anstieg der Zahl von GitHub-Forks zu beobachten; das wird als Proxy-Signal für Bestrebungen gedeutet, einen Hard Fork zu prüfen
  • Langfristig zeigt sich tendenziell, dass Original und Fork parallel weiterentwickelt werden, während bei relizenzierten Originalen eine sinkende Nutzung beobachtet wird
• Ein Start unter dem Dach einer Stiftung begünstigt in der Frühphase neuer Projekte die Gewinnung von Beiträgen, während eine spätere Überführung nur begrenzte Wirkung haben kann
  • Der Fall OpenSearch deutet darauf hin, dass eine Überführung allein keinen starken Anstieg externer Beiträge garantiert

Warnsignale und Leitlinien

• Die Verwendung von CLA (Contributor License Agreement) ist ein Signal dafür, dass Relizenzierungsrechte bei Unternehmen konzentriert werden und sich damit Machtungleichgewichte verstärken
  • Projekte auf Basis von DCO (Developers Certificate of Origin) weisen tendenziell ein geringeres Rug-Pull-Risiko auf
• Eine Prüfung der Governance ist notwendig; die Dominanz eines einzelnen Unternehmens und eine konzentrierte Führung sind Risikofaktoren
  • Projekte mit neutraler Stiftung, Führung durch mehrere Organisationen und breiter externer Beitragsbasis sind in Bezug auf Nachhaltigkeit im Vorteil
• Auch die Breite und Tiefe der Beitragsbasis ist ein zentrales Bewertungskriterium
  • Unternehmen sollten in Projekte, von denen sie abhängen, eigene Mitwirkende entsenden, um Einfluss und Nachhaltigkeit zugleich zu stärken
  • Die Metriken und Practitioner Guides von CHAOSS können zur Diagnose und Verbesserung der Projektgesundheit genutzt werden

Empfehlungen zu Community und Governance

• Die Förderung neutraler Governance-Strukturen und mehr externer Mitwirkender ist ein wirksames Mittel zur Eindämmung von Rug Pulls
  • Schon die Möglichkeit eines Forks erhöht die Kosten einer Relizenzierungsentscheidung für Unternehmen und wirkt damit abschreckend
• Auf die Frage von Hazel Weakly nach Schutzmechanismen verwies die Vortragende auf Valkey und OpenTofu als reale Erfolgsfälle, die ein Überdenken von Relizenzierungen ausgelöst hätten
  • Dirk Hohndel betonte, dass mehr externe Mitwirkende das Rug-Pull-Risiko erhöhen und damit auch das Managementrisiko bei Entscheidungen vergrößern

Fazit

• Mit dem wachsenden Einfluss großer Cloud-Anbieter nimmt das Open-Source-Ökosystem zunehmend eine feudalistische Struktur an
• Lizenzänderungen begrenzen zwar die Macht von Cloud-Anbietern, haben aber den Nebeneffekt, die Rechte der Community-Mitwirkenden zu schwächen
• Für Mitwirkende und Nutzer:innen gibt es jedoch mit dem Fork ein Mittel zum Gegenangriff; das ist eine besondere Stärke von Open Source im Unterschied zum Feudalismus
• Die reale Möglichkeit eines Forks beeinflusst künftige Unternehmensentscheidungen; angeregt durch die Erfolge von Valkey und OpenTofu haben einige Unternehmen Rug-Pull-Pläne wieder verworfen
• Letztlich sind Governance-Neutralität und aktive externe Mitwirkende der Schlüssel, um Rug Pulls zu verhindern und ein gesundes Ökosystem zu erhalten

Referenzmaterial

• Vortragsfolien: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Da Forks derzeit noch nicht wirklich einfach sind, wäre es schön, wenn es unter den Open-Source-Organisationen Stellen gäbe, die dabei helfen.

[GN⁺]

Hacker-News-Kommentare

• Bei Projekten mit CLA (Contributor License Agreement) kommt es nach Ansicht einiger häufiger zu einem rug pull (wenn die Arbeit von Beitragenden von wenigen privatisiert wird), während dieses Ungleichgewicht bei Projekten mit DCO (Developer Certificate of Origin) seltener sei. Wer eine CLA unterschreibt, räumt dem Projekt das Recht ein, den eigenen Beitragscode neu zu lizenzieren. Das heißt: Selbst wenn man zu einem GPL-Projekt unter GPL beiträgt, kann die Lizenz geändert werden. Bei einer bereits permissiven Lizenz hat eine CLA kaum Auswirkungen, bei Copyleft (z. B. GPL) wird es jedoch unfair, weil nur die Partei mit der unterzeichneten CLA exklusives Eigentum beanspruchen kann. Um rug pulls zu vermeiden, sei es besser, Copyleft-Lizenzen zu verwenden und das Unterzeichnen einer CLA zu vermeiden. Bei permissiven Lizenzen müsse man verstehen, dass rug pulls „Teil des Spiels“ sind
  • Auch GNU-Projekte verlangen CLAs, aber vermutlich nicht in der Absicht, einen rug pull durchzuführen
  • Es soll klargestellt werden, dass die Unterzeichnung einer CLA nicht automatisch alle Rechte zur Relizenzierung überträgt; das hängt von der jeweiligen CLA ab. Laut der Klausel in Canonicals CLA(Link) wird zum Beispiel zugesichert, dass mein Beitrag auch unter der bestehenden Lizenz verfügbar bleibt. Es ist wichtig, die CLA zu lesen und zu verstehen. In den meisten CLAs bleibt das Urheberrecht bei den Beitragenden, sodass man weiterhin mit dem eigenen Beitrag machen darf, was man möchte. Das Grundproblem ist, dass das Vertrauen in die Projektverantwortlichen zerbrechen kann. Eine CLA gibt den Verantwortlichen Kontrolle und erhöht damit das Risiko eines rug pull. Um auf einen rug pull zu reagieren, muss man praktisch einen Fork erstellen und selbst kollaborieren, um einen Nutzen daraus zu ziehen. Wenn zu einer Copyleft-Lizenz noch eine CLA hinzukommt (z. B. AGPL + CLA), kann das sogar schädlicher sein als eine permissive Lizenz + CLA. Die AGPL verpflichtet auch bei Bereitstellung als Service zur Offenlegung des Quellcodes, aber durch die CLA können die Verantwortlichen einen geschlossenen Service betreiben, ohne Verbesserungen offenzulegen. In Fällen wie Incus und LXD hat diese Kombination aus Lizenz und CLA tatsächlich zu Community-Spaltung und Einschränkungen beim Code-Sharing geführt(ausführlicher Fallbericht)
  • Das Phänomen eines rug pull existiere in Open Source nicht. GPL-Kopien existieren für immer
  • Bei permissiven Lizenzen sei ein rug pull zwar wahrscheinlicher, aber eine CLA übertrage nicht immer automatisch alle Rechte
  • Diese negative Debatte um den Begriff „rug pull“ in Open Source übermäßig puristisch zu führen, sei nicht gesund. Projekte müssen nachhaltig sein. In einer Situation, in der große Cloud-Anbieter die Infrastruktur monopolisieren, sei es sinnvoller, dass kleine Entwickler ihre Energie auf die Abschwächung solcher Großkonzern-Monopole verwenden, statt sich in Konflikten um Open-Source- oder CLA-basierte Projekte zu verausgaben
• Beitragende und Maintainer sind oft sogar schwächer als kleine Unternehmen. Dennoch gilt: Wenn die Lizenz liberal ist, kann man bei Unzufriedenheit forken und einen neuen Weg gehen. Die dynamischen Lizenzveränderungen zwischen Redis und Valkey seien interessant. Insgesamt habe die Entwickler-Community sich zuletzt zu sehr an Cloud-Services gewöhnt und zeige nicht mehr die frühere Bereitschaft, Betriebssysteme, Compiler oder Datenbanken neu zu forken oder zu implementieren. Oft wird übersehen, dass Cloud-Unternehmen wie AWS Projekten durch ihr Angebot als Service auch zu mehr Bekanntheit verholfen haben (z. B. die Popularität von ElasticSearch nach dem AWS-Angebot). Dass die Cloud zum Kernel, zu gcc oder zum jdk beiträgt, bringt auch kleineren Unternehmen indirekte Vorteile. Statt einfach nur große Cloud-Anbieter zu kritisieren, sollte man vielleicht das Geschäftsmodell selbst neu überdenken. Wenn man von Anfang an geschlossen startet, interessiert sich am Ende niemand dafür
• Wenn man Software nicht als Binärpaket bezieht, sondern direkt aus dem Quellcode baut, erhöht das die Reaktionsfähigkeit bei Ereignissen wie einem rug pull. Wer über vom Anbieter gelieferte Binärdateien oder Images installiert, hat es schwerer, auf einen Fork umzusteigen; die Build-Infrastruktur auf neue Quellen umzustellen, ist vergleichsweise einfach. Man kann nötige Änderungen oder Funktionen selbst einpflegen und ist dadurch weniger von fremder Wartung abhängig
  • Genau deshalb wird Guix geschätzt. Source-Builds sind dort Standard, und über Caching werden trotzdem Binärpakete bereitgestellt. Falls keine Binärdatei vorhanden ist, wird der Quellcode direkt reproduzierbar gebaut. Auch gepatchte Versionen lassen sich mit demselben Paketmanager einfach installieren, sodass keine separate Build-Infrastruktur nötig ist. In großen Deployment-Umgebungen ist ein Build-Server allerdings effizienter
  • Ich weiß nicht, warum es dafür Downvotes gibt, aber ich stimme zu. Source-Builds sind in der Regel nicht schwierig (siehe sqlite)
  • In der Praxis hängen die Einschränkungen tatsächlich von der Softwarelizenz ab. Es gibt auch kommerzielle Software, bei der der Quellcode bereitgestellt wird, man ihn laut Lizenz aber nicht frei bearbeiten darf. Beispiele sind kommerzielle Produkte auf Basis von Skriptsprachen oder Fälle im Unternehmens-Consulting, in denen Kundinnen und Kunden zwar den Quellcode erhalten, Kompilierrechte aber separat bezahlt werden müssen
• Nach dem rug pull bei Elasticsearch ist Amazon direkt zu einem beitragenden Open-Source-Fork (OpenSearch) übergegangen; das kann man trotz anderer ursprünglicher Absichten als gewissen Erfolg sehen. Dennoch bleibt die Instabilität von Projekten durch das Ungleichgewicht zwischen Beitragenden und Profiteuren großer Unternehmen ein wichtiges Thema
  • Software entsprechend der Lizenz zu nutzen, ist kein Problem. Wenn Entwickler oder Startups aber permissive Lizenzen verwenden, weil sie nur auf Verbreitung und Wachstum aus sind, und dann Probleme bekommen, sobald große Cloud-Anbieter einsteigen, ist das widersprüchlich. Man kann nicht beides haben
  • Elastic wollte am Ende mehr Lizenzerlöse, aber viele Nutzer wechselten zum Fork, wodurch das Vertrauen in Elastic sank. Der Wettbewerb zwischen OpenSearch und ElasticSearch könnte dem Ökosystem sogar nützen, aber inzwischen sind die beiden Produkte nicht mehr kompatibel, und Elastics Position ist geschwächt
  • Copyleft-Lizenzen wie AGPL/GPL verlangen erzwungene Code-Beiträge und können dadurch auch ohne proprietäre Lizenz einen Feedback-Loop schaffen
• Open-Source-Projekte lassen sich nicht allein durch eine Lizenzänderung leicht per rug pull umdrehen. Das grundlegendere Problem ist die Realität, dass wir nicht in einer utopischen Umgebung leben, in der jeder kostenlos arbeiten und trotzdem eine gute Lebensqualität haben kann. Ohne Maintainer ist die Halbwertszeit von Projekten zwangsläufig kurz, und ohne Sponsoring wird die Bewegung hin zu geschlosseneren Lizenzen eher zunehmen
  • Das erinnert an den Fall Mojang/Microsoft und die Bukkit-Community. Im Zuge der Einstellung eines Entwicklers wurde das Projekt heimlich aufgekauft, jahrelang arbeiteten Freiwillige unbezahlt weiter, und am Ende nutzte der Entwickler DMCA, um das Projekt abzuschalten. Mehr dazu: blog
  • Am Ende ist es ein Anreizproblem. Selbst wenn man Open-Source-Software selbst entwickelt, können Cloud-Anbieter sie leicht übernehmen und damit Geld verdienen. Dass FOSS (Fully Open Source Software) genau diese Bedeutung hat, ist bekannt, aber die Gesellschaft habe sich zu sehr an unbezahlte Arbeit gewöhnt. Deshalb wirken neue Modelle wie SSPL (Source-available licensing) zunehmend attraktiv. Dass AGPL wegen einer einzigen Klausel FOSS ist, SSPL aber nicht, wirkt eher wie begriffliche Verwirrung
• Ich verstehe, dass Nutzer über einen rug pull verärgert sind, aber auch Unternehmen, die ein Projekt federführend entwickeln und pflegen, stoßen finanziell an Grenzen und haben dann nur noch wenige Optionen. Ohne Erlösmodell kann eine Lizenzänderung unvermeidlich werden. Als Alternativen werden Crowdfunding, Reduzierung des Arbeitsaufwands, Merchandise-Verkäufe oder die Ankündigung genannt, das Projekt offen zu halten, falls keine zusätzlichen Mittel kommen. Verwandter Artikel
  • Der Kern des Ärgers ist, dass etwas erst als OSS veröffentlicht wurde, um Nutzer zu gewinnen, und dann plötzlich in eine geschlossenere Lizenz überführt wurde. Wäre es von Anfang an nicht OSS gewesen, gäbe es dieses Gefühl des Verrats nicht; problematisch ist, dass man zum Nutzeraufbau als OSS startet und später umschwenkt
  • Mongo, Elastic, Redis, Hashicorp und andere befanden sich zum Zeitpunkt ihres rug pull nicht in schwerer finanzieller Not. Bei Hashicorp könnte es sogar eine Strategie zur Steigerung des Übernahmewerts gewesen sein
• In letzter Zeit häufen sich Fälle, in denen man Governance-Boards oder stärker regulierte Betriebsmodelle vorschiebt, um Techniker zum freiwilligen Rückzug zu bewegen, Gegenstimmen zu unterdrücken und Projektberechtigungen zu entziehen. Unter dem Schlagwort „Sicherheit“ zieht eine orwellsche Atmosphäre in Communities ein
• Fast alle Open-Source-Nutzer sind Trittbrettfahrer. Wir nutzen Projekte frei, ohne etwas beizutragen. Open Source kann man als Geschenk ohne Gegenleistung oder als Kultur des Lernens am Beispiel fremder Hausaufgaben sehen. Wenn man der Welt etwas geben will, dann gern — aber ohne irgendeine Gegenleistung zu erwarten. Eine Lizenzänderung gleich als rug pull zu bezeichnen, ist ebenfalls ein voreingenommener Blick. Den Code haben wir schließlich bereits bekommen, und auch wenn eine Richtungsänderung bedauerlich ist, ist nichts auf der Welt von Dauer
  • Die Behauptung „Wir nutzen meistens nur, ohne etwas zurückzugeben“ ist nicht vollständig wahr. In vielen Projekten gab es reale Beiträge in Form von Code, Tests, Dokumentation, Marketing und Evangelisierung. Solche Projekte wurden nicht einfach zufällig still auf GitHub hochgeladen, sondern Unternehmen haben viel Geld investiert, aktiv Developer Evangelists beschäftigt und die Vorteile von Technologie und Lizenz kommuniziert, um den Nutzerkreis zu erweitern. In so einer Situation in großem Stil Code und Beiträge einzusammeln, dann plötzlich die Lizenz zu ändern und ein Versprechen zu brechen, auf das andere FOSS-Projekte bereits angewiesen sind — genau das ist die Kritik, die als rug pull bezeichnet wird. Wäre ein Projekt ohne gesondertes Marketing zufällig auf GitHub gelandet und organisch übernommen worden, würde man es wohl kaum als rug pull diskutieren. Solche Fälle sieht man aber fast nie
  • Es muss nicht zwangsläufig so laufen. Unternehmen oder kapitalkräftige Akteure können Open-Source-Projekten, von denen sie abhängen, finanziell und technisch helfen und so ihre Nachhaltigkeit stärken. Möglichkeiten sind etwa die Einrichtung eines Open Source Program Office, die Analyse aller eingesetzten Software und Abhängigkeiten, Zeitinvestitionen von Beitragenden und finanzielle Förderung sowie die Förderung einer solchen Kultur in der gesamten Branche
• Auch im Unternehmen, in dem ich derzeit arbeite, sorgt das Thema rug pull für Verunsicherung im Betrieb. Wir haben immer auf Supportverträge für Systeme bestanden, aber ähnliche Situationen gab es bei Chef, CentOS, VMWare, Broadcom und anderen. Obwohl wir bereit waren zu zahlen, kosten schon grundlegende Wartungsleistungen pro Jahr mehrere tausend bis zehntausend Dollar, und trotzdem fehlt das Vertrauen. Deshalb scheint es sinnvoller, lieber eine Stiftung zu unterstützen oder regelmäßig OSS-Maintainer direkt anzustellen. Früher wäre man solchen Vorschlägen zynisch begegnet, doch inzwischen finden sie immer mehr Zustimmung. Persönlich würde ich eher Entwickler von Proxmox oder qemu anstellen, als Geld an VMWare zu zahlen
  • Ich halte das für die richtige Idee. Es ist wichtig, sämtliche eingesetzte Software und Abhängigkeiten zu prüfen, durch Entwicklungszeit und finanzielle Beiträge Nachhaltigkeit zu sichern und diese Haltung auch in verwandten Branchen zu verbreiten
  • Interessanterweise haben die genannten Unternehmen Open-Source-Program-Offices eingerichtet, um stärker community-orientiert zu arbeiten; wird eine Organisation jedoch zu groß, ist eine gewisse Doppelgesichtigkeit zwischen Community und Unternehmensinteressen wohl der unvermeidliche Preis
• Forks sind nicht einfach; für ihren Erfolg braucht es Menschen und Ressourcen. Open Source funktioniert letztlich nur, wenn es viele Beitragende gibt. Wenn ein Fork stirbt, bedeutet das, dass es in diesem Projekt zu viele Trittbrettfahrer gab. Das größte Problem bei einem rug pull ist eigentlich, dass er faktisch irreführender Werbung gleichkommt. Erst gewinnt man Kundschaft mit Open Source, und sobald es einem selbst zum Nachteil gereicht, bricht man dieses Versprechen — das ist moralisch problematisch. Dass Beiträge irgendwann eingestellt werden, beunruhigt mich hingegen nicht. Niemand ist verpflichtet, für immer in einem Projekt zu bleiben, daher ist es ganz natürlich, wenn Einzelpersonen oder Unternehmen sich zurückziehen