Why We Open-Sourced ZSvirt #2
bgerxx
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
ZSvirt didn't start life as an open-source project. Its commercial counterpart, ZStack ZSphere, is a virtualization platform built by ZStack's engineering team over years of large-scale VMware replacement work — continuously developed, validated in real production environments, and deeply optimized.
The codebase now released as ZSvirt v1.0.0 has been running in demanding production environments for a long time. In these environments, the control plane manages more than 10,000 hosts, and a single VM can carry up to 768 vCPUs. For workloads this critical, makeshift maintenance is simply not an option.
That history matters to us, because virtualization is not a field where a demo alone proves long-term value.
A hypervisor's real worth is proven in critical moments and under pressure: when a disk fails, when you live-migrate during peak hours, when an audit deadline lands.
We've been through enough of these moments to believe that ZSvirt is ready for scrutiny from a wider community.
Why Now? Why Open Source?
Two years ago, this decision wouldn't have felt as urgent.
Since Broadcom acquired VMware, the way we talk to infrastructure administrators has changed. Teams running vSphere — and teams also running Hyper-V, Proxmox VE, or Nutanix — are re-evaluating their virtualization strategy, often under cost and budget pressure.
In these conversations, the questions we keep hearing are not about features. They are:
"Can we read the code?" "Can we audit it?" "If the vendor's strategy changes down the road, how do we protect ourselves?"
We could have answered these questions with promises. Instead, we chose to answer with a public repository. ZSvirt v1.0.0 is the first release to open the complete source code, build scripts, a signed installation ISO, and the accompanying documentation.
More importantly, in our view, "zero vendor lock-in" should live in the license and the code itself — not as a tagline in a product brochure. The virtualization layer carries a large share of an enterprise's business-critical workloads. If users can't read, audit, or build from the code themselves, a critical part of their infrastructure remains a dependency they don't fully control. Our belief is simple: infrastructure this important should not be subject to any single vendor's commercial decisions — including our own.
We understand that people may have questions about this decision, because we'd ask the same ones. An infrastructure open-source project launched by a commercial company naturally raises legitimate concerns: will the license change as the project grows? Is this an open-core play that keeps the real capabilities hidden?
So we want to state our commitments publicly.
A Transparent Business Model
We will clearly define the boundary between the community edition and the commercial offering.
What stays open, always:
What's commercial:
We will maintain public documentation that spells out which capabilities belong to the community edition and which to the commercial edition — and we will not move already-open features behind a paywall. That commitment applies to future releases as well.
Where We Fit
We don't believe ZSvirt is the only right choice for every organization, and we're not here to dismiss approaches the industry has widely adopted. Organizations have different infrastructure needs. ZSvirt is built for teams and individuals who want enterprise-grade capability, openness, and control at the same time.
There are several valid paths in virtualization, each serving different operational needs:
Many enterprise teams, though, have a different set of needs. They want to keep the familiar operating model of a traditional virtualization platform while gaining the openness, flexibility, and control that come with an open foundation. These teams typically manage infrastructure around familiar concepts — clusters, hosts, VMs, networks, and datastores — and need production-grade capabilities. At the same time, they want to avoid hardware and platform lock-in, don't want Kubernetes as a prerequisite for managing VMs, and want a fully open API.
For these teams, ZSvirt offers:
If your organization is looking for that balance, ZSvirt is built for you. If another approach fits your needs better, we respect that — and encourage you to adopt the platform that best suits your environment.
Our Community
For us, open-sourcing ZSvirt is not a one-time launch event. It's the start of a long-term collaboration.
Concretely:
We look forward to the community shaping where ZSvirt goes next — open collaboration builds stronger software.
Try ZSvirt
Download the ISO — published with checksums and cryptographic signatures — and explore ZSvirt in your own environment:
Star or watch the ZSvirt repository to follow new releases, development progress, and technical discussions.
Join the Community
All reactions