You investigate a $1M acquisition for months and adopt a load-bearing dependency in an afternoon. The adopted dependency is an acquisition.
In 2011, Hewlett-Packard bought a British software company called Autonomy for roughly eleven billion dollars. This was not a casual purchase. HP ran the kind of due diligence that an eleven-billion-dollar deal commands: a team, a data room, months of work, and the accounting firm KPMG retained to comb the books. Then, almost exactly a year later, HP wrote down the value of Autonomy by $8.8 billion and accused the company of having misrepresented its finances by billions before the sale. The deal is now a business-school case study in failure, and one detail from the post-mortems is the reason it belongs at the top of an essay about software: HP's diligence, for all its expense, was reportedly shallow, limited to the publicly reported numbers and a thin slice of the actual contracts. They looked. They just didn't look hard enough at the thing that turned out to be load-bearing.
Here is why that should make every engineer uncomfortable. HP at least knew it was importing liabilities. That is the entire reason due diligence exists: when you acquire an asset, you acquire everything attached to it, the debts, the lawsuits, the obligations, the skeletons in the closet. HP spent eleven billion dollars and hired KPMG specifically to go find those skeletons, and still missed one. You do a structurally identical thing most weeks, you absorb an asset and every liability bolted to it, except you spend an afternoon, you hire no one, and you don't go looking at all. You type npm install, a library you've never read drops into your tree along with the hundreds of transitive dependencies behind it, and it ships to production where it runs in every single request. The price tag said “free,” and “free” is precisely what switched off the part of your brain that, in any acquisition, would have demanded a data room.
The adopted dependency is an acquisition. And the discipline that the M&A world spent decades and a great many $8.8-billion lessons building is exactly the discipline software adoption skips.
When a company buys another company, the diligence runs across a standard set of categories, because an acquisition imports the asset along with its full liability surface. Financial diligence: are the numbers real? Legal: what contracts, licenses, and lawsuits come with it? Operational: does the thing actually work, and what's it exposed to? And the one every study says gets underweighted, cultural: will the people and the way they work survive contact with yours?
Now read those categories as a dependency, because they map almost one to one. The library you're about to adopt has a financial / going-concern profile: is it funded, is it actively maintained, or is its sole author one bad week away from walking? It has legal exposure: a license with copyleft obligations, and the part nobody checks, terms the owner can change after you've built on it. It has an operational posture: a CVE history, a supply-chain attack surface, a record of how it behaves on untrusted input. It has a cultural dimension, which in software we call governance and bus factor: who controls it, how many people actually maintain it, and what happens to all of that when one of them quits. And, the category that maps to a parent company's hidden subsidiaries, it comes with transitive sub-dependencies, every one of which is its own little acquisition with its own license and its own absent maintainer, none of which you chose or even saw.
I should be honest about the prior art here, because this is not a new observation about software. Russ Cox wrote the canonical version of it in 2019, in an essay called “Our Software Dependency Problem,” whose thesis (“we are trusting more code with less justification”) is the whole anxiety in nine words. Cox gives you the engineering checklist: look at how widely a package is used, read its security history, ask whether it will process untrusted input, run its tests, write your own. If you do nothing else, do what Cox says. What the mergers-and-acquisitions frame adds on top is not how to inspect the code (Cox owns that) but three things his checklist doesn't carry: a map of which liability classes you're silently absorbing, a hard warning about where the failures actually concentrate, and a way to decide how much diligence a given adoption even deserves. Cox tells you how to inspect a dependency. M&A tells you to close it like a deal, sized to the stakes.
Start with the warning, because it reorganizes where you point your attention. The number that gets repeated about mergers is that somewhere between 70% and 90% of them fail to create value, a range, with real methodological caveats about what “fail” means, but a range that has survived a lot of replication. The interesting part isn't the size of the number. It's where the failures live.
They do not live in the financials. The financials are the thing every acquirer diligences to death; that's the easy, legible, spreadsheet-shaped work, and it is almost never what kills the deal. In a Bain study, executives who had run mergers named culture as the single biggest reason a deal failed to reach its potential, the soft, hard-to-quantify dimension that the diligence process consistently shortchanges. The most expensive illustration is AOL–Time Warner: the merger that closed in 2001 produced a writedown of roughly $99 billion the following year, and the standing post-mortem is that two organizations with violently incompatible cultures were stapled together by a process that had scrutinized the numbers and waved through the mismatch that actually mattered. Failure concentrated in the dimension nobody seriously checked.
Software fails the same way, on the same logic. Your dependencies do not blow up on the functionality you unit-tested, that's the legible part, the financials, the thing you naturally check. They blow up on the dimensions you skipped: the maintenance health that was quietly a bus factor of one, the transitive sub-dependency you never knew you'd absorbed, the exit cost you never priced. The cheap-looking adoption is where the hidden liabilities concentrate, for exactly the reason the value destruction in M&A hides in the soft diligence nobody runs. The thing that says “free” and “two-minute install” is wearing the same disguise as the deal whose numbers all checked out.
These aren't abstract liability classes. Each one has a name and a date.
The transitive subsidiaries. A single npm install can pull in hundreds of transitive dependencies, each with its own license and its own maintainer; you don't acquire one company, you acquire it and every shell entity it secretly owns. In March 2016 a developer named Azer Koçulu, in a dispute over a package name, unpublished his code from npm. One of those packages was left-pad: eleven lines of JavaScript that padded out a string. Eleven lines, removed in a moment of pique, broke the builds of thousands of projects, including pieces of React and Babel, because the entire ecosystem had absorbed it as a sub-sub-subsidiary nobody knew was on the org chart. That is a hidden-subsidiary liability detonating, no different in shape from discovering post-close that your shiny acquisition owns a bankrupt entity in another country.
The maintenance health, and the cultural check inside it. Many load-bearing open-source projects have a bus factor of one: a single human whose departure ends the project. M&A would call that a key-person dependency and price it heavily. The dependency version of “cultural fit,” the soft check that the data shows is the fatal one, is even softer: is the maintainer about to quit in anger? That question has answers, the recent wave of maintainers who rage-quit or sabotaged their own widely-used libraries after years of unpaid corporate use is the maintenance-health red flag screaming, and it is exactly the diligence that gets skipped because it doesn't fit in a vulnerability scanner.
The security posture. In December 2021, the world's enterprises learned that a logging library called Log4j, which they had collectively “acquired” with precisely zero diligence on its security history, contained a flaw that let an attacker run arbitrary code by getting a single string into a log. Log4Shell wasn't an outage. It was the discovery that a huge fraction of the corporate world owned a remote-code-execution liability it had never once examined, a liability imported in an afternoon, years earlier, by someone who needed to log a message.
The license, and the obligation that changes after close. The classic M&A nightmare is the obligation that mutates after you sign. Software has a direct analog, and it has been epidemic. A string of foundational infrastructure projects, almost all of them adopted by their users as “free and open source,” have relicensed once a cloud provider started monetizing them: MongoDB to the SSPL in 2018; Elastic to the SSPL in 2021 (it later added back an open option in 2024); HashiCorp's Terraform to the Business Source License in 2023, which triggered the OpenTofu fork; Redis to a restrictive source-available license in 2024, which triggered the Valkey fork that dozens of companies rushed to within a year. If you had built your entire infrastructure-as-code practice on Terraform the week before that announcement, you discovered that the license, the thing you never diligenced because it said “open,” was an obligation the seller could, and did, change underneath you. That is acquiring an asset whose terms weren't actually yours to keep.
Here's the objection that makes most versions of this advice useless, and the surprise that resolves it. You cannot run months of diligence on every package. You have hundreds of transitive dependencies; reading them all is impossible, and you'd never ship anything. So is the lesson “just try harder”? No, and HP is the proof, because HP ran maximum diligence, with KPMG and eleven billion dollars on the line, and still imported a skeleton. Diligence is not a guarantee. Doing more of it everywhere is both impossible and, even where possible, not sufficient.
The actual prescription is the one word the M&A world would lead with: proportionality. You match the depth of diligence to how load-bearing the thing will become. A leaf dev-dependency used once in a build script gets a glance, it's a rounding error, treat it like one. But a library that will run in every production request, or a SaaS platform that will quietly become impossible to leave, gets the full deal, because the stakes there can genuinely exceed a one-million-dollar acquisition. A transitive dependency in your hottest code path, sitting between your users and their data forever, is a larger liability than most small companies you could buy, so it deserves more scrutiny than the deal, not the three minutes it currently gets. The asymmetry in the title isn't just unfair. It's backwards.
And there is one check in the deal that software adoption skips almost universally, and it is the one to add first: price the exit before you're locked in. M&A diligence always asks what divestiture or unwinding would cost; dependency adoption almost never asks what removal or migration would cost, and by the time the question becomes urgent, the answer is “catastrophic.” Here the analogy honestly bends, and it's worth saying where: a dependency is nominally free (which is exactly why the scrutiny gets skipped), and you can often fork or rip out a library in a way you can never “un-acquire” a company. That escape hatch is real, but lock-in steadily welds it shut. SaaS data gravity, deep framework coupling, the database you can no longer migrate off of without a year-long project: these turn a removable dependency into something with an exit cost that rivals a divestiture. The time to measure that cost is at adoption, while you still have the bargaining power of not having adopted yet. Ask anyone who'd built their platform on Terraform how cheap the exit felt the week the license changed.
So the rule is short, and it inverts the title. Adoption is acquisition. You would never buy a company off the strength of its homepage; stop adopting load-bearing dependencies off the strength of their README.
The move is concrete and it fits in a single afternoon, because proportionality is what makes it tractable. Open your dependency manifest and mark the handful that are genuinely load-bearing, the ones that will run in every request, hold your data, or be agony to remove. Ignore the long tail; it doesn't earn the attention. On just that critical few, run the deal:
Five checks, on the load-bearing few, sized to the stakes.
Log4j and left-pad were not outages, and Terraform's license change was not a press release. They were failed acquisitions, billion-dollar liabilities absorbed in an afternoon because the price tag said “free” and switched off the scrutiny that any deal of that consequence would have triggered. The price was never actually zero. It was just filed in the liabilities column, which is the one column M&A taught everyone to read first, and the one column that, with one npm install, nobody reads at all.
Adoption is acquisition, and agents adopt faster than anyone.
The five checks are a trust evaluation: maintenance and reputation, security history, who controls it, the transitive provenance, the exit. When the thing adopting a dependency (or another agent, or a tool) is itself autonomous, that evaluation has to be machine-readable and verifiable, not a README and a vibe. The Agent Trust Stack is that diligence as infrastructure: a tamper-evident provenance record underneath, learned reputation on top, fast checks at the point of adoption, so an agent can run the deal before it imports the liability.
See a verified provenance chain · Hosted Chain of Consciousness
pip install agent-trust-stack · npm install agent-trust-stack