State of Kaniko: Unmaintained?

[lc-guy]

It seems that all the remaining maintainers of this project have retired. Could we get some clarification regarding Kaniko's development situation right now? Is the project being abandoned?

The Gitlab CI docs, for example, reference Kaniko as the first choice when it comes to building container images without doing privileged Docker-in-Docker. Buildah has emerged as an alternative since, but it requires using vfs (which slows down builds quite a bit) and seems to require additional privileges on containers now, which kind of ruins the point.

Thank you in advance.

[next-jesusmanuelnavarro]

Silence seems to give you the answer to your question.

[waldemarmeier]

I do not want to thrash the incredible piece of work that this project is but in my opinion buildah is a real alternative.

I migrated a project from kaniko to buildah. Overall, it was the right move. The concerns regarding the speed of vfs did not materialize. In the opposite, buildah is about 3x faster (even with vfs) and has way better Dockerfile support (e.g. RUN --mount=type=bind ...) which allows to improve multi-stage builds and reduce the size of container images.

That being said, the builds run in podman containers which might be the reason why issues regarding the right set of privileges did not appear.

[sudheej]

How about caching ? Kaniko is far better especially use case with tekton

[NeckBeardPrince]

Top-notch communication from project leadership.

[jboyens]

I understand folks may be upset, but speaking as an occasional open source maintainer myself: We're not entitled to free support, free ongoing maintenance, free anything-else-under-the-sun. We all knew this going in. The maintainers gave their time, effort, and love to this. If they can't or don't want to anymore, that's their prerogative. If the community wants to take on the maintenance, then perhaps it can live on.

With the widespread proliferation of open-source software and libraries, it can seem like the maintainers owe you something, but it has always said:

🚨NOTE: kaniko is not an officially supported Google product🚨

right at the top of the README.

Best I, or any other OSS maintainer can do is offer you a full refund of your purchase price. Thanks @waldemarmeier for the suggestion of buildah. I'll look into it!

[lc-guy]

I understand folks may be upset, but speaking as an occasional open source maintainer myself: We're not entitled to free support, free ongoing maintenance, free anything-else-under-the-sun. We all knew this going in. The maintainers gave their time, effort, and love to this. If they can't or don't want to anymore, that's their prerogative. If the community wants to take on the maintenance, then perhaps it can live on.

With the widespread proliferation of open-source software and libraries, it can seem like the maintainers owe you something, but it has always said:

🚨NOTE: kaniko is not an officially supported Google product🚨

right at the top of the README.

Best I, or any other OSS maintainer can do is offer you a full refund of your purchase price. Thanks @waldemarmeier for the suggestion of buildah. I'll look into it!

I don't think the snark there at the end is necessary. This isn't really about owing anything to anyone; I'm not irked because the project isn't being maintained anymore, I'm irked because there has been no communication over what's going on behind the scenes with the project, or whether we can expect things to change in the foreseeable future.

Hell, even the fact that the maintainers are gone has only been announced in an open pull request that hasn't been merged yet, which is super easy to miss and a little dubious...

I'm not asking for them to maintain this piece of software forevermore; all I'm asking for is a statement on whether it's abandoned, or someone is stepping back at the helm eventually, or whether the community can organize a fork (many pull requests have been getting ignored over the past year and a half) without starting fork wars with the original repo, etc.

It would take 5 minutes to write out such a reply; even saying they don't know would be fine. And we're talking about 3 maintainers leaving in the last 3 months for a product that has the semi-official backing of a company, not just a single dude who's gone offline for an extended time and won't reply because of that...

I'm not gonna say this is about professionnalism, because really, it's just basic community tact.

[jboyens]

I don't think the snark there at the end is necessary.

Maybe. I do, however, argue that it's helpful to make the point. My style could be argued, but :shrug:

If I give a little snark to remind folks in a humorous way about the social contract and it saves hundreds of posts or people getting irate: seems worth it.

To extend the point: It's highly likely we'll never get a sufficient answer. We don't know what's going on behind the scenes. While it may seem super simple to drop an issue or update the README to say: "We don't know what will happen, but right now there are no maintainers." doing so, unfortunately, carries a lot of baggage. Abandoning a project that is even semi-popular usually results in some sort of uproar. It gets posted to a news aggregator, maintainers get doxed, phones ring, emails fly... You do get messages of support and sometimes folks understand, but lot of times you just get a lot of demands and vitriol. It can be really hard to cope with it all; especially if you value building a good community. Add on the fact that they could be prohibited from saying anything by a legal team even if it isn't an official product. It's not hard to see why just stepping away into might be the healthier option... It didn't used to be this way, but times change.

To your point of whether the community could organize a fork, we sure could! It's just hard to see with the current state of things that it would be even remotely safe to do so. Even if the folks behind the project wanted to give maintainership to another group or the community at-large, passing off the project brings a whole new level of risk (see liblzma backdoor). It kind of always had that risk, but it's been a point of discussion and worry of how all this works going forward.

I'm just as dependent on this project as anyone else is. I've got to change a lot to make this work with a new system, but to me, it was worth it. The code was there to read and use, I learned a few things, and it helped me move away from the super-jankety VM that I connected to over SSH for my CI pipelines before.

All that said: you do you. I'm just a user of the software. I just hope everyone can understand that it's just software. It's disappointing for sure, but I'm thankful for their contributions to the community all the same.

[bclodius]

This message from one of the last two maintainers kind of confirms they have moved on: https://github.com/GoogleContainerTools/kaniko/discussions/3316#discussioncomment-10965197

[bhack]

There was an effort this summer to move it to CNCF https://github.com/cncf/sandbox/issues/88

Also skaffold is slowly dying: https://github.com/GoogleContainerTools/skaffold/issues/2492#issuecomment-2032805645

So I think there is a more general topic related to some tools under the GoogleContainerTools github org.