The Open Container Initiative Launches, Standardizing Container Formats

The Open Container Initiative (OCI) launched on June 22, 2015, founded by Docker, CoreOS, and a broad coalition of industry players — created specifically to establish open, vendor-neutral standards for container image formats and runtimes.

Why standardization was needed at this specific moment

By 2015, container adoption was accelerating rapidly, but the ecosystem risked fragmenting around competing, incompatible image and runtime formats — Docker’s own format was the de facto standard, but competitors including CoreOS’s rkt had begun proposing alternatives. Rather than letting the ecosystem split into incompatible camps, the founding members chose to establish shared, open specifications everyone could build against.

A broad, genuinely competitive coalition

Founding members included direct competitors and major cloud/infrastructure players alike: Amazon Web Services, Cisco, Google, IBM, Microsoft, Red Hat, VMware, and many others, alongside Docker and CoreOS themselves. That breadth was itself significant — the container ecosystem’s largest players agreeing to collaborate on shared standards rather than compete purely on incompatible formats.

Docker’s direct contribution to bootstrap the project

Docker donated its own draft specifications and a substantial amount of existing code for its image format and container runtime to launch the initiative — rather than the OCI starting from a blank slate, it began from a working, already-widely-deployed foundation that the broader industry then continued developing collaboratively.

What the OCI actually standardized

The OCI’s output is a small number of focused specifications: the Runtime Specification (how a container actually gets executed), the Image Specification (how a container image’s filesystem layers and metadata are structured), and the Distribution Specification (how images get pushed to and pulled from a registry) — together defining container portability at exactly the layers where incompatibility would have mattered most.

The Runtime Specification defines the configuration, filesystem bundle, and lifecycle expected by an OCI runtime. The Image Specification defines manifests, configuration, layers, descriptors, and content-addressable relationships. The Distribution Specification standardizes registry API behavior. Implementations can conform at one layer while differing substantially in orchestration, networking, storage, security defaults, build features, and user experience.

Standards enabled specialization

Once image and runtime boundaries were shared, tools did not need to be vertically integrated. A builder could produce an OCI image, a registry could distribute its blobs and manifests, containerd or CRI-O could manage execution, and an OCI runtime such as runc could create the low-level container process. Kubernetes could orchestrate above those components without defining a proprietary image format.

That modularity widened choice but also made provenance more important. Compatibility answers “can this artifact be consumed?” rather than “should it be trusted?” Signatures, attestations, software bills of materials, vulnerability management, registry authorization, and admission policy remain separate controls.

Portability has precise limits

An OCI image can still fail on another system because its CPU architecture is absent from the manifest list, the kernel lacks a required feature, runtime configuration differs, or the application assumes a particular filesystem, user, network, or device. The standards create interoperable artifact and execution contracts; they do not make every workload platform-independent.

OCI specifications evolve through published releases and conformance work. Producers and consumers need to declare supported versions and test actual combinations. The initiative’s lasting contribution is not that container tooling became identical, but that competition moved above common foundational contracts rather than repeatedly fragmenting them.

Why this mattered for the ecosystem’s long-term health

Standardizing these formats meant a container image built with one tool could reliably run under a different vendor’s runtime, and a registry implementation didn’t need to support every tool’s proprietary protocol separately — the same kind of portability guarantee that made container runtimes like containerd and CRI-O interoperable rather than mutually incompatible silos, directly enabling the multi-vendor container ecosystem that exists today.

Related:

Sources: