Open Source: Good Medicine Or Placebo?

In my second blog post in this series examining the open source and open standards movements, I discussed problems with the IETF processes. This raises the question: Should the networking community, then, move towards open source, abandoning the “one step away” model of open standards to resolve the problems we’re facing in the open standards process? Don’t fast moving open source projects prove the point that open source can solve problems more effectively than open standards? Before the networking industry moves in this direction, there are several dark linings to the open source movement that need some little illumination.

First, commercial enterprises tend to be short on memory and long on vision. Which one of these slogans makes for better marketing material in the latest glossy:  -"We’ve funded a new open source project to solve problem X" or  "We’ve been supporting project X for 15 years and intend to continue supporting it"?. In the world of “the new wins now,” it’s harder to justify the second than the first. This has at least one unfortunate side effect.

When the pond gets muddy, just build a new pond. When an open source project expands to fill a wide array of use cases, or the requirements of dozens of different vendors (each trying to maintain some sort of commercial differentiation), open source projects tend to become muddy, chock full of modules and components and pieces and parts, with no real control over what piece should be used for what or why one solution for a specific problem is better than another. The tragedy of the commons quickly sets in  and in the virtual world of software, it’s often easier to just move to a new pond. But what happens to everyone who was actually swimming in the pond that was just abandoned?

This can actually be taken to the next step: Why not just build a new pond every few years? It makes for really nice glossies to hand out at the next trade show, and those who don’t agree with your approach aren’t likely to jump into your pond when it’s so easy to build their own. There’s little downside for the vendor, but a lot of downsides for those who, again, are currently swimming in the ponds being abandoned for the prettier one around the corner, or who tend to believe the entire point is to get all the vendors into the same pond.

Second, there’s no discipline to solve a single set of problems in a common way. Rather, what tends to end up happening is that each unique set of problems is met with a unique solution. If you don’t like a solution as proposed or implemented, just cut a branch and build your own. Someone who actually has problems that cross the boundaries of the projects is often left trying to sort out, on their own, how and what to merge, or what pieces to take from what, to make the whole thing work.

Third, commercial enterprises are more concerned about profit margins than longer term software project viability. Once the software is no longer new and exciting, there’s a strong feeling that support for the project can be left to people who care, while the commercial (paid) coders can move on to work that is more profitable. 

This certainly makes the commercial enterprise more profitable, but it causes a “long tail” in the area of support. As the project increases in age, there’s little incentive to jump on board in maintenance, and every incentive to start something new and exciting that will “make your name.” The apparent support staff dwindles to a handful, then to a pair, then to one. Users can always jump to another open source project that’s doing the same thing, but someone has to pay to move the data, modify software and processes built around the open source project, and take care of all those things that tend to accrete around something used on a daily basis.

Open source and open standards: Working together

Exploring all these dark corners of the open source world, however, doesn’t answer the question previously stated: Why not replace the entire concept of open standards with open source projects, instead? Open source still seems to be faster, and a lot of these problems might be workable given enough time and ingenuity. In reply, several points seem to be in order.

First, without open standards there wouldn’t be open source. Open standards, no matter how slow, no matter how painfully built, ultimately lay the foundation for open source. By building IP, for instance, the IETF has laid the foundation of OpenStack, and every other network virtualization package. By standardizing BGP, the IETF has laid the groundwork for every open source implementation of the protocol.

Second, by slowing down, and taking the development of a protocol or system into the realm of “one step away,” the open standards process pays more attention to use cases, nailing down requirements, and considering how the solution actually fits the problem set.

Third, by engaging a more deliberate and deliberative process, open standards encourage a more architectural view. As noted above, in the world of open source there is no real limit on the number of solutions for a particular problem set. In fact, the opposite is true; if a company can sponsor an open source project that “wins” against some other project, then there is real commercial gain to be attained. While this is certainly true in the open standards world, the process tends to encourage a smaller set of solutions that are more widely accepted.

In the end, open standards produce the APIs and architectures open source needs to work, and open source can potentially be a great source of the software projects open standards need to work the ideas and architectures out on something other than on a napkin.

Open source and open standards complement one another, rather than one replacing the other. In my next and final blog in this series, I'll examine how the IETF is improving the open standards process.

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.