Forking Docker: The New Open-Source Culture
Has Docker become too powerful for its own good? That’s what some representatives of the Docker community are implying as they lament the lack of container standardization and raise the prospect of a Docker fork.
A recent blog post by Daniel Riek of Red Hat sums up best why the idea of forking Docker is now on the table. In bullet-point format, the reasoning leading up to a Docker fork looks like this:
- Docker is resisting efforts to standardize its container runtime on the basis of the Open Container Initiative, or OCI.
- Docker integrated Swarm—a container orchestration tool that previously fell outside the purview of the Docker platform itself—into the Docker stack this summer. That makes it more difficult for Docker partners to sell solutions that deliver container orchestration and management features.
- Companies such as Red Hat accuse Docker of killing these companies’ own code contributions to the Docker open-source project “for the simple reason that they don’t fit into Docker Inc’s business strategy,” in Riek’s words.
- Companies are also upset that Docker is evolving so quickly. Its rapid update cycle makes it hard for partners to keep their own Docker-related technologies up to date.
Taken together, these concerns are leading to rumors of a Docker fork. So far, those rumors have not been substantiated. And people, like Riek, are speaking out against forking, arguing instead that standardizing Docker on the OCI would be a better solution.
Still, the mere fact that there is now open talk of forking Docker is huge news. No major open-source project has forked since the OpenOffice/LibreOffice split of 2010. Discussion of a Docker fork underlines just how much tension exists within the Docker community.
Misunderstanding Modern Open Source
Why is the Docker community now so unhappy with Docker? It all boils down to a mismatch between how the community expects Docker to behave as an open-source company and how Docker defines its own priorities.
Traditionally, open-source companies thrived by collaborating openly on software development, even if the companies competed in the market. No single company dominated the development of a key open-source project. Instead, they all submitted code to projects such as Linux, which were operated by third parties without direct ties to any particular company.
But Docker is different. Docker is both a company and an open-source project. While in theory the Docker code is being developed by the community, in practice Docker the company exerts a level of control over the Docker code that seems strange to older open-source companies.
This difference fundamentally alters the way Docker behaves toward the community. Docker has an ability to control its own open-source product that companies such as Red Hat lack.
The reason for this difference is that Docker came of age in 2013, a time when open source was already the default way to create software. As a result, Docker built its own product as open source from the start. If Docker had been born five or 10 years earlier, it probably would have been a closed-source project, and no one would have thought it strange for Docker to design its product in a way that promoted its own business strategy.
Yet because Docker is open source, Red Hat et al complain when Docker appears reluctant to create the type of product they think Docker should be, rather than the one that Docker executives want it to be.
What’s really at stake in the Docker forking controversy is a mismatch of cultural standards. The old open-source mindset, exemplified by companies such as Red Hat, is pitted against the new open-source mindset, exemplified by Docker.
The Battle of the Fork
Who will win? Probably no one, if Docker is forked. A fork would undercut Docker’s momentum, damaging Docker as well as the companies that rely on it. And the latter would probably not be able to evolve Docker as fast as Docker itself is doing if it tried to build Docker around open standards.
A better solution is for Docker and Docker vendors to realize that open source no longer translates to open community. The open-source business strategy, not the Docker code base, is what needs to change.
