I’ve been thinking quite a bit about docker, and more specifically, about the docker-related tension that’s been brewing in the cloud community.
Within the past couple of weeks, articles published by Barb Darrow, Matt Asay and Alex Williams/Joab Jackson all put a huge and necessary spotlight on the core issue of whether docker (little ‘d’ – the project) can succeed without true independence from Docker (big ‘D’ – the company).
I’m not here to claim any position (pro or con) on the forking topic or on recommending that the market pursue a container alternative. I certainly have some strong opinions on the topics of forking and docker, but I’ll reserve that conversation for another post. Instead, I think it’s important to take a step back and ask, “Why is everyone so bent out of shape regarding docker and Docker?” What we’re all sensing is a “Battle of the ize’s,” an inherent conflict that exists between the need to democratize and the need to monetize. As it turns out, those two things don’t really reconcile well.
When docker (the project) was started as an open-source project, it had the intent of making containers easy to use. This allowed for rapid, widespread adoption—a democratization effect that lowered the accessibility bar that developers had to hurdle to start using containers in their own projects. This democratization was the exact thing necessary to catalyze an unstoppable market shift. Vendor after vendor has lined up to pledge support to docker, catapulting it into the limelight as a fundamental cloud computing primitive—democratization at its finest.
As an architectural cloud primitive, the project has intense (and expected) pressure to remain neutral and adoptable, with no bias. Much like a mathematical axiom whose self-evident nature allows it to be a unit of construction for more abstract concepts, an architectural technology primitive has no room for opinion or obtuse influence. The concern in the community is focused on Docker (the company’s) actions and how its actions may violate the integrity of the project in a way that impacts the very tenets that made docker easy and safe to adopt as a generally accepted cloud primitive. Why is this even happening?
Docker (the company) had to raise money—big money—and fast. The company and its investors saw this massive adoption of docker as an un-monetized base, ripe for the taking. The problem is that the characteristics that helped docker catch on like wildfire also makes it difficult to monetize. This isn’t a new problem; virally successful open-source projects are notoriously difficult to monetize because they become a standard because of their ability to go viral. Additionally, becoming a cloud primitive means that the said primitive, by definition, must become a commodity in the cloud supply chain. As a commodity, monetization becomes a game of pennies rather than dollars at that tier in the stack—and no one likes playing for pennies.
Unfortunately for Docker, the easy adoptability of docker as a primitive means that most of the companies who adopted it built tech focused on management and clustering—the natural “next layer” in a modern and evolving technology stack. To deal with this, monetization almost certainly implies the need to quickly neutralize threats that may get in the way of revenue at this next layer.
How do you neutralize a layer? Try to commoditize it in a near-monopolistic way through bundling and forced adoption (e.g. Swarm Kit), and then charge for features in a product that are associated with these newly minted capabilities. At the community level, this is equivalent to “biting the hand that feeds you.” You’ve immediately disenfranchised all those who viewed docker as a primitive. A bait and switch if you will.
Any violation of the core characteristics that allowed docker to become a broadly adopted primitive will lead to the revocation of its status as an accepted foundational element, at least in its current form. As I said, I’m not here to support or oppose a community fork, but I sure hope things are course corrected soon.
To be fair, Docker is in a tough spot—their stance on this issue is along the lines of “We’re just innovating quicker than vendors can keep up and they want us to slow down. It’s too early for container standards and we don’t want this to be OpenStack where it’s designed by committee.” Sometimes, broad acceptance and broad deployments are not aligned, so I certainly empathize with Docker’s non-trivial struggle.