繼任層：採購中「我們的合作夥伴會處理」是代價最高的一句話

Three stories on Hacker News today, and not one of them is about an outage.

Roku moved its developer repositories from GitHub to GitLab (252 points). Node2Shell grew into HTTP2Shell, and the blast radius now covers "many HTTP libraries and apps" (273 points). Google reportedly turned a batch of Nest thermostats back into dumb thermostats (29 points). Different companies, different categories, same event: an obligation changed hands, and nobody signed for it.

That's the succession layer. Not who owns the thing today — who answers for it tomorrow, when the entity that promised you something is no longer the entity that exists.

Ownership is not succession

Every vendor relationship bundles two different things, and contracts only price one of them.

The first is custody: who holds the code, the keys, the hardware, the account. This is documented, invoiced, and audited.

The second is succession: who inherits the obligation when the holder stops answering. This is assumed.

A contract can transfer liability. It cannot transfer the ability to answer the phone. When a maintainer burns out, when a repository moves hosts, when a product line gets quietly re-scoped to enterprise, the legal obligation may survive intact while the practical one evaporates. You keep the invoice and lose the counterparty.

Three failure shapes come out of that gap, and today gave us one of each.

The address moves. Roku didn't delete anything. It relocated. Which means every pipeline, webhook, package reference, CI badge, and documentation link that pointed at the old address now depends on a redirect that nobody promised to maintain forever. No error was thrown. The dependency just acquired a new landlord.

The blast radius widens underneath you. HTTP2Shell isn't a new vulnerability in your code. It's a vulnerability in code you inherited by using a library that used a library. The maintainer of the middle link may have stopped answering in 2021. You now own a remediation deadline for someone else's abandoned obligation.

The product outlives the service. A thermostat is a lump of metal and radio. What made it a thermostat was a service. When the service retires, the hardware keeps working and stops being the thing you bought. Nobody stole it. Nobody breached anything. The obligation simply wasn't inherited by anyone with an incentive to honor it.

The two-in-the-morning test

Here's the cheapest audit you can run this week. Ask one question about every dependency that could break a customer-visible behavior: at 2 a.m., who do I call, and will that person still be there after the next acquisition?

Most teams can name a company. Far fewer can name a person. Almost none can answer the second half, because the honest answer requires knowing things that aren't in the contract:

• Who can authorize a change to this system on the vendor side?
• Who holds the credentials if the account owner leaves?
• Is there a named successor in their own runbook, or is the account a single human with a laptop?
• If the vendor is acquired, does your contract survive the assignment — and did anyone check whether it's assignable at all?

The pattern that falls out of those four questions is uncomfortable: the dependencies you can least afford to lose are usually the ones with the thinnest succession. Critical infrastructure tends to be maintained by three people and a mailing list. Enterprise vendors with 40-page contracts tend to be the ones you could replace in a quarter.

Inheritance is a design decision, not a legal one

You cannot contract your way to succession. You can architect for it. Four properties do most of the work:

Address independence. Never hardcode where a dependency lives. Resolve it through a layer you control — your own mirror, your own registry proxy, your own DNS. When someone else relocates their repository, you should experience it as a config change, not an incident.

Escrow with a key. Source code in escrow is a souvenir unless it ships with the build system, the secrets rotation procedure, and a document explaining which of the 40 services actually matters. Ask what's in the box before you need the box.

Exit-capable data. If you can't export the full state of a system into a format a stranger could import, you don't own your data — you're renting access to it. This is the same test as the continuity layer, applied one level down.

A named successor inside your own house. Every critical vendor needs a second person who has logged in, read the docs, and knows what breaks. Bus factor one on the buyer's side is just as fatal as bus factor one on the seller's side, and it's entirely within your control.

What you owe the client

If you resell any part of your stack — and if you run an agency, a SaaS, or an agent product, you do — succession is a disclosure problem before it's an engineering problem.

Clients don't want your vendor list. They want to know three sentences: what happens to their service if a supplier disappears, how long you can keep operating while you replace it, and who inside your company is accountable for that answer. If you can't produce those three sentences, you're selling them a dependency you haven't stress-tested.

The teams that survive supplier exits gracefully are rarely the ones with better suppliers. They're the ones whose clients heard the risk from them first, in ordinary language, months before it mattered. That costs a paragraph and buys years of trust.

Six things to do this week

1. Run the 2 a.m. test on your top five dependencies. For each: a company name, a person name, and the answer to "who authorizes changes." Blank cells are the finding.
2. Mirror anything you can't replace. One internal registry proxy, one DNS layer you control. If a repository relocation would break your build, fix that before the relocation happens.
3. Open the escrow box. If you have one, verify it contains build instructions and secret rotation — not just source. If you don't, price one.
4. Add assignment clauses to renewals. Contracts that can't be assigned on acquisition are worth less than the paper they're on. Ask the question at signing, not at renewal.
5. Break bus factor one on your side. A second engineer logs in, reads the runbook, and does one change this month. Written access is not the same as exercised access.
6. Write the handover paragraph. One paragraph: "If supplier X disappeared, here's what changes, for how long, and who owns it." Send it to your biggest client before they ask.

None of this shows up in a demo. All of it shows up in the quarter when a supplier stops calling back — and by then, the only thing that matters is whether someone already wrote down who inherits the obligation.

Next in the series: the escrow layer — what actually has to be in the box for a successor to act, and why source code without the keys, the build, and the runbook is a souvenir, not an asset.