Update 4

Maintainers recently voted continuing releases #5293. The next release date is temptative for sept. 22nd.

With the contributor support we are seeing on community meetings, and remaining actions taken by the maintainer team regarding contributor burnout, my thoughts is that the "big elephant in the room" is now addressed.

Thanks a lot to all the people and companies involved. Hopefully, this awareness persists so that we are never ever close to a similar spot again.

Update 3

Since our last update, more than 300 people from across the globe and different organizations have signed up to
contribute. This is incredible - thank you! 🙏. We were expecting only a handful of volunteers - it turns out we cannot reach out to that amount directly, sorry!

We’ve also heard valuable feedback: not everyone can contribute code, but many still want to help. In parallel, we’ve spoken with the CNCF, who shared guidance on ensuring long-term project health.

Governance & Contribution Ladder

To provide clarity and structure, we’ve updated our Governance model and added a Contribution Ladder.
The ladder now has four roles:
Contributor → Member → Reviewer → Maintainer

✅ Everyone who engages with the project in any way is already a Contributor.
✅ Consistent Contributors can self-nominate to become Members.

Members are expected to help with:

• Triaging issues and participating in discussions
• Continuing to contribute features and improvements
• A member can self nominate to become a reviewer

Reviewers are expected to help us with reviewing Pull Requests and design decisions.

We’ve also defined specific tracks where people can focus their efforts, beyond general maintainership:

• CI – GitHub Actions and automation
• Testing – improving frameworks, platform conformance, and contributor experience
• Core – the main controller codebase
• Providers – provider-specific implementations

More tracks may be added as the project evolves. Let us know if you miss anything you’d like to see and be able to help 🙏

In addition, we’ve introduced interim roles, and nominated two interim maintainers to help with the heavy lifting required to keep ESO healthy. If you’re interested in becoming an interim reviewer/interim member, let us know! (either as a github issue or pinging in #external-secrets-dev slack channel

How to Get Involved?

For each track, we’ll create initiatives - long-term features, refactors, or automation that reduce maintenance overhead and improve the contributor experience. The best way to do this is by going to our project board:
External Secrets. It contains all the open issues by tracks and our open initiatives.

If you want to get involved, the best way to start is:

• Contribute on Issues - Either by helping out issues triaged as triage/support or by helping us reproduce bugs.
• Contribute with code - Help us implement new features or fix bugs - related or not with a given initiative.
• [optional] - Express your interest to join an initiative - these are issues labeled with kind/initiative and are umbrella issues;
• Review PRs – this directly helps maintainers and is the clearest path toward becoming a Reviewer or Maintainer.
• Join a track – contribute in the area that best matches your skills and interests.

You can also check our community guidelines for more information.

Releases are still paused, though

While we trust the newcoming maintainers, we can only go back to release software when we are confident we have a healthy contribution lifecycle, via this contributor ladder. This means we need to spend time exercising, testing, adjusting it before we feel confident enough to release it.

What does “Healthy” mean? Well, it means we are on a good track to move to incubation within CNCF:

• 6 Consecutive community meetings with at least 5 members/reviewers/maintainers joining;

• We have continuous contributors joining our ladder;

• Permanent reviewers elected;

• Permanent maintainers elected;

All of our contribution status on LFXInsights are marked as healthy

This is a process that can take at least 6 months. Please, plan accordingly.

---

Update 2:

OMG thank you all for signing up. We weren't expecting such a positive response from the community <3

Update

We've decided to stop releases until more long-term maintainers join our team.

If you want to, have the capacity, and the organization support to help, please signup here https://forms.gle/Hgv7igBYNnATmzP28

Original Text

Hey everyone 😄.

TL;DR - I think external-secrets as a project is unhealthy. I think we should either remove our support scope entirely or move this project to a maintenance-mode and dedicate our resources only to support it.

First of all, we've discussed this on today's community meeting - which as always had maybe 0.001% of overall external-secrets userbase. So, i'm making this public as an issue to:

1 - Give transparency on what's going on
2 - Show my suggestions on how to make it sustainable
3 - Allow the community to decide what to do forward (even if it is 'do nothing').

It's been quite a while since I'm feeling we (maintainers) have simply 'too much to do'. Our contribution number increases, the support request increases
but unfortunately the active community members to help this project to grow (by helping, maintaining, etc), is shrinking.

Our maintaining team is mostly burnt out. I am on the path of burning out, where things that used to bring me joy (like helping out users), are not anymore (heck, I've been more and more rude with the community people! So, for sure I am already very much affected with the overload here).

I really can only say our only active maintainer these days is @Skarlso - which is a bad sign. Last week when he was on vacations, we had 0 Pull Requests merged, + 20 issues open (most of them support issues).

Rant done - we need to discuss what we can do for this project to be healthy. Here are my honest, realistic suggestions:

1. We have people from the different enterprise companies using and distributing external-secrets to step up and provide maintaining help, until we have at least 5 maintainers.
   I am not adding here the "mentor junior people to become maintainers" as a realistic option because, well, I don't think that's realistic (😆). We would need more time that we don't have to fully do it - so we need people that are somewhat already used to maintain a project.

OR

2. We either accept the fact our maintainer team is always going to be fewer than 5 active maintainers (where, as I've stated above, I do not consider myself active) AND:

• Define the maintainer role solely for contributions and bug fixes, removing supporting issues altogether (i.e. auto-close issues triaged as support);
• Stop supporting the most consuming deliveries - like versioned releases, weekly patches, e2e testing, etc (probably more if we realize they're consuming, like FIPS images).

OR

3. We move this project to a "maintenance mode" - probably after 1.0.0 - and we only address critical bugs and security issues - refuse All feature requests and keep up the support to users (including security patches, releases, e2e tests, etc.).

OR

4. We collectively give up as no organization really cares enough to step up and we believe doing either 2 or 3 is impractical for whatever the reason (like threats from the community 😆); Then we communicate CNCF to start up the archival of this project.

OR

5. Ignore me. Maybe I'm going crazy, IDK. That's also an option we can do.

Honestly, I believe options 2 and 3 (and 5) are the realistic options we can take here on the short term. I also believe 2 is more realistic than 3, as several security concerns are addressed in new designs we did not start to implement. So, IMO, we should decide if our energy goes to new features OR supporting users - as even if we do have enough companies volunteering resources to maintain external-secrets, it will still take a lot of time to bring them up to speed (time that ,if I personally had, I wouldn't be creating this issue in the first place). Also it allows us to take feedback from the community and if needed, go 4.