OCI: Speaking the Same Language

The Container Wars and Why Standards Matter

In 2014–2015, the container ecosystem was fragmenting. Docker had its own image format and runtime. CoreOS was building an alternative called rkt (Rocket) with a different image format. If you built an image with Docker's tooling, it was not guaranteed to run on CoreOS's tooling, and vice versa. The ecosystem was heading toward the same fragmentation that plagued early virtualization.

To prevent this, Docker, CoreOS, Google, Microsoft, and others formed the Open Container Initiative (OCI) in June 2015 under the Linux Foundation. The OCI's mandate was to define vendor-neutral, open standards for container technology. It produced two foundational specifications:

1. The OCI Image Spec: Defines exactly how a container image must be structured — the layered filesystem (as a series of tarballs), the image manifest (a JSON file listing the layers), and the image configuration (the default command, environment variables, exposed ports, etc.). Any tool that produces an OCI-compliant image can be consumed by any tool that reads OCI images.

2. The OCI Runtime Spec: Defines exactly how a compliant runtime tool must behave when given an unpacked image bundle. It specifies the format of the config.json file (which describes the container's root filesystem, namespaces, cgroups, capabilities, and mounts) and the lifecycle operations a runtime must support: create, start, kill, delete, and state.

Because of OCI, the container ecosystem is now genuinely interoperable. You can build an image with Docker's buildkit, push it to a registry, pull it with containerd, and run it with runc — or with any other OCI-compliant runtime. The standards are the glue that makes the relay race possible.