The advisory board met last month. Here is a writeup http://blog.docker.com/2014/11/docker-governance-advisory-bo...
There is also a link to full minutes.
JB (Google): Docker is an anchor of a large ecosystem of projects. Docker Inc
bought Fig, is it a separate project or is it going to be in Docker?
SH: it should be explicit. The Fig guys make proposals and those are reviewed
as every body else's.
JB (Google): The idea is we will be more comfortable if we know how to
contribute both to Docker and the larger ecosystem.
SH: The day after Docker Inc. acquired Fig nothing changed at all, everything
is still in the Open. The reason for the acquisition was to make Docker more
user friendly. The experience should be awesome. The more people we can throw
at the problem the better.
VL: Understanding what is off limits or at least where the limits are would
be helpful. This is entirely driven by technology? We can collaborate "here"
but maybe we can compete "there".
BG: It's absolutely right, there is a large number of projects competing with
Docker Inc. and that's fine. Some folks want Docker to remain a packaging
format. We should add a statement there on clarifying this.
https://gist.github.com/inthecloud247/00eb3130f728b635db9e
https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg
The Docker team needs some space to execute on the opportunity before them. Space to try, fail, innovate. The end product will be better if they have that space and don't have to achieve equilibrium with too many stakeholders or worry about political microfriction when attempting big leaps.
The bleeding edge is bloody; if you need full-featured orchestration TODAY, your best bet is probably something older than Swarm, Fig, etc.
Docker Machine is separate from Docker. Once Machine was released, what was the point of talking about integrating the functionality into Docker?
They've repeatedly stated that they want Machine and Swarm to be totally separate tools.
Why then is there all this fuss about how these projects are organized? If its a good idea (which it is) won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?
That is not true. It can be just one process. It does not have to be.
> So its just a better Operating System process
No. That's just a tiny bit of what Docker provides, and even that part of what Docker provides is largely "packaging" of cgroups functionality. That was largely there with tools like LXC
The real value Docker provides is a means of building and managing images, and mediating things like capabilities and port mapping in a user friendly way
> won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?
Not a chance. There's no reason why these things needs to be done in kernel space. Some features that they may want, such as improvement to filesystem overlay support, or low level "plumbing" to make overlay networks more efficient, could end up in the kernel if someone comes up with something good, but there'd still be plenty to do for the userspace tools.