Open Container Initiative must balance Docker, CoreOS demands

How open is the Open Container Initiative? We’re about to find out.

In theory, the OCI industry consortium has come together to agree on standards for software containers. But one of the OCI’s most prominent members has reservations about what needs to be done and how.

The OCI formally announced its governance structure and is preparing to tackle a potentially messy task: taking what was once the exclusive domain of a couple of creators — mainly Docker —  and turning it into not only a true open standard but an open process for overseeing how the standard will be maintained.

Much of how containers work in the real world revolves around Docker’s product — in the short time Docker’s been on the market, it’s created a whole ecosystem of tooling, infrastructure, and procedures. The challenge for the OCI will be to ensure future work on containers doesn’t invalidate all that’s come before.

In addition to backward compatibility, the OCI lists several values it’s trying to promote. Openness is big one, meaning the standard — both the container format and runtime — is properly specified and community-developed, “to ensure code development drives specification development.”

The exact container format remains a sticking point for CoreOS, one of the OCI’s main members. Long critical of the way container designs have treated security as an afterthought and how the container format seems largely dictated by Docker, CoreOS offered a security-first container design (appc) and runtime (rkt) to compete with Docker’s. 

CoreOS is a critical participant in the OCI. In a blog post released the same day as the OCI announcement, CoreOS took the consortium to task for “solely [focusing] on the runtime, which is more narrowly focused than we anticipated for the project. Our efforts to bring in container image and image distribution of appc have not been incorporated, but we still believe these are important parts of a container standard.”

CoreOS’ rationale for a single container image format is that it obviates the need to repackage the container’s contents for different runtimes or vendor implementations. CoreOS is also pushing for a vendor-neutral option for “how containers are namespaced, discovered, and downloaded,” in the same manner that GitHub uses Git’s version control.

The current OCI spec road map, hosted on GitHub, lists Container Definition as one of the key topics for a draft 1.0 container specification, but it’s not clear whether it includes a definition of the image format. (No owner is currently listed for that part of the spec.) Container discovery also isn’t mentioned. That said, two of the goals listed are Define Container Lifecycle and Full Lifecycle Hooks, so it’s possible discussion of image formats and container discovery might take place later on.

Much of what’s currently included in the OCI’s road map seems driven by the needs of the current generation of container software — by and large, Docker and its immediate family of tooling. For example, the only language binding for the spec is Go, which is the language Docker was authored in.

Even outside of CoreOS’s criticisms, a lot of issues must be addressed.