Bus Factor 1: The Metric Your Dependency Review Is Missing

Stars, forks, and last-commit-date. These are the three numbers most developers check before adopting a dependency. None of them answer the question that actually matters: what happens if one person stops contributing?

Bus factor — the number of contributors who account for 50% or more of recent work — is the single strongest predictor of project fragility. A project with 10,000 stars and a bus factor of 1 is one resignation, one burnout, one job change away from becoming unmaintained.

This is not hypothetical. It is the pattern behind most of the open source failures that make the news.

The metric nobody checks

When engineering teams evaluate a new dependency, the review process typically looks like this: check the star count (social proof), check the last commit date (is it alive?), maybe glance at the issue tracker (is anyone responding?). Some teams go further and check the license, the test coverage, or the SBOM.

Almost nobody checks how many people are actually doing the work.

The problem is that GitHub’s default metrics create a misleading picture. A repository can show 200 contributors in its history while only 1 of them has committed anything in the last 90 days. The contributor list is a cumulative count. It tells you who has ever touched the project, not who is keeping it alive right now.

Bus factor corrects this by measuring concentration of recent work. The computation is straightforward: rank contributors by their share of recent activity, then count how many you need before you cross 50% of total contributions. If the answer is 1, your dependency has a single point of failure.

How DevPulse computes bus factor

DevPulse computes bus factor from actual contribution events — pull requests, reviews, issues, and comments — over a configurable time window (default: 90 days). The query ranks each contributor by event count, computes a running cumulative sum, and returns the number of contributors whose cumulative total first exceeds 50% of all activity.

This is not an approximation or a heuristic. It is a direct measurement: how many people would need to leave before more than half the project’s recent work output disappears?

DevPulse also computes a parallel metric called pony factor, which applies the same 50% threshold at the organization level. A bus factor of 3 sounds reasonable until you realize all three contributors work at the same company. If that company deprioritizes the project, the effect is the same as losing one person.

Both numbers appear on the Health tab alongside an overall health grade that combines them with demand, throughput, and responsiveness scores.

What bus factor 1 actually looks like

A project transitioning from healthy to fragile rarely announces itself. The pattern is slow and the symptoms are easy to miss if you are not watching the right metrics. Here is what to look for:

Contributor retention drops first. Before a project becomes a one-person show, it loses its returning contributors. DevPulse tracks new versus returning contributors over time. A healthy project converts newcomers into repeat contributors. When returning contributor count trends downward while new contributor count stays flat, the community is not retaining people.

Time to first response climbs. When fewer people are doing the work, incoming issues and PRs wait longer for attention. DevPulse measures the hours until a PR gets its first review and until an issue gets its first comment. This is the most direct signal for contributor experience — slow responses drive external contributors away, which accelerates the retention problem.

PR review ratio deteriorates. Healthy projects maintain a review culture where PRs get reviewed before merge. When the reviewer pool shrinks, either PRs go unreviewed or the remaining maintainer becomes the bottleneck. DevPulse tracks reviews per PR over time. A declining ratio often precedes the bus factor dropping to 1.

Lead time inflates. Days from PR creation to merge stretch out. External contributors submit work, wait, and eventually stop contributing. DevPulse’s velocity charts show this clearly: lead time and first-response time trend upward together.

The pattern reinforces itself. Fewer maintainers leads to slower responses, which leads to fewer contributors, which leads to fewer maintainers. By the time bus factor hits 1, the project has usually been in decline for months.

Stars hide fragility

It is tempting to treat star count as a health indicator. It is not. Stars are a measure of historical interest, not current maintenance capacity.

Consider the dynamics: a project gets popular, accumulates stars over years, and becomes a transitive dependency for thousands of other projects. The original maintainer gets a new job, starts a family, or simply burns out. Stars keep accumulating because people keep discovering the project through blog posts, tutorials, and Stack Overflow answers that were written when the project was actively maintained.

The star count says 15,000. The bus factor says 1. The last response to an external PR was 4 months ago. The project is technically alive (there was a commit last month) but functionally unmaintained for anyone outside the single remaining contributor.

Forks tell a similar misleading story. A rising fork count without rising PRs often means people are forking to work around issues they cannot get addressed upstream. DevPulse tracks forks alongside activity events specifically to surface this divergence.

The xz-utils connection

The xz-utils incident (CVE-2024-3094) is primarily discussed as a social engineering attack, and it was. But the precondition for the attack was a project health problem: a critical compression library, depended on by most Linux distributions, maintained by a single burned-out developer.

The attacker did not need to compromise a large team. They needed to earn the trust of one overwhelmed person. The bus factor was already 1 before the attack began. The social engineering succeeded in part because the maintainer needed help and someone showed up offering it.

This is where project-level health metrics and contributor-level trust scoring are complementary. DevPulse would have shown the fragility: bus factor 1, no meaningful contributor retention, a single-person bottleneck. DevTrace would have provided the per-contributor analysis of the new person stepping in. Neither tool alone tells the full story. Together, they surface the combination of conditions that makes a project vulnerable.

How to use bus factor in dependency decisions

Bus factor is most useful as a triage metric — a fast way to separate dependencies that need deeper investigation from those that are reasonably healthy.

Before adopting a dependency:

Open the project on DevPulse and check the Health tab. Bus factor and pony factor tell you the concentration risk. But do not stop there. Check contributor retention (are people sticking around?), time to first response (are external contributors getting attention?), and PR review ratio (is there a review culture?). A bus factor of 3 with strong retention and fast response times is a healthy project. A bus factor of 3 where all three contributors are from the same org and retention is declining is a project heading toward fragility.

For dependencies you already use:

DevPulse tracks metrics over time, so you can watch for trends. Set up your portfolio to include your critical dependencies and check the Health Scorecard periodically. The scorecard grades three categories — Demand (community interest and growth), Throughput (how efficiently work moves), and Responsiveness (how quickly the team reacts) — each on an A through F scale. A project whose responsiveness grade drops from B to D over two quarters is telling you something, even if the star count keeps climbing.

At the organizational level:

For OSPO leads and engineering managers, the portfolio view shows bus factor across all tracked repositories in one table. Sort by bus factor to identify which dependencies carry the most key-person risk. Cross-reference with your dependency graph to understand blast radius: a bus-factor-1 library that appears in 3 services is a different risk than one that appears in 300.

What the metric is not

Bus factor measures concentration of recent work. It does not measure code quality, security posture, or whether the project’s architecture is sound. A project with a bus factor of 5 can still have unreviewed PRs, no test suite, and known vulnerabilities.

Bus factor also does not account for contribution quality. A maintainer who reviews every PR and triages every issue contributes more to project health than someone who commits frequently but only touches CI configuration. DevPulse weights all event types equally in the bus factor computation because distinguishing “important” from “routine” contributions requires judgment that a metric cannot automate.

Treat bus factor as one input to your risk assessment, not the assessment itself. It answers a specific question — how concentrated is the work? — and that question matters more than most teams realize. But it is not the only question.

Check your dependencies

DevPulse is free to use. Track any public GitHub repository at devpulse.thingz.io and see bus factor, pony factor, contributor retention, velocity, and 30 other metrics across the Health, Activity, Velocity, Quality, and Community dashboards.

If you are also evaluating the contributors behind the bus factor number — DevTrace scores individual contributors across 23 signals covering identity, engagement, community standing, and behavioral patterns. The two tools are complementary: DevPulse tells you the project has a bus factor of 1, DevTrace helps you evaluate the one person it depends on.