预计阅读时间：12 分钟
现代软件几乎都站在开源项目的肩膀上，但那些被数万应用依赖的包，未必都还活着。Andrew Nesbitt 的研究揭示了一个令人不安的现实：大量高度依赖的开源软件包已经"死了"，而它们走向死亡的方式，远不止一种。
维护者消失了
最常见也最直白的情况——项目最后一次人工提交停留在几年前，issue 堆积如山却无人回应。维护者可能换了工作、失去了兴趣，或者干脆离开了这个行业，但项目在 npm、PyPI 上的包还在，还在被每天数百万次地下载。
这类项目被称为"幽灵维护者"（Ghost Maintainer）状态：仓库看起来还在，README 还在，CI 还在跑（如果没过期），但没有任何活人在这背后做决策。
只剩一个人撑着
比幽灵维护者更危险的是"单点维护者"。项目看起来还在更新，但所有提交、所有 issue 回复、所有 release 都来自同一个人。这个人一旦生病、离职或单纯不想干了，项目立刻进入死亡状态。
这种情况在中小型基础设施包里极为常见。你可能每天用的某个解析库、某个 CLI 工具，背后就只有一个人。
被依赖但无人付费
很多项目下载量惊人，但维护者没有收到任何赞助。维护成本（处理 issue、修复安全漏洞、适配新版本）持续存在，收入却为零。这不是突然死亡，而是慢性衰竭——维护者逐渐减少投入，响应时间从一天变成一周变成一个月，最终项目滑入幽灵状态。
内部冲突导致停滞
维护者之间出现分歧——方向之争、代码风格之争、甚至纯粹的人际冲突。PR 长期悬而未决，release 被无限推迟，项目名义上"活跃"但实质上已经冻结。外部贡献者看到这种氛围，也会选择远离。
被更活跃的替代者"自然淘汰"
有时候项目没有做错什么，只是出现了更好的替代。用户逐渐迁移，issue 变少不是因为都解决了，而是因为用户走了。维护者看到参与度下降，也慢慢失去动力，形成双向退出的恶性循环。
实战：用脚本扫描你依赖中的"僵尸"
知道项目会死，不如主动检查自己的依赖是否已经出现死亡迹象。下面这个 Python 脚本可以批量扫描 GitHub 仓库的健康指标——最后提交时间、issue 响应速度、贡献者数量，帮你提前识别风险。
"""
dep_health_check.py — 扫描 GitHub 仓库的开源健康指标
使用前需设置环境变量 GITHUB_TOKEN（个人访问令牌）
依赖：pip install requests
"""
import os
import sys
import json
from datetime import datetime, timezone
from collections import defaultdict
import requests
GITHUB_API = "https://api.github.com"
TOKEN = os.environ.get("GITHUB_TOKEN", "")
HEADERS = {
"Accept": "application/vnd.github.v3+json",
"Authorization": f"token {TOKEN}" if TOKEN else "",
}
# 健康阈值（可根据团队标准调整）
THRESHOLDS = {
"last_commit_days": 365, # 超过一年无提交 → 警告
"open_issues_ratio": 0.5, # 未关闭 issue 占比超过 50% → 警告
"contributor_count": 3, # 活跃贡献者少于 3 人 → 警告
"stale_issue_days": 90, # issue 超过 90 天未回复 → 警告
}
def api_get(path: str) -> dict | None:
"""调用 GitHub API，返回 JSON 或 None"""
url = f"{GITHUB_API}/{path}"
resp = requests.get(url, headers=HEADERS, timeout=15)
if resp.status_code != 200:
print(f" [WARN] API 请求失败: {url} → {resp.status_code}")
return None
return resp.json()
def check_repo(owner_repo: str) -> dict:
"""
对单个 repo 做健康检查，返回指标字典。
owner_repo 格式: "owner/repo"，如 "pallets/flask"
"""
result = {"repo": owner_repo, "warnings": []}
# 1) 仓库基本信息
repo_data = api_get(f"repos/{owner_repo}")
if not repo_data:
result["warnings"].append("无法获取仓库信息")
return result
# 最后提交时间
last_push = repo_data.get("pushed_at")
if last_push:
last_dt = datetime.fromisoformat(last_push.replace("Z", "+00:00"))
days_since = (datetime.now(timezone.utc) - last_dt).days
result["last_commit_days"] = days_since
if days_since > THRESHOLDS["last_commit_days"]:
result["warnings"].append(
f"最后提交距今 {days_since} 天（阈值 {THRESHOLDS['last_commit_days']}）"
)
# issue 统计
open_issues = repo_data.get("open_issues_count", 0)
# GitHub API 的 open_issues_count 包含 PR，需单独取 issue
# 简化处理：用搜索 API 获取纯 issue 数
issues_data = api_get(
f"search/issues?q=repo:{owner_repo}+type:issue+state:closed&per_page=1"
)
closed_issues = issues_data.get("total_count", 0) if issues_data else 0
total_issues = open_issues + closed_issues
ratio = open_issues / max(total_issues, 1)
result["open_issues_ratio"] = round(ratio, 2)
result["open_issues"] = open_issues
result["closed_issues"] = closed_issues
if ratio > THRESHOLDS["open_issues_ratio"]:
result["warnings"].append(
f"未关闭 issue 比例 {ratio:.0%}（阈值 {THRESHOLDS['open_issues_ratio']:.0%}）"
)
# 2) 贡献者数量
contrib_data = api_get(f"repos/{owner_repo}/contributors?per_page=100")
if contrib_data and isinstance(contrib_data, list):
active_contribs = [c for c in contrib_data if c.get("contributions", 0) > 1]
result["active_contributors"] = len(active_contribs)
if len(active_contribs) < THRESHOLDS["contributor_count"]:
result["warnings"].append(
f"活跃贡献者仅 {len(active_contribs)} 人（阈值 {THRESHOLDS['contributor_count']}）"
)
else:
result["warnings"].append("无法获取贡献者数据")
# 3) 最近 issue 的响应时间（取最近 5 个 open issue）
recent_issues = api_get(
f"repos/{owner_repo}/issues?state=open&sort=created&direction=desc&per_page=5"
)
if recent_issues and isinstance(recent_issues, list):
stale_count = 0
for iss in recent_issues:
created = datetime.fromisoformat(
iss["created_at"].replace("Z", "+00:00")
)
days_open = (datetime.now(timezone.utc) - created).days
if days_open > THRESHOLDS["stale_issue_days"]:
stale_count += 1
result["stale_open_issues"] = stale_count
if stale_count > 0:
result["warnings"].append(
f"最近 5 个 open issue 中有 {stale_count} 个超过 "
f"{THRESHOLDS['stale_issue_days']} 天未关闭"
)
return result
def main():
# 从命令行参数或文件读取 repo 列表
if len(sys.argv) > 1:
repos = sys.argv[1:]
else:
# 默认扫描几个常见基础设施包作为演示
repos = [
"pallets/flask",
"psf/requests",
"numpy/numpy",
"urllib3/urllib3",
"certifi/certifi-python",
]
print("未指定仓库，使用默认演示列表。用法: python dep_health_check.py owner/repo ...")
print("=" * 60)
print("开源依赖健康检查报告")
print("=" * 60)
for repo in repos:
print(f"\n🔍 检查 {repo} ...")
report = check_repo(repo.strip())
print(f" 最后提交: {report.get('last_commit_days', '?')} 天前")
print(f" open/closed issue: {report.get('open_issues', '?')}/{report.get('closed_issues', '?')}")
print(f" 未关闭比例: {report.get('open_issues_ratio', '?')}")
print(f" 活跃贡献者: {report.get('active_contributors', '?')}")
if report["warnings"]:
print(" ⚠️ 警告:")
for w in report["warnings"]:
print(f" - {w}")
else:
print(" ✅ 暂无明显风险指标")
print("\n" + "=" * 60)
print("提示：阈值可在 THRESHOLDS 中调整；建议结合人工判断做最终决策。")
if __name__ == "__main__":
main()
运行方式：
# 安装依赖
pip install requests
# 设置 GitHub Token（提高 API 限额，可选但推荐）
export GITHUB_TOKEN="ghp_你的令牌"
# 扫描指定仓库
python dep_health_check.py pallets/flask urllib3/urllib3
# 不传参数则使用内置演示列表
python dep_health_check.py
输出示例：
============================================================
开源依赖健康检查报告
============================================================
🔍 检查 pallets/flask ...
最后提交: 42 天前
open/closed issue: 23/820
未关闭比例: 0.03
活跃贡献者: 8
✅ 暂无明显风险指标
🔍 检查 urllib3/urllib3 ...
最后提交: 15 天前
open/closed issue: 47/310
未关闭比例: 0.15
活跃贡献者: 4
✅ 暂无明显风险指标
这个脚本只覆盖了基础指标。更完整的健康检查还可以加入：安全漏洞历史（通过 OSV 或 Snyk API）、release 频率趋势、CI 是否还在运行、是否有 OpenSSF 最佳实践徽章等。
依赖风险管理清单
识别出风险依赖后，该怎么做？以下是一份实用的决策清单：
| 信号 | 严重程度 | 建议动作 |
|---|---|---|
| 最后提交 > 1 年 | 高 | 评估替代方案，准备迁移路径 |
| 活跃贡献者 ≤ 1 | 高 | 不再新增对该包的依赖，锁定版本 |
| 未关闭 issue 比例 > 50% | 中 | 检查是否有你关心的未修复 bug |
| issue 长期无回应 | 中 | 自己 fork 维护，或提交 PR 前先确认维护者是否还在 |
| 有活跃替代项目 | 低~高 | 视迁移成本决定是否切换 |
| 维护者明确宣布停止维护 | 高 | 立即制定迁移计划 |
几个实操建议：
- 锁定版本：对高风险依赖，在
requirements.txt/package.json中锁定精确版本号，避免意外拉到有问题的更新。 - fork 并自维护：如果依赖小且简单，fork 到自己组织下是成本最低的保险。改一行代码比换一个包容易得多。
- 参与资助：对关键依赖，通过 Open Collective、GitHub Sponsors 等渠道给维护者打钱。几十美元的月度赞助可能就是项目继续存活的关键。
- 加入维护：如果你有精力，成为贡献者甚至 co-maintainer。单点维护者最需要的往往不是钱，而是有人一起分担。
开源项目不会突然死亡，它们是慢慢枯萎的。而你的应用依赖它们活着——提前看一眼那些依赖的健康状态，比事后救火划算得多。