Not every open source project is destined to be forked. But when it happens, it's both a sign of its popularity and disagreement within the developer community over how the project ought to evolve.
Now, a "boring" fork of Docker, proposed by a vocal group of developers who build on the container software, may be the next big thing in open source.
Move fast and break (too many) things
The New Stack writes that as-yet-unconfirmed discussions to fork the Docker engine are taking place among companies that have built a commercial business out of supporting the technology.
What has been confirmed, and is public for all to see, is dissatisfaction with Docker's release cycle, which "puts third-party system providers at odds with their own customer base," the article says. The rapid pace of changes means that breakage -- and the cost of addressing that breakage -- is pushed down to those who work with Docker either as a user or a partner.
Bob Wise of Samsung SDS asked in a blog post linked to by The New Stack, "Is it time for a common open source stability fork of the Docker engine, container image packaging, naming, and deployment specifications?"
Wise was especially dismayed by Docker's recent move to include its Swarm orchestration functionality, since it was "a large new system developed in secret without transparent community involvement." He cited this as an example of Docker pursuing a strategy of "[using its] position to impede the progress of [open source] communities in favor of [Docker's] commercial interests."
Slowing it down with the OCI
Docker strives to have its product seen as production-ready technology, so criticisms like this are especially stinging. While there is talk of a fork, where a "boring" version of Docker could be used as a reference implementation, where would it live and how would it be managed?
One likely solution, explored in the New Stack article, is for the Open Container Initiative -- a group formed to provide a home and set of reference implementations for container standards -- to maintain its own fork of Docker as a baseline. Originally, the OCI focused on the runtime, albeit to the exclusion of container image format (over the objections of OCI member and Docker competitor CoreOS).
If the OCI becomes the steward of Boring Docker, everyone involved will need to decide two issues: Which parts of Docker Engine will be considered stable core and maintained with the OCI? And what criteria should the OCI use to accept patches for core from Docker or other third parties?
The New Stack cites Red Hat's use of the controversial systemd as an example of the questions that will arise about what to include. Docker uses its own service manager rather than systemd, so Red Hat has devised a patch set to work around the problem. If the OCI decides that its version of Docker should play well with systemd, because of the latter's uptake across Linux distributions, Docker's version will be notable for both what it removes and what it adds -- and a fight over systemd's tendency to embrace and engulf everything it touches may loom.
Maybe the solutions begin at home
Another possibility is for those who are disgruntled with Docker to pick a competitor -- most likely CoreOS' rkt -- and back it as the more stable option. CoreOS has promoted itself as a more security-conscious alternative to Docker, so it wouldn't be much of a stretch to also deem itself as the more stable, dependable alternative. The hard part might be convincing customers to change workflows to a new brand of container product, given the wide acceptance of Docker.
Yet another possibility is that a fork won't be required at all, if Docker makes the wise move and finds elegant responses to criticisms about its products. For instance, API breakage could be limited to every other version of the application, as suggested by one Hacker News commentator.
Docker likes to style itself as amenable to customers requests -- for example, creating a more comfortable desktop environment for Docker developers. Providing a stable and reliable product could -- and should -- also be part of its mission.
Maybe Docker should address these issues before someone beats the company to the punch.