Open Source: Another Value Proposition
I must create a System, or be enslav’d by another Man’s; I will not Reason and Compare: my business is to Create. - William Blake
That’s the quote we chose to open our first textbook back in 1995, in an effort to capture our belief in the importance of system-building. In a follow-up to last week’s post about the writing process, this week we look at how building systems with open source software has shaped our books.
Open source software has become an integral part of today’s technology marketplace. We’ve written about weaponizing open source software in the context of our experiences using SDN to disrupt the networking industry. It’s also common to hear people talk about business models for monetizing open source software, for example, by selling support (think RedHat) or cloud services (think Databricks operationalizing Apache Spark). Discussions of this kind typically reduce to an exercise in defining a value proposition for open source software; if you’re going through that exercise in a business setting, that value has to be direct and quantifiable.
But there’s another way to think about value, which struck me recently as we went to press with our Private 5G book. Without consciously adopting it as a strategy, I realized that all four of the Systems Approach books we’ve written recently are strongly influenced by—and in most cases, organized around—open source software. The Private 5G book describes Aether as a combination of SD-RAN, SD-Core, and SD-Fabric (all open source); the SDN book describes a software stack that starts with a P4-programmable forwarding plane, and builds through a Switch OS, a Network OS, and a set of control applications (all open source); and the Edge Cloud Operations book describes how to build a cloud management platform from a combination of over 20 open source projects ranging from Kubernetes to Keycloak to Elastic Stack. Even the TCP Congestion Control book leans heavily on the implementation in the Linux kernel (which as I’ve argued in another post, is effectively the specification of the algorithm). And as Bruce reminded me in his last post, one of the reasons I decided to write the original Computer Networks book was that I was able to leverage open source protocol stacks that I had been working with. I should have seen this pattern long before now; I thought I was just being opportunistic.
I’m not sure what name to put on that value, or even the right way to characterize it. Part of it is my own internal drive to understand how complex systems work, and part is wanting to share that understanding with anyone struggling with the same questions—but it definitely feels like value to me. I guess the easy label would be educational value, but with understanding comes empowerment to make the ideas your own, adapt them to your purposes, and ultimately, to innovate. None of these are easily quantifiable, and I have no idea how to go about computing the Return on Investment, but that doesn’t make the value any less real.
But I’m getting ahead of myself. I think there’s more than meets the eye to the conclusion that open source software leads to understanding and know-how. For example, it’s obvious that open source makes it possible to see the engineering details of a given software tool. That’s important, but what I have found to be equally true is that having access to a breadth of implementation detail is essential to having a deep conceptual framework for complex systems like the Internet or the cloud. Or said another way, seeing the “Powerpoint rendition” of a system often leads to a superficial understanding unless you also have an opportunity to look “under the hood”, and ideally, play with the code. Here are three other observations that I came to appreciate about the topics we’ve been reporting on in our book series.
Starting with SDN, it is well known that the objective was to catalyze a horizontal market around the historically vertical networking industry, and to this end, our book describes all the components that go into building an end-to-end Software-Defined Network. There comes a point about three-quarters of the way through the book where we acknowledge that everything discussed up to that point merely “reproduce(s) functionality that already exists”, at which point we are finally ready to start talking about SDN’s supposed value proposition: the ability to rapidly evolve and customize the network. But if you stop and think about it, that first 75% is a complete blueprint for how to build a modern high-speed L2/L3 switch, which until fairly recently has been the proprietary know-how of a handful of device and chip vendors. (And this understanding is now finding its way into undergraduate networking courses; see for example CS 422 at Purdue.) It’s impossible to predict how a widespread understanding of the internals of packet forwarding will impact the future of networking (even at a time when the commercial viability of programmable hardware is being questioned), but I have no doubt that it will.
There is a similar story about 5G, arguably with the potential for even greater impact. An in-depth understanding of the mobile cellular network has been known only to a handful of incumbents for 40 years. The availability of an open, software-defined RAN and Mobile Core changes that dynamic. And even though the MNOs are starting to pull back from Open-RAN, presumably because the incumbent vendors have given them good business reasons to do so, I think it’s fair to say that there’s no turning back. It’s now the case that even I am able to bring up a 5G network; surely others will figure out ways to leverage that know-how in innovative ways. Making it easier for anyone to do that is the motivation behind the book’s hands-on appendix, which is starting to find its way into courses like CS 596 at UMass.
The final example is from how to operate an edge cloud. The know-how needed to operationalize an inert pile of code (whether it’s open source or proprietary) is substantial enough that we’re willing to pay other people to do it for us. Ease-of-use is often worth paying for, but doing so should not be due to a belief that wizardry is required. This is especially true since all the tools you need to operationalize cloud services are readily available as open source (complete with excellent tutorials). At the very least, you should know what you’re paying for when you outsource the problem. It’s also the case that the steepness of the learning curve is partially related to the newness of the technology, with lots of overlapping tools competing for mind-share. Once enough people understand the space in a principled way, we should expect to see a distillation that simplifies the toolset, hopefully lowering the barrier to entry.
At this point it’s fair to observe that someone has to pay for it, and it’s difficult to fund open source software for its educational value alone. Fortunately, the educational angle is usually not the whole story. Sometimes the technical people get out in front of the business people and make their code available without an obvious business model. That happened many years ago at Bell Labs, and still happens with researchers who value impact over monetary reward. Sometimes governments pay for it as a matter of public policy (or national security). That is what’s happening today in the 5G space. Sometimes companies take a long-term perspective as a way of growing a market rather than focusing on their share of an existing market. You could argue Google has done that by releasing tools like Kubernetes, or Nicira with Open vSwitch. But I suspect that most of the time, it’s software for which someone originally put together a business plan that ends up delivering this indirect and unquantifiable value (whether or not the business plan ever panned out).
These observations may be obvious in hindsight, but I think they are easy to overlook in a field so often focused on entrepreneurship and business value. There’s the marketplace of products, but also the marketplace of ideas, and how those ideas are manipulated impacts all of us. Learning from open source software—as a means of internalizing the know-how that went into building it—is one way to consume it. Our books aim to be an aid in finding and extracting that value. As we noted in our last post, we are primarily motivated by our potential impact, and open source software is one of the best ways we’ve found to deliver it.
Regular readers of our posts will know we like to stay on top of developments in quantum computing, and we were excited to read Scott Aaronson’s review of a new book called “Quantum Supremacy”. It’s a highly entertaining take-down of what seems to be a deeply flawed book, which also serves as a quick summary of all the mistakes you should avoid when talking about quantum computing. We’ve toyed with writing a book on quantum computing ourselves but this review certainly showcases the perils facing the non-expert author. And in another oft-hyped topic area, we enjoyed this guest blog post at the Linux Foundation on the benefits of open source large language models over their proprietary counterparts.