Who actually makes decisions about Keycloak? – Open Source SSO

April 2026

Author: Sadrick Widmann

Open Source SSO and the reality behind Governance

Keycloak is one of the best-known open-source projects in the field of Identity & Access Management – and at the same time one of the most widely used Open Source SSO solutions in enterprises that want to operate single sign-on, identity federation, or authentication standards such as OAuth2 and OpenID Connect themselves.

Especially in tech-savvy companies, you often see a move toward open source with the idea:

“We can operate and control this ourselves.”

Keycloak also appears regularly in public administration – particularly in Germany. There, open source is often equated directly with sovereignty.

(We explained why this equation falls short in our previous blog: Digital sovereignty through open source: cure-all or fallacy?)

At first glance, this seems logical:
The code is open.
The software can be operated independently.
No one is forced to use a specific provider.

Open Source SSO and Keycloak, one of its best-known implementations, promise: complete control, no licensing costs, and no vendor lock-in.

But if you take a step further, another, more crucial question arises:

Who actually decides the future of Keycloak?

An Open Source project – with a clear origin

The software was originally developed by Red Hat and remains heavily influenced by that environment to this day. Alongside the community version, there is a commercial distribution: Red Hat Build of Keycloak.

The project has since been transferred to the Linux Foundation.

But even though the project is now organized under the umbrella of a foundation, a closer look reveals that the actual development and direction continue to be largely driven by developers from the Red Hat and IBM ecosystems.

This model is typical of many successful Open Source projects:

Community project
Commercial distribution
Support and subscription models

This is not inherently problematic. But it highlights an important reality:

Open Source – even within a foundation – does not automatically mean that a project is managed independently of individual companies.

Who actually writes the code?

A look at the contribution data paints a very clear picture.

Keycloak sovereignty? - Dependence on a few organizations, as illustrated by the ‘Authored a Commit’ statistics

Looking at the “Authored a Commit” figures for the last 365 days makes it clear:

46% come from Red Hat
35% from IBM
10% from Hitachi

This means:
👉 Over 80% of development comes from two organizations
👉 Over 90% comes from just three organizations

And even this distinction is only partially meaningful. Red Hat has been part of IBM since 2019. This means that large portions of the development effectively originate from the same corporate environment.

A similar picture emerges when considering not just code contributions, but the entire activity within the project – such as reviews, comments, or maintainer activities:

Keycloak independence? - dependence on a few organizations: The case of the “All Activities” statistics

👉 About 74% of all contributions over the past 365 days also come from the Red Hat and IBM ecosystems.

This assessment is even supported by the Linux Foundation itself. It states: “This project mainly relies on only two organizations, which suggests risk if one withdraws.”

Anyone wishing to examine the data in detail can find it in the Linux Foundation Insights Report.

This shows not only who writes the code, but also who truly understands the product. Over the years, the core expertise surrounding Keycloak has been built up precisely within this ecosystem.

Organizations like Red Hat have the expertise to further develop the product, make architectural decisions, and set the direction.

Has the influence of Red Hat and IBM changed as a result of the Linux Foundation?

Keycloak was transferred to the Linux Foundation in 2023.

The expectation: More neutrality. More community. More distributed development.

But the numbers paint a different picture.

Even in the long term – over the last five years – the distribution remains very similar:

73% Red Hat
12% Hitachi
5% IBM

In other words:
👉 The governance structure has changed formally
👉 The actual development has not

Even more importantly: Who decides what gets merged?

A second perspective is at least as important:

It’s not just about who writes the code, but who manages the project and decides which code is included in the project in the first place.

This role is assumed by the maintainers.

They:

review code
decide on pull requests
control the merge process
manage releases

And in many projects, these very roles are held by a relatively small group of people – often with close ties to specific companies.
A look at the current Keycloak maintainers reveals a similar picture:

Here, too, the Red Hat and IBM ecosystems are strongly represented or even dominate – among both active and former maintainers: https://github.com/keycloak/keycloak/blob/main/MAINTAINERS.md

So anyone who relies on Keycloak is not only choosing an Open Source SSO – but indirectly also the corporations that sponsor the project.

Open Source is an option – not a strategy

This is not a criticism of Keycloak. It is the reality of many successful Open Source projects.

Even large projects such as:

Kubernetes
Linux
OpenStack

are significantly shaped by specific companies.

Open Source therefore does not automatically resolve the issue of governance or digital sovereignty.

And this is where it gets interesting: Keycloak is a good example of how Open Source enables innovation and can create a strong technological foundation. But Open Source alone does not answer the strategic questions.

Keycloak is thus – despite the openness of its code – ultimately a product like any other.

A product,