Should we open-source our internal developer platform? That is the question I brought to the audience during this talk. Instead of a traditional presentation, I gave a live demo of the Zühlke Platform Plane and then opened the floor for an honest discussion about the benefits, risks, and realities of open-sourcing a commercial platform product.
What is the Platform Plane?#
The Platform Plane is an internal developer platform that goes far beyond what most people think of when they hear “IDP.” It was born about two years ago from a shared investment between Zühlke and LGT, a private bank in Liechtenstein. LGT came to us and said: “We want to build a platform, but not just for ourselves. Let’s make a shared investment because we think other companies can benefit too.”
The result is a platform that spans the entire software lifecycle, from development through to production, covering both cloud and on-premises environments. It runs in a developer cloud where external and internal developers can access it, with the same platform deployed in production and on-prem. This means teams use the same pipelines and tools in development and production, which massively reduces friction.
Architecture: Domain-Driven and Tool-Agnostic#
The architecture follows domain-driven design. We identified the different domains (repositories, container registries, security, observability, deployment) and created unified integration blocks for each. Tools are never integrated directly with each other. They are always integrated through the platform.
Why? Consider GitLab as an example. GitLab loses roughly $50 million every quarter. If Google buys the company, everything is fine. If Broadcom buys it, you might want to swap that tool very quickly. The floating platform principle, described in Gregor Hohpe’s book “Platform Strategy,” ensures you can play Lego with your tools.
The whole concept is: integrate all tools, DevOps platforms, and cloud providers into your floating platform so you can standardize processes and tool usage. The critical rule is: never duplicate the features of integrated tools, or your platform will become dependent and start to sink.
Live Demo Highlights#
During the demo, I showed the Zühlke instance of the Platform Plane, which currently serves 445 users, 14 partners, and 22 spaces across 15 Kubernetes clusters. Here are the highlights:
Partner Management: The partner concept lets you onboard external companies. Using Azure Entra ID (with Keycloak migration underway), partners bring their own identity. An owner can onboard someone, and within a second, that person gets access to all integrated tools and repositories. Offboarding is equally instant. Compare that to my recent experience at a large company where it took three weeks to get access.
Spaces: Each space is a network zone using the hub-spoke pattern. Teams get their own isolated environment where they can run VMs, Kubernetes clusters, or whatever they need.
Security (DevSecOps): Every repository is automatically scanned for vulnerabilities, license compliance issues, and secrets using Trivy. Developers do not need to configure anything. Credentials are stored in a vault automatically.
Golden Path Templates: When creating a new repository, developers can choose from templates that include predefined infrastructure and GitOps configurations.
Container Registry: Full vulnerability scanning, layer visualization, and even an AI-powered container analysis feature that was built in just eight hours because the platform APIs made it easy.
Kubernetes Management: Applications deployed via GitOps through Argo CD. Built-in log aggregation through Grafana, service graphs via Tempo, and pre-configured dashboards. Developers do not need to care about logging configuration.
Service Catalog: Developers self-service provision databases, Azure OpenAI endpoints, and more. No passwords, no backup configuration needed.
Release Management: Releases are created in the developer cloud and pulled into production environments, with vulnerability reports attached. Release managers in regulated industries can approve deployments with full traceability.
The Open Source Discussion#
After the demo, I asked the audience three questions: Should we open-source it? What are the benefits and risks? How can we convince management?
The discussion was rich and nuanced. Here are the key perspectives that emerged:
The “land and expand” model: One audience member pointed out that companies like HashiCorp and Terraform open-source their tools as a go-to-market strategy. Developers adopt the open-source version, it gets embedded in infrastructure, and then professional services and enterprise licenses follow. The question is whether this business model applies here.
Community is everything: Open-sourcing only makes sense if you can build a community. Without community adoption, it does not help. With a community, you get more developers than you could ever afford to pay. But building that community requires significant investment in marketing, documentation, and onboarding.
Subscription model compatibility: Since the Platform Plane already uses a subscription model, open-sourcing would not fundamentally change the revenue model. People buy subscriptions for support and services, not for access to the software itself. Those who want to run it without paying for support would never have become paying customers anyway.
“There is no real risk to revenue. The risk is the time investment needed to nurture the community and build critical mass.”
The onboarding challenge: Setting up the platform currently takes weeks because of the many integrations, different APIs, and customer-specific configurations. If developers cannot get it running quickly, they will not contribute. This same problem exists whether the product is open or closed: a proper product needs great onboarding.
Partial open-sourcing: One suggestion was to open-source parts of the platform, similar to how Backstage operates. The core is open, and commercial services layer on top. This could attract developers who want to build integrations for their own tools.
Competition with existing solutions: The platform competes with Red Hat Developer Hub, Backstage, VMware Tanzu, and others. But none of them cover the full lifecycle from ideation to production the way the Platform Plane does.
The Current Position#
The honest answer is that we are still evaluating. Right now, the ROI is better without open-sourcing because we are early-stage and cannot yet predict how many clients will adopt the platform. But the arguments for open-sourcing are compelling: more eyeballs on the code improve security, community contributions accelerate development, and adoption could grow faster.
The most pragmatic advice from the audience was: focus on making the platform easy to set up and run. Whether it is open or closed, the onboarding experience is what determines adoption.
Key Takeaways#
- A developer platform is more than a portal. The Platform Plane covers the full lifecycle from ideation through production, including on-premises deployments.
- Tool integration through the platform (the floating platform principle) protects you from vendor lock-in and enables tool swaps without disrupting teams.
- Open-sourcing is a business decision, not a technical one. It requires community building, great onboarding, and a clear revenue model.
- Subscription models survive open-sourcing. People pay for support and services, not for code access.
- Onboarding friction is the enemy of both open-source adoption and commercial success. Making setup fast and simple is a prerequisite for either path.
- The discussion showed that there is no single right answer. The decision depends on the organization’s readiness to invest in community building and the strategic bet on market adoption.