One of the first initiatives to gain widespread industry engagement is the OCI. Among the 36 industry collaborators are Docker, Red Hat, VMware, IBM, Google, and AWS, as listed on the OCI website at https://www.opencontainers.org/.

The purpose of the OCI is to split implementations, such as Docker and rkt, from a standard specification for the format and runtime of containerized workloads. According to their own terms, the goal of the OCI specifications has three basic tenets (you can refer to more details about this in the Further reading section at the end of the chapter):

• Creating a formal specification for container image formats and runtime, which will allow a compliant container to be portable across all major, compliant operating systems and platforms without artificial technical barriers.
• Accepting, maintaining, and advancing the projects associated with these standards. It will look to agree on a standard set of container actions (start, exec, pause, and so on), as well as a runtime environment associated with a container runtime.
• Harmonizing the previously referenced standard with other proposed standards, including the appc specification.

By following these principals, the OCI hopes to bolster a collaborative and inclusive ecosystem that provides a rich and evolving toolset to meet the needs of today's complex application workloads, be they cloud-native or traditional.

There are additionally some guiding principles for the development of standards in this space. These principles were integrated from the founding beliefs of the folks who created appc, and are as follows:

• Security: Isolate containers via pluggable interfaces using secure cryptographic principles, and a chain of custody for both images and application code.
• Portability: Ensure that containers continue to be portable across a wide variety software, clouds, and hardware.
• Decentralized: Container images should be straightforward and should take advantage of federation and namespacing.
• Open: The runtime and formats should be community-built, with multiple interchangeable parts.
• Backward compatible: Given the popularity of Docker and containers with nearly 9 billion downloads, backward compatibility should be given high priority.
• Composable: Tools for the operation of containers should be well integrated, but modular.
• Code: Consensus should be built from running, working code that follows principles of minimalism that adhere to domain-driven design. It should be stable and extensible.