How the Moby Project Pivots Docker’s Open Source Business Model

410

When Docker creator Solomon Hykes announced the Moby Project at DockerCon, he said it was very close to his heart. It was the second most important project since Docker itself.

What makes the Moby Project so special for Hykes is that it fundamentally changes the Docker world. It changes the way Docker is being developed and consumed. It changes the relationship between Docker the company and Docker the ecosystem, which is the open source community around the project. It changes the entire business model.

Moby, and other components that Docker has open sourced, are result of the continuous pressure the community has been building on Docker to componentize Docker. There was growing  criticism of Docker that, instead of being building blocks, Docker was becoming a monolithic solution where ecosystem had no say in the stability and development of those components. There were even rumors of forking Docker. The company responded by releasing core components of Docker to address these concerns. Componentizing Docker addresses those concerns of the community.

“It [Moby] has a more fruitful, more central role in how Docker does open source in general, and it’s our answer to a few different concerns that were articulated by the community over time and also an answer to a problem we had,” said Hykes.

There are many factors that, over a period of time, led to the creation of the project. It’s no secret that Docker containers are experiencing an explosive growth. According to Hykes, Docker Hub downloads have gone from 100 million to 6 billion in the past two years.

With this growth, there has been increasing demand for Docker on more platforms. Docker ended up creating Docker for Windows, Docker for Mac, Docker for Cloud, Docker for Azure…bare metal, virtual machines, and what not.

Over time, Docker has released many core components of Docker, the product, into open source making them independent projects. As a result, Docker became modular, which actually made it easier to build all these separate editions.

As Docker worked on these specialized editions, using the open source components, the production model started to break down. They saw wasted efforts as different teams working on different editions were duplicating efforts.

“There’s a lot of work that’s platform specific, and we’ve created pooling and processes for that,” said Hykes. “For creating different specialized systems out of the same common building blocks, because at the end of the day you still need to run containers for Docker. You need to orchestrate, you need to do networking, etc.,” he continued.

Hykes compares it with the car industry where manufacturers share the same components for totally different cars.  Docker is not a huge company, they don’t have all the engineering resources in the world to throw at the problem. They were using the same components for different editions, so all they needed was to create a very efficient internal assembly line to build these systems and solve the problem. Then, they decided to open source this project, which puts all these different open source components together. And, that assembly line is the Moby Project.

Moby has become upstream for Docker. Every bit of code that goes into Docker goes through Moby.

If the relationship between the Moby and Docker reminds you of Fedora and RHEL, then you are right. That’s exactly what it is. The Moby Project is essentially Fedora, and Docker editions equate to RHEL. Moby is a Docker-sponsored project that’s upstream for Docker editions.

“There’s a free version, there’s a commercial version, and the consensus is that at some point beyond a certain scale, if you want to continue to grow both the project and the product, at some point you owe it to both of them to separate them, give them each a clean, well-defined space where the product can thrive as a project and the project can thrive as a product. So, in a nutshell, that’s what Moby is,” Hykes said.

Now the ecosystem and the community can not only contribute and improve the independent components that make Docker, they can participate in the assembly process. It also means they can build their own Docker to suit their own needs.

“Docker is a citizen of this container ecosystem, and the only way for Docker to succeed is if the ecosystem succeeds,” Hykes said.

The Moby project comprises three core components:

  • A library of containerized back-end components (e.g., a low-level builder, logging facility, volume management, networking, image management, containerd, SwarmKit, etc.)

  • A framework for assembling the components into a standalone container platform, and tooling to build, test and deploy artifacts for these assemblies.

  • A reference assembly called Moby Origin, which is the open base for the Docker container platform, as well as examples of container systems using various components from the Moby library or from other projects.

And because all of the Moby components are containers, according to the project page, creating new components is as easy as building a new OCI-compatible container.

Growth of Docker, the company

Moby solved another problem for Docker: identity crisis. Hykes admitted that there was some confusion between Docker the company, Docker the product, and Docker the project. That confusion has been lifted by the creation of the Moby Project.

“Anything with Docker mark is product land, and anything with the Moby Project name or related to it involves open source specific projects created by the open source community, not Docker itself,” said Chris Aniszczyk, executive director of the Open Container Initiative, an open governance project — formed in 2015 by Docker, CoreOS, and others —  for the purpose of creating open industry standards around container formats and runtime.

But the creation of Moby has repercussions beyond Docker. “Moby is allowing other people to take parts of the Moby stack and make their own respective product, which people do,” said Aniszczyk.

“Communities can use these components in their own project. The Mesos community is looking at containerd as the core runtime, Kubernetes is looking at adding support for containerd through its CRI effort. It allows tools to be reused across ecosystems, at the same time allowing Docker to innovate on the product side,” Aniszczyk continued.

Along with the freedom to innovate on the product side, Docker has brought in enterprise veteran Steve Singh as CEO.

“I think With Singh coming in, Docker will have a focus on enterprise sales. With Moby and Docker Enterprise Edition, we will see Docker trying to mimic what Red Hat has done with Fedora and RHEL. We will see them push enterprises toward paid Docker Enterprise Edition,” said Aniszczyk.

Evolution of the platform

Right now, containers are the focus of the discussion but that will change as the platform matures. Aniszczyk compares it with the web. Initially, the discussion was around CSS, HTML, and file formats. W3C standardized what it meant to be CSS and HTML. Now the actual innovation and competition is happening between web browser, between developer tooling, different browser engines…  on performance. Once you create a web page, it works everywhere.

The same standardization is happening in the container world, where organizations like OCI are standardizing the container format and runtime, the core components. Just as there are different web frameworks like ReactOS, Angular.js, there will be different components and orchestration platforms in the container world, such as Docker Editions, OpenShift, Kubernetes, Mesos, Cloud Foundry. As long as there are standards, these projects are going to compete on features.

“I think in five years, people will talk less about containers, just the way we don’t talk about CSS and HTML,” said Aniszczyk. “Containers will be just be the plumbing making everything work; people will be competing at a high level, at a product level that will package technologies like Kubernetes and OpenShift and so on.”

Want to learn more about containers? Containers Fundamentals (LFS253) is an online, self-paced course designed for those new to container technologies. The course, which is presented as a series of short videos, gives a high-level overview of what containers are and how they help streamline and manage the application lifecycle. Access all the free sample chapter videos now!