In the TOC meeting today there were a number of questions around Helm. I can add a little more context and some links. If there additional questions please feel free to ask.

When it comes to Helms scope it might be useful to look at Debian Apt. Helm is inspired by apt in many ways. For example, anyone can run a repository and you can have more than one of them. This means we can have static repos, open source projects that implement push/pull servers, and proprietary projects (jFrog Artifactory) that can all be registries. Another example is the way it can be used in corporate environments with mirrors, internal projects, and so forth.

While implementation details will vary because of the nature of the platform, the same types of features you can find in apt are found in Helm.

There were questions around what's owned by the Kubernetes project. Brian can add more context than I can but the short version is that the Kubernetes project is focusing on core Kubernetes rather than projects that sit on top of it or around it. Something like Helm would not be considered to be part of the Kubernetes project if it were a decision today. Numerous things around Kubernetes have been proposed recently and the guidance was to do them in the ecosystem.

Kubernetes, as a project, is attempting to focus on core Kubernetes. It provides a boundary where the project can handle managing itself and not try to manage too many things.

The Kubernetes project doesn't want to bless any one project or way of doing things when it comes to that which is beyond core Kubernetes. This includes package management, developer tools, and so forth. There is a goal to allow and even enable a competitive landscape. This has even lead to asks of moving Helm out of Kubernetes to help Kubernetes be less biased.

Along with that, a platform can have multiple package managers. For example, ubuntu has both apt and snaps. The experience around those can be quite different and that's OK.

When it comes to the numbers, Helm is the package manager people use. Kubepack, the package manager Brian brought up on the call, only showed up once on the Kubernetes Application Survey. When Helm was gaining traction there was KPM competing against it. KPM had a lot of potential and good ideas. Helm gained far more traction and now KPM is no longer maintained.

At the moment there are no other package managers competing with Helm that have traction. That's not to say what will happen but rather an observation of the current state.

Personally, I'm quite OK with competition because, I think, it can push competing projects to be better than if they were left on their own.

Helm is focused on the package manager problem. There's a blog post with diagrams to show how it can related to other projects. There are tools built on top of Helm such as Armada, landscaper, and helmfile. Helm isn't trying to expand into these spaces though some people are trying to bend it that way. Instead, the helm team is trying to encourage more of these projects to be used.

Helm v3 is currently under development and you can learn more about it in the proposal for it. Some of the design changes and the philosophy is to provide better interoperability and extension mechanisms. As the community has grown and people want to interact with various other tools we're looking to make that easier.

I'm happy to dig into more of this. You can respond here or reach out to me personally. I'm happy to help fill in any gaps.

Regards,

Matt