Should Docker Standardize? Lessons of Other Projects
Much has been written lately about Docker and standardization. What does Docker have to gain or lose by adopting an open container specification such as the ones from the OCI? Keep reading for some lessons from similar open-source projects.
In a nutshell, the debate over Docker standardization looks like this: Docker is currently developing its container platform using its own homegrown architecture. However, some people would like to see Docker adopt an open, community-defined standard, such as the ones being defined by the Open Container Initiative (OCI).
Standard Procedure?
An open standard would help assure that Docker remains compatible with third-party container tools. But it also might slow the pace of Docker development, since Docker potentially would have to wait on other organizations to define standards before it could make changes to its own technology. Standards also could undercut Docker’s competitive edge over competing platforms, in some respects.
So, does Docker have more to gain or to lose by adopting an open container standard? Here are some lessons from other big open-source projects, which grappled with the same question.
Linux
Linux was built from the beginning around POSIX standards, which define how a Unix-like operating system should work. It’s hard to imagine Linux having become a runaway success within the first few years of its release if Linus Torvalds had chosen to design the kernel based on his own whims rather than POSIX.
Of course, Linux was different from Docker in the respect that Linux was emulating a product—Unix—which had existed for a long time when Linux came along. Potential Linux users already knew how they wanted Linux to look and feel, because they wanted it to be a free implementation of Unix. In contrast, Docker is in the midst of defining what application containers can and should be.
The lesson: Standards matter if your open-source project is trying to emulate a closed-source platform that already exists. But they may not matter much if you are creating a totally novel platform. Docker falls into the latter category.
Apache HTTPD
The open-source Apache web server, HTTPD, was born in the mid-1990s when a group of admins extended a different web server developed at the National Center for Supercomputing Applications.
HTTPD emerged early enough in the history of the World Wide Web that standards for how web pages should be designed and served, such as the HTTP standard, were not yet fully defined. As a result, the Apache developers had free rein to design their server to work in whatever way they wanted. In other words, in Apache’s case, there were no real standards to adhere to in the first place.
The lesson: If no standards exist, you get to do what you want. But in Docker’s case, standards do exist. Docker can’t use the Apache excuse.
GNOME
GNOME, the desktop environment for Linux-based computers, was created as an alternative to KDE, another desktop environment. KDE depended on software libraries that were licensed by a company called Troll Tech. GNOME developers worried that Troll Tech might cease making the libraries available on GNU/Linux systems, leaving KDE in the dark. So they built GNOME as an open platform that was not dependent on any proprietary libraries.
Although KDE never disappeared, GNOME went on to do pretty well for itself. (In the meantime, the Troll Tech issue was cleared up, and KDE ceased depending on proprietary libraries long ago.) It is still widely used today.
The lesson: The GNOME vs. Troll Tech case was not quite the same thing as a debate about open standards. But a similar lesson applies. In GNOME’s case, the desktop environment thrived largely because it promised an open alternative to KDE, unencumbered by proprietary dependencies. And people cared about that.
LibreOffice and OpenOffice
LibreOffice and its predecessor, OpenOffice (well, LibreOffice is actually a fork of OpenOffice, but I’ll spare you the details) are word processors. Both offer support for Microsoft Office’s native file formats. By default, however, they use the Open Document Format (ODF) for reading and writing files.
That means LibreOffice and OpenOffice support proprietary standards and open standards at the same time. That approach is arguably key to their success. Personally, I would not be able to use LibreOffice if it did not support Microsoft Office formats. I need to read and write those documents when collaborating with people who only have Microsoft Office. But I use ODF-based documents for my own files.
The lesson: Docker could consider emulating LibreOffice and OpenOffice by supporting an open container standard and retaining its own framework at the same time. It would not be impossible to offer two versions of Docker. In this way, Docker could deliver a standards-compliant option for people who care about that, while also offering a separate edition of Docker that might have additional features.
This approach actually could work pretty well for the community and Docker. It would allow the community to get a standards-based Docker while allowing Docker to remain as competitive as it wants to be.
