In an effort to distance itself from what had been called OCID, the Open Container Initiative strongly declared that this project to build a Kubernetes-based container runtime was not, in fact, an official OCI endeavor.
The Red Hat-led OCID effort, which was short for the “OCI daemon,” has been renamed CRI-O, the first part of which apparently referring to the Container Runtime Interface for Kubernetes.
The statement from OCI — a project of the Linux Foundation — read in part:
“The Open Container Initiative (OCI) is focused on creating a formal specification for container runtime and image format, as standardization of these areas will promote other innovations. Any additional projects are currently outside the scope of the OCI; however, we encourage our members to continue iterating on the runtime spec and image format as it benefits the entire industry. Innovation happens rapidly at the implementation level, and we aim to feed any relevant advances back into the specifications. Our goal is to support the effective growth and health of container technology and the entire open source community.”
Without admonishing the project itself or diminishing its goals, OCI is evidently taking steps to eliminate any appearance of direct involvement with the project, which itself is a culmination of the Kubernetes Incubator, a collection of open source resources to support the Kubernetes orchestrator. A CRI implementation specifically for CoreOS’ rkt, called rktlet, is another project supported by the Incubator.
The project formerly known as OCID has drawn a lot of attention in light of an apparent growing dissatisfaction with the speed of which Docker is advancing its container and container runtime technologies. A number of companies that rely on Docker for their own products and services, including Red Hat, have called for a more stable Docker base and have raised the possibility of forking the Docker code base. While the maintainers of CRI-O insist that their project is not a Docker fork, their software would lessen the requirement to run Docker containers in a Kubernetes-based system.
Recent editions to the CRI-O page on GitHub make it more explicit that the project is not a container creation system. It also now states very clearly that CRI-O now omits tools for “building, signing, and pushing images to various image storages” — presumably, repositories and Docker registries.
In an interview with Red Hat’s contributors to the project last week, consulting engineer Dan Walsh described the project at that time as consisting of a handful of pillars, one of which was skopeo — a part of Red Hat’s Project Atomic — originally developed for managing containers in registries. That project evolved into containers/image, which does remain listed as part of CRI-O.
Just Because It’s Open Doesn’t Mean It’s Not Trademarked
As OCID was originally presented to the public and described — for example, as an “Open Container Initiative-based implementation of Kubernetes Container Runtime Interface” — it was very easy to assume that the project had at least the blessing, if not the backing, of the Open Container Initiative. Tuesday’s statement from OCI very effectively repudiates such assumptions.
OCI’s statement went on to say it expects to conclude version 1.0 of its container format specifications “in the next couple of months.” At that time, the organization’s Trademark Board will initiate a certification program for projects that include the OCI runtime (runc) and that follow the OCI container format.
“In terms of the OCI project itself, the governance of this is fairly lightweight,” Dolan said. “It’s a fairly streamlined process in terms of what gets worked on and by whom. There are some business matters that need to be addressed around trademarks, budgets and certification, and for that, we have a Trademark Board. We have tried to make this as inclusive as possible, and so any member can participate in the Trademark Board.
“It’s really about figuring out how to allocate the budget that is raised amongst the members — that is the focus of the Trademark Board,” he continued. “That is completely independent from any technical work that is going on, and all of the technical work and the collaboration on both the open source code bases or the specification for containers is being done in the technical development community.” He went on to say that this latter community was completely open to participation from any willing party, not just prominent organizations in containerization or infrastructure.
We asked Chris Aniszczyk, the Executive Director of OCI (and, incidentally, the COO and former interim director of the Cloud Native Computing Foundation, which now manages Kubernetes) what the OCI’s policy will be, from this point forward, with regard to contributions to OCI’s technology from this community — particularly when they are the same companies, and often the same people, affiliated with other projects whose objectives lie are outside the OCI’s scope.
“As [with] any open source project, we encourage and expect there to be innovation beyond the scope of our project,” Aniszczyk responded. “That’s just the nature of open source development. Any OCI member is also welcome to bring forward a new project proposal to the Technical Oversight Board for review, just like the new recent OCI Tooling projects. While we hope that OCI members will consider contributing relevant advances back to the specification, it is not required by any means.”
Does this mean the OCI cannot endorse, or even informally bless, those projects? “Projects developed independently of the OCI need not be contributed to the OCI in order to be deemed compliant with an associated OCI specification,” wrote Aniszczyk, “but we will have an official certification process down the line. At the moment, OCI can’t certify these projects, but the certification process and trademark guidelines are actively being worked on as we get closer to the v1.0 release. After the v1.0 release, we look forward to certifying qualifying solutions based on the certification program that is developed by the OCI membership.”
Joe Fernandes, who directs product management for OpenShift at Red Hat, told The New Stack that the name change was a decision made by his company and Google, following a consultation with OCI. He cited a recent company blog post, continuing to characterize the project as “an OCI-based implementation of the Kubernetes Container Runtime Interface.” As OCI’s Aniszczyk pointed out, a project is permitted to call itself “OCI-based” without that organization’s permission or direct involvement.
“While the OCI trademark policy is being developed, Red Hat and Google consulted with OCI and agreed to change the repo name within the Kubernetes incubator from OCID to CRI-O to avoid any confusion,” Fernandes told us. “That doesn’t change anything in terms of Red Hat’s commitment to the project or to driving container innovation and standards.
“The project reflects Red Hat’s commitment to drive new container innovations that expand the use of containers in production environments,” he continued, “and also reflects our commitment to drive industry standards for container runtime and format through the Open Container Initiative.”
While CRI-O is not an OCI project, Red Hat and Google do contribute to OCI, as does Docker, Inc.
Earlier this month The New Stack collected data from about contributions to OCI and the people behind them. According to the data pulled from GitHub, Docker, Inc. continues to employ the largest quantity of contributors to OCI, with 21. Red Hat comes in second with 16, but in an indicator of the important role of networking in containerization, Huawei is tied with IBM for third place with 12 contributors. The remainder of the chart above shows known companies with greater than one contributor.
The New Stack’s Lawrence Hecht contributed research to this report.