Broadcoms CNCF-Spende: Reaktionen der Community und Vertrauen in Open Source

In der neuesten Folge von „Big Tech versucht es wiedergutzumachen" steht Broadcom erneut im Rampenlicht – nicht wegen Innovation, sondern wegen Schadensbegrenzung. Das Unternehmen kündigte kürzlich die Spende eines Kubernetes-Diagnosetools an die Cloud Native Computing Foundation (CNCF) an und stellte dies als Geste des guten Willens und des Engagements für Open Source dar. Klingt großartig, oder? Nicht für jeden.

Für viele in der Kubernetes- und Open-Source-Community fühlt sich dieser Schritt nicht wie Großzügigkeit an. Er fühlt sich wie ein Taschenspielertrick an.

Gehen wir kurz einen Schritt zurück. Broadcom übernahm VMware 2022 – ein gewaltiger Deal, der die Enterprise-IT-Welt aufrüttelte. Mit VMware kam auch ein Portfolio von bei Entwicklern beliebten Tools, darunter Bitnami und das Open-Source-Projekt Harbor. Im Jahr 2025 hat Broadcoms Umgang mit diesem Erbe bei vielen bereits einen bitteren Nachgeschmack hinterlassen.

Die Entscheidung, Bitnamis öffentliche Container-Images früher in diesem Jahr aus Docker Hub zu entfernen – ein Schritt, der CI/CD-Pipelines über Nacht lahmlegte und in Entwicklerkreisen für Empörung sorgte – ist im kollektiven Gedächtnis noch präsent. Wenn Broadcom jetzt also mit Schlagzeilen über die Unterstützung von Open Source aufwartet, überrascht es nicht, dass viele misstrauisch sind.

Was wird eigentlich gespendet?

Broadcoms große Ankündigung dreht sich um die Spende eines Kubernetes-Tools an die CNCF, genauer gesagt eines etcd-Diagnosetools – ein Hilfsmittel, das beim Debuggen und Überwachen von etcd helfen soll, dem Key-Value-Store, auf den sich Kubernetes stützt. Auf dem Papier ist es nützlich. In der Praxis? Die Community ist sich nicht einmal sicher, ob es überhaupt eine Rolle spielt.

Und hier wird es heikel. Ein Redditor wies schnell darauf hin, dass ein Großteil des Artikels, der diese „Spende" ankündigt, auch Harbor hervorhob – ein Projekt, das ursprünglich 2018 von VMware an die CNCF übergeben wurde. Das war Jahre, bevor Broadcom überhaupt auftauchte. Warum wird es also in einer Pressemitteilung von 2025 erwähnt?

Wie ein Kommentator es unverblümt ausdrückte: „Sie können es nicht noch einmal spenden. Sie hatten nichts damit zu tun, also ist es müßig, es überhaupt zu erwähnen." Autsch.

Auch andere hielten sich nicht zurück. Ein Nutzer formulierte die Schlagzeile komplett neu: „Broadcom versucht verzweifelt, mit minimalem Aufwand Goodwill bei der Community aufzubauen, die sie gerade aktiv über den Tisch ziehen." Die Wortwahl ist hart, aber die Stimmung? Weit verbreitet.

Das Muster des Corporate Dumping

Gräbt man etwas tiefer, wirkt das, was wie eine freundliche Geste erscheint, eher wie Kostensenkung, verpackt in eine Open-Source-Schleife. Laut mehreren Nutzern aus der Kubernetes-Community folgen Broadcoms Open-Source-Beiträge oft einem ähnlichen Muster: Sie streichen interne Teams, die für die Pflege der Tools zuständig sind, und werfen die Codebasis dann der CNCF oder einer anderen Foundation zu.

Das Ziel ist nicht die Bereicherung der Community – es ist interne Kostenersparnis.

„Sie nutzen sie auch noch ein bisschen", merkte ein Entwickler mit Blick auf die gespendeten Tools an. „Sie wollen nur keine Engineers dafür bezahlen, die an dem arbeiten, was sie gespendet haben." Das ist das Software-Äquivalent dazu, ein gebrauchtes Sofa bei Goodwill abzugeben – nur dass Broadcom in diesem Fall hofft, dass jemand anderes die Wartungsrechnung übernimmt.

Und machen wir uns nichts vor: Die Community bemerkt das. Entwickler erkennen schnell, wenn ein Projekt eingeschlafen ist. Ein Nutzer teilte die GitHub-Commit-Historie von Kapp (einem weiteren Tool, das kürzlich mit VMware in Verbindung gebracht wurde): eine sechsmonatige Flaute in der Aktivität, gefolgt von ein paar „verdächtig getimten" Commits kurz vor der Spende. Es fällt schwer, das nicht als Last-Minute-Aufräumaktion für die PR-Optik zu interpretieren.

Warum das viele vor den Kopf stößt

Die Kubernetes- und die breitere Open-Source-Community sind nicht einfach nur zynisch. Ihr Misstrauen wurzelt in echten, aktuellen Erfahrungen.

Der Bitnami-Rückzug war nicht nur unbequem – er war ein Schlag in die Magengrube für Teams, die darauf angewiesen waren, dass diese Container verfügbar blieben. Broadcom bot privaten Zugang an, aber nur hinter Paywalls oder über proprietäre Plattformen. Der freie und offene Charakter des Projekts ging verloren. Ein solcher Schritt schadet nicht nur der Verbreitung, er zerstört Vertrauen.

Kombiniert man das mit den nach der Übernahme in die Höhe geschossenen VMware-Lizenzkosten, entsteht das Gefühl, dass Broadcom Enterprise-Software in eine geschlossene Gesellschaft verwandelt – eine, in der nur diejenigen mitspielen dürfen, die tief in die Tasche greifen können.

Ein Redditor fasste die Unternehmensstrategie in drei Worten zusammen: „Embrace, Extend, Extinguish." Das ist ein altes Spielbuch aus der Microsoft-Ära: ein offenes Tool übernehmen, es so weit anpassen, dass es den internen Bedürfnissen dient, und den breiteren Community-Anwendungsfall still und leise auslöschen.

Es ist nicht einmal klar, ob Broadcom überhaupt ein guter Open-Source-Bürger sein will. Ein anderer Kommentator behauptete: „Broadcom unterstützt Open Source nur, um Top-Engineers zu halten, die sonst abwandern würden." Mit anderen Worten: Open Source wird geduldet – nicht gefördert.

Was kostet das hier wirklich?

Es ist verlockend, das Drama einfach abzutun. Schließlich vollziehen Unternehmen ständig strategische Kurswechsel. Aber wenn diese Kurswechsel die Zuverlässigkeit und Langlebigkeit weit verbreiteter Infrastruktur beeinträchtigen, sind die Auswirkungen real.

Kubernetes ist die Grundlage des modernen Cloud Computing. Wenn Tools rund um Kubernetes plötzlich abgekündigt, geforkt oder weggeschlossen werden, sind die Folgen für unzählige Teams spürbar, von kleinen Startups bis zu großen Unternehmen.

Und wenn große Konzerne wie Broadcom versuchen, Open-Source-Beiträge als Marketinginstrument zu nutzen – ohne tatsächlich in die dafür nötigen Menschen, Wartung und Transparenz zu investieren –, schaden sie nicht nur ihrem eigenen Ruf. Sie schaden dem gesamten Ökosystem.

Hier geht es nicht um ein einzelnes Tool. Es geht um Kultur.

Kann Broadcom das Vertrauen der Community zurückgewinnen?

Unmöglich ist es nicht, aber einfach wird es auch nicht. Wenn Broadcom in der Open-Source-Welt wieder Glaubwürdigkeit gewinnen will, muss es mehr tun, als Hochglanz-PR zu veröffentlichen. Es muss:

• Transparent sein darüber, warum es Projekte spendet – und ob es sie intern weiterhin nutzt.
• In echtes Engagement in der Community investieren, nicht nur in rechtliche Übergaben.
• Maintainer unterstützen, statt nur Code abzuladen und zu verschwinden.
• Aufhören, das zu monetarisieren, was früher frei zugänglich war, ohne einen gleichwertigen Gegenwert zu bieten.

Und vielleicht am wichtigsten: Sie müssen aufhören, so zu tun, als wären diese Schritte selbstlos. Die Entwickler-Community ist zu klug, zu vernetzt und zu lautstark, um darauf hereinzufallen.

Fazit

Broadcoms Spende an die CNCF mag formal als Open-Source-Unterstützung durchgehen, aber vom Geist her fühlt es sich eher wie Reputationswäsche an. Wenn die jüngste Geschichte eines Unternehmens voller gebrochener Versprechen, zurückgezogener Produkte und Preiserhöhungen ist, setzt eine einmalige Code-Spende den Zähler nicht auf null.

Entwickler wollen keine polierten Pressemitteilungen. Sie wollen stabile Tools, transparente Roadmaps und Respekt für die Community. Bis Broadcom beweist, dass es das liefern kann, wird jede Spende mit Skepsis und schiefen Blicken quittiert.

Und ehrlich gesagt? Diese Skepsis fühlt sich verdient an.