A lot of the cgroup kernel code is from google among others (openvz also notable). The lxc userspace is primarily driven by canonical (and previously ibm).
The release roadmaps of docker and lxc are completely decorelated. lxc reaching 1.0 doesn't mean much for docker - other than perhaps requiring working around yet another reverse-incompatible change.
What's more interesting is progress in the kernel on user namespaces, and stabilization of the cgroups api. That has nothing to do with the lxc userland scripts.
Do you know if the 3.14 kernel will have full support for user namespaces for unprivileged containers? On the LXC blog, they mention requiring 3.13 with some staging patches.
lxc is sort of just a wrapper and is pretty broken (I found around 10 bugs before giving up) why build on lxc? a simple C library (not libvirt) would be much better.
We built on lxc to save time and move faster on the things that differentiate Docker: image management, build from source, a developer-friendly UI, etc.
Now that Docker has traction we can go back and invest more time in a cleaner, leaner implementation of our own.
We have already started gradually: Docker has a low-level implemetation of cgroups, capability dropping, bridge and veth handling, and there is a pull request for namespacing. None of these are rocket science.
No because it's the code itself that is the problem not actual bugs but wrong behaviour lxc has too much to address. It would take me months to work on it.
It's improved, though still a root exploit in the kernel will almost certainly make possible root access to the host. For a lot of situations, this is an acceptable risk.
The real win in the present for containers is simplifying deployment and improving segmentation of services that already might run on the same machine.
