
Why Broadcom gave Velero to the CNCF Sandbox — and what it means for Kubernetes data protection
Get every episode summarized
Each time The New Stack Podcast publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
About this episode
“VMware by Broadcom delivers VMware Cloud Foundation, a single platform with built-in certified Kubernetes runtime called the V-Sphere Kubernetes Service.”From the transcript
Broadcom continues to expand its role as a major contributor to cloud-native open source, particularly within the Cloud Native Computing Foundation (CNCF) ecosystem. Its recent donation of Velero—originally developed by VMware—to the CNCF Sandbox reflects a strategic move to foster broader community trust and collaboration. By shifting governance away from vendor control, Broadcom aims to position Velero as a truly community-driven data protection standard for Kubernetes environments, encouraging wider adoption and contribution.
At the same time, the company is reinforcing its position as a full-stack Kubernetes provider across both cloud-native and private cloud environments. Despite Kubernetes’ dominance, many organizations still struggle with its complexity. Broadcom is addressing this by focusing on lifecycle management, long-term support, and deep integration with existing infrastructure like vSphere.
In a podcast recorded at KubeCon + CloudNativeCon Europe 2026, Dilpreet Bindra emphasized that open source success comes not just from code contributions, but also from relinquishing control to empower the broader ecosystem and drive sustainable innovation.
Learn more from The New Stack about the latest developments around Velero:
How AI Search Is Supporting Artistic Freedom
Join our community of newsletter subscribers to stay on top of the news and at the top of your game.
Get every episode summarized
Each time The New Stack Podcast publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
Transcript ready
215 searchable segments. Every word is indexed and playable.
Full transcript
The New Stack Podcast — Why Broadcom gave Velero to the CNCF Sandbox — and what it means for Kubernetes data protection. Machine-transcribed; use the interactive transcript above to jump the player to any line.
VMware by Broadcom delivers VMware Cloud Foundation, a single platform with built-in certified Kubernetes runtime called the V-Sphere Kubernetes Service. The simplifies Kubernetes deployment management, enabling enterprises to run modern applications alongside traditional workloads. With automated deployment and lifecycle management, built-in security and resiliency and enterprise grade scalability, VCF offers a comprehensive private cloud infrastructure. VKS delivers high-performance, cost optimization, and a familiar management experience, making Kubernetes more accessible for IT teams. Hi, it's V Cameron Gain of Revcom, and I'm here with the new stack at KubeCon Cloud NativeCon in Amsterdam, and I'm here with DealPreet today of Broadcom,
and we're going to talk about some very interesting things on open source. Nice to be here. Thank you. And I was wondering if you could, as we were discussing before, just describe to me, if you could bring us up to speed on Broadcom's open source commitment. We're going way back initially with Broadcom, and as your routes, or VMware's routes, we're in Kubernetes. They're the latest Kubernetes, for example, and this remains a major if one of the top, or a top, indoor top contributor to the Kubernetes project. How's that evolved now? Where are we with that as far as open source goes? Yeah, I think we saw the strategic importance of Kubernetes as a platform probably seven, eight years ago when we materially began a project to integrate Kubernetes deeply within our stack. And if you're embarking on Kubernetes or anything open source,
you have to be a strong contributor into that space. And along with the Heptio acquisition, we had both contributors, also founders that showed up at VMware that were really critical in establishing our open source foundation, especially around CMCF. That goes way back. Can you bring our viewers up to speed with that Heroku acquisition? And why, how that, how you gained the original Kubernetes co-creators? Yeah, who was that? That was a while ago. That was a while ago. I've been around for a while, so I know some of the history. We had actually kicked off a Kubernetes project inside of VMware prior to the acquisition. And so the executive team was starting to see the importance of Kubernetes overall. As a platform, we were seeing the uptake, of course, and so on. And then alongside that,
there was another part of the overall Dell family at the time, called Pivotal, that was also that built an orchestration capability around, it's Bosch, orchestrator that was doing Kubernetes as well. And so there was some, there was essentially a Grantswell that allowed for them to look at, okay, what do we need to go acquire? And when they acquired Heptio, they brought a very strong, you know, Kubernetes team that included two founders of Kubernetes, Craig McClucky and Joe Vated. And they really helped us steer the overall investment in both cloud-native computing, but also help steer what we needed to build into the product and how we would go and deliver something that was really capable for modern computing. And when was that roughly? That was, I think, about probably seven years ago.
A while ago, something like that. So that was when that coalesced into a very, that was, or that VMware stake in Kubernetes, and that provided a basis. And so how has that evolved, and where are we now? Yeah, you know, we went through various phases. You know, VMware went through a lot of learning when it came to Kubernetes. We had various distros and so on. And, you know, now we're focused on one distribution that is directly built into our V-Sphere platform called V-Sphere Kubernetes Service. Yes. And it's a rename of a, of a distro we already had, which was the TKGS, but the naming convention was very, very confusing for our customers and so on. And we wanted to show that the, no, no, no, this Kubernetes is directly tied to the foundations of V-Sphere, right? Yeah. And, you know, as we, we've been, you know, like doing this after post-Broadcom acquisition,
we consolidated all the Kubernetes capability and knowledge within my team in Broadcom to actually drive the end to end Kubernetes, both the Kubernetes distribution as well as the the service, as well as the management and so on of Kubernetes. And, along with that comes this huge responsibility to maintain the culture around contribution up to the open source community. Because again, if you're trying to do something significant here, you have to actually have contributors that are working in your team and driving certain capabilities up through the stack. And that, to that end, that was a large motivating factor for your donation this week. Yeah. To donate Valero to the CNCF. So, so when we looked at our overall investments in this,
it did currently, we're very, very focused on enterprise Kubernetes because this is, this is, you know, Kubernetes is taking some time to mature to the point where every enterprise is looking at some Kubernetes estate that they need for either developing their own applications or instantiating some pre-built applications from the field. And, you know, when we looked at this, there's a few projects that are critical. Last year, we announced something around LCD where we had a set of tooling that enhances the ability to debug and resolve issues in LCD and we contributed that back to the community. And this year, we had the opportunity to contribute Valero into a CNCF sandbox, which, you know, once we decided we wanted to do so and and the community started to vote on it, we got this resounding like, yeah, yeah, this makes
complete sense. And Valero is at the heart of all the data protection capabilities inside of VR. Yeah, exactly. And then also, you know, we're a big contributor to cluster API as well, which is the, you know, all the lifecycle management capability inside of Kubernetes. And so, those three major areas along with our harbor contributions, you know, really focus in on the modern, but enterprise Kubernetes experience. How is this new? I mean, this aspect of these particular projects and is there a way maybe to quantify this? Are you, is Broadcom actively say, okay, we need to change, well, you changed the governance structure of Valero by Donatee yet. And so, is there a way, maybe to give you a four and after as far as open source program goes at VMware? Yeah, you know, I think, I think we went through a period of open source
contributions that were very much explorative. Hey, we will explore a set of different open source capabilities. And we would have a set of, you know, people that were just doing open source contributions, you know, exploring the various things you could do in this space. And now we're very, very strategic about it in terms of the set of things that we require to really simplify Kubernetes for our customers and contribute that backup upstream, right? But how's that going to change though? For example, what's the Valero being open, being donated now? It's going to change the governance structure, of course, but what's going to be the before and after? So, so that's a good question. I think, I think from an organization standpoint, CNCF does this brilliant job of having a very good model for governing a set of components and being able to
shepherd them in a neutral way. And we view that as a, you know, with this contribution of Valero into CNCF as a critical capability, not just for us, but also the industry. We really don't want people to mistrust the open source project and believe that it's somehow a VMware thing. It hasn't been a VMware thing for quite some time. We've contributions from a number of different corporations. And we want to make sure that people are free to view that as a CNCF thing and not just a VMware. A token of good faith that the licensing changes aren't going to be, the rub's not going to be pulled from under them. Yeah, but also that they can freely enhance and also have the safety of being able to enhance it and being able to use it within their products. And not worry about, hey, you know, VMware is holding the strings here. Yeah. And how, and there,
there would be more, I would assume, commits as well as this because more collaborative. How would that, how would that pay enough, paying out? We're going to see, I would suspect that we're going to see some really interesting work now in a more collaborative way with, you know, data disaster recovery and that storage, for example, for that functionality. Absolutely. I think it will help Valero evolve into the type of data protection solution, the industry standard data protective solution that we want it to be. You know, we view Valero as critically important, not only to our Kubernetes, you know, estate, but also to our VM estate. Oh, yeah. Of course. And so we, we plan to use it even broader than its current definition. And that's why I think the contribution up to CNCF helps us not expand it, but expand it with the commentary and the, and the collaboration with these other corporations. In the realm of open source, what I would assume that, you know,
Kubernetes remains, though, your largest project that you're contributing to. And is there been, maybe a directive or a sort of effort to increase your contributions to Kubernetes or just, can you talk, speak to that? It's not a directive in so much as that. Someone has pushed down, you now shall do XYZ. But when we look at our, we did this actually recently, we looked at our, our strategically important projects that we need to be part of to actually help drive various things that we need to get done. And we evaluated which areas do we need to go and double down on, and then we figured out, okay, we need additional contribution or additional contributors in these spaces. And then we're, we're, we're opening up the positions. Actually, we did this last year, but we opened up the positions that we required to be able to actually go and up our, our contribution
overall. I see. And how was that built into, say, the actual projects? I mean, with the platform engineering, did you, is that change slump in the specs? You know, I think, you know, when you, know that you need to, let's say, for instance, do a great job with LCD, which is the core of Kubernetes, right? In terms of the distributed database. Then, and if you, if you don't have sufficient maintainers, then you go and look for maintainers. That's what, that, that, that's what we're doing. I see. Yeah. And that would be also, I mean, again, how's that changing, though? What is changing? Yeah. You know, I, I, I don't know how to put it in different way, but like when we look, where we're taking a very strategic view of what we, how we want to deliver our Kubernetes service, then we're saying, Hey, here are the, the open source areas we need to participate in
significantly. We're also evaluating that over and over again. Actually, even with the AI changes and, you know, there was the LLMD that was contributed recently as well to, to CNCF, and we're looking at the, the overall space of CNCF, and we're saying, Okay, what further do we want to contribute to moving forward? And is there a particular area where you look, you're looking to contribute at this time? I think, I think, you know, one of the areas that's really interesting on the, on the resource management side is DRA. And we look at that, and we look at its tie into our overall resource management capabilities. That is our bread and butter inside a, a vSphere, and VCF, and we're like, Hey, that's, that's interesting. And we should explore that further. What, why, why is that? Or what, what, what, what, what, you know, what would be the solution? What's going to happen? Well, you know, our, our resource management capabilities are the reasons we, the other exists. It's the reason why we can get the overcommit way we want a need. It's the reason why we can pack more and utilize more of the underlying hardware. And so,
when you look at DRA and the way that it does resource, and manages these critical resources like GPUs, we want to make sure that the, the tie in with our underlying resource schedule or and DRA is very, very tight knit, so that customers can gain the, the same advantages that they've gained previously with CPU and memory. I see. And I guess a lot of customer feedback, though, is coming through the open source projects. Yes. Yes. How does that work? You know, I, with, with all the open source contributions that we do, and even in, in, in this conference, we're, we're seeing a lot of customers come to our booth and ask us very deep questions about some of the areas that we maintain. And again, that, that also leads to a lot of trust in not only the fact that we're experts in that area, but also that we can help drive their overall, you know, road map into or, or around
modern computing. And these are the folks that are often active contributors as well. Yes. Yes. And they're saying, I mean, can you give an example of something we need or that there have been a lot of pullover class for? Well, you know, you know, cluster API, which is one of the things we contribute to, we have a, you know, a maintainer of cluster API that is considered one of the key experts in that space is been, you know, doing some very recent blogs on the aspects around immutability around cluster API, various aspects that people may not know of, but also where cluster API is going down in the future in terms of making sure that the life cycle of a Kubernetes cluster can be better managed. And like, for instance, we care a lot about the ability to take a customer from a version that is long term supported to another version that's long term
supported. And given the fact that VKS has two years of long term support, we want to be able to build in the ability to do the necessary upgrade, the chained upgrade from one version to the next version to the next with a single click. So they have a large window if they want that. They don't have to update their compliance or just start over. Yes. Because your guarantee and that support for for two years. Yes. Can you describe what that means or how that it's not terribly apparent how that works? Well, given the fact that we have the capacity within to maintain these various pieces including core Kubernetes and all the various pieces that go around, we can work with the community to figure out when we need to go and patch the release. And so we're relying on the that knowledge and the ability to take, you know, patches that may happen in the next
release because the community has moved on and bring them back to the previous version so that our customers can continue to leverage that version. And so, so, so it's really a customer can be rest assured that we're able to support, we're able to maintain, we're able to stay ahead of the set of crucial issues that they care about for the security. Exactly. Even though it might be, there might be using a version that's 18 months old. Exactly. They're still getting their security updates. Exactly. They might not have a really nice new API, API that's arguably fun or interesting, but as it comes down to, it's more than just good enough what they have now and you're providing that support. And then that's still core for enterprise use. Enterprises don't want to be in this in this treadmill of the new thing all the time. It's expensive too. Right. Yes. Yes. And also the
feedback too is that if they want though, if you want to get the latest features, that is available rapidly as well. And that's the interesting thing is that are more so than certain hyperscalers. Absolutely. Our Kubernetes is built surely on open stores and CNCF concepts. So our use of cluster API and other pieces allow us to have very rapid turnaround of taking the upstream and then validating and getting it out within two months of the upstream release faster than nearly actually all of our on-prem competitors and faster than some of the cloud competitors that we have. And so that turnaround time gives even more time for that customer to have the upstream support if they were to move to that version. But also we support multiple versions at the same time. So they have the ability to actually latch onto a version and not worry about having to move
very quickly. Yeah. And they have that choice. Yes. And how does that overlap though with open source? You know, we Kubernetes. We tried for a while to influence them. We're going to continue to try to influence the Kubernetes community to increase the community support window. And that's where the overlap with open sources is like the community support window is 12 months. But we're seeing enterprises and as Kubernetes mature as you're going to need that runway for enterprises to be able to continue to run their applications with of course applying patches and so on. But run their applications without disturbance for that longer period of time. And so we really want to work with the community and figure out how to do this best. And we don't care to be special here. We just want to make sure that the customers get the right solution. And as I move more towards VMs,
is it moving more towards VMs? And I mean, VMs are becoming that much more prevalent now. On containers are in the VMs, obviously. Yes. Yes. How is that changing? I think that what we've proven actually, and both from an operational standpoint, but also from a skill and performance standpoint, that the containers and Kubernetes runs best on virtualization. And especially the set of things that we invested in with VCF9O, we brought all of our VM foundation and our Kubernetes together under a single Kubernetes API so that you can actually take all advantage of all of our IAs objects in with a declarative Kubernetes document that you use to be able to actually drive that API. And so now you can do a VM just like you do a Kubernetes
cluster and so on. And you could do it using get ops if you wanted to or so on. And for, you know, this when we say, you know, VMs, there's a healthy exchange between which workloads run best on which and also corporations want the choice of being able to figure out when they want to transition from one to the other on for what reasons they would and for and when they should as a developing or augmenting one of their applications. And now they can do so with the investment protection in one, you know, a platform. Well, thank you. It's be camera gain signing off here at KubeCon plus cloud native con Europe and Amsterdam. And I wanted to thank DealPreet for a very fascinating conversation. Thanks for having me.
More episodes
More from The New Stack Podcast

How Microsoft is governing thousands of Kubernetes clusters without manual inter...
The New Stack Podcast

Why long-running AI agents break on HTTP and how Ably is fixing it
The New Stack Podcast

Why the Linux Foundation adopted MCP, with Jim Zemlin and Mazin Gilbert
The New Stack Podcast

Fresh data has us asking, does AI demand Kubernetes?
The New Stack Podcast