The Open Container Project is born

Over the years, the Linux Foundation has taken on a number of different projects to try to foster collaboration between competitors and potential rivals. These include efforts like Automotive Grade Linux, Dronecode, OpenDaylight, and many others. The most recent entrant is the Open Container Project (OCP), which seeks to develop and promote standards for containers. Behind the scenes, though, it seems clear that part of the purpose of OCP is to help heal the recent rift between Docker and CoreOS, both of which are participating in the project.

OCP was announced on June 22 as a project formed by a long list of industry players: Amazon Web Services, Apcera, Cisco, CoreOS, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware. The announcement also noted that Docker would be contributing the existing code and draft specifications for its container image format and runtime to the project. By the sound of it, that will be the basis of OCP's work going forward.

Things are a little less clear for the App Container ("appc") specification (and its new committee of maintainers). The appc effort was started by CoreOS as a container format and runtime standard that was not controlled by a single company (i.e. Docker). CoreOS's rkt containerization effort is meant to simply be one implementation of appc. The announcement is not entirely clear about what will happen with appc: "The leadership of the Application Container spec (“appc”) initiative, including founding member CoreOS, will also be bringing their technical leadership and support to OCP." It would seem that some of the ideas behind appc, along with backward compatibility with it, will be adopted into OCP's work going forward.

In some ways, the announcement reads like the outcome of a negotiated settlement between Docker and CoreOS, which should probably be seen as a good thing. Appc came about to try to create an industry standard around a container image format and runtime. By donating its technology to a neutral entity (OCP), Docker has turned its de facto standard into an actual standard governed by various industry players—which is the outcome that CoreOS was aiming at with appc.

Based on the OCP FAQ, the project will be trying to maintain compatibility with existing formats and runtimes, while coming up with new specifications in the near term. Those will be driven by the OCP maintainers group. That group was formed by adding two appc maintainers (Brandon Philips of CoreOS and Vincent Batts of Red Hat) to the existing group of libcontainer maintainers (Michael Crosby and Alexandr Morozov of Docker, Rohit Jnagal and Victor Marmol of Google, Mrunal Patel of Red Hat, and two independents: Daniel Minh and Tianon Gravi). The libcontainer project has effectively become the runC project, which is now being developed in the OCP GitHub repository.

Ultimately, the output of the OCP will be the "Open Container Format" (OCF) and tools to work with it, though the project is exploring alternative names for the specification. The FAQ notes that the first draft specification is expected "in a matter of weeks". It will presumably pick up the security focus that has been one of the governing principles behind appc, but it will also try to maintain backward compatibility with the existing Docker format and runtime. As it can, the specification is also meant to embrace other containerization schemes beyond just those from Docker and CoreOS.

The OCF specification is specifically not targeted at things above the container level. As was noted in our recent CoreOS Fest coverage, orchestration (i.e. the tools to manage and deploy large numbers of containers) is the area where many of the vendors involved in OCP will be trying to compete. The idea is that users can build OCP-compliant containers with Docker, CoreOS, or some other vendor's tools then use any of a number of different orchestration platforms to deploy and manage them.

The analogy that seems to be repeated by many of the participants in OCP is based on the railroads. OCF is seen as an agreement on the width of the rails, which will allow vendors to compete based on where the rails have been laid and on who can build the fastest engines. Like all such analogies, this one has its flaws, but it is apt at some level as well.

While Docker's de facto standard has taken the container world by storm, it is too risky for the rest of the industry to allow that situation to continue. All it would take is for some large company to buy Docker to have its "own" containerization strategy, then changing the "standards" to try to shake off competition. Or if Docker were to get into some financial trouble, it might shift gears suddenly in a way that would harm the others. None of that can happen now.

Putting the container format and runtime in the hands of a neutral organization will alleviate much of the concern of Docker having too much control. It will also likely bring even more players into the fold. In that sense, the appc maneuver by CoreOS was a resounding success—regardless of where that specification ends up.

OCP is also yet another example of where the Linux Foundation's "project governance in a box" strategy has paid off as well. By now, the organization can seemingly whip up a foundation-like structure for a project in a matter of weeks. To help settle—heal—fast-moving disagreements like this one, being able to bring together a wide swath of competitors under one roof quickly is quite an advantage. We will undoubtedly see the Linux Foundation do more of this kind of thing. Some may prove to be duds, or to go nowhere, but others may well go far. At first blush, OCP seems like one of the latter varieties.