Velero nach der Übernahme: Risiko für die Community und Notfallpläne

Es liegt etwas Poetisches in der Open-Source-Welt: An einem Tag baut man frei vor sich hin, arbeitet über Kontinente hinweg zusammen und tauscht Witze über YAML-Einrückung aus. Am nächsten Tag übernimmt ein milliardenschweres Unternehmen still und leise Ihr Lieblingsprojekt, und plötzlich fragen Sie sich, ob Ihre Backups in sechs Monaten noch funktionieren.

Genau da stehen Kubernetes-Nutzer gerade mit Velero - dem beliebten Open-Source-Backup-Tool - und seinem neuen Unternehmenseigentümer Broadcom.

Auf den ersten Blick klingt das nach nur einer weiteren Software-Übernahme. Aber jeder, der lange genug im Cloud-Native-Ökosystem unterwegs ist, weiß es besser. Broadcoms Erfolgsbilanz mit Open-Source-Communities liest sich wie eine Warngeschichte, und Velero könnte das nächste Kapitel dieser Geschichte sein.

Schauen wir uns also an, wie aus einer einfachen Diskussion über Kubernetes-Backups ein Mikrokosmos des Open-Source-Vertrauensproblems wurde - und was Nutzer dagegen tun.

Das Backup-Tool, das wirklich alle mögen

Für alle, die sich noch nicht mit Disaster Recovery auf Kubernetes befassen mussten: Velero ist eines dieser seltenen Open-Source-Tools, die einfach funktionieren. Es ist eine Kubernetes-native Lösung zum Sichern und Wiederherstellen von Clustern, Namespaces und Persistent Volumes. Es lässt sich mit einer breiten Palette an Storage-Anbietern integrieren, unterstützt sowohl On-Prem- als auch Cloud-Setups und sperrt Sie - was am wichtigsten ist - nicht hinter eine Paywall.

Velero hält seit Jahren still die Stellung in Produktivumgebungen. Es ist flexibel, skriptbar und transparent. Viele Platform Engineers vertrauen ihm genug, um die Cluster-Wiederherstellung komplett darüber zu automatisieren.

Ursprünglich von Heptio entwickelt (denselben Leuten, die uns einige der frühesten Kubernetes-Produktivtools brachten), wanderte es unter das Dach von VMware Tanzu und landete durch Übernahme schließlich bei Broadcom. Jetzt ist es technisch gesehen ein Broadcom-Produkt - und genau da fangen die Sorgen an.

Auftritt Broadcom: Der Unternehmens-Elefant im Cluster

Broadcoms Ruf in Open-Source-Kreisen ist, gelinde gesagt, nicht besonders gut.

Das ist dasselbe Unternehmen, das VMware und Bitnami kaufte und dann prompt begann, deren Produktmodelle so umzubauen, dass Open-Source-Nutzer unruhig wurden. Kostenpflichtige Stufen. Lizenzverschiebungen. Die schleichende Migration von Community-Projekten in "Enterprise"-Angebote. Broadcoms Ansatz dreht sich tendenziell eher um Gewinnmaximierung als um den Erhalt von Goodwill.

Als Engineers also merkten, dass Velero jetzt Teil von Broadcoms Portfolio war, war die Reaktion keine des Vertrauens. Die Angst war nicht unbedingt, dass Velero über Nacht verschwinden würde - sondern dass es langsam hinter eine Paywall abdriften würde. Hier ein neues "Premium"-Dashboard, dort ein "Support-Abo". Die Art von subtiler Verschiebung, die aus einem Open-Source-Grundpfeiler ein unternehmenskontrolliertes Produkt macht.

Manche Engineers scherzten, sie würden Velero weiter nutzen, "bis jemand es aus ihren kalten, toten Clustern reißt". Andere sprachen ernsthaft über die Möglichkeit, es zu forken und eine Community-Version am Leben zu halten.

Das mag dramatisch klingen, aber in der Open-Source-Welt ist das keine Paranoia. Das ist Mustererkennung.

Forken ist der neue Widerstand

Jedes Mal, wenn ein großes Unternehmen ein Community-Projekt übernimmt und dessen Lizenz oder Richtung ändert, entfaltet sich dieselbe Geschichte: Die Community forkt es.

Terraform wurde zu OpenTofu. Redis wurde zu Valkey. Elasticsearch wurde zu OpenSearch.

Das Muster ist in seiner Vorhersehbarkeit fast schon beruhigend geworden. Wird der Unternehmenseinfluss zu stark, regeneriert sich das Open-Source-Ökosystem einfach selbst, nach Hydra-Manier.

Velero könnte diesen Weg gehen, sollte Broadcom jemals die Zügel anziehen. Die gute Nachricht: Velero hat bereits Contributors außerhalb von VMware und Broadcom. Es wird breit über Cloud-Anbieter und Distributionen hinweg genutzt. Sollte das Unternehmen es jemals proprietär machen, stehen genug fähige Entwickler bereit, um es zu forken und sein Erbe unter einer neutralen Organisation wie der CNCF (Cloud Native Computing Foundation) fortzuführen.

Das ist die Schönheit - und der Sinn - von Open Source: Der Code kann nicht als Geisel gehalten werden.

Das hatten wir schon einmal

Nichts davon ist neu. Das Déjà-vu der Community ist berechtigt.

Als HashiCorp Terraform unter ein restriktiveres Lizenzmodell stellte, beschwerte sich die Community nicht nur - sie organisierte sich. Innerhalb weniger Wochen entstand OpenTofu, unterstützt von der Linux Foundation. Dasselbe geschah, als Redis seine Lizenz änderte; Amazon und andere Unternehmen antworteten mit Valkey.

Diese Vorfälle haben verändert, wie Entwickler über Open-Source-Abhängigkeiten denken. Es geht nicht nur darum, gute Software zu finden - es geht darum, Stabilität und Kontinuität sicherzustellen, wenn die Eigentümerschaft wechselt.

Genau das passiert gerade mit Velero. Engineers stellen dieselben harten Fragen:

"Können wir darauf vertrauen, dass das offen bleibt?"

"Sollten wir Alternativen einplanen?"

"Wie schnell könnten wir migrieren, wenn sich etwas ändert?"

Das sind längst keine theoretischen Sorgen mehr - es sind praktische. Die Erinnerung an verschwundene Projekte, plötzlich geänderte Lizenzen oder kaputte APIs ist noch frisch.

Die Alternativen im Blick

Natürlich fingen Leute an, sich nach Alternativen zu Velero umzusehen, falls Broadcoms Verwaltung problematisch werden sollte. In Community-Diskussionen und Evaluierungen sind mehrere Kandidaten aufgetaucht:

Kasten K10 von Veeam - Eine leistungsstarke und ausgereifte Option auf Enterprise-Niveau. Es bietet anwendungskonsistente Backups und umfangreiche Storage-Integrationen, ist aber nicht Open Source.

VolSync - Eine leichtgewichtige, replikationsbasierte Lösung für asynchrone Backups und Lab-Setups. Besonders beliebt in GitOps-Umgebungen.

K8up - Ein CNCF-Projekt, das einen unkomplizierten Open-Source-Backup-Operator bietet. Es entwickelt sich noch, bietet aber die Beruhigung einer anbieterneutralen Governance.

CloudCasa - Ein Kubernetes-agnostischer Backup-Dienst, der Flexibilität mit Einfachheit verbindet. Er kann sich in bestehende Velero-Deployments integrieren oder eigenständig laufen, was Teams Optionen gibt, ohne sie zu zwingen, das aufzugeben, was sie bereits haben.

Jedes dieser Tools bringt etwas anderes mit. Kasten K10 spricht Unternehmen an, die Garantien brauchen. VolSync ist für Entwickler, die Minimalismus bevorzugen. K8up sorgt durch Community-Eigentümerschaft für Seelenfrieden, und CloudCasa bietet eine verwaltete Alternative, ohne Vendor Lock-in zu erfordern.

Keines von ihnen ist ein perfekter Ersatz für Velero, aber zusammen bilden sie eine Landschaft gangbarer Wege nach vorn - jeder mit eigenen Kompromissen bei Offenheit, Kosten und Komplexität.

Die menschliche Seite von Open Source

Unter all den technischen Debatten liegt etwas viel Emotionaleres: Vertrauen.

Bei Open Source geht es nicht nur um Zugang zu Code. Es geht um Transparenz, Zusammenarbeit und geteilte Eigentümerschaft. Entwickler entscheiden sich für Open-Source-Tools, weil sie sich als Teil einer gemeinsamen Anstrengung fühlen, nicht nur als Kundenbasis.

Das ist es, was viele an Broadcoms Beteiligung beunruhigt. Unternehmensübernahmen verschieben tendenziell die Prioritäten - von Community-getriebener Entwicklung hin zu umsatzgetriebenen Entscheidungen. Pull Requests werden langsamer bearbeitet. Community-Maintainer verlieren an Einfluss. Aus "für immer kostenlos" wird plötzlich "kostenlos, vorerst".

Das ist nicht nur frustrierend - es ist entmutigend.

Velero war nicht nur ein weiteres Kubernetes-Add-on. Es wurde zu einem vertrauenswürdigen Bestandteil unzähliger Infrastruktur-Setups. Wenn dieses Vertrauen erschüttert wird, sorgen sich Teams nicht nur um Backups; sie sorgen sich um genau das Prinzip, das sie überhaupt erst dazu brachte, auf Open Source zu setzen.

Forken vs. Neubauen: Der realistische Weg

Auch wenn "einfach forken" zum Schlachtruf der Open-Source-Welt geworden ist, ist das leichter gesagt als getan. Ein großes Projekt zu forken braucht Koordination, Führung und anhaltendes Engagement. Dokumentation muss aktualisiert werden. CI/CD-Pipelines müssen neu aufgesetzt werden. Governance muss definiert werden.

Deshalb nehmen viele Entwickler eine pragmatische Haltung ein: Velero weiter nutzen, bis etwas kaputtgeht, und mit einem Migrationsplan bereitstehen.

Und vielleicht ist das okay. Die Drohung eines Forks reicht oft aus, um Unternehmen ehrlich zu halten. Unternehmen wissen: Wenn sie die Open-Source-Community zu aggressiv verprellen, verlieren sie nicht nur Goodwill - sondern Relevanz.

Terraforms Fork zu OpenTofu war nicht nur ein Akt der Rebellion; es war ein Akt der Selbsterhaltung. Dasselbe könnte mit Velero passieren, sollte die Notwendigkeit entstehen.

Sich auf alles vorbereiten, was als Nächstes kommt

Wenn Sie heute Kubernetes in Produktion betreiben, ist der beste Zug nicht Panik - sondern Vorbereitung. Ein paar praktische Schritte können einen großen Unterschied machen:

Dokumentieren Sie Ihr Velero-Setup klar. Halten Sie Manifeste, Backup-Konfigurationen und Storage-Einstellungen portabel.

Evaluieren Sie Alternativen frühzeitig. Probieren Sie K8up, VolSync oder CloudCasa in einem Testcluster aus. Verstehen Sie deren Workflows, bevor Sie sie tatsächlich brauchen.

Verfolgen Sie Lizenzänderungen. Achten Sie auf jede Verschiebung in Veleros Repository, Eigentümerschaft oder Release-Struktur.

Beteiligen Sie sich an der Community. Je aktiver Sie sind, desto mehr Einfluss haben Nutzer gemeinsam darauf, die Zukunft des Projekts zu gestalten.

Hält Broadcom Velero offen, umso besser - nichts verloren. Falls nicht, sind Sie bereit.

Forken als Feature, nicht als Scheitern

Am Ende des Tages liegt die Stärke von Open Source in seiner Resilienz. Forken ist kein Scheitern; es ist ein Feature des Ökosystems. Es ist das Sicherheitsventil, das Innovation und Zusammenarbeit am Leben hält, selbst wenn Unternehmenskontrolle sie zu ersticken droht.

Veleros Geschichte mag ein weiteres Kapitel in der langen Saga von Open-Source-Tools sein, die von der Großwirtschaft aufgesogen werden, aber sie ist auch der Beweis für etwas Kraftvolles: Die Community findet immer einen Weg.

Broadcom mag die Markenrechte besitzen, aber es besitzt nicht das Vertrauen - oder den Geist des Codes.

Sollte also der Tag kommen, an dem Velero zu einem ummauerten Garten wird, wird die Kubernetes-Community nicht in Panik geraten. Sie wird sich anpassen, forken und neu aufbauen. Genau wie sie es immer getan hat.

Denn in Open Source geht es beim Überleben nicht um Loyalität zu einer Marke. Es geht um die Freiheit, so lange zu forken, bis man es geschafft hat.