The security patch lands on a Tuesday. The maintainer is still awake on Thursday, fielding embargoed disclosure calls, rewriting the advisory, and answering downstream vendors who want a private walkthrough. The contract paid for the commit. It did not pay for the pager. That gap sits at the center of how open-source security is funded, and it pushes the most expensive hours onto the least funded party.

The Fix Ships, the Hours Do Not

A patch is a deliverable. The hours that produced it are not. Most maintainer agreements, whether sponsorship tiers or corporate contracts, are written around artifacts: pull requests merged, releases tagged, issues closed. The 2 a.m. triage that precedes the commit does not appear in any statement of work. It is absorbed by the individual who happens to hold the commit bit.

Reviewers bill hourly for code review. Incident responders bill hourly for containment. The maintainer who coordinates a disclosure across four downstream projects bills nobody. That work is real, and it is often the difference between a quiet patch and a public exploit. The market prices the commit because the commit is visible. The pager is invisible until it rings.

Consider a critical parser with a single active maintainer. The bus factor is one. When a malformed input triggers a memory-safety bug, that maintainer becomes the incident commander for a component used by thousands of products. No contract clause anticipates that role. The work arrives unannounced, unpaid, and outside the release calendar.

The asymmetry shows up in how fast each phase moves. Writing the fix is often a day of focused work. The disclosure window that follows typically runs for weeks, sometimes longer when downstream vendors need coordinated release dates. During that window the maintainer is on call in a low-grade way: monitoring a private channel, answering questions under embargo, keeping a draft advisory current as details shift. None of that registers as a commit, and none of it fits a sponsorship tier built around merged pull requests.

What the Money Actually Buys

Sponsorship tiers fund features, documentation, and the occasional audit. They rarely fund on-call. A company that sponsors a project at a few thousand dollars a month is buying visibility and goodwill, not a guaranteed response window. Grants cover security audits and tooling improvements. They do not cover the 2 a.m. call when a researcher reports a bypass in the authentication flow.

A security.txt file routes vulnerability reports to an inbox. Often that inbox belongs to one exhausted person. The standard is a useful convention, but it does not create a staffed rotation. It creates a documented address for reports that still land on the same desk. The tooling around disclosure has improved; the staffing behind it has not kept pace.

The Open Source Security Foundation runs working groups on tooling, metrics, and best practices. Those efforts matter. They do not pay stipends for on-call hours. The gap between tooling and stipends is structural: funders prefer to buy artifacts they can point to, and availability is hard to point to until it fails. This site has covered how foundations fund compliance work from trademark royalties, which illustrates the same pattern of matching money to visible outputs.

There is a second-order effect worth naming. When sponsorship pays for features, maintainers rationally spend their limited hours on features. Security work that produces no visible artifact competes for the same hours and loses. A maintainer who wants to spend a week hardening input validation is choosing that week over the roadmap items their sponsors actually funded. The incentive is not malicious; it is arithmetic. Funders get the behavior they pay for, and the current payment structure quietly deprioritizes the unglamorous defensive work that prevents the next incident.

Contracts Written Around Deliverables

A typical statement of work lists pull requests, release cadence, and issue triage. It may include a security review. It almost never includes an availability clause. There is no line item for embargoed disclosure calls, no retainer for weekend response, and no defined escalation path when the primary maintainer is unreachable.

Indemnity usually sits with the individual, not the foundation. If a vulnerability causes downstream harm, the maintainer who merged the fix may face questions they have no contractual cover to answer. Foundations hold trademarks and steward projects; they do not typically employ maintainers. That legal distance is efficient until an incident tests it.

Renewal cycles assume steady-state maintenance. They budget for a year of predictable work and price it accordingly. A security incident is not steady state. It compresses weeks of coordination into days and pulls in legal, communications, and downstream vendors. Contracts that assume calm weather leave the maintainer exposed when the weather turns.

Procurement teams add a further wrinkle. A large buyer often cannot sign a contract with an individual maintainer at all; the paperwork needs a legal entity with insurance and a bank account. That pushes money toward foundations and vendors, which is reasonable for accounting but awkward for the solo maintainer who is the actual point of contact for a critical dependency. The result is a funding path that routes around the person doing the work, or requires that person to incorporate before anyone can pay them for availability.

The Bus Factor as a Balance Sheet Item

Single-maintainer projects carry hidden concentration risk. Downstream vendors rarely map their dependency graph to the level of a named person. They know they depend on a package. They do not know that the package depends on one individual who is currently on holiday. The risk is real and it is unaccounted for on most balance sheets.

Handover documentation is cheap to produce. Handover time is not. Writing down how to cut a release takes an afternoon. Training a secondary responder to handle an embargoed disclosure takes weeks of shadowing. That time has a cost, and it is usually the first thing cut when a project is underfunded. The result is a documented process that no second person has ever executed.

The failure mode is subtle. A runbook that has never been run is a guess. The person who wrote it knows the steps; the person who inherits it does not know which steps are load-bearing and which are vestigial. When the primary maintainer is unreachable during a real incident, the secondary responder discovers the gaps in real time, under time pressure, with downstream vendors waiting. That is the worst possible moment to learn that a build step depends on a credential only one person holds.

Insurance products exist for outages and cyber incidents. They do not insure the maintainer's availability. A company can buy coverage for downtime caused by a vulnerability, but it cannot buy a guarantee that the person who understands the parser will be reachable this weekend. The market has priced the outage, not the on-call.

Who Bears the On-Call Cost

Foundations hold trademarks and steward projects. They do not typically hold employment contracts for maintainers. Corporate consumers contribute code more often than cash, and code contributions do not pay for the pager. The market structure pushes the on-call cost to the least funded party: the individual with the commit bit.

That individual absorbs disclosure coordination unpaid. They negotiate embargo dates with researchers, brief downstream vendors, and draft advisories. The work is skilled and it is time-bound. It is also invisible to a sponsorship dashboard that tracks merged pull requests. The mismatch between what is measured and what is needed is the core economic problem.

There is a distributional question underneath. The projects most likely to need on-call coverage are the ones embedded deepest in dependency graphs, and those are often the ones maintained by a single person with the least negotiating leverage. A widely used library can sit in thousands of products while its maintainer has no formal relationship with any of the companies shipping it. The leverage to demand a retainer exists in theory. In practice it requires knowing which downstream vendors depend on you, and most maintainers have never been told.

A related piece on maintainer burnout and green tooling metrics makes a similar point from the human side. The metrics look healthy because they count commits and closures. They do not count the nights spent on a disclosure call. Until the metrics change, the funding will follow the wrong signals.

Practical Steps for Buyers and Maintainers

Buyers can add an on-call retainer line to sponsorship agreements. A retainer pays for availability, not for a specific commit. It sets an expectation that someone will respond within a defined window. Even a modest retainer changes the economics for a solo maintainer deciding whether to answer a 2 a.m. report.

Maintainers can name a secondary responder in the security.txt file. That single line creates accountability and gives researchers a fallback. It also forces the project to identify who that person is before an incident, which is the first step toward reducing the bus factor.

• Budget explicitly for disclosure coordination hours in the next contract renewal.
• Track bus factor per critical dependency every quarter, not once a year.
• Document handover steps before the next major release, and have a second person execute them.
• Add an on-call retainer to at least one sponsorship agreement this cycle.

None of these steps is expensive relative to the cost of an uncoordinated disclosure. The objection is that retainers pay for something that may never happen. That is true of every insurance policy. The difference is that here the premium goes directly to the person who will answer the call.