Closed source, open minds: addressing four real worries about proprietary Kubernetes platforms

Introduction

“Is it open source?” That question invariably comes up in our first meeting with prospective Palette users. It’s a fair one: Kubernetes was born in the open, and the cloud‑native landscape grew up on the shoulders of thousands of community projects. 

When buyers hear that Palette is proprietary, we can almost see the follow‑up concerns forming in their minds. Will a closed product hem us in? What happens if the vendor disappears? Surely we can save money by staying open source? And is proprietary software really as secure as code the whole world can read?

Those are reasonable questions, not naïve objections. In fact they echo the mood of the wider Kubernetes community. In the 2024 State of Production Kubernetes report, 55% of practitioners said they already feel “locked in” and are worried about vendors they depend on going under, while 82% of senior decision‑makers expect the ecosystem to consolidate in the coming years.

In this article we will look at four themes — flexibility, vendor risk, cost and security — reframing each concern with real data, examples and the lived experience of our own engineers, many of whom still maintain open source projects on weekends. The goal is not to dismiss your concerns, but to give you a clear basis for deciding whether Palette’s commercial model aligns with your own risk and value lenses.

Before we start: I’m one of you

But before we start and you write me off as a commercial shill, let me introduce myself: I’m Dmitry, and I’ve worked in open source for years. I spent five years at Red Hat, a couple more at Rancher/SUSE, and I’ve always used open source software heavily. 

In fact, Spectro Cloud is my first employer whose flagship product is not open source. Although Spectro has a vibrant open source office, sponsoring projects like Kairos, and the MAAS Cluster API provider, the Palette platform is a closed source commercial product. 

I still hold the open source model close to my heart, and I’ve heard all the valid concerns and arguments that the community raises about closed source. I’ve been burned too by various vendors offering a convenient version of their product only to dramatically increase prices years after their product was deployed. So: I hope you can trust me to give a balanced view!

Concern 1: Does closed source cut me off from innovation?

The worry in customers’ words

“If the code sits behind a licence, I will lose the ability to plug in emerging CNCF projects, fork the code if I need a custom feature, or keep pace with new Kubernetes versions.”

Yep, there’s that word: lock-in. By definition, most open source licenses give you a lot of freedom. But the real world is a bit more nuanced than open vs closed.

A broader definition of ‘open’

Openness is not a single dimension. It spans standards compliance, documented interfaces, upstream contributions, community engagement and, yes, access to source code. Palette is closed in the narrow sense of a commercial licence, but wide open in almost every other respect.

• Standards first. Palette leans on upstream Cluster API (CAPI) for lifecycle automation, so every cluster we create is 100% conformant. Remove the Palette namespace and you are left with plain vanilla Kubernetes — no foreign CRDs or secret sauce required.
• Ecosystem neutral. Because we treat clusters as first‑class upstream objects, Helm, Kustomize, Kyverno, Crossplane, OPA and any other CNCF darling work exactly as intended.
• Extensible. Out of the box Palette gives you choice of dozens of supported integrations (both commercial and open source), from operating systems to your choice of distro, service mesh, monitoring tool, etc. And we encourage you to bring your own repos, build your own packs, to add whatever you choose.
• Contributing back. Spectro Cloud engineers maintain or regularly commit to projects such as Kairos, the CAPI MAAS provider, LocalAI and several others, working both in our dedicated open source office, or during their dayjobs and weekends elsewhere in the business. Closed source at the product level does not equal closed doors at the community level.

Closing the loop (pun intended) on the original concern: you absolutely can adopt the next hot project from the CNCF landscape on Palette, just as you could with a home‑grown stack — the difference is that you spend your time deploying innovation, not building the plumbing.

Concern 2: What if the vendor goes bust?

The landscape view

If you’re worrying about the risk of a commercial vendor going bust, you’re not alone. But open source has no monopoly on longevity. 

Of the 416 practitioners surveyed for our 2024 research, more than half had already suffered a project or vendor disappearing, and 55% explicitly fear vendors shutting down. 

At the same time, GitHub statistics show that fewer than half of new repositories remain actively maintained after five years. 

Projects get abandoned all the time, officially or practically. Many projects only have one (!) maintainer.  Would you trust production use to a project last updated two years ago, when the maintainer has got bored and moved on? When there are no bugfixes or CVE patches? Do you have the resources to step in as a maintainer? Closed or open, continuity is never guaranteed.

Mitigating vendor risk with Palette

• Self‑hosted and offline capable. You can run Palette entirely within your own infrastructure, air‑gapped if necessary. The control plane needs no phone‑home. If Spectro Cloud were to vanish tomorrow, your management instance and your clusters would continue to run for as long as you needed.
• Exit‑friendly architecture. Because clusters are native CAPI objects, you can delete our namespace and keep operating with kubectl, or switch to any other CAPI‑compatible tool. No exotic storage formats or proprietary agents remain.
• Contractual safeguards. Our enterprise agreements can include source‑code escrow and extended support clauses. These are standard mechanisms used across the software industry to protect buyers of proprietary platforms.
• People, not just code. Remember the open source maintainer burnout problem. A commercial vendor employs engineers whose full‑time job is to fix bugs and cut releases. That day‑to‑day reliability can be just as valuable as an open repository.

An illustrative contrast is Mirantis Lens. Hailed as an open source Kubernetes IDE, Lens shifted to a paid model in 2023, removing significant parts of the public codebase. The move sparked community backlash not because proprietary software is inherently bad, but because users had assumed permanence where none existed (news.ycombinator.com).

Concern 3: Surely open source is cheaper?

The hidden line items

It’s hard to argue with ‘free as in beer’, but in today’s world, open source projects are rarely powered by altruism alone. Most are backed by businesses with monetization road‑maps. The common playbooks are to gate advanced features behind a hosted or “enterprise” edition, or to sell support contracts — knowing that a community Slack channel is thin insurance at 3 a.m.

The software license might be free on paper, but if you need to pay to upgrade to unlock features, or to get a basic support contract, you might not be saving anything at all versus a commercial product.

The cost of your own time

Now layer in the effort curve. The 2024 State of Production Kubernetes found that 77% of adopters felt Kubernetes complexity had actively inhibited their progress. Enterprises today run dozens of clusters, in 5+ different environments, with a rich and complex software stack in each cluster. 

Building and maintaining a home‑grown management stack for that estate is a material opportunity cost. OSS tools may be free, but you get no onboarding help. It's likely to be rough around the edges, with limited documentation. In fact, a company that’s trying to sell premium support contracts is actively incentivized to make their community documentation and support worse, to drive users to upgrade.

Without a customer success team, it’s all on you to spend time setting your software up, operating it, patching it, etc. Depending on skills availability, priorities within the team/company and long-term strategy, your best might be to invest in software or in time for your staff/contractors.

Palette’s cost equation

With Palette, the subscription price is usage-based, visible and predictable. What you do not pay for is the engineer‑weeks your team would otherwise spend wiring together Helm charts, CI pipelines, upgrade automation and compliance tooling. Many of our customers have reallocated those people to product features that drive new revenue, rather than platform toil.

Concern 4: Is closed source less secure?

Sunlight helps — but it’s not sufficient

There is undeniable value in open scrutiny. Yet recent events show that visibility alone cannot neutralize risk. In March 2024, a contributor slipped a sophisticated backdoor into the popular XZ Utils compression library. The malicious code made it into several Linux distribution betas before a vigilant engineer flagged an anomaly (arstechnica.com). The episode demonstrated that even high‑profile open source projects can harbor threats for weeks or months.

What commercial vendors add

Spectro Cloud undergoes regular SOC 2 Type II and ISO 27001 audits, publishes scannable artefacts for every release and maintains a dedicated security response team. When a critical CVE issue lands on the desk, a funded team is on the hook to produce and validate a patch fast — not just when volunteer cycles allow.

Our secure development lifecycle includes signed container images, supply‑chain scanning and third‑party penetration testing. None of these practices depends on the public reading our source code; they depend on process, accountability and resources.

Shared responsibility, not binary trust

Of course Palette is not magically bulletproof. The right question is whether the vendor’s security posture complements your own. With Palette you gain detailed hardening guides, pre‑built CIS benchmarks and sensible default network policies. You can also inspect the runtime artefacts in your own registry and run additional scanners if you choose.

In practice: What happens if you want to leave Palette?

Let’s dig in more to your exit strategy, because I know this is an important part of your decision to adopt a platform like Palette.

So the scenario: you’ve purchased Palette and deployed it across your estate (in the cloud, on the edge, or in your data centers: for hosting Kubernetes on bare metal or for running Virtual Machines). 

You want to make sure you don’t have to rebuild all of your clusters if for one reason or another you’d move away from Palette. How exactly would you achieve that? 

In all three scenarios, there’s no direct dependency of your clusters on Palette (this permits us to scale to thousands of clusters), but devil is in the details. So let’s work through the examples.

Cloud

This is the easy option. If you switch Palette off today, all of your clusters will still be running, as they’re physically running in your cloud. You’ll now have to manage all of your day-2 operations (Helm chart upgrades, K8s upgrades, monitoring, etc) manually, but your clusters are still completely with you. You can continue using native cluster management mechanisms offered by cloud providers. It’ll be cloud-provider specific, as at the end of the day they all want you to live in their respective ecosystem, but it’s doable.

Data center

Bare metal Kubernetes use case

If you used one of our providers for installing clusters, such as vSphere, MAAS or even OpenStack, then your cluster is based on Cluster API. Like with cloud, you can simply switch Palette off: your clusters are all still there, but you will need to find another tool for managing day-2 operations. If you found another Cluster API-based solution, you should be in position to simply run a cluster takeover process from it.

Virtual Machine use case

If you’re homing VM workloads in Kubernetes, using Palette’s VMO, you’ll know that it’s based around KubeVirt, which is an open-source solution. 

Remove Palette, and KubeVirt is still there. However, managing the ecosystem around KubeVirt will become your responsibility. Basically, it’s like assembling your own car when you have just an engine. Is it something that you can theoretically do? Absolutely! Is it an approach you would choose and recommend to others? Depends on your circumstances of course.

Edge

Edge use cases need some secret sauce components to cope with edge-specific problems, including a fully immutable operating system. In reality that will most certainly mean that you’ll have to apply a lot of manual management. Fortunately, today there’s a plethora of tools available for it: Crossplane, Terraform, Ansible or hardcore REST API calls. Edge can be different in various deployments, so it’s difficult to provide an exact migration scenario, but some guidelines around your replacement solution you should consider:

• How would you upgrade your OS, assuming you keep our open-source Kairos solution?
• How would you push your new containers to all of your devices at scale?
• How would you deal with device misbehaving/disappearing from your new console?

So you want out?

The implications of leaving Palette depend on how you’re using the many features of the platform, such as RBAC/SSO, logging, monitoring and others. Let’s examine them one by one.

RBAC/SSO

That should be fairly straightforward: nowadays most Kubernetes management solutions support OIDC/SAML integrations. You’d simply need to point your Palette replacement to the same authentication/authorization source to get users, groups and passwords. You’ll need to recreate Palette-provided roles though.

Packs

These will need to be replaced by Helm charts. While most Palette packs are available to consume comparable Helm charts, that’s not the case for all of them. Also, a level of QA testing for Helm charts differs across the community. Hence, Your Mileage May Vary: it’s possible it’s going to be a simple swap, but it’s also quite possible you’d have to do a noticeable amount of testing yourself.

User interface

Changing habits is always challenging. If you want to abandon Palette (or any product with UI), you’ll have to change your habits, unless you’ve been driving Palette via API or Terraform. No real technical effort here, just a human one.

CI/CD integration

Depending on the level of integration, it’s highly likely that some code modifications will be necessary. Perhaps a chance to review your choices or CI/CD orchestration if you were with Flux, ArgoCD or others.

Bringing it all together

Closed source, open source — the licence is only one part of the due‑diligence puzzle. The bigger questions are about standards compliance, exit options, total cost of ownership and operational rigour. Yes, Palette is proprietary, but I hope you can see we’ve engineered it for minimal risk (for example, your exit strategy), and maximum value in a true TCO calculation, even versus ‘free’ software. 

If you’re weighing up the pros and cons of open vs closed software in your K8s environment, we’re here to have an honest conversation. Get in touch here.