Sollten wir unsere interne Entwicklerplattform als Open Source veröffentlichen? Das ist die Frage, die ich dem Publikum während dieses Vortrags gestellt habe. Statt einer klassischen Präsentation habe ich eine Live-Demo der Zühlke Platform Plane gezeigt und anschliessend eine offene Diskussion über die Vorteile, Risiken und Realitäten einer Open-Source-Veröffentlichung einer kommerziellen Plattform eröffnet.
Was ist die Platform Plane?#
Die Platform Plane ist eine interne Entwicklerplattform, die weit über das hinausgeht, was die meisten unter «IDP» verstehen. Sie entstand vor etwa zwei Jahren aus einer gemeinsamen Investition von Zühlke und der LGT, einer Privatbank in Liechtenstein. Die LGT kam zu uns und sagte: «Wir möchten eine Plattform bauen, aber nicht nur für uns selbst. Lasst uns gemeinsam investieren, weil wir glauben, dass auch andere Unternehmen davon profitieren können.»
Das Ergebnis ist eine Plattform, die den gesamten Software-Lebenszyklus abdeckt, von der Entwicklung bis zur Produktion, sowohl in der Cloud als auch On-Premises. Sie läuft in einer Entwickler-Cloud, auf die externe und interne Entwickler zugreifen können, wobei die gleiche Plattform in der Produktion und On-Premises deployiert wird. Das bedeutet, dass Teams die gleichen Pipelines und Tools in Entwicklung und Produktion nutzen, was die Reibung massiv reduziert.
Architektur: Domain-Driven und Tool-agnostisch#
Die Architektur folgt Domain-Driven Design. Wir haben die verschiedenen Domänen identifiziert (Repositories, Container Registries, Sicherheit, Observability, Deployment) und für jede einheitliche Integrationsblöcke geschaffen. Tools werden nie direkt miteinander integriert, sondern immer über die Plattform.
Warum? Nehmen wir GitLab als Beispiel. GitLab verliert ungefähr 50 Millionen Dollar pro Quartal. Wenn Google das Unternehmen kauft, ist alles gut. Wenn Broadcom es kauft, möchte man das Tool vielleicht sehr schnell austauschen. Das Floating-Platform-Prinzip, beschrieben in Gregor Hohpes Buch «Platform Strategy», stellt sicher, dass man mit seinen Tools Lego spielen kann.
Das gesamte Konzept lautet: Alle Tools, DevOps-Plattformen und Cloud-Provider in die eigene Floating Platform integrieren, um Prozesse und Tool-Nutzung zu standardisieren. Die entscheidende Regel: Nie die Features der integrierten Tools duplizieren, sonst wird die Plattform abhängig und beginnt zu sinken.
Live-Demo: Highlights#
Während der Demo habe ich die Zühlke-Instanz der Platform Plane gezeigt, die derzeit 445 Nutzer, 14 Partner und 22 Spaces über 15 Kubernetes-Cluster bedient. Hier die Highlights:
Partnermanagement: Das Partnerkonzept ermöglicht das Einbinden externer Unternehmen. Über Azure Entra ID (mit laufender Keycloak-Migration) bringen Partner ihre eigene Identität mit. Ein Owner kann jemanden einbinden, und innerhalb einer Sekunde erhält die Person Zugang zu allen integrierten Tools und Repositories. Das Offboarding ist ebenso sofort. Im Vergleich dazu hat es bei mir kürzlich in einem Grossprojekt drei Wochen gedauert, bis ich Zugang zu allem hatte.
Spaces: Jeder Space ist eine Netzwerkzone im Hub-Spoke-Muster. Teams erhalten ihre eigene isolierte Umgebung, in der sie VMs, Kubernetes-Cluster oder was auch immer benötigt wird betreiben können.
Sicherheit (DevSecOps): Jedes Repository wird automatisch mit Trivy auf Schwachstellen, Lizenz-Compliance und Secrets gescannt. Entwickler müssen nichts konfigurieren. Credentials werden automatisch im Vault gespeichert.
Golden-Path-Templates: Beim Erstellen eines neuen Repositories können Entwickler aus Templates wählen, die vordefinierte Infrastruktur und GitOps-Konfigurationen enthalten.
Container Registry: Vollständiges Schwachstellen-Scanning, Layer-Visualisierung und sogar eine KI-gestützte Container-Analyse-Funktion, die in nur acht Stunden gebaut wurde, weil die Plattform-APIs es einfach machten.
Kubernetes-Management: Applikationen werden via GitOps über Argo CD deployed. Integrierte Log-Aggregation über Grafana, Service-Graphen via Tempo und vorkonfigurierte Dashboards. Entwickler müssen sich nicht um Logging-Konfiguration kümmern.
Servicekatalog: Entwickler provisionieren Datenbanken, Azure-OpenAI-Endpunkte und mehr im Self-Service. Keine Passwörter, keine Backup-Konfiguration nötig.
Release Management: Releases werden in der Entwickler-Cloud erstellt und in Produktionsumgebungen gezogen, mit angehängten Schwachstellenberichten. Release Manager in regulierten Branchen können Deployments mit voller Nachvollziehbarkeit freigeben.
Die Open-Source-Diskussion#
Nach der Demo stellte ich dem Publikum drei Fragen: Sollten wir es als Open Source veröffentlichen? Was sind die Vorteile und Risiken? Wie können wir das Management überzeugen?
Die Diskussion war reichhaltig und differenziert. Hier die wichtigsten Perspektiven:
Das «Land and Expand»-Modell: Ein Zuhörer wies darauf hin, dass Unternehmen wie HashiCorp und Terraform ihre Tools als Go-to-Market-Strategie als Open Source veröffentlichen. Entwickler übernehmen die Open-Source-Version, sie wird in die Infrastruktur eingebettet, und dann folgen Professional Services und Enterprise-Lizenzen. Die Frage ist, ob dieses Geschäftsmodell hier zutrifft.
Community ist alles: Open Source ergibt nur Sinn, wenn man eine Community aufbauen kann. Ohne Community-Adoption bringt es nichts. Mit einer Community bekommt man mehr Entwickler, als man je bezahlen könnte. Aber den Aufbau dieser Community erfordert erhebliche Investitionen in Marketing, Dokumentation und Onboarding.
Kompatibilität mit dem Subscription-Modell: Da die Platform Plane bereits ein Subscription-Modell nutzt, würde Open Source das Umsatzmodell nicht grundlegend ändern. Kunden kaufen Subscriptions für Support und Services, nicht für den Zugang zur Software. Wer es ohne Support betreiben möchte, wäre ohnehin nie Kunde geworden.
«Es gibt kein echtes Umsatzrisiko. Das Risiko liegt in der Zeitinvestition, die nötig ist, um die Community aufzubauen und eine kritische Masse zu erreichen.»
Die Onboarding-Herausforderung: Die Einrichtung der Plattform dauert aktuell Wochen wegen der vielen Integrationen, verschiedenen APIs und kundenspezifischen Konfigurationen. Wenn Entwickler es nicht schnell zum Laufen bekommen, werden sie nicht beitragen. Dieses Problem besteht unabhängig davon, ob das Produkt offen oder geschlossen ist: Ein gutes Produkt braucht ein grossartiges Onboarding.
Teilweises Open-Sourcing: Ein Vorschlag war, Teile der Plattform als Open Source zu veröffentlichen, ähnlich wie Backstage. Der Kern ist offen, und kommerzielle Services bauen darauf auf. Das könnte Entwickler anziehen, die Integrationen für ihre eigenen Tools bauen wollen.
Wettbewerb mit bestehenden Lösungen: Die Plattform konkurriert mit Red Hat Developer Hub, Backstage, VMware Tanzu und anderen. Aber keine davon deckt den vollständigen Lebenszyklus von der Idee bis zur Produktion so ab wie die Platform Plane.
Die aktuelle Position#
Die ehrliche Antwort: Wir evaluieren noch. Aktuell ist der ROI ohne Open Source besser, weil wir uns noch in einer frühen Phase befinden und noch nicht vorhersagen können, wie viele Kunden die Plattform übernehmen werden. Aber die Argumente für Open Source sind überzeugend: Mehr Augen auf dem Code verbessern die Sicherheit, Community-Beiträge beschleunigen die Entwicklung, und die Verbreitung könnte schneller wachsen.
Der pragmatischste Rat aus dem Publikum war: Konzentriert euch darauf, die Plattform einfach einzurichten und zu betreiben. Ob offen oder geschlossen, das Onboarding-Erlebnis entscheidet über die Akzeptanz.
Kernaussagen#
- Eine Entwicklerplattform ist mehr als ein Portal. Die Platform Plane deckt den gesamten Lebenszyklus von der Idee bis zur Produktion ab, einschliesslich On-Premises-Deployments.
- Tool-Integration über die Plattform (das Floating-Platform-Prinzip) schützt vor Vendor-Lock-in und ermöglicht Tool-Wechsel ohne Störung der Teams.
- Open Source ist eine Geschäftsentscheidung, keine technische. Sie erfordert Community-Aufbau, grossartiges Onboarding und ein klares Umsatzmodell.
- Subscription-Modelle überleben Open Source. Kunden zahlen für Support und Services, nicht für Code-Zugang.
- Onboarding-Reibung ist der Feind sowohl von Open-Source-Adoption als auch von kommerziellem Erfolg. Schnelles und einfaches Setup ist die Voraussetzung für beide Wege.
- Die Diskussion zeigte, dass es keine einzelne richtige Antwort gibt. Die Entscheidung hängt von der Bereitschaft ab, in den Community-Aufbau zu investieren, und von der strategischen Wette auf die Marktakzeptanz.