Open-source maintainers used to be the people who fixed things when they felt like it, or when a particularly nasty bug finally got under their skin. That era is closing. Projects that anchor the modern software supply chain now run on-call rotations, complete with pagers, escalation paths, and compensation schedules. The bus factor, once a grim joke about how many maintainers could get hit by a bus before a project stalled, has become a formal line item on a salary schedule.

The shift is understandable. A critical dependency that breaks at 3 a.m. cannot wait for a volunteer to wake up in a good mood. Companies that build products on open source need guarantees, and guarantees require someone to be accountable at specific hours. So the informal goodwill economy of open source is slowly being replaced by something closer to a utility company's reliability engineering team.

But the transformation carries costs that few budgets account for. Paying for hours changes what the work means, both to the maintainer and to the community that once rallied around a shared mission. This article looks at how on-call rotations spread, the trap of tying passion to a timesheet, and what actually works when the schedule starts to beat the enthusiasm out of the people who keep the lights on.

The Bus Factor Was Always a Risk, Now It's a Schedule

Every maintainer knows the bus factor. It is the number of people whose sudden disappearance would bring a project to its knees. For many popular libraries, that number used to be one. A single developer held the keys to a package that thousands of companies depended on, and everyone crossed their fingers that nothing would happen to them.

On-call rotations are a direct answer to that risk. Instead of hoping the one maintainer is awake and willing, projects now assign a rotation of people who are paid to be available. The pager goes to whoever is on shift, not to whoever happens to be online. The bus factor stops being a hypothetical and becomes a staffing plan.

The formalization changes what maintenance means. Incident response replaces organic contribution. When a security vulnerability surfaces, the on-call engineer's job is to triage, patch, and communicate within a defined SLA, not to muse about design improvements. The rhythm of the work shifts from creative problem-solving to disciplined execution.

Burnout, once a quiet risk that volunteers could manage by stepping away, turns into budgeted overtime. Employers pay for the 2 a.m. pages and the weekend incidents, but they also expect the work to happen. The schedule becomes the contract, and the contract has teeth.

Why Rotations Spread in Open Source

The spread of on-call rotations in open source tracks the growing dependence of corporations on a handful of critical dependencies. A single logging library or JSON parser can sit in the dependency tree of half the internet. When something goes wrong, the blast radius is enormous, and the legal and reputational fallout lands on the companies that shipped the broken code.

Supply chain attacks have accelerated the trend. Malicious packages and compromised maintainer accounts have made 24/7 vigilance a requirement rather than a nice-to-have. A vulnerability disclosed on a Tuesday afternoon in one time zone needs a response before the next business day opens in another. A volunteer who checks email twice a day cannot provide that.

Individual maintainers also hit a hard ceiling. The maintainer of a popular library might spend evenings and weekends on reviews, issues, and releases, but there are only so many hours. When the project's health depends on a single person's stamina, the project is fragile. Rotations spread because they distribute the load, and distribution requires more than one person who cares.

Funding follows formal responsibility. Once a rotation exists, someone has to pay for the hours. Companies that depend on the project are natural sponsors, and many now fund maintainer positions directly. The money is welcome, but it comes with strings: the funder often wants a say in priorities, and the maintainer becomes an employee in all but name.

The Salary Schedule Trap

The salary schedule trap is the quiet danger of paying maintainers for on-call time. Pay ties attention to hours, and hours are a poor proxy for the kind of care that open source actually needs. A maintainer who is paid to be on call will show up, but the intrinsic motivation that drove them to build something beautiful in the first place does not survive contact with a timesheet.

On-call compensation changes the incentive structure in subtle ways. When the reward is tied to incidents handled, there is a temptation to game the metrics: close tickets quickly, escalate aggressively, write terse runbooks that only the author understands. The health of the project, the quality of the documentation, the patience with new contributors, all of those become secondary to the number of pages answered.

Volunteer passion becomes paid labor, and paid labor has a different texture. The maintainer who once stayed up late because they loved the project now watches the clock. The community that once felt like a family becomes a user base. The energy that attracted contributors in the first place dims, and the project starts to feel like a job.

Sustainability, measured in dollars and incident counts, misses the point. A project can be perfectly funded and still die of neglect if the people who maintain it have lost the will to care. The salary schedule keeps the lights on, but it does not keep the heart beating.

What Good Rotations Actually Look Like

Not all rotations are doomed to crush the joy out of maintenance. Some projects have found a model that works, and the pattern is surprisingly consistent. The first element is clear escalation paths with human backups. The on-call person is not the last line of defense; there is always someone more senior who can be pulled in, and that someone is explicitly named and available.

Limited shifts prevent fatigue. A week of on-call is common, and some projects cap it at five days. The rotation is long enough to develop context but short enough that the constant vigilance does not become a lifestyle. Time off after a heavy on-call week is not a perk; it is a rule.

Documented runbooks are the backbone of any good rotation. When a common incident occurs, the on-call person should not have to reverse-engineer the fix from memory. A runbook that walks through symptoms, likely causes, and tested resolutions turns a 3 a.m. panic into a checklist. The runbook is written by the person who solved the incident, and it is reviewed by the team.

Post-incident reviews are shared openly. The point is not to assign blame but to improve the system. What made this incident hard? What would have made it easier? The answers feed back into the runbooks and the architecture. The rotation becomes a learning loop, not just a duty roster.

Funding Models That Preserve Autonomy

The most contentious question in open source maintenance is who pays and what they get in return. Sponsor pools, where multiple companies contribute to a common fund, are one of the better answers. No single employer owns the maintainer's priorities, and the project can chart its own course.

Grants for focused maintenance sprints are another model. Instead of paying for endless on-call hours, a foundation or a consortium funds a month of dedicated work on a specific problem: upgrading a dependency, fixing a backlog of security issues, or rewriting a critical component. The work has a clear scope, and the maintainer returns to their normal rhythm afterward.

Crowdfunding covers the infrastructure costs that nobody thinks about: CI runners, hosting, code signing, and the occasional conference trip. A transparent budget, published on the project's site, builds community trust. People are more willing to chip in when they can see exactly where the money goes.

Co-op structures with shared governance are the most radical option. The maintainers own the project collectively, and decisions about funding and direction are made democratically. This model preserves autonomy better than any sponsor arrangement, but it requires a level of organizational maturity that many projects do not have.

When the Schedule Beats the Passion

There comes a point in every paid rotation where the schedule starts to beat the passion. The maintainer who joined because they loved the project begins to dread the pager. The incidents blur together, and the joy of solving a hard problem is replaced by the relief of getting through the shift.

Rotations can accelerate burnout precisely because they make the work relentless. A volunteer can step away for a month and come back refreshed. A paid on-call engineer cannot. The pressure to be available, combined with the knowledge that the project's health depends on their vigilance, creates a slow-burning stress that is hard to escape.

Turnover creates new bus factors. When the person who wrote the runbooks leaves, the knowledge walks out the door. The rotation is supposed to distribute knowledge, but in practice, the most experienced person still ends up holding the critical context. The bus factor just moves to a different seat.

Metrics gaming replaces real health. Projects that tie compensation to incident response times will see response times improve, but the underlying fragility may not. The schedule becomes the goal, and the actual health of the codebase, the community, and the maintainers gets ignored. The fix is not better metrics; it is better succession planning.

Practical Steps for Maintainers to Stay Sane

For maintainers who are considering or already running a rotation, a few practical steps can keep the schedule from destroying the project. Start with rotating shadowing. Before anyone is formally on call, have them shadow an experienced maintainer for a few weeks. They learn the runbooks, the common pitfalls, and the intuition that cannot be written down.

Automate incident detection early. The fewer pages that are the result of false alarms or alert fatigue, the more the on-call person can focus on real problems. A well-tuned alerting system is worth more than a larger rotation.

Set explicit on-call boundaries. The pager does not have to ring for every issue. Define what counts as an incident, and what can wait until morning. The maintainer's sleep is a resource, and it should be protected.

Share ownership via written docs. The runbooks, the architecture notes, the decision logs, all of it needs to live somewhere that is not in someone's head. The goal is that any member of the rotation can handle any incident, and that requires the knowledge to be externalized.

Revisit the rotation design quarterly. What worked in the winter may not work in the summer. The rotation should be a living system, adjusted based on incident data, feedback, and the changing shape of the project. The bus factor will never be zero, but a well-run rotation can make it small enough to stop being a source of dread.

The Human Cost of Always-On Availability

Beyond the obvious burnout, the always-on nature of on-call rotations exacts a subtler toll on maintainers' personal lives. The pager's buzz at 2 a.m. does not just interrupt sleep; it interrupts family dinners, weekend hikes, and the quiet moments that make life worth living. Maintainers report feeling a low-grade anxiety that persists even when they are not on call, a lingering anticipation of the next alert. This hypervigilance is the same psychological state that emergency responders experience, and it has measurable effects on health and well-being.

Studies of on-call workers in other industries show that the mere possibility of being called increases stress levels, even if the call never comes. The brain does not fully disengage from work when it knows it might have to re-engage at any moment. For maintainers, this means that even their off weeks are tinged with a background hum of responsibility. The rotation might be one week on, three weeks off, but the mental load does not follow that schedule.

Some projects have tried to mitigate this by rotating time zones, so that the on-call person is always in daylight hours. But this only works for projects with a global contributor base, and it introduces its own coordination overhead. Others have experimented with follow-the-sun models, where the pager is handed off to a colleague in a different time zone at the end of the business day. These models reduce the 3 a.m. pages but do not eliminate them, and they require a level of organizational maturity that many projects lack.

The human cost is not just psychological; it is also financial. On-call compensation, when it exists, is often a fixed stipend rather than an hourly rate. A maintainer who gets three calls in a night earns the same as one who gets none. This is fair in the sense that it does not incentivize incidents, but it also means that the person who bears the brunt of a bad week is not compensated for the actual disruption. The stipend is a token, not a wage.

Alternative Models: Beyond the Rotation

While rotations are the dominant model, they are not the only way to handle the bus factor. Some projects have moved to a model of proactive maintenance, where instead of waiting for incidents, they invest heavily in automated testing, fuzzing, and continuous integration. The goal is to catch problems before they become incidents, reducing the need for on-call response. This approach shifts the work from reactive to proactive, and it can be more sustainable because it does not require constant vigilance.

Other projects have adopted a model of community-based support, where the on-call duty is shared among a wider group of volunteers, but the compensation is not tied to individual hours. Instead, the project pays for a dedicated support person who triages issues and coordinates responses, but the actual fixes come from the community. This distributes the load without creating a salary schedule, preserving the volunteer spirit while still providing accountability.

There is also the option of insurance-style models, where companies that depend on the project pay into a fund that covers the cost of a professional incident response team. This team is not composed of maintainers but of hired engineers who are experts in the project's codebase. They handle the 3 a.m. pages, and the maintainers are free to focus on feature development and community building. This model is expensive, but it is the most effective way to protect the maintainers' passion while still providing the guarantees that companies need.

Finally, some projects have simply decided that the bus factor is acceptable. They document the risks, they encourage forking, and they accept that the project might die if the maintainer leaves. This is a radical act of honesty, and it can be more sustainable than a poorly run rotation. The project's users know what they are getting into, and they can plan accordingly. The maintainer is free to leave without guilt, and the project's death is not a failure but a natural end.

Conclusion: The Future of Maintenance

The shift from volunteer goodwill to paid on-call rotations is not a betrayal of open source ideals; it is an evolution. The projects that survive will be the ones that find a balance between the reliability that companies demand and the passion that drives maintainers. The bus factor will never be zero, but a well-designed rotation, funded by a diverse set of sponsors, and run with a focus on human health, can make it small enough to stop being a source of dread.

The key is to remember that the schedule is a tool, not a master. The rotation exists to serve the project and its maintainers, not the other way around. When the schedule starts to beat the passion, it is time to redesign the rotation, not to push the maintainer harder. The future of open source depends on the people who maintain it, and their well-being must be the first priority.

For maintainers, the advice is simple: do not let the pager define your life. Set boundaries, automate what you can, and remember why you started. The code will always be there, but the joy of building it is fragile. Protect it, and the project will thrive. The bus factor is a risk, but it is not an inevitability. With the right structure, the right funding, and the right mindset, open source can be both reliable and sustainable.