Container advocates remember why a Unix application can't run on all versions of Unix. They know why a virtual machine can't run with just any hypervisor. Different vendors tweaked the underlying mechanics in the code just enough to distinguish their version from all others, imposing a mind-numbing complexity on customers.

Leading developers at CoreOS, Docker, Red Hat, Suse and Kubernetes, among others, were all too familiar with the resulting variability, complexity and tendency to fail. Two years ago, with community tensions showing, they gathered behind a common standard and produced a specification and reference implementation of a shared container environment.

The Open Container Initiative was that effort, and this morning the initiative brought forth its issue: OCI Version 1.0. Red Hat and other major Linux vendors, Kubernetes, Docker, CoreOS, Cloud Foundry and Mesosphere have flocked behind the standard and already incorporate OCI code into their products.

"There were jokes about the container wars at the time we got started," recalled Chris Aniszczyk, executive director of the OCI, in an interview. OCI is now part of the Linux Foundation. Docker had gotten the jump on other interested practitioners by building a popular container formatting process and Docker container engine. The code was open source, but Docker kept adding to the Docker platform and had the means to change the runtime environment, if it chose to, to shut out of the environment those who had followed its lead.

Want to learn more about how Docker fits into an enterprise container strategy? See Docker Shifts Toward the Enterprise.

CoreOS, supplier of a lightweight version of Linux for running container servers, proposed a shared runtime environment as well as a shared image format. The OCI was formed, originally known as the Open Container Project, then renamed OCI in July 2015, and set about generating a container image specification and a container runtime environment specification. Both now exist in their 1.0 versions on Github.

The specifications and their reference implementations can't erase the differences between computer architectures. Microsoft, for example, became interested in adding containers to its Windows Server environment and did so with the 2016 release of its operating system. But a Windows Container must still run on a Windows Server machine, just as a Linux container must run on Linux servers.

Nevertheless, the shared specification assures container users if they build a Linux container in an OCI 1.0 specified fashion, it's going to run in any OCI 1.0 certified server environment. A common element is the runc library that makes up the core of a Linux container engine and recognizes the elements of a Linux container format as they're unpacked from a disk. Docker originated the runc library and donated it to OCI.

A container amounts to a set of files that put an application together in the order in which it must be fired up, with required elements of its operating environment included. To maintain mobility, the container must move from the version of the operating system under which it was first assembled to a server running that same version, but otherwise the code moves between locations with few hindrances or requirements.

Containers thus are a boon to testing new business applications, moving from development to test to staging and to production, without IT operations scrambling each step of the way to prepare the next environment. OCI 1.0 makes it possible to provide tools for producing containers, moving them around and firing them up that are guaranteed compatible with the code they're handling, explained Aniszczyk.

Docker has taken the concept a step further by building a platform that can be used to generate containers, and then, at the last minute, designating the environment in which they're to run. That means developers could produce a container under Linux but direct toward a Windows Server with automated help from the Docker Platform, according to Stephen Walli, director of Docker open source programs.

"I went through the Unix wars," recalled Walli, when IBM produced AIX, HP produced HP-UX and Sun Microsystems fielded Solaris. "There was a lot of divergence between implementations," he said during an interview. Without the OCI 1.0 specification, container users would need to reformat their containers for each vendor's approach to container serving, such as Red Hat's Atomic Server or CoreOS' CoreOS and rkt engine.

The OCI specification "gives implementers a basis for going forward" and basing tools, container engines and deployment practices on certain assumptions about how a container will be formatted and behave, he said.

Aniszczyk said the OCI will offer courses and testing to ensure vendors who wish to be OCI-compliant are certified as such. "Getting the 1.0 version out the door is step one," he said, with vendors building on the shared standard to build additional support for using containers.

The major cloud environments that offer container launching services, including Amazon Web Services, Google and Microsoft, have said they will keep their services OCI-compliant.

The OCI specification and reference implementation process has been most actively supported by Docker, CoreOS and Red Hat, whose contributions make up more than half of the code included in the reference implementations, said Aniszczyk. Also active in contributing were Suse, Microsoft, Intel, Google, IBM and Huawei, he added. The project has attracted a total of 250 contributors from 40 companies.

The vigorous community and agreement on a 1.0 specification "signals to the wider industry that the whole container space is maturing," said Aniszczyk.