Motivations Behind the Moby Project

One of the major announcements from DockerCon 2017 is the creation of the Moby Project. Following the extraction of several docker engine components over the last few years (hyperKit, swarmKit, etc), Docker has launched the Moby Project which includes the tools and libraries to piece these components together into a container-based system. Those interested can use the Moby Project as the "lego set" to build a custom solution of components based on their needs.

Continuing on the effort of extracting their internals, Docker has committed to modularizing what's left of their monolithic project: docker/docker. The docker/docker project has been moved to moby/moby for temporary incubation as its being broken down into modular components.

Note: Even though there is some shuffling on Github, none of this affects how the docker-ce or docker-ee products are packaged or distributed. The Moby Project DOES NOT affect how application developers or operators use docker. The project changes how the internals of Docker are pieced together to create the Docker product, but the end-user interface and experience of the Docker Engine will not be affected by this transformation. Dependencies on the docker/docker github project itself will be able to gracefully handle redirects to the new moby/moby project.

I had a chance to listen to Solomon speak about the Moby Project and the motivations behind it. His words were very helpful in understanding why the Moby Project was created, so I will share a couple of those thoughts here:

Drive Community Innovation With Stand-Alone Projects

The goal of extracting out components like InfraKit, Swarmkit etc is to create stand-alone projects, that are driven by needs of the community and are used in other ways besides the Docker engine.

There are still components to be extracted from the docker/docker project, and the launch of the Moby Project acts as a kick-starter to complete this effort. Some of the new components will have merit to stand on their own. Once that happens, expect them to move into their own organizations on Github. Similar to what happened when extracting containerd/containerd.

Product vs Project

Extracting out internals is great in theory, but before the Moby Project, contributions had to answer 2 questions: "Is this contribution good for the project?" and "Is this contribution good for the Docker product?" Moving these projects outside of Docker alleviates this conflict of interest by making a clear separation of product vs project. This allows for Docker to implement changes into their product that are not appropriate for the community projects, and vice versa.

Docker Needs to Scale

Docker runs everywhere: Windows, Linux, Mac, multiple cloud providers. Imagine the task of maintaining feature parity for all of these platforms! One of the reasons for extracting out these components is to allow the community to contribute and drive the upstream components, while Docker can focus on the things that bring business value specific to the Docker product. Loosening control over these parts of the ecosystem benefits the community as well, because the community can use these components for free with their own implementations outside of Docker.

Create Community Around Component Assemblies

The idea behind the Moby Project is to enable a community to develop and share component assemblies and packages. With this new level of collaboration the community can innovate on new tools and projects to solve some pretty big problems in our industry.

The Moby Project is a HUGE step for Docker that is consistent with the commitment Docker has shown to develop their products in the open and will enable community innovation and collaboration on the upstream components of Docker.