Let’s just get the big question out of the way so if you have something better to do (which you should since you’re probably at work getting paid to do something meaningful instead of reading blogs and tweeting) forking Docker is not a good idea right now.
Unlike some who see it as their job to “stir the pot” to either get some reaction from readers, or to simply sell more newspapers (yes I’m that old to initially think of newspapers instead of web page visits), I view all of the recent noise about forking Docker as just that – noise with an alternative purpose. Â And like many 4 letter words “fork” brings the conversation to a new level, one that gets more attention.
Whatever the reason, it might be good to actually look at what “forking Docker” could mean. In my experience open source projects are typically forked when there’s a fundamental disagreement over one or more core design points – ones that can’t be managed via things like plug-points or options for the user of the code. Do we have that with Docker? I don’t think we do and I’ll explain why.
First, and foremost, the core pieces of the open source Docker engine were already contributed by Docker Inc. to help form the Open Container Initiative (OCI) as announced by Solomon at DockerCon mid-2015. Despite the mixed signals coming from Docker Inc. last month on social media concerning their feelings for OCI, the handful of individuals saying “fork Docker” seem to be forgetting that they already have what they want with respect to the heart of Docker. The OCI community now shares governance and evolution of the runtime and image specifications and runc. If anyone feels that the direction of those components is off-track then they’re free to join/continue working in OCI to help change it. But, I doubt this is the part of Docker people really want to fork. Â So, let’s move on.
Moving up the stack we have the Docker UX for using the OCI core components.Â Is there a fundamental design difference at this level? Â You may think that since I’m not in the “fork Docker” camp my answer would be no, but I do actually think there are significant differences here. Â Just to name two that are hot buttons for me: first, there’s the inability to set the default image registry to something other than DockerHub, and second the lack of a way to extend Docker.
Why those two when I’m sure there are others that get more attention? In the past, Docker Inc. has consistently said â€śbatteries included but swappableâ€ť but now, a key part of their strategy appears to be based on forcing the use of their DockerHub/DockerStore – enabling Docker Inc. to own the â€śAppStoreâ€ť for containers. That’s a fine strategy for a company but not for an open-source project. If Docker Inc.’s version of Docker that they sell commercial support for pointed to DockerHub, but the open-source version had a way to point to some other one (even if the default was DockerHub) then I would feel differently. Open-source projects shouldn’t be hard-wired to one commercial offering over another.
The lack of extensibility for Docker is another control point issue. If people can’t add new features, then Docker Inc. can retain total control over the Docker user-experience and it makes it harder for others to offer an alternative. Take as an example the recent SwarmKit features that were rolled-out in Docker v1.12. If Docker had a plug-in model (for the engine and the CLI) then two things could have happened: first, the SwarmKit features could have been shipped via plugins – meaning that it would be truly optional. And second, people could have been working on and offered an alternative without having to wait for Docker Inc. to decide it’s finally time to work on orchestration. Â Again, â€śbatteries included but swappableâ€ť applies.
(On a side note, v1.12 does included a new plug-in model, which is good, but it’s “freedom within a box”. By that I mean you can offer your own customized logic at certain points in the flow, like your own networking pattern, but that’s not quite the same thing as adding a new API or CLI command, which is what I was hoping SwarmKit would leverage.)
So, with these two control points not yet addressed by Docker, you may be wondering why I’m not in the “fork Docker” camp – basically for three reasons. First, there are work-arounds. Most companies that ship Docker make some kind of modifications to the code. Mainly, it’s to add a patch that isn’t upstream yet but some folks do it to actually change the functionality – like to have the ability to change the default registry. My point is that these customizable builds are always going to be there, which is common practice in open source communities. Another reason is because when it comes to bigger issues (like orchestration) I think some people are looking at alternatives (like Mesos, Kubernetes, etc.). However, I do still think the community would benefit from proper extensibility points added to Docker.
The final, and perhaps most important reason I don’t think a fork is a good idea is because I currently don’t see the value of a fork to the Docker end-user. Are there fundamental differences with the core Docker UX that people want to change? I’m not sure there are. What about clientsâ€™ concerns over a captive relationship with Docker Inc.? Over time, customers will want to address “lock-in” to a project that is not completely openly governed, but they are not quite there – yet. Â So, while people will continue to complain about how Docker the project is managed, I don’t think there’s enough noise from the user base that the features offered by Docker are fundamentally the wrong direction. And without those screams I think a fork would fail, so why bother.
Now, that’s not to say that all of this chatter couldn’t have some other kind of positive impact, and I won’t bother to speculate since I don’t want to jinx it, and only time will tell. Â But, in the end, most of the calls to fork Docker are probably generated either by people just looking to “stir the pot” or by Dockerâ€™s competitors who are frustrated and have some legitimate concerns but are also (rightfully) afraid. So, take it all with a huge grain of salt and enjoy the show.