At the same time that Docker offered to donate its containerd technology to the Cloud Native Computing Foundation (CNCF), CoreOS did the same with its competing rkt.

Containerd (pronounced “container dee”) and rkt (say “rocket”) are both container runtime facilities, managing container images, a key component of cloud native computing.

Both can work for any number of container managers, but the CNCF is probably best known as the open forum overseeing the development of Kubernetes, the container manager that Google devised in 2014 and donated to the CNCF in 2015.

Continuing development of Kubernetes and other container managers, along with the coordinated development of associated technologies, all in an open environment, is considered necessary for progress in the trend toward cloud native.

Referring to the donations from both companies, CoreOS said, “By donating these projects to the CNCF we ensure that the container community will continue to thrive in a neutral home for collaboration."

Docker’s and CoreOS’s donations are simply proposals at this point. The CNCF will spend the next few weeks evaluating both for formal adoption.

Docker, CoreOS, and other companies with similar products are more likely to profit if they develop their technologies within open forums, hence their eagerness to work with the CNCF.

CoreOS CTO Brandon Philips explained it this way to SDxCentral: “We work closely to establish shared specifications on how container images get downloaded and created by application developers. Containerd and rkt can be separate implementations but also work together and run the exact same applications. It’s very much like web browsers. Just because Firefox, Chrome, and Internet Explorer compete in the market place, they do come together on HTML5 and JavaScript.”

CoreOS naturally considers its rkt to be a superior implementation. The company built it from the ground up, creating an architecture it says is most conducive to providing container security, composability, and interoperability.

An important differentiator with containerd is that rkt is a daemonless tool. Being daemonless, Philips said, addresses potential problems at the initiation of a process – during bootstrapping.

A technical explanation requires diving deep into the weeds, Philips said, but at a high level, “We need to have daemonless because we need to have a concrete Linux process that is executing the rest of the container system. If we have a container system that is based on container system, we begin to run into these circular dependencies. If you start with a daemonless system, you can bootstrap the system from a container to run more containers.”