> Coming up with a new "standard", then criticizing the established open-source project for failing to implement it, is a common tactic
> One last fact, which you might find funny: one of these alternative implementations of Docker's image distribution system is developed by CoreOS, the very same vendor which is propping up this so-called standard
> Do you know how many complaints I received, since Docker was created, that I didn't "comply" with this or that self-proclaimed standard? Dozens
> But [CoreOS] never did, because as competing commercial vendors their interest is to weaken and fragment the Docker standard, not contribute to it.
~~
> based off the bad blood developing between CoreOS and Docker
You know, I think this is really 1-way... I have not see anything along these levels of hostility coming from the CoreOS camp.
Containerization on Linux is really poised to be the "next big thing", enabling all sort of new workflows, deployments, etc. In order for it to really take off, people need a universal standard image format which is portable to other implementations. There must be multiple competing implementations. It must avoid vendor "lock-in".
Back when virtualization was getting off the ground, there was no standardized format. Every vendor had their own format, and all were completely incompatible with one another. This made migrations incredibly painful, sometimes impossible.
It created a "vendor lock-in" even when it came to the open source hypervisors -- ie. once you decided on a product, you were stuck.
The OVF (Open Virtualization Format) came along after years of this... not without it's imperfections -- but it was a real life saver in a great many ways. Vendors and open-source projects alike started to support the format, allowing users to export their VM's and import them into a different hypervisor with relative ease -- no weird hacky work-arounds, no re-imaging your vm, no nonsense.
~~~~
For this kind of industry-changing technology, it's more important to have an open standard than an open implementation.
Alternate implementations of docker run (e.g. Garden), although a daemonless mode for Docker may satisfy most of these cases.
Alternatives to docker build (plenty of room for innovation here IMO).
Alternative registries.
Personally, I agree with you, just trying to stay neutral with my comment. Recently went to a CoreOS meetup in NYC and from what I can tell the CoreOS guys seem super nice and very knowledgeable, nothing else I've seen anyone representing them say or do in public suggests any malice against Docker.