You're really missing my point. It's not always enough to create a technically successful project. Docker was a _cultural_ revolution, it had its finger on the pulse, and without that revolution Kubernetes would not have the traction it does.

Indeed. The striking difference is that Google's internal culture is (?used to be, at least at the time this documentary takes place) that of: build your static binaries, perhaps bundle a couple of other files in a package (basically a tarball) if you really must, and run in the code in a "container" whose system image is not controlled by the author of the code package but by the place where you deploy the code (the compute infrastructure, ime. the Borg cell). When the admins of the compute infrastructure decide to roll out a new system image they'll let you know and you'll have to coordinate in order to maintain proper hygiene.

The public version of this embraced a fundamentally different status quo: software is a mess. People pull in dependency in many different ways. You may end up using some python code that has a C extension that in order to build requires some C library whose installation instructions are a mix of run some install script after having installed some apt package.

This idea that you build a container with a container (and accepting that the resulting mess is "ok") is indeed something that has to be granted as a form of innovation to docker. It created a whole new industry of people trying to tame the dependency hell and supply chain woes that have been just swept under a carpet.