How is the Internet Engineering Task Force (IETF) broken? Can you count the ways? The process is too slow, the standards are often opaque, the results are often complex and difficult to deploy; any engineer who’s been in the networking field long enough most likely can recite a litany of complaints.
Open source, on the other hand, seems to be building new software and systems quickly and efficiently. Given the ascendance of open source, why not just abandon the apparently old, outmoded, and painful open standards process for a more modern, faster open source process?
This question has been answered a number of times in various venues, but it’s worth revisiting the problem. In a four-part series of blogs, I'll make observations about both the open source and open standards worlds in the context of networking, particularly from the perspective of network control planes or routing. I'll examine the potential issues of dropping the open standards process in favor of open source. Finally, I'll look at what the IETF is doing to speed the standards process. But first, let's take a look at the open source movement and what's making it so hot right now.
The same, only different
Open source software is actually quite old. In the early days of computers, BASIC, xBase, C, and even Assembler programs were widely available that would do things from the trivial (print out an image) to the complex (math solutions, astronomy, some very complex text based games, and even graphics packages to handle many common, but complex, rendering and image manipulation functions).
In fact, open source is probably responsible for the majority of software ever installed on every computer in the world; if it’s not installed directly, it’s probably the foundation of some commercial piece of software just about everyone uses or used at some point in their lives.
So why is open source suddenly so much in the news in the last few years? There’s no new model involved; it still essentially involves a small (or, less often, large) group that puts up a common repository of code and voluntarily designs, writes, and manages some piece of software that anyone can download. While the repository has moved from a Bulletin Board System (BBS) with a dial bank of modems to an Internet-facing server running Git, the ideas undergirding the movement are still the same.
Is the crucial change improved development processes and tools? This doesn’t seem likely; better processes are likely to accrue over time, but very few (or none) of the current crop of stories about the explosion of open source talk about how much easier it is to code software.
Maybes it’s the widespread use of computers in everyday life. Bigger markets make for bigger pools of talent from which to draw, and more interest in “making a splash.” Perhaps, but there are counterweights. For instance, if new coders want to make a splash, they’re just as likely to write a “killer app,” that might make them real money than to check the code into a Git repository in order to improve the general codebase available to “the world.” Even if some new coder does want to make a splash, he or she isn't really likely to jump into some large-scale existing project to participate in everyday maintenance work. It’s much more interesting to “do something new.”
Vendor support
Maybe it’s just the availability of coders, or the number of people who want to get into the computer world? This doesn’t seem likely, on the surface, but perhaps a little digging around under the surface will provide an answer. Most software that’s touted as open source today, particularly in the world of networking, is closely tied to a recognizable vendor.
For instance, OpenStack was originally created by RackSpace, a commercial cloud provider, and has since been bolstered by just about every large company associated with cloud services, network hardware, storage, or virtualization software. Companies like Arista, AT&T, Ericsson, and Oracle all support OpenStack financially and with the time of coders working in related areas.
This support, in fact, might be considered the most important reason open source has suddenly become such a big deal. It’s not so much news when a few folks get together and write a virtualization or orchestration system, stick it in a Git repository, and open it to the world. It is big news when a big industry player -- or a lot of big industry players -- starts devoting time and money to the project.
The question that needs to be answered to understand the recent explosion in open source software is, then: Why would a large company, dedicated to adding value for shareholders, actively participate in creating software that will be open to public use by other, competing, companies? As organizations interested in creating value for their shareholders and employees, there must be some reason other than altruism towards the market. While it might be interesting to discover why this might be, the more important conclusion of this discussion is the commercialization of open source.
It can be argued that the biggest change -- the change that has led to an explosion of open source software -- isn’t the availability of open source software, nor the process of developing open source software, but the commercialization of open source software. We’ve always had an open source software community. What’s new is we have people who are commercializing the open source model.
How did this commercialization come about? There are a lot of reasons, from newer business models and larger available code bases in the open source sphere to better tools and processes that lower the cost of building software. But there's one factor that has a major impact on the difference between open source and open standards.
In the world of open source, the people contributing to the project directly make their living off of developing software and the tools surrounding software. In other words, as a direct result of the commercialization of open source, when a company hires someone to build a piece of code they are also hiring someone to build a piece of open source software. Developers working on a piece of open source software are either doing their job, or doing work that is closely related to their job in some way.
In my next blog post, I'll compare the open source movement to the open standards process, especially as it's embodied in the IETF.
Alvaro Retana, Distinguished Engineer at Cisco, and IETF Routing Area Director Alia Atlas, Distinguished Engineer at Juniper, provided input to IETF Routing Area Director Russ White for this article.