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 quietly acquires your favorite project, and you're suddenly questioning whether your backups will still work six months from now. That's where Kubernetes users find themselves with Velero—the beloved open-source backup tool—and its new corporate owner, Broadcom. At first glance, it might sound like just another software acquisition. But anyone who's been in the cloud-native ecosystem long enough knows better. Broadcom's track record with open-source communities reads like a cautionary tale, and Velero might be the next chapter in that story. So let's unpack how a simple discussion about Kubernetes backups turned into a microcosm of the open-source trust problem—and what users are doing about it. ## The Backup Tool Everyone Actually Likes For those who 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—it doesn't lock you behind a paywall. Velero has been quietly holding the fort in production environments for years. It's flexible, scriptable, and transparent. Many platform engineers trust it enough to automate cluster recovery entirely through it. Originally developed by Heptio (the same folks who brought us some of the earliest Kubernetes production tools), it moved under VMware Tanzu's umbrella and, through acquisition, ended up under Broadcom. Now, it's technically 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. Paywalled tiers. Licensing shifts. The slow migration of community projects into "enterprise" offerings. Broadcom's approach tends to be more about maximizing profit than maintaining goodwill. So when engineers realized Velero was now part of Broadcom's portfolio, the reaction wasn't one of confidence. The fear wasn't necessarily that Velero would vanish overnight—but that it would slowly drift behind a paywall. A new "premium" dashboard here, a "support subscription" there. The kind of subtle shift that turns an open-source staple into a corporate-controlled product. Some engineers joked that they'd keep using Velero "until someone pried it from their cold, dead clusters." Others talked seriously about the possibility of forking it and keeping a community version alive. It might sound dramatic, but in the open-source world, that's not paranoia. It's pattern recognition. ## Forking Is the New Resistance Every time a big company takes over a community project and changes its license or direction, the same story unfolds: the community forks it. Terraform became OpenTofu. Redis became Valkey. Elasticsearch became OpenSearch. The pattern has become almost comforting in its predictability. When corporate influence grows too strong, the open-source ecosystem simply regenerates itself, Hydra-style. Velero could follow that path if Broadcom ever tightens its grip. The good news is that Velero already has contributors from outside VMware and Broadcom. It's well-used across cloud providers and distributions. If the company ever turned it proprietary, there are plenty of skilled developers ready to fork and continue its legacy under a neutral organization like the CNCF (Cloud Native Computing Foundation). That's the beauty—and the point—of open source: the code can't be held hostage. ## We've Been Here Before None of this is new. The community's déjà vu is justified. When HashiCorp relicensed Terraform under a more restrictive model, the community didn't just complain—it organized. Within weeks, OpenTofu emerged, backed by the Linux Foundation. The same happened when Redis changed its license; Amazon and other companies responded with Valkey. These incidents reshaped how developers think about open-source dependencies. It's not just about finding good software—it's about ensuring 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 aren't theoretical concerns anymore—they're practical ones. The memory of projects disappearing, licensing suddenly changing, or APIs breaking is still fresh. ## Exploring the Alternatives Naturally, people started looking at alternatives to Velero in case Broadcom's stewardship becomes problematic. Several contenders have come up in community discussions and evaluations: **Kasten K10 by Veeam** – A powerful and mature enterprise-grade option. It offers application-consistent backups and extensive storage integrations, but it's not open source. **VolSync** – A lightweight, replication-based solution designed for asynchronous backups and lab setups. It's especially popular in GitOps environments. **K8up** – A CNCF project that offers a straightforward, open-source backup operator. It's still developing but provides the reassurance of vendor-neutral governance. **CloudCasa** – A Kubernetes-agnostic backup service that combines flexibility with simplicity. It can integrate with existing Velero deployments or run independently, giving teams options without forcing them to abandon what they already have. Each of these tools brings something different to the table. Kasten K10 appeals to enterprises that need guarantees. VolSync is for developers who prefer minimalism. K8up provides peace of mind through community ownership, and CloudCasa offers a managed alternative without requiring vendor lock-in. None of them are perfect replacements for Velero, but together they form a landscape of viable paths forward—each with trade-offs in openness, cost, and complexity. ## The Human Side of Open Source Beneath all the technical debates lies something far more emotional: trust. Open source isn't just about access to code. It's about transparency, collaboration, and shared ownership. Developers choose open-source tools because they feel part of a collective effort, not just a customer base. That's what worries many about Broadcom's involvement. Corporate acquisitions tend to shift priorities—from community-driven development to revenue-driven decisions. Pull requests slow down. Community maintainers lose influence. "Free forever" suddenly becomes "free for now." It's not just frustrating—it's disheartening. Velero wasn't just another Kubernetes add-on. It became a trusted part of countless infrastructure setups. When that trust is shaken, teams aren't just worried about backups; they're worried about the very principle that made them adopt open source in the first place. ## Forking vs. Rebuilding: The Realistic Path While "just fork it" has become the rallying cry of the open-source world, 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 reestablished. Governance needs to be defined. That's why many developers take a pragmatic stance: keep using Velero until something breaks, and be ready with a migration plan. And maybe that's okay. The threat of a fork is often enough to keep corporations honest. Companies know that if they alienate the open-source community too aggressively, they'll lose not just goodwill—but relevance. Terraform's fork into OpenTofu wasn't just an act of rebellion; it was an act 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 isn't to panic—it's to prepare. A few practical steps can 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. 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 in shaping the project's future. If Broadcom does keep Velero open, great—nothing lost. If not, you'll be ready. ## Forking as a Feature, Not a Failure At the end of the day, the strength of open source lies in its resilience. Forking isn't a failure; it's a feature of the ecosystem. It's the safety valve that keeps innovation and collaboration alive, even when corporate control threatens to suffocate it. Velero's story might be another chapter in the long saga of open-source tools absorbed by big business, but it's also proof of something powerful: the community always finds a way. Broadcom may own the trademarks, but it doesn't own the trust—or the code's spirit. 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 isn't about loyalty to a brand. It's about the freedom to fork it till you make it.