That's assuming Docker doesn't expand its interface to allow for more parts of the platform to be interoperable :)

The whole point of Docker is to introduce simple interfaces to important components of distributed systems, and get a critical mass of people to agree on it, producing interoperability. So far we did this for packaging and sandboxed execution of individual components, with some success. We plan on doing this for other areas in the future, including clustering, stack composition, application networking, service discovery, authentication and access control, etc. This will allow rival implementations to compete in each of these areas, without creating fragmentation. I don't want a World where "CoreOS containers" can't talk to "Atomic containers" or "Mesos containers" because we couldn't agree on a common interface - we can do better than that.

We are pretty open about that plan. The Deis guys know this and are making the bet that embracing "Docker-native" interoperability is good for them.

I think I didn't present what I was saying clearly.

I think you definitely want to be very open about what the inside of the container looks like and even what the interface is between the containers and the rest of the world.

I was thinking about the platform that the containers run on top of. You don't gain anything by using a given host platform, but building alternate components that handle deploying and wiring up those containers. You're better off either using the existing platform's components or contributing patches to it, and the latter really only makes sense if you're adding something distinctive.

I understand. But from the point of view of Deis, CoreOS is not a platform. It is a Linux distro with a loose collection of tools pre-installed, some of which Deis happens to use. One such tool is Fleet. Another is the systemd log journal. Each of those tools has dozens of competitors. Deis reserves the right to pick and choose from those competitors without locking themselves in. It also reserves the right to use some pieces of CoreOS without using the other. If you think of CoreOS as an end-to-end monolithic platform, this may seem strange. But it is perfectly aligned with the Docker philosophy, which is that big monolithic platforms are not a good thing. What you want is a vast ecosystem of small composable lego bricks.

> Deis reserves the right to pick and choose from those competitors without locking themselves in.

Well of course! It is your own project.

> If you think of CoreOS as an end-to-end monolithic platform, this may seem strange.

Yeah, but I'm not looking at CoreOS as an end-to-end monolithic platform. I'm looking at it as a bunch of components that happen to be bundled together, each of which is pretty nice all by itself. It doesn't mean you have to use them all, but on the other hand, you would hope that if you were going to replace one of them entirely you'd go with something with a significant advantage (and I'd argue in some cases it has gone the opposite way).

> What you want is a vast ecosystem of small composable lego bricks.

Understood. I just don't think you help yourself much if you take out one brick and replace it with one of your own, particularly if the new brick isn't any better than the old one (and might be worse).

I should clarify that I am not part of the Deis project, although I know Gabriel and follow their roadmap closely.. Sorry if I wasn't clear.