Oops, I'm part of a supply chain. 😳

Open source has become the modern development platform, and organizations across all industries are using more and more open source in their applications today. Our Tidelift data shows that over 90% of applications contain open source components, and in many of these applications, it makes up 70% or more of the code.

As more organizations use more open source, we’ve begun to hear a phrase more and more over the past year: “the open source software supply chain.”

If you work for a large organization, the term “supply chain” is familiar, and it makes sense that you’d think of externally sourced open source components as “supply” produced by open source maintainer “suppliers.”

But in our experience, open source maintainers don’t think like that. In many cases they never signed up to be a supplier, at least in the traditional sense of producing something of value and getting paid for it (see this blog post entitled I am not a supplier for one example). In most open source software licenses, the code is available to use freely, with few restrictions, but also with “no warranty.”

So if you are an open source maintainer who accidentally has found yourself part of a “software supply chain” or you are building applications with open source and want to better understand how open source software both is AND isn’t a supply chain, this post is for you!

What is a supply chain?

Supply chains have existed and thrived for producers and creators in many different industries, and the concept is defined as a network of producers, manufacturers, distributors, and retailers involved in the creation and sale of a product.

For example, in the automobile industry, parts suppliers mass produce the individual components needed to build cars, then automobile manufacturers use these parts to assemble cars under their brands. There’s a shared understanding that each individual producer is creating a small part to contribute to a whole car, and retailers understand that each individual part has contributed to the end result.

Even more importantly, car manufacturers have contractual relationships with their parts suppliers where they pay them to produce the parts, and negotiate details like the quantity to produce, the date they will be produced by, and a warranty or guarantee of quality that the supplier agrees to as part of standing behind their work.

So for a supply chain to function effectively, there must be a clear agreement between supplier and customer that includes a mutual exchange of value.

By that definition, is open source software supply chain a misnomer?

So imagine for a minute that you are an open source maintainer. You created a small solution in your free time that automates task queue management across machines, which helps you solve a problem you were having in your own project. Thinking it might be helpful to others as well, you decide to publish the code on a package manager. Nice job, we appreciate you!

Over time, your repo grows, as does your number of GitHub stars and downloads. Other developers have found that your project helps them fill a need in their project, so they introduce it as a dependency.

Eventually, your small project becomes a highly depended-upon addition to larger products, and starts being used in applications developed by companies with names we’ve all heard of.

You start receiving correspondence from people at these companies looking for more consistent issue and update support. Occasionally you even get demanding notes that you fix something immediately, or notes from corporate lawyers asking you to fill out paperwork you don’t have the time (or incentive) to review.

As a solo maintainer of a project that started as a quick fix, you’re now responsible for consistently maintaining the health of your project, its security, and its reliability. As your project continues to grow in popularity, new government and industry security requirements create even more work, and pressure mounts as you feel the increasing responsibility of ensuring this free time project you created doesn’t cause some big company’s application to melt down or its customer data to get hacked.

Oops! You are now part of a supply chain.

Well, sort of. You are a supplier in the sense that you’ve written code that others are using. But you’ve given it to them with no warranty or contractual agreement, which means that only one of the two parties is thinking of this as a traditional supply chain.

Therein lies the issue.

The open source supplier’s dilemma

Security incidents like Log4Shell have dramatically illustrated the importance of heightened security and maintenance measures for open source packages, but our scenario and the reality for many open source maintainers has illuminated a big problem: the volunteer open source maintainers who create the code most organizations rely on did not usually ask be a part of anyone’s supply chain, and in many cases aren’t being paid to do the work to ensure their project meets the level of security and maintenance standards that enterprise users might expect.

Some of them have no interest in being an enterprise software supplier. Many of them would be interested in doing this work—but not for free—only if it is worth their time, effort, and attention.

So how do we fix the accidental supply chain in open source?
How do we fix the accidental supply chain? Can we create a system that benefits both the open source creators and the organizations that rely on their work?

I'd love to hear your thoughts here, or in our dedicated open source space, the Tidelift Community.