Health of External Secrets project

[gusfcarvalho]

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: https://github.com/orgs/external-secrets/projects/2. 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.

[gusfcarvalho]

I am also taking the liberty to pin this issue. 🥲 Sorry for doing that with no consultation @Skarlso

[Skarlso]

No worries. I agree.

[IdanAdar]

I can try and step up to review and merge more PRs that I am comfortable with (ie not the code-heavy ones). Used to do that and admittedly neglected in recent times.

[knelasevero]

Thanks for starting this discussion @gusfcarvalho, for proposing a path forward, and for noticing the problems you are raising. Should we define a timeline for this to be discussed here on this issue, and then bring it to a community meeting for final decisions?

[gusfcarvalho]

Should we define a timeline for this to be discussed here on this issue, and then bring it to a community meeting for final decisions?

I think so. IMO, this should be urgent. Whatever we decide, I'd hope we decide it sooner than later. I would personally like to discuss it on the next community meeting. If not possible, on the one after it.

[gusfcarvalho]

I'm honestly personally in favor of 2 because I believe it will trigger a lot of companies to help us with 1. Versioned code is probably the biggest asset we have here to leverage in return of maintainers from more companies.

[Skarlso]

To be clear, I'm still an active maintainer and I'm not planning on stopping to be one. ESO will not shut down as long as I'm around. But obviously, I'm just a single person that works during the day and occasionally goes on vacations. :P So be aware of that.

And, of course, that also means that no one is reviewing my code. :) So making changes becomes a bit difficult at that point.

[gusfcarvalho]

To be clear, I'm still an active maintainer and I'm not planning on stopping to be one. ESO will not shut down as long as I'm around.

Im not suggesting we actively shut down ESO because we are all tired of it (even though I think I need some holidays from it). With our current metrics on time to review PRs, active maintainers, active contributions, etc - we might be going to CNCF project health audit anyways.

And I think it is a part of our role as maintainers to proactively tell them if we think this would fail such an audit (I don’t believe we would as of today, but we are on a very close thin thread IMO).

[Skarlso]

For sure, I just wanted to make that clear. :) 👍

[moolen]

Thanks for writing this up. My 5ct / IMO:

• support is one of the most time consuming tasks and requires a lot of ctx switching and cognitive load. It (usually) doesn't reward the person providing support
• time & effort to bump deps & cutting a release is minor if we lower the frequency of releases and bumps
• reviewing PRs is (for me) the most problematic activity as it (if i want to do it right) requires me to allocate at least an hour to (re-)read code, do manual testing and write appropriate comments. At least for non-trivial changes. Today, i can not afford to reserve a full, uninterrupted hour. At least not at the moment as a parent of two small kids. I guess we can/should consider to invest into tooling to make this less time consuming (@Skarlso used some AI stufff in the past iirc?)

I agree with 2/3.

[Skarlso]

I did start to work on that. I shelved it for now because I actually thought that the majority of the work is support and not reviewing PRs. Until now. :) The Prs actually suddenly increased so maybe I will take that project OFF the shelf. :)

[gusfcarvalho]

Also worth to the discussion: https://insights.linuxfoundation.org/project/externalsecretsoperator/repository/external-secrets-external-secrets?timeRange=past365days&start=2024-08-01&end=2025-08-01

[kamikaze]

Stop the project, get the real life. Nobody cares. Bye.

[gusfcarvalho]

Stop the project, get the real life. Nobody cares. Bye.

Thanks for your useful contribution 😃

Now, please don’t repeat this as it goes against our code of conduct. Failure to do so will be answered with a ban from external-secrets organization.

[identw]

It would be great if you could add GitHub Sponsors (https://github.com/sponsors) as an additional way to support the project, alongside OpenCollective. GitHub Sponsors is more convenient for many users since it doesn’t require separate registration, and most of us already have GitHub accounts. Also, in my case, OpenCollective doesn’t accept my bank card, while GitHub works without any issues.

It seems like you're putting a tremendous amount of effort into the project. Honestly, it's already amazing. Perhaps occasional releases and critical bug fixes would be enough. And if the maintainers sometimes come across as blunt in issue discussions, that's simply the cost of having such a great product. I personally believe it's the responsibility of the person creating the issue to provide clear, thorough, and helpful information for the maintainers.

If the only way to keep the project alive was to completely ignore community issues and focus only on your own use cases, and the project still continued to exist, I would still be very happy with that.

[moolen]

On:

It would be great if you could add GitHub Sponsors (https://github.com/sponsors) as an additional way to support the project

I have considered this, however there is a lot of paperwork that needs to be done and it is not something i am willing to do. To receive GitHub Sponsorship one must need to:

1. fill in tax information
2. have a bank account

That implies (at least in german jurisdiction) that ESO must be a legal entity in order to receive a tax id and be able to open a bank account. We need to prepare, sign and store contracts for forming a legal entity across contry boundaries. On/Offboarding a maintainer requires us to do more paperwork (e.g. remove ability to access bank account, re-do the contracts). Further, depending on the Legal form, we may become liable with our personal capital for whatever other maintainers do (e.g. signing contracts in the name of ESO) or we would have to put in €25k as share capital when forming a GmbH corporation. And then you need to do the taxes on a yearly and quarterly cadence 😵‍💫.

That's quite a lot to ask for, specially when you don't really know your peers (still love you though @Skarlso @gusfcarvalho ❤️)

There is much more to be said on money in OSS (still holding back my rant, will come back with it eventually), but 💸 money is not going to fix the problem - unless we're able to fund a significant amount $~20-50k yearly which is never ever going to happen. We need corporations to spend engineering time on it, that will help.

---

@identw thank you for your kind words, really appreciated 🙇. I don't want this to come over as a rant on the point you've made.

[Skarlso]

Dang it. My dastardly plan is foiled.

[jakobmoellerdev]

Hey folks! I wanted to chime in here and say that sometimes, all it needs is a bang on the table for things to move, and you should do that if you think there is a need for it. @Skarlso and I spoke about the project and when I became aware of the state I wanted to join up forces with you folks.

I would at least be open to contribute more to ESO and I think it's a super valuable project for the K8s Ecosystem so letting it die is something I want to avoid personally. I cannot speak for enterprises (full disclosure, engineer at SAP and we have stake in this project as a company too) - so only speaking as myself here, but I know that there are interested companies that are even considering pushing engineering capacity on their payroll into this project.

Also happy to join next community call and talk open issues new contributors can tackle there.

[ivankatliarchuk]

Worth to start with document and clarify the process for becoming a maintainer ;-)

[gusfcarvalho]

Worth to start with document and clarify the process for becoming a maintainer ;-)

Our governance document already stated that - you just need to ask basically.

But I realize this wasn't as clear as one could read through, so I am pushing some changes to make it 'uber clear': https://github.com/external-secrets/external-secrets/pull/5115

[gusfcarvalho]

On today's community meeting, we had super majority vote to stop Releases until the health of External-secrets via maintaining contributions is re-established.

We will define criteria to when will this happen, but yeah. The short version is - we need help.

[gusfcarvalho]

For those who have the will, capacity & company support to help, please signup this form: https://forms.gle/Hgv7igBYNnATmzP28

[szh]

Wow, this is so tough. If my company would have a team solely dedicated to contributing to upstream OSS projects that would be a dream job for me. This seems to be part of the industry wide problem of enterprises not giving back to open source projects they rely so much on.

[logicalhan]

Have you considered donating the project to sig-auth?

[gusfcarvalho]

Have you considered donating the project to sig-auth?

We had discussions with them - specially how to integrate with sscsi-driver, for a while now. We were not able to find common grounds, and IIRC they have their own implementation based on sscsi manifests https://github.com/kubernetes-sigs/secrets-store-sync-controller

[kaipee]

For those who have the will, capacity & company support to help, please signup this form: https://forms.gle/Hgv7igBYNnATmzP28

Might be worth adding a field to capture the skills of the person completing the form (not just Go proficiency)

[christianhuening]

Thanks for putting this on the table. We're long time users (and thus beneficiaries) of ESO in various companies and also committed the one or the other thing to it. To me the shoutout is helpful as I now know there is an issue (I've been totally unaware). I will see what I can do in my team and org to get some engineering workforce going towards ESO (will take a bit due to vacationing, I know what you mean @Skarlso 🙂‍↕️)

🙏

[mrueg]

Disclaimer: I'm fully aware that this is not an option right now because it adds an extra burden onto the maintainer team.

If you have more capacity, it might be worth looking into https://github.com/cncf/mentoring and see if participating in one of the mentoring programs makes sense for this project. From an OSS project perspective that just started participating in it, the response from potential mentees and new contributors was really positive so far. We hope to convert some of them to maintainers eventually. That might be an option for external-secrets as well.

[gusfcarvalho]

Disclaimer: I'm fully aware that this is not an option right now because it adds an extra burden onto the maintainer team.

If you have more capacity, it might be worth looking into https://github.com/cncf/mentoring and see if participating in one of the mentoring programs makes sense for this project. From an OSS project perspective that just started participating in it, the response from potential mentees and new contributors was really positive so far. We hope to convert some of them to maintainers eventually. That might be an option for external-secrets as well.

Yup, I've applied for GSOC a couple of summers ago for external-secrets , but I wasn't contemplated.

[bavarianbidi]

For those who have the will, capacity & company support to help, please signup this form: https://forms.gle/Hgv7igBYNnATmzP28

We are heavily using ESO in different ways. And for some of our Platforms, ESO is part of the service offering.

I will try to make some people within the organization aware of this and hopefully get some time, or find someone who might have time to become a maintainer.

That said, we're in the middle of the summer season. Hope it's OK if we came back in three to four weeks.