Docker to Donate Another Core Component to a Foundation

The part of Docker Engine that produces container images in response to commands, will be ceded by its steward to the open source community, in a move probably designed to win back support.

Scott Fulton III, Contributor

December 14, 2016

4 Min Read
Docker to Donate Another Core Component to a Foundation

In an announcement Wednesday morning, Docker Inc. — the company behind one of the most rapidly adopted software infrastructure components in history — said it will let go of a critical software component, called containerd (pronounced “container-dee”), donating it to an open source foundation yet to be determined.

“Containerd is a daemon that runs on a single machine, that lets you create containers from that machine,” explained Patrick Chanezon, a member of Docker’s technical staff, in an interview with Data Center Knowledge.

“Containers are based on isolation primitives from the underlying operating system.  Linux has primitives that are called ‘namespaces’ and cgroups, that are used to create these containers.”

A cgroup, or control group, is an artifice of the Linux operating system for staging resources within their own, private namespaces.  It’s the root component of a container, and although Linux has made this feature available for years, it was Docker Inc.’s predecessor company that first had the epiphany of using this construct to stage workloads on cloud infrastructure.

The component being donated to the community, containerd, is presently the part of Docker Engine that produces a container within such a control group, either to be deployed or stored in a registry, Chanezon explained.  Back in the spring of 2015, the format for Docker containers and the runtime library inside of them, called runc, was donated to an open source organization now known as the Open Container Initiative (OCI).

Docker Inc. acknowledged to Data Center Knowledge that this donation would make it feasible for other firms, including its own competitors, to produce OCI-compliant containers using their own engines.  In the company’s discussion with us, David Messina, Docker’s vice president for enterprise marketing, said that’s fair, because the simple ability to produce an industry standard container is no longer a differentiating element of the platform.

What’s more, he pointed out, containerd was already open source, stewarded by Docker Inc. but not owned by it.  The donation to a foundation — which should take place during the first calendar quarter of next year, he said — will effectively cede stewardship to an independent entity.  Runc stewardship was ceded to an entity of the Linux Foundation, though Messina made clear that his company is leaving its options open with respect to the maintainer of containerd’s new foundation.

“The idea of containerd is that, if third-party technologies need a core container runtime, this is the perfect solution for them,” explained Messina, “in that it’s giving them exactly what they need, separate and distinct from all the other pieces of plumbing that they might not choose to use in their platform — which are effectively bundled in Docker Engine.”

It’s this bundling to which Messina referred, which has fueled a storm cloud over his company this entire year.

Last July, the company rolled out version 1.12 of its main Docker Engine platform, which for the first time was bundled with Docker Swarm, its container orchestration system.  Open source advocates saw this as a potentially anti-competitive move, and a play against Kubernetes, the emerging leader in container orchestration which is stewarded by the Cloud Native Computing Foundation (another entity of the Linux Foundation), and is championed by Google.

The move led to a brief period of once-unthinkable speculation that some third party would take Docker’s open source code and produce a fork of Docker Engine, without Docker Swarm bundled with it.

But even the storm around that discussion was squelched when contributors to Kubernetes, including Red Hat, began work on a stand-alone container engine of their own, called CRI-O.  As this reporter first covered for the software developers’ publication The New Stack (to which he still regularly contributes), CRI-O is intended to serve as a free and open source container deployment mechanism (without the accompanying creation mechanism) for Kubernetes, substituting for Docker Engine or CoreOS rkt.

That move was regarded by some as a way for Kubernetes to strike out on its own, Docker-free path.

Yet Wednesday’s move by Docker Inc. may serve two purposes:  One would be to render the creation of a stand-alone deployment mechanism for containers in Kubernetes both academic and moot at the same time.  The other would be to appeal to open source developers who came to suspect Docker Inc.’s motives in bundling Docker Swarm, and in preparing to make similar moves with future versions of Docker Engine — reassuring them that it has no intent to stake any undue ownership claims now, on an open technology that it led the way in evangelizing.

“We’re going to market with a great level of competition, and we’re excited by that,” said Messina.  “I think it furthers innovation.  Competing ideas are great for the market, and for user choice.”

About the Author

Scott Fulton III

Contributor

Scott M. Fulton, III is a 39-year veteran technology journalist, author, analyst, and content strategist, the latter of which means he thought almost too carefully about the order in which those roles should appear. Decisions like these, he’ll tell you, should be data-driven. His work has appeared in The New Stack since 2014, and in various receptacles and bins since the 1980s.

Subscribe to the Data Center Knowledge Newsletter
Get analysis and expert insight on the latest in data center business and technology delivered to your inbox daily.

You May Also Like