I think the key distinction here is unprivileged builds outside a container. Kaniko was aimed at an actually-quite-large problem, which is performing unprivileged building inside a container in a shared cluster.

This matters a lot, because otherwise CI/CD is a serious weak point in your overall security model. Especially if you will run PRs that folks send you -- ie, run sight-unseen 3rd-party code in a privileged container.

In terms of the OpenShift vs local development experience, we heard something very similar about Cloud Foundry too, so now there's `cf local`[0].

Essentially, Stephen Levine extracted buildpack staging into standalone container images (which now use Kaniko) along with a little CLI tool to help you make the local development experience more like the `cf push` one.

As it happens there is a lot of cooperation happening in this space right now -- folks from Google, Pivotal and Red Hat have been comparing notes about container building in the past few months. It's something we share a common interest in improving.

At Pivotal we have also begun closer cooperation with Heroku on buildpacks, which is really exciting. The buildpacks model lends itself to some really cool optimisations around image rebasing[1].

Folks heading to Kubecon this week who are interested in container builds should make sure to see the joint presentations by Ben Parees (Red Hat), Steve Speicher (Red Hat) and Matt Moore (Google).

Disclosure: I work for Pivotal.

[0] https://github.com/cloudfoundry-incubator/cflocal

[1] https://www.youtube.com/watch?v=jsNY4OP3IrE

For folks coming to this later, a correction. The buildpacks team are using the "crane" tool in go-containerregistry[0], rather than Kaniko, as the basis for their daemonless container-building containers.

There is so much container-related work coming out of Google right now that I am struggling to keep up.

[0] https://github.com/google/go-containerregistry