Wer entscheidet eigentlich über Keycloak? – Open Source SSO

Open Source SSO und die Realität hinter der Governance

Keycloak ist eines der bekanntesten Open-Source-Projekte im Bereich Identity & Access Management – und gleichzeitig eine der meistgenutzten Lösungen für Open Source SSO in Unternehmen, die Single Sign-On, Identity Federation oder Authentifizierungsstandards wie OAuth2 und OpenID Connect selbst betreiben wollen.

Besonders bei technologieaffinen Unternehmen sieht man häufig einen Einstieg über Open Source mit dem Gedanken:
„Das können wir ja selbst betreiben und kontrollieren.“

Auch in der öffentlichen Verwaltung – insbesondere in Deutschland – taucht Keycloak regelmäßig auf. Dort wird Open Source oft direkt mit Souveränität gleichgesetzt.

(Warum diese Gleichsetzung zu kurz greift, haben wir in unserem vorherigen Blog: Digitale Souveränität durch Open Source: Allheilmittel oder Trugschluss? eingeordnet.)

Auf den ersten Blick wirkt das schlüssig:

Der Code ist offen.
Die Software kann selbst betrieben werden.
Niemand ist gezwungen, einen bestimmten Anbieter zu nutzen.

Open Source SSO und Keycloak als einer der bekanntesten Vertreter versprechen: vollständige Kontrolle, keine Lizenzkosten, kein Vendor Lock-in.

Doch wenn man einen Schritt weitergeht, stellt sich eine andere, entscheidendere Frage:

Wer entscheidet eigentlich über die Zukunft von Keycloak?

Ein Open-Source-Projekt – mit klarer Herkunft

Die Software wurde ursprünglich von Red Hat entwickelt und wird bis heute stark durch dieses Umfeld geprägt. Parallel zur Community-Version existiert eine kommerzielle Distribution: Red Hat Build of Keycloak.

Inzwischen wurde das Projekt zudem in die Linux Foundation überführt.

Doch auch wenn das Projekt heute unter dem Dach einer Foundation organisiert ist, zeigt ein genauerer Blick: Die tatsächliche Entwicklung und Prägung erfolgt weiterhin maßgeblich durch Entwickler aus dem Umfeld von Red Hat bzw. IBM.

Das Modell ist typisch für viele erfolgreiche Open-Source-Projekte:

• Community-Projekt
• kommerzielle Distribution
• Support- und Subscription-Modelle

Das ist grundsätzlich nichts Problematisches. Aber es zeigt eine wichtige Realität:

Open Source – auch innerhalb einer Foundation – bedeutet nicht automatisch, dass ein Projekt unabhängig von einzelnen Unternehmen gesteuert wird.

Wer schreibt eigentlich den Code?

Ein Blick auf die Contribution-Daten zeigt ein sehr klares Bild.

Wenn man sich die „Authored a Commit“ Zahlen der letzten 365 Tage ansieht wird deutlich:

• 46 % stammen von Red Hat
• 35 % von IBM
• 10 % von Hitachi

Das bedeutet:
👉 Über 80 % der Entwicklung kommen aus zwei Organisationen
👉 Über 90 % aus nur drei Organisationen

Und selbst diese Trennung ist nur bedingt sinnvoll. Red Hat gehört seit 2019 zu IBM. Damit stammen große Teile der Entwicklung faktisch aus dem gleichen Konzernumfeld.

Ein ähnliches Bild zeigt sich auch, wenn man nicht nur Code-Beiträge betrachtet, sondern die gesamte Aktivität im Projekt – also z. B. Reviews, Kommentare oder Maintainer-Aktivitäten:

👉 Rund 74 % aller Contributions der letzten 365 Tage kommen ebenfalls aus dem Umfeld von Red Hat und IBM.

Diese Einschätzung wird sogar durch die Linux Foundation selbst gestützt. Dort heißt es: “This project mainly relies on only two organizations, which suggests risk if one withdraws.”

Wer sich die Daten im Detail anschauen möchte, findet sie im Linux Foundation Insights Report.

Das zeigt nicht nur, wer den Code schreibt, sondern auch, wer das Produkt wirklich versteht. Über Jahre hinweg hat sich das zentrale Know-how rund um Keycloak in genau diesem Umfeld aufgebaut.

Organisationen wie Red Hat haben die Kompetenz, das Produkt weiterzuentwickeln, Architekturentscheidungen zu treffen und die Richtung vorzugeben.

Hat sich der Einfluss von RedHat und IBM durch die Linux Foundation geändert?

Keycloak wurde 2023 in die Linux Foundation überführt.

Die Erwartung: Mehr Neutralität. Mehr Community. Mehr verteilte Entwicklung.

Doch die Zahlen zeigen ein anderes Bild.
Auch langfristig – über die letzten fünf Jahre – bleibt die Verteilung sehr ähnlich:

• 73 % Red Hat
• 12 % Hitachi
• 5 % IBM

Mit anderen Worten:

👉 Die Governance-Struktur hat sich formal verändert
👉 Die tatsächliche Entwicklung nicht

Noch wichtiger: Wer entscheidet, was gemerged wird?

Mindestens genauso wichtig ist eine zweite Perspektive:

Nicht nur, wer Code schreibt – sondern wer das Projekt steuert und entscheidet, welcher Code überhaupt ins Projekt kommt.

Diese Rolle übernehmen die Maintainer.

Sie:

• reviewen Code
• entscheiden über Pull Requests
• kontrollieren den Merge-Prozess
• steuern Releases

Und genau diese Rollen liegen in vielen Projekten bei einem relativ kleinen Kreis von Personen – häufig mit enger Verbindung zu bestimmten Unternehmen.

Ein Blick auf die aktuellen Maintainer von Keycloak zeigt ein ähnliches Bild:

Auch hier ist das Umfeld von Red Hat bzw. IBM stark vertreten bzw. dominiert – sowohl bei den aktiven als auch bei ehemaligen Maintainern: https://github.com/keycloak/keycloak/blob/main/MAINTAINERS.md

Wer also auf Keycloak setzt, entscheidet sich nicht nur für ein Open Source SSO – sondern indirekt auch für die Konzerne, die das Projekt sponsern.

Open Source ist eine Option – keine Strategie

Das ist keine Kritik an Keycloak. Es ist die Realität vieler erfolgreicher Open-Source-Projekte.

Auch große Projekte wie:

• Kubernetes
• Linux
• OpenStack

werden maßgeblich von bestimmten Unternehmen geprägt.

Open Source löst also nicht automatisch die Frage von Governance oder digitaler Souveränität.

Und genau hier wird es spannend: Keycloak ist ein gutes Beispiel dafür, wie Open Source Innovation ermöglicht und eine starke technologische Basis schaffen kann. Doch Open Source allein beantwortet nicht die strategischen Fragen.

Keycloak ist damit – bei aller Offenheit des Codes – am Ende ein Produkt wie jedes andere auch.

Ein Produkt,

• mit einer bestimmten Governance
• mit klarer Prägung durch bestimmte Organisationen
• und mit Abhängigkeiten, die verstanden werden müssen

Open Source nimmt uns diese Realität nicht ab.

Sie suchen mehr Infos zum Thema Keycloak und digitaler Souveränität?

Erfahren Sie dazu mehr auf den folgenden Seiten:

• Digitale Souveränität durch Open Source: Allheilmittel oder Trugschluss?
• Digitale Souveränität
• Auf Wiedersehen SAP IDM – Zeit Identitäten neu zu überdenken
• IAM made in Europe: Digitale Souveränität beginnt mit mutigen Plattformen

Sprechen Sie mit uns darüber, wie Sie die Sicherheit in Ihrem Unternehmen stärken können: Machen Sie einen kostenlosen Termin mit unseren Experten aus.