The health of this repo, an open discussion.

[NeckBeardPrince]

First, I want to thank @mrparkers for all the work he has done; it has been invaluable to both the Keycloak and Terraform communities. Looking at his past GitHub activity, he is certainly a busy individual. That being said, the velocity of this repo has not been able to keep up with the changes being made in the Keycloak project. The current, latest release only officially supports up to 21.0.1, which is from March 2023. I understand that this module likely supports higher versions, but it does not seem to support the latest 24.x.x releases. With close to 200 open issues, 34 open PRs and no activity from @mrparkers I fear this module is going to continue to be unmaintained.

So, I ask, what can this community do to revitalize this repo? Is @mrparkers open to adding additional maintainers? Transferring the project to someone else? I'd love it if Keycloak themselves could pick this up and build on it. I am open to discussion and suggestions.

[mrparkers]

Hi @NeckBeardPrince, thanks for starting this discussion.

It's not really a secret that I've been losing steam maintaining this repo. When I first started this project, I was using Keycloak in production at the company I was working for at the time, and wanted a better way to manage it with the tooling that we were already using. However, I've since changed jobs (twice), and I haven't used Keycloak in production in years. So it's been difficult for me to find the motivation to continue working on this, especially since I don't have production experience with the new versions and new functionality that's been added.

I'm absolutely open to adding new maintainers and even transferring the ownership of the project to someone else. However, recent compromise of other open source projects makes it very difficult for me to do this. This project, even in its somewhat inactive state, is still trusted by thousands of companies around the world to manage Keycloak, which is arguably one of the most security-critical pieces of software you could implement at an organization. I would feel terrible if I handed out maintainer access or transferred ownership and it led to something like this. Ultimately, I think transferring this project to the Keycloak team is the best solution here, but I don't really know if they're willing or able to take this on. If anyone in the community knows the best way to reach out to them, let me know and I can try to get that discussion started.

I do want to say that I feel guilty that I've let so many issues go unresolved and PRs unreviewed. I will try to do a better job of, at the very least, reviewing PRs and getting these changes merged and released. However, I don't think I can commit to working on any new features myself.

[NeckBeardPrince]

@mrparkers I completely understand not wanting to just transfer the project to someone else. Would you be willing to open an issue on the Keycloak to open a dialog with the Keycloak team about taking on the Terraform module? It might be better received if it's coming from the maintainer of the most used and relied upon Terraform module.

[mrparkers]

I've sent an email to the Keycloak team to discuss this. I'll follow up with an issue if I don't hear back soon.

[AchimGrolimund]

i hope it will continue here in this repo, or with another maintainer. i myself use it privately as well as for business. creating a fork of it and developing it myself seems a bit much to me, so i hope it will be continued by the keycloak team.

[gim-]

It's important to understand that Keycloak is driven by RedHat Inc., not community. So far they always prioritised Keycloak Admin UI over Configuration-as-Code approach. There are some steps towards CoC with their CRDs, but last time we've tried it, it didn't support most features that we needed and appeared to be unreliable in some cases. So this Terraform provider was a rescue for us.

The point is, so far the current state of things has worked out for RedHat over many years. I'd really like to see official Terraform provider support from Keycloak team, but I wouldn't keep my hopes up too much. We as a community should think about plan B already to keep this project maintained.

[Breee]

Any news @mrparkers ?

[Woitekku]

RedHat is part of IBM these days, just like Terraform, so in theory there should not be a blocker to release official provider for Keycloak. (keeping my fingers crossed)

[NeckBeardPrince]

RedHat is part of IBM these days, just like Terraform, so in theory there should not be a blocker to release official provider for Keycloak. (keeping my fingers crossed)

Keycloak isn't supported by Red Hat, hasn't been since April 2023. Red Hat used it for an upstream build for their Red Hat build of Keycloak. In the same month, Red Hat donated it to the CNCF. source

[ahus1]

@NeckBeardPrince - the information you're citing there is almost accurate. It should be "uses" and not "used". It is still the upstream source of Red Hat Build of Keycloak, and Red Hat continues to support it with a team of engineers, managers and other resources.

At the same time it is a joint effort with the community to maintain the code base and enhance it with new features.

Full disclosure: I'm one of the maintainers of the Keycloak project, working full time on the Keycloak project and I'm funded by Red Hat.

[Breee]

@ahus1 Would the keycloak team be willing to support this provider? As experts for the API that would be a great addition.

I'm maintainer of https://github.com/crossplane-contrib/provider-keycloak - which directly depends on this provider repository, as we are currently using the tool upjet to generate crossplane resources from the terraform provider.

If this repository stays unmaintained i'm forced to rewrite the crossplane provider from scratch or fork away from this repository to fix what needs to be fixed

[NeckBeardPrince]

@ahus1 Would the keycloak team be willing to support this provider? As experts for the API that would be a great addition.

I'm maintainer of https://github.com/crossplane-contrib/provider-keycloak - which directly depends on this provider repository, as we are currently using the tool upjet to generate crossplane resources from the terraform provider.

If this repository stays unmaintained i'm forced to rewrite the crossplane provider from scratch or fork away from this repository to fix what needs to be fixed

Pulumi also depends on this provider.

[ahus1]

Would the keycloak team be willing to support this provider?

@mrparkers has reached out to Keycloak's project lead. AFAIK there hasn't been a decision yet, and @mrparkers will reveal more information when there is something the share.

[mrparkers]

Yes I forgot to update here - I did reach out to the Keycloak team privately by email. I wanted to avoid publicly putting pressure on the team via GitHub issues.

I will post here if there are any updates.

[tboerger]

I would like to continue the maintenance of this provider with the support of the company I'm working for which will dedicate hours to maintain this project. Is there any update if this repo will be migrated to the Keycloak team? Or should we just fork the repo and start publishing releases within a new namespace?

[grolingm-VU]

Hello everyone,

if not done already please participate in the latest survey from the Keycloak team https://www.keycloak.org/2024/06/realm-config-manamagemtn-tools-survey. This could give this provider the needed gravity.

[NeckBeardPrince]

Hello everyone,

if not done already please participate in the latest survey from the Keycloak team https://www.keycloak.org/2024/06/realm-config-manamagemtn-tools-survey. This could give this provider the needed gravity.

Correct me if I'm wrong here, but doesn't the Pulumi and Crossplane providers also rely on this module?

Edit: @thomasdarimont responded

[pascal-hofmann]

Correct me if I'm wrong here, but doesn't the Pulumi and Crossplane providers also rely on this module?

Yes, they do.