Docker Introduces the Moby Project

Docker announced the Moby Project at DockerCon 2017 in Austin, Texas on April 18, 2017, as a structural reorganization of Docker’s open-source components. Solomon Hykes, Docker’s founder and CTO, introduced Moby as an open framework of modular components from which container systems — including Docker itself — could be assembled. Moby encompassed the building blocks Docker had developed over four years: containerd (container runtime, donated by Docker to the CNCF in March 2017), runc (the OCI-compliant low-level runtime, originally submitted as the reference implementation when Docker co-founded the Open Container Initiative in June 2015), LinuxKit (a toolkit for building minimal, immutable Linux distributions optimized for container workloads), BuildKit (a next-generation image build backend with parallel layer execution and improved caching), SwarmKit (orchestration primitives), and Notary (content trust and signing). Docker simultaneously rebranded its products: what had been “Docker” (free) became “Docker CE” (Community Edition), and “Docker CS” (commercially supported) became “Docker EE” (Enterprise Edition), clarifying the commercial/open-source boundary. The docker/docker GitHub repository was renamed to moby/moby, which caused immediate confusion among the large number of contributors who had contributed to that repository expecting to contribute to the Docker product.

The community reaction to the Moby announcement was substantially negative, for reasons that reflected genuine ambiguity in Docker’s original project governance. Many contributors had submitted code to the docker/docker repository believing they were contributing to the open-source tool they used daily; the Moby reorganization reframed those contributions as building blocks for a commercial product platform rather than the consumer CLI tool. Docker’s clarification that Docker CE would continue to be freely available and built from Moby components did not fully resolve the concern that the governance structure had changed without community input. The announcement also arrived at a moment of competitive pressure: Kubernetes had definitively won the container orchestration market by 2017, and Docker’s Docker Swarm (launched November 2015 as Docker’s own orchestration solution) had been outcompeted by Kubernetes’s operator model, Helm package management, and CNCF ecosystem support. At DockerCon 2017, Docker acknowledged Kubernetes’s dominance by announcing native Kubernetes integration into Docker CE and Docker EE — a significant strategic pivot from promoting Swarm as the default orchestrator.

The Moby Project reflected a broader maturation in container infrastructure that made modular composition both possible and necessary. By 2017, container-related specifications had stabilized under the OCI (image spec v1.0 and runtime spec v1.0, both released July 2017), allowing any OCI-compliant runtime to execute any OCI-compliant image regardless of which tool produced it. The ecosystem had fragmented productively: container runtimes included runc, containerd, CRI-O (Red Hat’s Kubernetes-focused runtime using OCI), and gVisor (Google’s sandboxed runtime announced 2018); image builders included Docker’s own BuildKit, Kaniko (Google), Buildah (Red Hat), and Bazel for hermetic builds. Registries included Docker Hub, Google Container Registry, Amazon ECR, Azure Container Registry, and self-hosted Harbor (CNCF project). Moby’s modular approach acknowledged this reality by treating each component as independently useful rather than bundling them into a monolithic tool. For developers, the practical impact was minimal in 2017 — the Docker CLI and docker run / docker build / docker push commands worked identically after the Moby reorganization. The longer-term impact was accelerating the transition toward Kubernetes-native tooling that bypassed the Docker daemon entirely for production workloads, using containerd directly via the CRI interface that Kubernetes 1.5 (December 2016) had introduced.