The first page of a modern service-level agreement used to look like a spec sheet for a machine. Availability percentage, response time targets, error budgets, maybe a penalty schedule. The human who actually kept the service running was an abstraction, a role that could be filled by anyone with the right runbook. That is changing. In a growing number of contracts, the maintainer's name appears before the uptime promise. The SLA is starting to read less like a warranty and more like a will.

This is not a universal practice yet. It shows up most often in contracts for infrastructure built on open source components, where the line between vendor and community is thin. A company licensing a database, a message queue, or a deployment tool increasingly wants to know who, specifically, will be awake at 3 AM when the cluster degrades. The name on the contract is no longer a legal entity. It is a GitHub handle, a timezone, a history of commit messages.

The shift is a reaction to a decade of incidents where the uptime promise held but the service still failed in spirit. A system can be up and completely useless because the one person who understood the failure mode is on vacation. Availability numbers do not capture that. They never did. What they capture is the machine's heartbeat, not the knowledge that keeps it beating.

So the SLA is being rewritten. The second line, the one after the party names, now often reads: "Primary maintainer: [name]." The uptime guarantee follows. This ordering is deliberate. It tells the buyer that the contract is with a person, not a process. It tells the maintainer that their reputation is now a service-level metric. And it tells the rest of the industry that the bus factor, once a joke whispered in conference hallways, has become a line item in procurement.

The SLA That Reads Like a Will

The first sign of this change appears in the boilerplate. Legal teams that once fought over force majeure clauses now spend an equal amount of time reviewing a maintainer's GitHub profile. They want to know how many repositories the person maintains, how often they respond to issues, whether they have a history of disappearing for months. The due diligence is not about code quality. It is about continuity.

One procurement officer described the new review process as "reading a will before signing a lease." The buyer wants to know what happens if the maintainer is hit by a bus. Does the project have a documented successor? Are there bus factor numbers in the README? Has anyone else ever pushed to the main branch? The answers shape the risk premium in the contract.

The name-first format forces a conversation that most teams avoided. Maintainers, who often work alone or in small groups, are being asked to name their own successors. This is uncomfortable. It means admitting that the project could survive without them, which feels like a small death. But the contract is not interested in feelings. It is interested in the probability that the service stays alive after an unplanned departure.

Some maintainers resist. They argue that naming themselves as the primary contact is a liability, that it makes them a single point of failure in a legal sense. They are right. But the market is pushing back. Buyers have learned that a service without a named human behind it is a service without a soul. The uptime promise is only as credible as the person who will answer the page.

The legal teams have adapted. They now write clauses that tie the SLA to the maintainer's continued involvement. If the maintainer leaves, the contract may be renegotiated or terminated. Some contracts include a "key-person" clause, a term borrowed from venture debt practice, which allows the buyer to walk away if the named individual is no longer in the role. The SLA has become a personal guarantee, and the person is collateral.

Why Uptime Alone Stopped Selling

For decades, the industry sold uptime as the ultimate metric. Five nines, 99.999 percent, was the gold standard. It was a number that procurement could understand and that sales teams could put on a slide. It worked because infrastructure was more predictable. A server was a server, and a network was a network. The failure modes were well understood.

That predictability is gone. Clouds fail in ways that are both more spectacular and more mundane. A misconfigured DNS record takes down a global service for an afternoon. A certificate expires at 2 AM and no one notices until the pager goes off. The postmortems all look the same: human error, lack of redundancy, a missing check. The industry has become numbed to these stories. Uptime numbers do not differentiate a service that has seen it all from one that has been lucky.

Buyers have started to price this in. They no longer believe that five nines means the service will work when they need it. They want to know who will be awake, who will understand the system, and who will make the call to roll back. The name on the SLA is a proxy for that confidence. It says that someone with context is responsible, not just a process that fires alerts into a void.

The shift is also a reaction to the open source sustainability crisis. Many critical services run on software maintained by a handful of volunteers. When a maintainer burns out or walks away, the project can stall, and the service degrades. Buyers have seen this happen too many times. They have learned that the uptime promise is meaningless if the underlying project is not healthy. The name is a signal of long-term stewardship, a way to bet on a person rather than a repo.

The Economics of Named Maintainers

Naming a maintainer changes the economics of a service contract. The name adds a risk premium. If the maintainer is well-known, with a long history of reliable releases, the premium may be lower. If the maintainer is new, or the project is a bus factor of one, the premium goes up. Some contracts now include a line item for "maintainer continuity insurance," a fund set aside to pay for a successor if the original maintainer cannot continue.

This is a form of key-person insurance, a concept familiar in corporate finance but new to open source. The buyer is not just paying for the service. They are paying for the probability that the service will be maintained next year. The price of that probability is negotiable, and it depends on the maintainer's track record, the bus factor of the project, and the availability of a documented succession plan.

Venture models are starting to feel this variable. A startup that builds its product on a single maintainer's library is now seen as riskier, and the valuation reflects it. Investors ask about bus factor during due diligence. They want to see that the startup has a relationship with the maintainer that goes beyond a GitHub sponsorship. Some investors are even asking startups to fund the maintainer directly, as a way to de-risk the dependency.

The funding model is shifting from repo to person. Instead of donating to a project, companies are signing contracts with individual maintainers. These contracts may include a retainer, a commitment to respond within a certain time, and a clause that the maintainer will train a successor. The money follows the human, not the code. This is a significant change from the early days of open source, where the code was free and the humans were invisible.

Bus Factor Becomes a Line Item

The bus factor, also known as the truck number, is the minimum number of team members who have to be hit by a bus before the project is doomed. It used to be a joke. Now it is a contract term. Some SLAs include a section titled "Bus Factor Mitigation" that requires the maintainer to document the knowledge needed to operate the service, and to identify at least one person who could take over in an emergency.

Key-person clauses are becoming standard in infrastructure contracts. They were borrowed from finance, where a company's value is often tied to a few key executives. In tech, the key person is the maintainer. The clause allows the buyer to terminate the contract if the maintainer is no longer involved, or to demand a replacement with equivalent skills. This puts pressure on the maintainer to build a bench, even if that bench is just a well-written runbook.

Maintainer health audits are now part of due diligence. Buyers look at the maintainer's commit history, their response time to issues, and their activity on social media. They look for signs of burnout, such as long gaps in commits or a tone of frustration in issue comments. The audit is not about code quality. It is about the probability that the maintainer will still be alive and willing six months from now.

Succession plans are being written in Markdown and committed to the repository. They are not legal documents. They are practical guides that describe the architecture, the deployment process, and the common failure modes. The plan is a form of insurance. It reduces the cost of a bus factor event, and it signals to buyers that the maintainer is thinking about the long term.

In some cases, the maintainer's GitHub handle is listed as collateral in the contract. If the maintainer fails to meet the SLA, the buyer may have a claim on the repository, or on the maintainer's time. This is an extreme measure, and it is rare. But it shows how far the industry has moved from the days when open source was a hobby and the worst punishment was a bad review.

What the Name Actually Guarantees

The name on the SLA is a promise that a person, not a process, will be on call. It is a promise that the person has context, that they have seen the system misbehave before, and that they know which log file to check first. This is a different kind of guarantee than an uptime number. It is a guarantee of judgment.

Reputation is now a service-level metric. A maintainer's track record, their history of handling incidents, their willingness to admit when they are wrong. These are the things that buyers are paying for. They are not paying for the code, which is often free. They are paying for the knowledge that lives in a human head. The name is a proxy for that knowledge.

Accountability has a face again. When something goes wrong, the buyer can call the maintainer by name. They can ask questions that only the maintainer can answer. This is a return to an older model of software, where the person who wrote the code was the person you called. The SLA formalizes that relationship.

The name is also a proxy for context. A maintainer who has been with a project for years has a mental model that cannot be transferred in a handover document. They know the quirks, the workarounds, the reasons why the code is structured the way it is. That context is valuable, and the SLA is a way to buy it.

But the name does not guarantee immortality. It does not guarantee that the maintainer will never get tired, or that they will never move on. It is a snapshot of the present, a bet on the future. The contract is a way to align incentives, to make it worth the maintainer's while to stay. It is a hedge, not a certainty.

Practical Moves for Maintainers Now

If you are a maintainer, the first step is to put your name on the SLA. This is not just a marketing move. It is a commitment. It means you are willing to be held accountable, and that you are thinking about the service as a long-term responsibility. It may also increase your negotiating power, because the buyer is now paying for you, not just the code.

Document your own bus factor. Even if you are a solo maintainer, write down the things that only you know. Where is the deployment script? What is the magic number in the configuration? What do you do when the queue depth spikes? This documentation is not just for a successor. It is a way to clarify your own thinking, and it is a signal to buyers that you are not a single point of failure.

Price your continuity, not your code. When you negotiate a contract, think about what it costs to keep the service alive for a year. Include the time you spend on call, the time you spend on maintenance, and the time you spend training a successor. Do not undervalue the context in your head. It is worth more than any single line of code.

Build a handoff runbook early. You do not need to wait until you are leaving. A runbook that describes how to take over the service is useful even if you never use it. It forces you to think about the parts of the system that are implicit, and it gives the buyer confidence that the service will survive a change in personnel.

Negotiate for a funded successor. If the buyer wants your name on the contract, ask for a budget to train someone else. This could be a part-time hire, a contractor, or even a student. The point is to create a situation where the bus factor is not one. This is a reasonable request, because it reduces the risk for the buyer as well.

The shift to named maintainers is not a panacea. It introduces new risks, like the possibility that a maintainer's reputation becomes a liability, or that the contract becomes too personal. But it is a response to a real problem: the industry has been treating software as a machine, when it is actually a human activity. The name on the SLA is a reminder that someone is responsible, and that responsibility has a price.