Open Source and the Software Supply Chain

How do you manage resources for building software made by the open source community?

John Mark Walker

Grasping the nuances of hardware supply chains and their management is straightforward—you essentially are tracking moving boxes. Managing something as esoteric as resources for building software with a variety of contributions made by the open source community is more amorphic.

When thinking about open source platforms and supply chains, I thought of the supply chain as a single process, taking existing open source components and producing a single result, namely a product. Since then, I’ve begun to realize that supply chain management defines much of the open source ecosystems today. That is, those who know how to manage and influence the supply chain have a competitive advantage over those who don’t do it as well, or even grasp what it is.

How a software supply chain functions

In the hardware world, supply chains and component sourcing is a necessary part of the business. A well-managed supply chain is crucial to business success. How do you determine ideal pricing, build relationships with the right manufacturers, and maximize the efficiency of your supply chain so you’re able to produce more products cheaply and sell more of them? Apple’s supply chain is legendary—they were one of the first to realize that a key to competing is building out an effective supply chain of parts, and they did it at a time when Silicon Valley preferred to build most of the components themselves.

The computing industry laughed at Apple, calling them a "marketing company" that just took parts from elsewhere. These days, every hardware company has an extensive supply chain and dedicates teams of people to managing different aspects of it. The irony is that Apple is probably more innovative on supply chain logistics than they are on actual product. To put it another way, their innovation in supply chain logistics gave them a great platform from which to launch innovative products.

In software, the supply chain has traditionally been much simpler than that for hardware. Whereas hardware supply chains source parts from many different partners in different geographies, traditional software supply chains have mostly defined the process of creating software made in-house, with some third-party software from vendors via commercial license agreements. In this model, most of the supply chain is defined by software sources inside the company itself, possibly from multiple engineering teams. With a small percentage of software coming from outside the company, the process of defining a supply chain was mostly left to internal product management and engineering teams. Yes, licensing software from third-party vendors required license compliance checks as the product was assembled, which meant getting legal approval for any software license agreement. This process was well-established with common practices, with many of the license agreements derived from the same legal template that legal and product management teams had experience with—but then open source became a lot more common, and everything changed.

Software supply chain management went from a relatively simple, well-defined process, like this:

To a chaotic, multi-layered mix of unproven licenses, untested software repositories, and a Wild West mentality that software supply chain teams were ill-equipped to manage. The funnel is now shaped more like:

As you can see, at least one extra layer of complexity has now been added.

You might think that this wouldn’t be the case—that simply plugging in open source components would be a direct 1:1 replacement for the traditional method of licensing agreements from third parties, but there’s an extra wrinkle to take under consideration. With regards to upstream open source components, many of these raw source repositories have no mechanism for commercial support. As the supply chain or product manager you have no single "throat to choke" when things go wrong, as they inevitably do.

You have two basic choices: either build your own internal means of vetting the code and applying product management processes, or rely on an intermediary to perform that function. You can make an argument for creating the processes for pulling down source code, determining legal compliance, applying patches, and getting it ready for production yourself, but it is expensive from a human resources point of view. You should base your decision whether or not to self-direct the process on its strategic importance to the company and some ROI analysis: If you build a team to manage that process for some software components, will you see a sufficient return on that investment?

In many cases, companies make the decision to go with an intermediary to vet the code, perform some quality assurance engineering, and apply whatever glue code is necessary to make it work satisfactorily. This is where software distributions come into play, filled by companies like Red Hat, SUSE, and Canonical. People often ask me why these companies are essential, and I hope you can see now why that is the case—because without them, the open source supply chain falls flat.

Without distributions such as Red Hat Enterprise Linux (RHEL) or its equivalent, companies creating products for either internal or external consumption would have to create from whole cloth the processes for pulling in these components, vetting them, hiring the in-house expertise to enhance them, and then perform the gluing process that allows a company to push a release into production. In this scenario, many companies determine that simply letting a distribution company fill in that layer and manage that part of the process is easier and more efficient.

Besides, that’s just in the case of the open source "user," not supplier. Here’s where it gets really interesting. At what point does a company that uses or inserts open source code into its products decide that it wants to become an influencer or supplier in the supply chain, and what’s the best way to do that? One potential conclusion is that to be successful at open source products, you must master the ability to influence and manage the sundry supply chains that ultimately come together in the product creation process. Once done, the end product you produce is able to benefit from your participation on the left side of the supply chain funnel directly.

Instead of maintaining a standard set of patches that you continuously apply to every new vetted upstream component, why not contribute those into the upstream components, making them more easily maintained outside of your organization? If you’ve already made the decision that working with downstream software distributions is easier than sourcing and vetting the source code yourself, isn’t there a direct benefit from working with the distribution vendor to get your code contributed upstream? Doing so results in the added benefit of other groups managing and supporting the maintenance of this code, freeing up your engineers to work on the interesting stuff that directly adds value to your product. Whether you sell software, sell software consulting services, or create an open source community, studying your supply chain and learning the best way to manage them is worth your time.

Hardware supply chains, based on physical materials, are more static in nature compared to software supply chains. The open source software supply chain is by definition very fluid. Projects wax and wane over time, and you, whether business person, developer, or community leader, must decide which pieces are worth your time and when it’s best to cut your losses and switch out one supply chain for another. Which components you use, modify, and create from scratch will all depend on the state of the supply chain that make up your project or product. The process is both proactive and reactive. You must decide proactively which supply chains to invest in and which to ignore, while also reacting to rapid changes in relied-upon ecosystems. Those that master this art will, in theory, have the most efficient processes and, like Apple, will win out in the end. The desired result is achieving a level of efficiency that gives your project team the means to innovate more.

If you can efficiently manage your software component supply chains and simultaneously create an efficient supply chain funnel that allows for fast iteration on a product under development, your product creation and management processes will improve. This management requires the investment of resources in not just your product’s QE team and supply chain funnel, but also in the supply chains that form the components you use to create your product.