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 p

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. [1] http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes.html http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-contai... [2] https://coreos.com/blog/rkt-0.8-with-new-vm-support/ https://coreos.com/blog/rkt-0.8-with-new-vm-support/ [3] https://github.com/containernetworking/cni https://github.com/containernetworking/cni