Red Hat’s OCID is a Docker Alternative, But Not a Fork

Is Red Hat’s new OCID project a fork of Docker? Unless you have an unorthodox definition of software fork, the answer is no.

Recently, Red Hat announced it was backing the launch of a new project as part of the Kubernetes Incubator called Open Container Initiative Daemon, or OCID. Red Hat calls OCID an “implementation of the Kubernetes standard container runtime interface.”

The container runtime Red Hat is referring to is runC. That happens to be the same container runtime that powers Docker.

In addition to releasing Red Hat’s own implementation of runC, OCID will also include an interface for controlling the runtime, which will basically be the equivalent of docker-cli. OCID will also feature a networking framework.

Red Hat says that all of these tools will remain consistent with the standards of the Open Container Initiative, or OCI, which was launched in summer 2015 to create a set of common standards for container platforms, including but not limited to Docker.

Is OCID a Fork?

Because OCID will include its own version of runC and an alternative to the Docker runtime tool set, people on the street are suggesting that Red Hat has created a “Docker fork” or launched a “new Docker initiative.”

However, it’s hard to see OCID as a fork of Docker when it’s not actually an extension of all of Docker. It simply builds upon some of the same underlying components that happen to form Docker, but are not developed as part of Docker itself.

A software fork in the formal sense means taking the source code of one project and using it to create a competing piece of software. Forks also usually involve a split within the developer community of the original piece of software. But that is not what is occurring in the case of OCID. The Docker code is not the basis for the fork, and Red Hat is not stealing Docker developers to work on its new project.

So, rather than thinking of OCID as a Docker fork, it’s best to approach it as another container platform. In that sense, what Red Hat is doing is no different than CoreOS’s efforts to build its own container stack based on the Rkt runtime. For that matter, OCID is also similar to platforms LXD and OpenVZ—container solutions that target different use cases than Docker.

Forks and Docker

The distinction matters because the subject of forking Docker has been a sensitive one lately. As the Docker developers have shown increasingly little interest in adhering to the OCI standard, the idea of forking Docker in order to create a version that is OCI-friendly has grown more popular. In response, Docker supporters have countered by warning that a Docker fork would not be able to sustain the rapid rate of development and innovation that Docker itself has undergone over the past several years, since standards would slow down development.

By launching another runC-based container platform, rather than forking all of Docker, Red Hat is providing an alternative container platform that will please people who seek a more standards-compliant container solution than Docker. Adopting Red Hat’s platform will require organizations to migrate to a whole new set of tools, which means that OCID is not simply a drop-in replacement for Docker. People already invested in Docker can continue to use it, while Red Hat markets its new container solution alongside Docker. Users will get another enterprise-ready container solution, and that is never a bad thing.

Christopher Tozzi

Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with and

Christopher Tozzi has 254 posts and counting. See all posts by Christopher Tozzi