What is an Open Source Cloud Platform?

A platform in this category is a set of cooperating services rather than a single binary:

• Compute - the API that creates and destroys virtual machines, and the hypervisor underneath them.
• Storage - block volumes, object stores and the network that attaches them to workloads.
• Networking - virtual networks, routing and isolation between tenants.
• Identity and quota - who may create what, in what amounts.
• A dashboard or API for self-service on top of all of it.

Managed cloud converts capital expense into operating expense and hands operations to someone else. An open source platform reverses that trade: lower recurring cost and full control, in exchange for the engineering to run it - upgrades, capacity planning, security patching. Neither is categorically better; they answer different constraints. What has historically been missing is a third path: running your own cloud and still reaching demand you do not own - which is what a compute marketplace provides.

Where each side wins also depends on the estate. A single application with predictable load rarely justifies running a control plane of its own; fleets of steady, known workloads with compliance constraints are where owning one starts to earn back the operational layer it demands. Most estates end up mixed - which is the subject of the open source hybrid cloud definition.

The hardware rarely makes something a cloud. A room full of hypervisors is a virtualization cluster: machines are allocated by tickets and spreadsheets, images are copied by hand, and network changes go through whoever owns the switches. The platform is what replaces those tickets with an API.

Once consumers can request capacity themselves - from a catalogue, within quota, against pre-approved images - the same metal behaves like a cloud. This is also why two deployments of the same open source project can feel completely different to their users: the difference lives in how the self-service layer, tenancy model and network policy are configured, not in which services were installed.

There is a middle setting, too. Some operators keep only the control plane - API, identity, images, quota - running on leased metal, so the policy layer stays theirs while the hardware is rented. What defines the category is where control of the cloud sits: with whoever runs the software.

Owning the operation is the trade the platform asks for. Upgrades move several cooperating services together and have to respect API compatibility for anything already running. Capacity needs headroom for failure, not only for growth. Security patches arrive on the operating system's schedule, not the platform's.

• Upgrade coordination between services, with a rollback path kept open.
• Capacity headroom sized for hardware failure as well as demand peaks.
• Monitoring across control plane and data path, not only host utilisation.
• Operators comfortable with distributed systems when the stack misbehaves.

Distribution-backed builds soften the edges with tested packaging and support channels, but the underlying lifecycle is still yours to schedule. Teams buying their first cloud are usually better served renting until the workloads justify carrying that operational layer themselves.

A provider running an open source cloud platform can expose its capacity to outside tenants without rebuilding its stack. Waldur already documents provider modules for OpenStack, Kubernetes, Rancher and VMware among others, and the provider daemon connects that control plane to VirtEngine: offerings are published, orders become leases, usage is metered, and settlement happens on-chain. The platform stays yours; the demand side becomes open.