IMO, they shouldn't get behind rkt, because it too is owned and primarily developed by a company who uses it as a commodity to sell their own products as well, and the same concerns arising from Docker wholly owning development against Docker Engine could very easily arise against rkt as well.
I believe an independent project managed by a board of shareholders would be better for us all.
We (CoreOS) built rkt because we feel strongly that the container engine should be a stable and fundamental building block of software. By itself rkt is not a product and we want to ensure it is something that can be integrated into other systems. For example, we continue to add rkt support to Kubernetes[1] to provide a user transparent option for container engines. Similarly, there are integrations with Mesos and others.
Also, rkt has had significant external contribution like the virtual machine isolation work from Intel[2]. We have spun out independent projects like the Container Networking Interface (CNI)[3] that is now used in Kubernetes, Cloud Foundry, and Mesos.
Stable and robust components are necessary to make this ecosystem work for people operating them. And we built rkt to help the entire ecosystem (and yes ourselves) be successful with that. The product strategy ends there. If a community of folks felt putting rkt into an independently managed foundation would help achieve that goal we would be happy to do that work with others.
But, I think the project has a good track record of working with others and focusing on a narrow feature set.
Out of curiousity, where do you feel that Docker has less of a focus on stability than rkt, is it just in releasing swarm or in other areas?
Whilst I'm more familiar with Docker than rkt it seems that both projects are still changing quite quickly and have a lot of movement in terms of features being added & changed...
rkt tries to stay out of the way for everything that isn't "download, validate, and execute a container". For example, it doesn't know about networks but will hook out to CNI to setup a network namespace. It isn't an init system and will instead rely on a system init system to monitor it. It doesn't do any clustering but can be used by things like Kubernetes.
I'd agree that if it seems that containerization is a fundamental part of an OS that it would make sense to have a neutral platform for it.
That said there were containerization efforts in this area in the past (e.g. LXC) which never really seemed to attract the same kind of traction as Docker.
Ultimtely if people want to create containers, it's entirely possible to do with pure linux commands and no upper-level software at all, it's just Docker makes it much easier/nicer to achieve :)
> Ultimately, if people wanted to create [text files], it's entirely possible to do with pure linux commands with no upper level software at all, it's just [Sublime Text] makes it much easier/nicer to achieve.
It's absolutely possible (see: Bocker), but not a very productive way to go about things. It's much more productive to take an existing technology and make it better than to start from scratch (yet again), especially with permissive licenses like those used in Docker Engine.
possibly although unless they got a decent number of the original developers across in a fork (Which seems somewhat unlikely) it would be a pretty difficult thing to pull off to maintain/develop the codebase.
Not sure I can think of a case where a fork has been successful without a decent percentage of the original developers supporting it.
I believe an independent project managed by a board of shareholders would be better for us all.