Venn Diagram Engineering
And Other Tactics in Weaponizing Open Source
If the reaction to our last post on MPLS is any guide, Systems Approach readers like hearing insider stories about networking history. Fortunately, there’s plenty more where that came from, as this week’s entry from the SDN world illustrates.
Open source software has been the subject of many essays, of which Eric Raymond’s insights in The Cathedral and The Bazaar still serves as a thought-provoking example. For those who haven’t read that piece, Raymond examines the conflict between what had been his experience with open source software:
“I believed that the most important software… needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.”
and a different approach he witnessed the Linux community using with great success:
"The Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches ...out of which a coherent and stable system could seemingly emerge only by a succession of miracles."
His observations came to mind as I reflected on our experiences at the Open Networking Foundation (ONF)1 over the last decade, leading me to write down a few of my own observations on one particular corner of the open source ecosystem.
ONF’s mission has been to disrupt the networking industry, with open source software serving as its primary tool for catalyzing that change. That disruption is widely known as Software-Defined Networking (SDN), but focusing on that term misses the point, which is that the overriding goal is to transform the networking industry from a vertical market to a horizontal market, and in doing so, both spur innovation and improve the opportunity for network owners to control their destiny. That mission has its roots in a 2001 National Academy report on the ossification of the Internet, but my take is that the goal is simply to lower the barrier for those who wish to program and control networks. The ONF journey has involved a long list of open source platforms and components (some of which are described in our SDN book), but rather than retrace the history of the specific projects, I’d like to focus on a few lessons we learned along the way.
Beyond its mission to be disruptive, ONF has two other fairly unique attributes. First, it has its own engineering team, and that team has no allegiance to any commercial product. (Mozilla is the only other similar example that comes to mind.) The objective is to push the principles of SDN—open source software, disaggregation, commodity hardware, cloud practices—into any space that provides an opportunity. There is no legacy business model to protect. Second, although the individual software components each have stand-alone value, with their own constituents driving requirements and their own development teams doing the work, they have been designed with an eye towards working in concert across the entire portfolio. This proved important because it provided in-house use cases that drove iterative improvements, which ultimately led to the creation of new platforms with their own set of requirements and use cases. This approach is arguably a hybrid Cathedral/Bazaar model, but more on that point below.
So what did we learn? The top-level lesson is that we knew we were making progress on the disruption mission because there was constant resistance. It’s impossible to know how much change to directly attribute to ONF given everything else going on in the industry, and making such a claim would be silly. But when you are trying to disrupt an entrenched industry, resistance is a sure sign that you are doing your job. Interestingly, this resistance came from stakeholders up-and-down the stack. It started with the incumbent network vendors who the network operators wanted to disrupt, but it ended up including the network operators themselves, whose approach to operationalizing the network is now being challenged by cloud native approaches. For fun, we report a few “ah ha” moments along the way. Some technical; some, not so much…
I learned a new term early in the journey: weaponizing open source. Make of that what you will.
It became clear after we started to deliver successful platforms that we were a pawn on a larger chess board, serving as a stalking horse for operators to negotiate better pricing from their vendors. Of course that was the case. The surprise was hearing it said out loud.
Standing up vendor-backed open source projects is the go-to approach for doling out incremental change, a strategy known in some circles as “throwing sand in the gears.'' This happened with Open Daylight (ODL) in the SDN Controller space, and the O-RAN Software Community (OSC) in the RAN Intelligent Controller space. (See our post on SD-RAN for an example of the point of contention in the 5G space.) When vendors bring all the engineering resources to a “community” effort, they retain control over the agenda. ONF’s vendor-neutral/engineer-led approach offered a counter-weight in both cases, which led to tangible features that would otherwise be missing.
A tried-and-true approach to discrediting a new (disruptive) technology is to brand it as a “research project”. This was a constant refrain, and of course any new approach isn’t going to be as mature as the incumbent solution. That should be expected. But time is a great equalizer, and in the case of ONF, much of its software now runs in production networks. (For some examples, see here, here, here, and here.) But that isn’t necessarily the point; it’s just a more measurable outcome than indirectly impacting the openness and programmability of commercial alternatives.
The best traction for a disruptive technology is in deployments facing generational upgrades, as was the case in the access network (e.g., DSL to PON/GPON and 4G to 5G). This is obvious in retrospect, but then again, SDN likely needed small wins in established settings to be a credible alternative in new environments.
Uncountable hours can be spent doing “Venn Diagram Engineering”, a term I coined to describe the process of mapping the constraints on any potential solution (before it’s implemented or fully understood) to respect existing business models and stakeholder boundaries. That’s certainly not how the Bazaar works. Creating new platforms requires freedom to refactor as you gain experience, and that refactoring may very well disrupt current business models.
Building complete solutions (and not just components) is a necessary first step in gap analysis, helping to identify the breadth of issues that need to be addressed to make a technology viable. The second step is to use and operate your solution, and not just throw it over the wall to someone else. Operational experience (aka “eating your own dog food”) is the best way to turn a proof-of-concept into a commercially viable solution. ONF is now doing this with Aether, a capstone project that combines its SD-Fabric, SD-Core, and SD-RAN components with a comprehensive operational platform to provide a managed edge cloud service.
These last two points are the main (technical) takeaway. The ONF approach to open source software includes elements of both the Cathedral and the Bazaar, but is also different in its open-ended approach to mapping out a new space. There is a shared set of architectural principles and a concerted effort to ensure that the components work together to build operational end-to-end solutions (the cathedral). But at the same time, each component is allowed to reinvent itself and fork new components, as necessary, to follow emergent opportunities (the bazaar). There is no prescribed framework that fixes interface boundaries a priori. This isn’t a revolutionary new approach: it’s just the natural consequence of making a system open and programmable.
We are about to start a print run (yes, we still do print books, and eBooks as well) on our TCP Congestion Control book, and we’d love to have as few typos or other mistakes as possible. So we’re offering an incentive: anyone who can point out two(2) or more mistakes, if we accept your corrections, will receive a free print or ebook download of the new book. One bugfix gets your our gratitude and a mention in the acknowledgements. Ideally, submit Issues or PRs via GitHub, or see other ways to reach us.
This week’s photo by Alex Azabache on Unsplash.
The ONF was created to shepherd the OpenFlow standard, and at the same time, a sister organization called the Open Networking Lab (ON.Lab) was established to build open source SDN platforms and solutions. In 2017 ONF and ON.Lab merged, keeping the name of the former and the mission of the latter.
This is such an original take. My sincere thanks for writing this and sharing your experience. This is so insightful as well as helpful. I worked on the OMEC project mainly on the build/deploy and protocol testing but didn't understand the big picture when I was working on it. It makes so much sense now how OMEC through SD-Core is part of something significant - Aether Project. I recently started focusing on 5G security, and the approach mentioned is so helpful for me in strategizing.