

Docker Says Absolutely Not to Collaboration on Standard Container Specification - Alupis
https://github.com/docker/docker/issues/9538#issuecomment-65967102

======
debacle
They didn't say no, they just said they wouldn't spend effort conforming to a
3 day old standard that no one was using.

That just makes business sense.

------
katabatic
Irrespective of the public back & forth between Docker and CoreOS, that's a
completely reasonable stance to take. Standards need to be proven in the real
world before being adopted. That's why the ANSI and ISO standardization
process takes so much time (EDIT: or at least, _one_ of the reasons).

When you write "standards" without implementation, what you get is the Object
Management Group, which published spec after spec that are impossible to
actually implement.

------
WestCoastJustin
It might be worth pointing out that Alupis (OP), and Shykes (Docker creator),
have had somewhat of a flame war on HN since Rocket was announced.

~~~
Alupis
I wouldn't really call it a flame war... more or less pointing out issues with
Docker the company. I feel it's greatly important since container technology
is poised to become a very big thing in the Unix ecosystem and we should take
a moment to think about the motives of a commercial for-profit company such as
Docker, before we embed it into everything. Shykes seems to take issue with me
pointing these things out, as I would expect him to.

Anyway, that does not change the content of Shykes' message on Github, which
makes it outstandingly clear he, and Docker, have absolutely zero intention of
collaborating openly on a standardized container format. They had zero
intention of creating a standard format prior to the Rocket announcement, and
just last night have published their own proprietary and incompatible
specification which they now call the standard.

That's not collaboration...

~~~
fluidcruft
Is there anything technically wrong with the Docker format, or do you just
have doses of Lovecraftian fear and uncertainty to offer?

~~~
Alupis
The issue with the Docker format is that there was no format, at least a
standardized one. The image format has changed, and without a formal format
specification, it's subject to future change. That makes it difficult to rely
on when building 3rd party tools, or alternative runtimes.

I'd argue that a single, universal standardized container format specification
is crucial for such a piece of technology that will soon be (is?) at the heart
of all application deployments, both servers and desktops. We can look at the
OVF specification[1] for a clear example of why this is necessary. Back in
2007 the top hypervisor vendors (VMware, Dell, HP, IBM, Microsoft and
XenSource) collaborated and created thhe OVF spec which would allow a virtual
machine which conformed with the spec to be portable between any of their
hypervisors. This enabled users to switch at-will, and provided great
orchestration between clusters of heterogeneous hypervisors.

We've seen how successful a format is when a single for-profit company self-
declares their format as the "standard" for all others to adhere to -- .RPM
promoted by Red Hat. Even today, there are systems that do not use RPM's
because there never was a consensus around what that format should look like
-- It was just declared one day it was the standard because they had market
share.[2]

A world where one becomes locked into any single vendor for any piece of
technology is not good to say the very least.

An inter-operable, collaborated standard is what is necessary.

[1]
[http://en.wikipedia.org/wiki/Open_Virtualization_Format](http://en.wikipedia.org/wiki/Open_Virtualization_Format)

[2]
[http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_R...](http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_RPM_package_format)

~~~
belak
_we should take a moment to think about the motives of a commercial for-profit
company such as Docker, before we embed it into everything. Shykes seems to
take issue with me pointing these things out, as I would expect him to._

What about the motives of CoreOS, also a for profit company?

 _I 'd argue that a single, universal standardized container format
specification is crucial for such a piece of technology that will soon be
(is?) at the heart of all application deployments, both servers and desktops._

Correct me if I'm wrong, but doesn't the new container proposal do the exact
opposite of this? Why not collaborate with Docker on a container format?

From the Github post: _But here 's a suggestion for you. If you were to
complain that Docker's image format and runtime specification, as massively
adopted as it is, is not appropriately documented, and it could be made easier
to produce alternate implementations - then I would completely agree with
you._

You state that Docker has _absolutely zero intention of collaborating openly
on a standardized container format_ however they explicitly invite help into
standardizing and documenting theirs, which is currently the most commonly
used.

This is the last thing I'm going to leave here.
[http://xkcd.com/927/](http://xkcd.com/927/) It may not be the most credible
of sources, however it makes the point I am trying to make quite well. Making
an additional standard when there is already something well established does
nothing but fragment the ecosystem.

You may be questioning the motives of Docker, Inc, however that leaves the
rest of us to question the motives of CoreOS. I did not seen ANY efforts at
collaboration by CoreOS before they released their own container
format/runtime. Especially in the passive-agressive (mostly agressive) way in
which they did it. If their motives were truely to create a "single, universal
standardized container format specification", the first step would have been
to at least attempt to work with Docker to create this. Instead of this
happening, this whole argument has turned into a pissing match between the two
companies. Seriously, both companies need to set aside their differences and
have a real discussion about this, not just doing things on the internet to
piss each other off.

