Re: Helm stagnation or we're missing something?

Adnan Abdulhussein

Hi Dmitry,

Thanks for reaching out. I can't speak for those issues and PRs in particular, but I wanted to make you aware that the Helm community is currently undergoing planning for Helm 3, and as such there are no major features being planned for Helm 2 releases.

Quite a few things are (possibly) set to change in Helm 3. For example, the server-side component (Tiller) is intended to be removed and possibly replaced by a Kubernetes controller. Release state will be stored as CRD objects.

Also, there are some new ideas around how hooks will work in Helm 3. Sounds like you're using hooks quite a bit, so it would be good to have you collaborate on the proposal to make sure what we do there will make sense in your workflow.

It's still early days in the planning, but if you'd like to get involved I encourage you to join the Thursday developer calls (

On Wed, Mar 14, 2018 at 9:41 AM Dmitry Shurupov <dmitry.shurupov@...> wrote:
Dear community!

Helm is crucial in our software stack since we heavily use it in our own CI/CD workflow tool (sorry, we still have no English docs but we'll be improving that soon). It's so important that missing some features means real problems in some parts of our business. Luckily, Helm is Open Source, so we are happy to become a part of its community and share our improvements… however, that's where our issue appears. Almost all our attempts to bring some singificant (for us) updates end up not being really accepted.

Here are examples describing our general feeling:
1. ­— that's our biggest disappointment as we've been doing a lot for logging, however there's no reaction since the very beginning of this issue. Does nobody need it? We are open to hear it — everything can be better than being totally uncertain.
2. — this PR has appeared after we've seen not so successfull attempt to add "wait" feature to "helm init": that previous (not our) PR was accepted but didn't work actually and brought new problems to the code. So, we've decided to clean the code and fix this "wait". It seems developers (not so fast but anyway…) have liked our idea, however they have decided to rewrite everything by themselves. We could have done it also if they just asked us for that… Okay, so here are developers ready to spend their time for this minor thing. What about our next PR?
3. — in this PR, we are requested to make docs + tutorial/example + tests while we haven't seen such requirements for other similar things (already existing policies). It's not we don't want to do it — it's just unexpected to observe this attitude here while minor issues are being rewritten by few developers. Is it only minor changes which are currently welcome in Helm?

If we add some public stats ( and check an overall scope of last PRs being merged (, it just strengthens our belief Helm is stagnating — at least, in public and especially, in contrast to Kubernetes itself. At the same time, it's the official package manager for K8s what makes us really care (and the whole community we hope?). We need some new features*, we are happy to implement them but we are blocked by core developers community of the project to pull (and, sometimes, even discuss) our changes. There can be another guess: some developers are actively working on a big new release of Helm with no real public signs of that (if so, it's not an Open Source way for sure).

Can anybody please shed us some light on what's really happening with Helm and what are the plans for its future? Maybe, all our "feeling" is totally irrelevant and we're doing something wrong?

* At least, we know one more important problem in Helm: isn't it strange to have a package manager which can't really check that the package has been installed successfully?

With sincere hopes to find some ways to work with community efficiently and make Helm better,

Dmitry Shurupov,

Adnan Abdulhussein
Software Engineer, Bitnami
+1 866 870 2383

Confidential - All Rights Reserved.
Bitnami (c) 2018

Join { to automatically receive all group messages.