Bus Number – The GitHub plugin my coworkers asked me not to write

Bus factor concept & measurement

• Bus factor discussed as “how badly a project suffers if key people vanish,” with two formulations: number of critical people per file/system vs. number that must disappear before the project halts.
• Original paper’s method: a system is at serious risk if current authors collectively cover <50% of current files; “author” means someone with significant weighted contributions.
• Some argue the ideal is effectively zero unique-knowledge holders per area (everyone can cover everything); others say frontier/complex projects will inevitably have a bus factor of 1 in some domains.

Existing tools and real‑world use

• Multiple tools/products already track “knowledge distribution” or “knowledge islands” (e.g., for hotspots, single‑maintainer areas, handover planning).
• Large enterprises reportedly have internal dashboards for bus factor and related metrics.
• CPAN shows bus factor per project, with documented methodology.
• Some teams rejected similar tools (e.g., Pluralsight Flow) after seeing them misused for performance reviews.

Value vs. misuse and Goodhart’s Law

• Proponents: useful for spotting silos, planning handovers, enabling rotation, and protecting engineers from being trapped as “irreplaceable.”
• Critics: metrics quickly get gamed, become hiring/layoff inputs, or are used to dehumanize staff and enforce fungibility; Goodhart’s Law is a central concern.
• Some warn such tools could be weaponized externally (e.g., creating “hit lists” of critical OSS maintainers).

Fungibility, careers, and culture

• One view: high fungibility is healthy—knowledge hoarding is toxic, and “you can’t be promoted if you can’t be replaced.”
• Opposing view: strict fungibility wastes talent, adds process overhead, and may be rationally resisted by employees who don’t primarily optimize for company profit.
• Experiences shared where people were denied transfers due to being “unbackfillable,” then left; others note some orgs reward “critical” people highly.

Documentation, code review, and team practices

• Suggestions: organized documentation, runbooks, banning manual one‑person processes, and broad code review to reduce bus factor.
• Debate over whether code review is primarily compliance overhead or a key mechanism for knowledge sharing and catching issues beyond tests/linters.
• Some emphasize that good engineers intentionally lower their personal bus factor; value is in future potential, not past unique knowledge.

Startups vs. mature orgs

• Tension between “document everything” and early‑stage velocity.
• Some argue under‑documentation and extreme tech debt kill flexibility; others note that heavyweight process from big‑company culture can also sink startups.

Terminology: “bus” vs. “lottery” factor

• Several object to the morbid “bus” framing, preferring “lottery factor” or “attrition risk.”
• Others argue “bus factor” more accurately reflects real sudden losses (death, injury, legal/visa issues) vs. gradual exits like lottery wins.

Technical tangent: parallelism in git cloning

• Side discussion on gnu parallel plus git clone over‑saturating CPUs due to nested parallelism (index-pack threads).
• Proposed fixes: limit pack.threads, pass per‑command config, or use a shared job server/global scheduler so only one layer parallelizes.