Open Container Initiative (OCI)

The Open Container Initiative (OCI) is a vendor-neutral, lightweight governance council operating under the umbrella of the Linux Foundation. Its primary responsibility is to govern and maintain low-level, open industry standards for the container ecosystem - making sure that containers built with one tool can run on another.

Why Was the OCI Created?

The Fragmentation Problem

Before the OCI, the early container ecosystem was fragmenting. Docker had grown dominant, but a company called CoreOS was unhappy with that position and created a competing standard called appc, along with a reference runtime implementation called rkt (pronounced “rocket”). Competing container standards meant confusion for users, slower adoption, and tools that couldn’t talk to each other.

Major players - including Docker, Google, VMware, and Microsoft - united to form the OCI in 2015. This allowed the community to archive the competing appc project and consolidate all low-level container specifications under a single, neutral governing body.

Goals

Standardization: Establish universal rules for how containers are built, run, and distributed
Preventing vendor lock-in: Open, public standards mean you’re not tied to any single platform or tool
Interoperability: Build an image with Podman, run it on Docker. Push to Docker Hub, pull with containerd. The spec guarantees compatibility

The Three Core Specifications

The OCI maintains three primary specs that cover the full container lifecycle:

Spec	What it governs
image-spec	The standard format and metadata for container images - how the layered filesystem is serialized and labeled
runtime-spec	The rules for how a container should be executed - what the runtime must do to go from an image to a running process
distribution-spec	The protocols for distributing images - how they are pushed to and pulled from container registries

These three specs together cover the entire journey of a container: from being built as an image, to being stored in a registry, to being executed by a runtime.

The Role of `runc`

To help establish these standards with a working implementation, Docker Inc. donated its internal libcontainer codebase to the OCI. This became the seed for runc - the OCI reference runtime implementation.

runc is a low-level CLI tool that directly creates and runs containers according to the OCI runtime spec. It is not meant to be used by developers directly - instead, higher-level tools like containerd and dockerd call into runc under the hood:

dockerd → containerd → runc → container process

This is why OCI images built with Docker run on Kubernetes without modification: Kubernetes uses containerd directly, which uses runc - the same runtime stack, just with the Docker daemon layer removed.

OCI in Practice: Docker’s Implementation

Modern Docker implements all three OCI specifications end-to-end:

Layer	OCI spec	Docker component
Build	image-spec	BuildKit creates OCI-compliant images
Store	distribution-spec	Docker Hub operates as an OCI-compliant registry
Run	runtime-spec	`containerd` + `runc` is an OCI-compliant runtime stack

This is why the dockershim removal in Kubernetes v1.24 didn’t break images: Kubernetes stopped calling dockerd, but the image format (image-spec) and the runtime underneath (containerd/runc) both stayed OCI-compliant. The container works the same - only the entry point changed.