pythonsurvival-analysisabandonmentresearchcontributor-diversity

Ali et al. — Python Project Survival, MSR

Provides a mathematically validated model for 'Software Survivability' and confirms that contributor diversity is the single strongest predictor of project longevity.

Summary

A statistical survival analysis of 3,052 popular Python projects over a 14-year period found that projects with diverse developer networks (at least 20 unique committers) are 6 times less likely to become inactive. Maintaining a consistent timeline of major releases makes a project 3 times more likely to survive compared to projects with only minor commits. While 28.8% of projects relied on a single developer, those that distributed code across multiple repositories (GitHub, PyPI, Debian) showed an 80% survival probability after 165 months, versus less than 20% for single-repository projects. This research demonstrates that contributor diversity and distribution breadth are the most reliable leading indicators of long-term project health and continuity.

Related Checks

SOURCE_SINGLE_CONTRIBUTOR

The study finds that projects with fewer than 20 unique developers are 5.95 times more likely to become abandoned or inactive.

Adverse Outcome

dependency on a project that lacks the 'Bus Factor' necessary to survive the departure of its core maintainers

Because

contributor diversity is a mathematically proven leading indicator of project longevity, with a 6x impact on survival probability.

PACKAGE_STALE_RELEASE

Projects that publish major releases are 3 times more likely to remain active over a 14-year period compared to those that only publish minor commits.

Adverse Outcome

inclusion of projects that have lost their development momentum and will likely stop receiving security updates

Because

periodic major releases serve as 'milestones' that indicate a healthy, forward-moving development lifecycle and sustained maintainer commitment.

Gaps Analysis

Evidence

Projects with repositories on multiple hosting services... multiplerepositories whether the project is hosted on multiple version control systems.

Blind Spot

Risk Guard evaluates the primary source repo but doesn't explicitly track the project's 'Distribution Breadth' across multiple registries.

Actionable Capability

Risk Guard would be better if it checked for 'Ecosystem Multi-homing' (presence on GitHub, PyPI, Debian, etc.) as a proxy for project seriousness and resilience.

← Previous Next →