Velero After Acquisition: Community Risk and Contingency Plans

There's something poetic about the open-source world. One day you're building freely, collaborating across continents, and swapping jokes about YAML indentation. The next, a multi-billion-dollar company acquires your favorite project, and you're suddenly wondering whether your backups will still work six months from now.

That's where Kubernetes users are with Velero, the much-loved open-source backup tool, and its new corporate owner, Broadcom.

At first glance it might sound like one more software acquisition, but anyone who's spent long enough in the cloud-native ecosystem knows better. Broadcom's track record with open-source communities reads like a cautionary tale, and Velero might be the next chapter in it.

So here is how a simple discussion about Kubernetes backups turned into a small model of the open-source trust problem, and what users are doing about it.

The backup tool everyone actually likes

If you haven't had to deal with disaster recovery on Kubernetes, Velero is one of those rare open-source tools that simply works. It's a Kubernetes-native solution for backing up and restoring clusters, namespaces, and persistent volumes. It integrates with a wide range of storage providers, supports both on-prem and cloud setups, and, most importantly, doesn't lock you behind a paywall.

Velero has been holding the fort in production environments for years without much fuss. It's flexible, scriptable, and transparent, and many platform engineers trust it enough to automate cluster recovery entirely through it.

It was originally developed by Heptio (the same folks who brought us some of the earliest Kubernetes production tools), moved under VMware Tanzu's umbrella, and through acquisition ended up with Broadcom. Technically it's now a Broadcom product, and that's where people start to worry.

Enter Broadcom, the corporate elephant in the cluster

Broadcom's reputation in open-source circles is, to put it mildly, not great.

This is the same company that bought VMware and Bitnami and then promptly began reshaping their product models in ways that left open-source users uneasy, with paywalled tiers, licensing shifts, and community projects slowly migrating into "enterprise" offerings. Broadcom tends to care more about maximizing profit than about keeping goodwill.

So when engineers realized Velero was now in Broadcom's portfolio, confidence was not the reaction. Few expected Velero to vanish overnight. The fear was that it would slowly drift behind a paywall, with a new "premium" dashboard here and a "support subscription" there, the kind of gradual shift that turns an open-source staple into a product under corporate control.

Some engineers joked that they'd keep using Velero "until someone pried it from their cold, dead clusters." Others talked seriously about forking it and keeping a community version alive.

That might sound dramatic, but in the open-source world it's pattern recognition more than paranoia.

Forking is the new resistance

Every time a big company takes over a community project and changes its license or direction, the same story plays out and the community forks it. Terraform became OpenTofu, Redis became Valkey, and Elasticsearch became OpenSearch.

The pattern is almost comforting in how predictable it is. When corporate influence gets too strong, the open-source ecosystem regrows the missing head, Hydra-style.

Velero could go the same way if Broadcom ever tightens its grip. The good news is that Velero already has contributors from outside VMware and Broadcom, and it's widely used across cloud providers and distributions. If the company ever made it proprietary, plenty of skilled developers are ready to fork it and carry it on under a neutral organization like the CNCF (Cloud Native Computing Foundation).

That is the whole point of open source: nobody can hold the code hostage.

We've been here before

None of this is new, and the community's déjà vu is justified.

When HashiCorp relicensed Terraform under a more restrictive model, the community did more than complain. It organized, and within weeks OpenTofu emerged, backed by the Linux Foundation. The same thing happened when Redis changed its license, and Amazon and other companies responded with Valkey.

Those incidents changed how developers think about open-source dependencies. Finding good software is only half of it; you also need stability and continuity when ownership changes hands.

That's what's happening with Velero now. Engineers are asking the same hard questions:

"Can we trust this to stay open?"

"Should we plan for alternatives?"

"How fast could we migrate if something changed?"

These have become practical concerns instead of theoretical ones. The memory of projects disappearing, licenses suddenly changing, and APIs breaking is still fresh.

Exploring the alternatives

Naturally, people started looking at alternatives in case Broadcom's stewardship turns into a problem. Several contenders have come up in community discussions and evaluations:

• Kasten K10 by Veeam is a powerful, mature option for enterprises. It offers application-consistent backups and extensive storage integrations, but it's not open source.
• VolSync is a lightweight, replication-based solution designed for asynchronous backups and lab setups, and it's especially popular in GitOps environments.
• K8up is a CNCF project that offers a straightforward, open-source backup operator. It's still developing but comes with the reassurance of vendor-neutral governance.
• CloudCasa is a Kubernetes-agnostic backup service that combines flexibility with simplicity. It can integrate with existing Velero deployments or run independently, so teams get options without abandoning what they already have.

Each of these brings something different. Kasten K10 appeals to enterprises that need guarantees, VolSync suits developers who prefer minimalism, K8up offers peace of mind through community ownership, and CloudCasa is a managed alternative that doesn't require vendor lock-in.

None of them is a perfect replacement for Velero, but together they give teams workable paths forward, each with its own trade-offs in openness, cost, and complexity.

The human side of open source

Underneath the technical debates is something far more emotional, and that's trust.

Open source means more than access to code. It means transparency, collaboration, and shared ownership. Developers choose open-source tools because they feel part of a collective effort instead of a customer base.

That's what worries many people about Broadcom's involvement. Corporate acquisitions tend to shift priorities from community-driven development toward revenue-driven decisions. Pull requests slow down, community maintainers lose influence, and "free forever" suddenly becomes "free for now."

That's frustrating, and it's also disheartening.

Velero was never just another Kubernetes add-on. It became a trusted part of countless infrastructure setups. When that trust is shaken, teams worry about more than their backups; they worry about the principle that made them adopt open source in the first place.

Forking vs. rebuilding, the realistic path

"Just fork it" has become the rallying cry of the open-source world, but it's easier said than done. Forking a large project takes coordination, leadership, and sustained commitment. Documentation needs updating, CI/CD pipelines have to be set up again, and governance has to be defined.

That's why many developers take a pragmatic stance: keep using Velero until something breaks, and have a migration plan ready.

Maybe that's okay. The threat of a fork is often enough to keep corporations honest, because companies know that if they alienate the open-source community too aggressively, they'll lose relevance along with goodwill.

Terraform's fork into OpenTofu was an act of rebellion and also of self-preservation. The same could happen with Velero if the need arises.

Preparing for whatever comes next

If you're running Kubernetes in production today, the best move is to prepare instead of panicking. A few practical steps make a big difference:

• Document your Velero setup clearly. Keep manifests, backup configurations, and storage settings portable.
• Evaluate alternatives early. Try K8up, VolSync, or CloudCasa in a test cluster and understand their workflows before you actually need them.
• Track licensing changes. Watch for any shifts in Velero's repository, ownership, or release structure.
• Participate in the community. The more active you are, the more influence users collectively have over the project's future.

If Broadcom does keep Velero open, great, nothing lost. If not, you'll be ready.

Forking as a feature of the ecosystem

In the end, open source is strong because it's resilient. Forking is a feature of the ecosystem, the safety valve that keeps innovation and collaboration alive even when corporate control threatens to suffocate them.

Velero's story might be another chapter in the long saga of open-source tools absorbed by big business, but it also shows that the community always finds a way.

Broadcom may own the trademarks, but it doesn't own the trust or the spirit of the code.

So if the day comes when Velero becomes a walled garden, the Kubernetes community won't panic. It'll adapt, fork, and rebuild, just like it always has, because in open source, survival comes from the freedom to fork it till you make it more than from loyalty to a brand.