You can be forgiven for thinking Docker cares about standardization.
A little more than a year ago Docker donated "its software container format and its runtime, as well as the associated specifications," to the Open Container Project to be housed under the Linux Foundation. In the FAQ, the Linux Foundation stressed, "Docker has taken the entire contents of the libcontainer project, including nsinit, and all modifications needed to make it run independently of Docker, and donated it to this effort."
It was euphoric, this kumbaya moment. Many, including Google's Kelsey Hightower, thought the container leader was offering full Docker standardization in our time.
As Docker founder Solomon Hykes declared last week, "We didn't standardize our tech, just a very narrow piece where it made sense." Importantly, what Hykes is arguing, a "reasonable argument against weaponized standards," may be the best kind of "Docker standardization" possible.
The committee to slow all real work
Standards are what people at lumbering old companies get paid to do. No, I'm not arguing that standards are not useful or good, but in the early days of a technology, standards are inimical to progress -- which, perhaps not ironically, is precisely what legacy vendors tend to want.
While I was at MongoDB, a popular open source NoSQL database, various legacy software companies courted us to establish foundations and "standardize" the technology. One went so far as to gather a gaggle of NoSQL vendors to try to harmonize an overarching NoSQL standard, an effort that baffled each of the different NoSQL organizations, given the diverse technologies (document, wide-column, graph, and so on) assembled under the NoSQL banner.
Not surprisingly, these large companies tended to have established database businesses of their own that were fading in popularity or threatened to do so. A quick look at DB-Engines database rankings may offer some clues as to who would have the most to gain from a sluggish MongoDB standard or from hobbling all the fast-moving NoSQL technologies under a common standard.
Such standards would no doubt help the legacy database vendors by giving them time to regroup, but they would also almost certainly cripple a movement that has redefined the data infrastructure landscape.
This is why Puppet CEO Luke Kanies was right to ask how requests to standardize Docker are remotely reasonable. Telling Hightower that he "wouldn't make Puppet a standard," Kanies goes on to declare, "I know of no great companies that standardized their tech before they had a mature business."
The reason, of course, is that the best "standards" are those that become such by default, not by committee. The minute multiple vendors are involved in defining code, that code becomes cumbersome and often irrelevant. We might wish it were otherwise -- the idea of diverse companies collaborating to define standards evokes feelings of blissful happiness -- but in the real world, companies, not committees, tend to win.
Even successful open source projects like Linux largely display this tendency. Though Linux involves a large number of organizations, each pursuing its own self-interest, the reason Linux works comes down to a very opinionated Linus Torvalds. This isn't to deprecate the work of other committers and maintainers on the the various Linux projects/subprojects, but simply to insist that Linux isn't designed by committee any more than Docker is (or should be).
If anything, Docker, Inc. chose its wording poorly, as Hykes acknowledges, when it talked about standardization for the Docker container format. Going forward, the company needs to keep doing what is best for the community, which ironically has nothing to do with "design by committee" industry standards and everything to do with advancing the state of the Docker container art such that real enterprises increasingly use Docker in real, mission-critical workloads. That has begun in earnest, but more is needed.
Docker's initial success, as with MongoDB and other de facto industry standards, has come through relentless efforts to make the technology simple for developers to adopt. Balancing this simplicity with the ability to tackle increasingly demanding workloads takes a village to put Docker through its paces in production, but requires a single mayor to establish and maintain order. That's Docker, Inc., and that's exactly the right kind of standard for Docker containers.