Getting to Know Your OSS Dependencies and Vendors

January 12, 2026

The prior post tied open source software (OSS) licenses back to a historical basis in property law and focused on rights and responsibilities. I discussed how explicit license terms enable collaboration. Now let’s consider the consequences of decades of collaboration.

In the earliest days of computing hardware was physically large, expensive (in dollars and power and human maintenance activities), and limited in its computing capabilities. This naturally coupled with bespoke software, usually distributed under a proprietary license. The combination was an opaque box.

Software Reuse is Everywhere

Since those early days computer science has also heralded the benefits of sharing and reusing software. We have abstract data types, hardware abstraction layers, dynamically linked and loaded libraries, and languages tailored to enabling interoperable components. As computers became smaller, less expensive, and more capable, they showed up in more and more diverse places making it impractical for each to have fully custom software. More and more software became a stack, with the underlying foundations treated as a commodity and the collaborative outputs of open source software communities seemed to be a perfect match.

https://xkcd.com/2347/ image of "All Modern Digital Infrastructure" as a stack of blocks ready to fall down if not held up by a tiny underlying block labelled "A project some random person in Nebraska has been thanklessly maintaining since 2003".

OSS Reuse is EVERYWHERE

Computers are all around us, and OSS is all around us. I like to pause when meeting in person with clients and do a brief survey. Look around: The laptops on the desks. Smart watches and smartphones on our person. Industrial devices like thermostats, light switches, and door entry controls. Conference room devices like TVs, projectors, telephone. So many computers and so much software. If you consider the distinct tuples of project/version/release and the reused componentry across operating system, language frameworks, and application, it is quite possible there are a million or more distinct pieces of open source software you can readily “see” around you.

Now remember where the prior post ended: OSS licenses do not ensure fitness to purpose or merchantability of the software and you have no contractual basis to hold them to an expectation of anything else. Nevertheless, as consumers purchasing devices, software, and services in the marketplace, we absolutely expect our vendors to stand behind their products.

So what happens when something goes wrong? When something breaks, who fixes it? How to reconcile this seeming contradiction between the ubiquity of OSS, the terms of OSS license, and our desire for things to actually work now and stay working into the future?

Who is Your Vendor?

Many vendors attempt to simply deflect to the OSS community which created the foundational pieces of software “upstream” of their position in the market supply chain. But those OSS communities, in their choices of OSS licenses, explicitly placed this responsibility out of scope contractually. A common refrain in OSS communities today is, “I am not your vendor”.

This leaves only two choices: Product vendors must take on the maintenance burden and carry the responsibility of ensuring the products are market ready, or they must establish commercial relationships with intermediate entities which bundle, test, document, and support the core foundational OSS software components.

Planning which portions of software supply chain lifecycle management to do in-house and where to leverage third-party vendor relationships is a critical business choice, with incorrect decisions leading to loss of revenue or undermining profitability.

So who are the vendors of your dependencies? Are you struggling choosing the vendors and dependencies for a new product or service? Or realizing now that updated plans are needed for existing ones? Reach out for a conversation…

Page updated

Report abuse