开源项目健康度度量

引言

「这个库还活着吗？」这是技术选型评审里最常被问、也最难回答的问题。凭印象回答的代价很实在：选了一个两年没发版的依赖，一年后发现它绑死了旧版运行时，迁移成本远超当初自研；或者反过来，因为某个库「star 少」而错过了一个维护得非常好的项目。健康度度量的目标就是把这个判断从直觉变成可复现的证据。

真正的难点不在「算不出数字」，而在「数字算出来之后怎么解读」。GitHub 上几乎所有指标都可以被低成本操纵：批量合并小 commit 能刷贡献者数，自动关闭 stale issue 能刷关闭率，机器人提交能刷提交频次。更隐蔽的问题是代理指标漂移——你想度量的是「项目能否持续得到维护」，但实际度量的是「过去 90 天的活动量」，而一个成熟的稳定库本来就应该活动量低。

本文按「目标与陷阱 → 贡献者 → 时效 → 发布 → 积压 → 依赖与供应链 → 采集工具 → 评分卡 → 反模式」的顺序展开。每个维度都给出 CHAOSS 口径的公式、可直接跑的 gh api 命令和一组阈值参考，最后落到一张可以贴进选型文档的加权评分卡。读者对象是需要为依赖做技术决策的工程师与架构师，前提是你已经知道 Git 基本操作，不需要事先了解 CHAOSS。

需要提前说明一条边界：本文关注的是治理与流程层面的度量，供应链安全扫描工具的用法（SBOM 生成、漏洞库比对、SCA 集成）不在重心，只在「依赖广度」一节里作为风险因子提及。度量与流程的关系，可以类比持续交付里的做法——先定义好指标，再让流程去逼近它，而不是先有流程再补指标。

目录

1. 健康度度量的目标与陷阱
2. 贡献者维度指标
3. 响应与合并时效
4. 发布与版本节奏
5. 积压与关闭率
6. 依赖广度与供应链风险
7. 指标采集工具与命令
8. 选型评分卡
9. 指标滥用与反模式

1. 健康度度量的目标与陷阱

度量前先明确消费方，因为不同消费方要的指标不同。选型者关心的是「未来 12~24 个月这个依赖会不会拖累我」，需要的是风险信号：bus factor、下游广度、发布节奏、维护者是否有雇主支持。维护者关心的是「我的项目哪里在漏水」，需要的是流程信号：首次响应时长、新贡献者流失点、积压增长率。基金会或雇主关心的是「这笔投入的产出」，需要的是生态信号：采用率、衍生项目、标准影响力。用选型指标去考核维护者，是最常见的错配。

Goodhart 定律在这里是最硬的一条约束：当一个度量成为目标，它就不再是好的度量。具体到开源场景，表现为三类陷阱。第一类是直接刷指标：为了让「贡献者数」好看而把大 PR 拆成几十个小 PR 由不同账号提交；为了让「关闭率」好看而用 stale bot 把无人处理的 issue 批量关闭。第二类是代理指标漂移：把「活跃度」当作「健康度」，结果惩罚了那些已经稳定、不需要频繁改动的成熟库。第三类是用单指标下结论：只看 star 数、只看最后一次提交时间。

因此度量必须遵守三条纪律。组合而非单点：任何单一指标都不足以支撑决策，至少要跨「人、流程、生态」三类各取一个。看趋势而非绝对值：一个 3000 star 的项目和 30000 star 的项目不能横向比，但同一个项目自己的 12 个月趋势可以比。区分因果：指标下降是原因还是结果？发布间隔变长可能是因为项目已经稳定，也可能是因为维护者 burnout，这两者的处置完全相反。

一个最小可用的度量闭环

闭环由四步组成，缺任何一步度量都会退化成报表：定义口径（用 CHAOSS 的措辞，避免自创）、自动采集（gh api + 定时任务）、阈值告警（只在越线时打扰人）、定期复评（把结论写回风险登记表）。实践中失败最多的是第四步——评估一次就归档，半年后依赖已经进入停滞期却无人察觉。

2. 贡献者维度指标

贡献者维度回答的是「如果核心维护者明天消失，项目还能活多久」。CHAOSS 给出的核心口径是 Contributor Absence Factor，也就是通常说的 bus factor（巴士因子）：把贡献者按提交数降序排列，记作 $c_1 \ge c_2 \ge \dots \ge c_n$，找到最小的 $k$ 使得前 $k$ 人的提交之和达到总提交的 50%，这个 $k$ 就是 bus factor。

bus factor 计算：
  排序: c1 >= c2 >= ... >= cn
  求最小 k: sum(c1..ck) >= 0.5 * sum(c1..cn)
  阈值: k >= 3 健康 | k = 2 偏薄 | k = 1 极高风险

与它配对的是 Elephant Factor：把贡献者按所属组织聚合，求最少几个组织覆盖 50% 的提交。Elephant Factor = 1 意味着单一公司完全掌控，商业公司放弃该项目时社区没有接盘能力；建议阈值是 $\ge 3$，同时任一组织占比 $\le 50%$。bus factor 看的是「人」，Elephant Factor 看的是「组织」，两者要一起读——3 个都来自同一家公司的维护者，bus factor 是 3 但 Elephant Factor 是 1，风险并不比单人维护低多少。

一个用 jq 直接算 bus factor 的片段（输入是 contributors 接口返回的 JSON 数组）：

gh api --paginate "repos/{owner}/{repo}/contributors?per_page=100&anon=1" \
  --jq '[.[].contributions] | sort | reverse
        | (add / 2) as $half
        | reduce .[] as $c ({n:0, s:0};
            if .s >= $half then . else {n:(.n+1), s:(.s+$c)} end)
        | .n'

如果更习惯用脚本处理，Python 版本只有几行，且便于把结果直接写进 CSV：

import json, itertools

def bus_factor(counts, threshold=0.5):
    """counts: 每个贡献者的提交数列表（降序或乱序均可）"""
    counts = sorted(counts, reverse=True)
    target = sum(counts) * threshold
    acc = 0
    for k, c in enumerate(counts, start=1):
        acc += c
        if acc >= target:
            return k
    return len(counts)

def elephant_factor(org_counts, threshold=0.5):
    """org_counts: 组织 -> 提交数"""
    total = sum(org_counts.values())
    acc, n = 0, 0
    for org, c in sorted(org_counts.items(), key=lambda kv: -kv[1]):
        acc += c
        n += 1
        if acc >= total * threshold:
            return n
    return n

第二个维度是新贡献者留存。CHAOSS 的定义是：在某时间窗口内完成首次贡献的人中，在随后 6 个月内再次贡献的比例。健康项目的参考线是 25% 以上；低于 10% 通常说明评审体验差、文档缺失或维护者回应冷淡。这个指标比「新增贡献者数」有价值得多——一次性 PR 很多但无人留下，是典型的「漏斗底部漏光」。建议把贡献者路径拆成四级漏斗来看，每一级都单独算转化率。

贡献者四级漏斗（每级算转化率）：
  1) 首次接触  提交 issue / 评论 / 提问
  2) 首次贡献  提交第一个 PR 或补丁
  3) 二次贡献  6 个月内再次提交
  4) 持续贡献  12 个月内 >= 3 次且被授予 triage 权限

第三是贡献者多样性：单一组织提交占比、地域与时区分布。时区分布偏窄会直接拉长首响时间——所有维护者都在 UTC+8 时，欧美贡献者的 PR 要等到第二天才有回应。这项指标在选型时容易被忽略，但它解释了很多「为什么这个库响应慢」的疑问。

采集命令（去重提交者并排序）：

gh api --paginate "repos/{owner}/{repo}/contributors?per_page=100&anon=1" \
  --jq '.[] | "\(.contributions)\t\(.login // "anonymous")"' | sort -rn | head -30

3. 响应与合并时效

时效指标回答的是「这个项目对外部输入有没有反应」。三个核心口径：

Time to First Response（TTFR）：issue 或 PR 从创建到第一条非作者本人评论的时间。这是维护者响应度最灵敏的代理。参考阈值：活跃项目中位数 < 24 小时，P90 < 72 小时；把「48 小时内有人回应」的覆盖率当作达标线，健康项目应 ≥ 80%。

Time to Close（TTC）：从创建到关闭的总时长。注意它必须与关闭原因联合解读——被 stale bot 关掉和被作者合并关掉，在 TTC 上可能完全相同，但含义相反。因此 TTC 只和「关闭类型」一起看。

Change Request Closure Ratio：某窗口内已关闭的变更请求数除以该窗口内新增的变更请求数，比值持续小于 1 意味着积压增长。

为什么必须看分位数

平均值在时效指标上几乎没有信息量。一个项目 90% 的 issue 在 2 小时内被回复，10% 拖了 3 个月，平均值会被拖到 9 天左右，而 P50 仍然是 2 小时。决策时应当同时看 P50 和 P90：P50 反映日常体验，P90 反映最坏情况——而「最坏情况」恰恰是选型时最该关心的，因为你不知道自己的 issue 会落在哪个分位。

issue 与 PR 要分开算

很多团队的仪表盘把 issue 和 PR 混成一个数字，这会让时效指标彻底失真。两者的期望响应时间差一个数量级：一个「这个 API 为什么这样设计」的 issue 可以讨论两周，而一个修 bug 的 PR 如果两周没人看，作者基本就流失了。建议把指标拆成两组分别设阈值——PR 关注 TTFR 与合并时长，issue 关注 TTFR 与 triage 完成率（即多久被打上类型与优先级标签）。此外，PR 的时效还要区分「维护者等待作者」和「作者等待维护者」两段：前者不计入维护者响应度，否则会冤枉那些认真迭代、反复修改 PR 的贡献者。

gh api --paginate "repos/{owner}/{repo}/pulls?state=closed&per_page=100" \
  --jq '.[] | [.number, .created_at, .closed_at, (.merged_at // "unmerged")] | @tsv'

gh api --paginate "repos/{owner}/{repo}/issues?state=open&per_page=100" \
  --jq '.[] | select(.pull_request == null) | "\(.number)\t\(.created_at)\t\(.updated_at)"'

想把这些指标做成持续看板，思路与持续交付里的 DORA 指标流水线 完全一致：定时抓取、落时序库、只对趋势和阈值告警，而不是对单点数值告警。区别只在于 DORA 度量的是自己团队，健康度度量的是别人家的仓库，因此不能要求对方改进，只能调整自己的选型与隔离策略。

4. 发布与版本节奏

发布节奏回答的是「这个项目还在交付可用的产物吗」。CHAOSS 的口径是 Release Frequency（单位时间内的发布次数）和 Time Between Releases（相邻发布的中位间隔）。阈值参考：

比频率更重要的是语义化版本合规性。检查方法很直接：看过去三年 major 版本的数量与变更日志。如果一个库频繁发 minor 版本却在 minor 里塞破坏性变更，那么任何 ^ 或 ~ 约束都是不安全的，这会直接推高你的升级成本。

gh release list --repo {owner}/{repo} --limit 50

gh api "repos/{owner}/{repo}/tags?per_page=100" --jq 'length'

gh api "repos/{owner}/{repo}/releases/latest" --jq '.published_at'

LTS 与 EOL 政策要检查什么

对基础设施类依赖，这一项的价值高于发布频率本身。一份合格的 EOL 政策应当回答四个问题：哪些版本进入长期支持（通常是最新的 1~2 个 major）；支持窗口多长（建议 ≥ 12 个月）；安全补丁是否回移到旧分支；弃用是否有提前公告期（建议 ≥ 6 个月）。如果项目没有任何 EOL 文档，你就要假设「升级到最新版是唯一的安全路径」，并把这条假设写进依赖风险登记表。发布节奏与维护者精力的关系值得单独展开——发布频率骤降往往是维护者倦怠的第一个可见信号，这一点在 维护者可持续性 里有更系统的讨论。

5. 积压与关闭率

积压指标回答的是「项目还在消化输入，还是只是在堆积」。两个基础量：

Backlog Growth Rate = 窗口内新增 issue 数 − 窗口内关闭 issue 数。取 90 天窗口，持续为正说明积压增长。Issue Closure Ratio = 窗口内关闭数 ÷ 窗口内新增数，健康项目应 ≥ 0.9（即 90% 的输入在同期被处理掉）。

老化（aging） 是比总量更有信息量的指标：统计 open issue 中「超过 90 天没有任何活动」的占比。参考线：< 30% 健康，30%~50% 需要关注，> 50% 说明维护带宽已经跟不上。注意要区分「无活动」和「无标签」——一个被 triage 过、打了 help wanted 标签但暂时没人的 issue，和一个从创建起就没人看过的 issue，是完全不同的状态。

积压要分三层看

把 open issue 拆成三层，处置策略完全不同。待办层：已被 triage、有明确标签与优先级，属于正常队列。待定层：缺少复现信息或维护者尚未判断，需要的是澄清而非修复。沉积层：超过 180 天无任何互动，往往是重复、过时或无法复现的问题。健康的项目应当让沉积层占比保持在 20% 以内；如果沉积层占比超过一半，说明 triage 环节已经失守，此时关闭率再高也没有意义。

Stale 比例是识别「刷关闭率」的关键。如果被关闭的 issue 里有很高比例是机器人以 stale 为由关闭的，那关闭率这个数字就失去了意义：

gh api --paginate "repos/{owner}/{repo}/issues?state=closed&per_page=100" \
  --jq '[.[] | select(.pull_request == null)] | length as $t
        | [.[] | select(.pull_request == null)
             | select([.labels[].name] | any(. == "stale" or . == "wontfix"))] | length as $s
        | "total=\($t) stale_closed=\($s)"'

gh api --paginate "repos/{owner}/{repo}/issues?state=open&per_page=100" \
  --jq --arg d "$(date -u -v-90d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  '[.[] | select(.pull_request == null) | select(.updated_at < $d)] | length'

另一个必须同时看的量是重新打开率（reopened ÷ closed）。如果关闭率很高但重新打开率也在上升，说明问题被「关掉」而不是被「解决」。这两个数字放在一起，就能识别出大部分以指标为导向的关闭行为。

gh api --paginate "repos/{owner}/{repo}/issues?state=all&per_page=100" \
  --jq '[.[] | select(.pull_request == null)]
        | {closed: [.[] | select(.closed_at != null)] | length,
           reopened: [.[] | select(.state == "open" and .closed_at != null)] | length}'

把「关闭率、stale 关闭占比、重新打开率」三个数字放在一张表里按季度看，就能得到一个相当可靠的「维护者是否在认真处理输入」的判断。三者同时健康的项目很少见，但一旦出现，几乎可以确定这是一个值得长期依赖的库。

6. 依赖广度与供应链风险

前面几节看的是「项目自身」，这一节看的是「项目在你系统里的位置」。同一份健康度报告，对一个下游数量为 5 的库和对一个下游数量为 50000 的库，风险含义完全不同。

四个风险因子：

下游数量（Dependents）：直接依赖它的仓库数。数量大意味着两件事同时成立——生态价值高，且一旦出问题爆炸半径大。传递依赖深度：它自己依赖了多少库、那些库又依赖了多少。一个只有 200 行代码但拖进 40 个传递依赖的包，供应链暴露面反而更大。

关键性评分：Google Open Source Insights 的 criticality score 把「被依赖程度、发布频率、贡献者数、组织多样性、最近提交」合成 0~1 的分数，可作为初筛——通常 0.5 以上就值得纳入重点关注名单。

维护活跃度：最后提交距今 < 90 天、最后 release 距今 < 365 天，是两条简单的红线。组织与身份风险：是否只有一个维护者持有发布权限？发布是否经过签名？仓库是否启用了强制 2FA？这些直接决定「账号被接管」的概率。依赖更新与漏洞告警的流程可以单独建立，但请注意本文的重心是判断而不是工具配置。

gh api "repos/{owner}/{repo}" --jq '{
  stars: .stargazers_count,
  forks: .forks_count,
  open_issues: .open_issues_count,
  pushed_at: .pushed_at,
  archived: .archived,
  license: (.license.spdx_id // "NONE"),
  default_branch: .default_branch
}'

综合判断规则可以参考这条：若「下游 ≥ 10000」且「bus factor ≤ 1」且「无 LTS 政策」，判定为高风险依赖——要么投入资源参与维护，要么在架构上做可替换设计，要么准备 fork 预案。反之，下游不多但活跃、bus factor ≥ 3 的小库，往往是被低估的优质依赖。判断时要特别留意 archived 字段：归档仓库不接收任何输入，是确定性风险，不需要再看其他指标。

依赖分级与处置策略

把「下游广度」与「自身健康度」两个轴交叉，可以把依赖分成四类，每类的处置动作不同：

这张表可以直接作为依赖巡检的输出格式：每次巡检后每个依赖落到一个格子，格子变化本身就是告警信号。比「健康度分数掉了 0.3」更有行动指引。

7. 指标采集工具与命令

三个层次的采集方案，按投入排序：

现成平台。CHAOSS 社区维护的 GrimoireLab 与 Augur 都能直接对接 GitHub/GitLab，产出贡献者、issue、PR 的时序指标并带 dashboard。适合需要长期看板、且愿意维护一套 OpenSearch 栈的团队。CHAOSS 的价值更多在指标定义本身——即使你不用它的工具，也建议照它的口径定义，因为口径统一后跨项目对比才成立。

gh CLI + jq。轻量、无状态、可塞进 CI 定时任务，适合做几十个依赖的定期巡检。

GraphQL 批量查询。当依赖数量上百时，REST 的每仓库一次调用会撞 rate limit（有 token 时 REST 为 5000 次/小时，GraphQL 为 5000 点/小时，但一次 GraphQL 查询可覆盖多个仓库，实际效率高得多）。用别名把多个仓库拼进一次查询：

gh api graphql -f query='
query($o:String!,$n:String!){
  repository(owner:$o,name:$n){
    stargazerCount
    pushedAt
    isArchived
    releases(first:5,orderBy:{field:CREATED_AT,direction:DESC}){nodes{tagName publishedAt}}
    issues(states:OPEN){totalCount}
    pullRequests(states:OPEN){totalCount}
  }
}' -f o=owner -f n=repo

采集频率与配额预算

配额要按「依赖数量 × 查询点数 × 频率」做预算。经验值是：高风险依赖（约 10~20 个）每日巡检，其余长尾依赖每月一次快照。pushed_at、archived、license 这类字段变化很慢，缓存 24 小时完全够用；open_issues_count 这类会波动的字段才需要每次重新拉。另外务必给 gh 配置 token——匿名调用每小时仅 60 次，跑不到十个仓库就会 403。

自建脚本。把上面几条命令封装成 Python，对一份 deps.txt 逐行跑，输出 CSV，再算 bus factor 与老化率。脚本设计上建议把「采集」与「计算」分离：采集层只负责把原始 JSON 落到 data/{owner}__{repo}.json，计算层读本地文件算指标。这样调整阈值或新增指标时不需要重新打 API，也避免调试过程中反复消耗配额。

import json, os, subprocess, datetime as dt

DATA = "data"
CACHE_HOURS = 24

def gh(path, cache_key):
    """带本地缓存的 gh api 调用：命中缓存则直接读文件"""
    fp = os.path.join(DATA, f"{cache_key}.json")
    if os.path.exists(fp):
        age = dt.datetime.now().timestamp() - os.path.getmtime(fp)
        if age < CACHE_HOURS * 3600:
            return json.load(open(fp))
    out = subprocess.run(["gh", "api", "--paginate", path],
                         capture_output=True, text=True, check=True).stdout
    os.makedirs(DATA, exist_ok=True)
    json.dump(json.loads(out), open(fp, "w"))
    return json.loads(out)

def snapshot(slug):
    """slug 形如 owner/repo，返回一条可落库的记录"""
    repo = gh(f"repos/{slug}", slug.replace("/", "__"))
    rel = gh(f"repos/{slug}/releases?per_page=1", slug.replace("/", "__") + "__rel")
    counts = [c["contributions"] for c in
              gh(f"repos/{slug}/contributors?per_page=100&anon=1",
                 slug.replace("/", "__") + "__ctb")]
    return {
        "slug": slug,
        "stars": repo["stargazers_count"],
        "archived": repo["is_archived"],
        "license": (repo.get("license") or {}).get("spdx_id", "NONE"),
        "pushed_at": repo["pushed_at"],
        "last_release": rel[0]["published_at"] if rel else None,
        "bus_factor": bus_factor(counts),
        "contributors": len(counts),
    }

if __name__ == "__main__":
    for slug in open("deps.txt").read().split():
        print(json.dumps(snapshot(slug), ensure_ascii=False))

脚本本身不复杂，容易踩坑的是两点：一是 --paginate 在 contributors 接口上会把多页结果拼成一个数组，直接 json.loads 会失败，需要按流式解析或改用 gh api --paginate --jq '.[]'；二是日期一律用 UTC ISO 8601 存储，展示层再做时区转换，否则跨时区团队看到的「最后提交距今」会不一致。

8. 选型评分卡

把前面的维度落成一张可以打分、可以复算的表。做法是：每个维度给定阈值与权重，逐项打分（0~5），加权求和后映射到风险等级。权重不是普适的，应按你的依赖性质调整——基础设施类依赖应加大「发布节奏」与「LTS」权重，工具类依赖可加大「响应时效」权重。

总分换算：≥ 4.0 可直接采用；3.03.9 可采用但需登记风险与替代方案；2.02.9 需架构隔离（例如包一层适配器）；< 2.0 不建议引入。

一个打分示例

假设要评估一个中等规模的 HTTP 客户端库。采集到：bus factor = 2、Elephant Factor = 2、6 个月留存 18%、TTFR 中位 36 小时、48 小时覆盖 70%、每季度发布且 SemVer 合规、关闭率 0.85、90 天老化率 35%、下游约 3000、Apache-2.0 且有治理文档。逐项打分：贡献者 2 分、留存 3 分、时效 3 分、发布 3 分、积压 3 分、依赖广度 4 分、许可证 5 分。加权后约 3.0 分——结论是「可采用，但登记 bus factor 偏薄的风险，并准备一个替代库作为后备」。

许可证与治理这一维不要省，它可以一票否决——许可证不明或与你的分发方式冲突时，其他维度再高也不能用。判定方法与常见冲突组合属于选型流程里的前置检查项，建议单独整理成 开源许可证合规 的检查清单。

权重怎么调

评分卡的权重是这套方法里最主观的部分，也最需要按场景校准。三条经验规则：基础设施类依赖把「发布节奏」与「许可证与治理」各加 5%，因为它们的破坏性变更与许可冲突的代价最高；开发工具类依赖把「首次响应时效」加 5%，因为工具遇到问题时你更需要快速拿到答案；深度耦合的库（比如被写进核心数据结构序列化格式的库）把「贡献者多样性」加 5%，因为替换成本高、长期存活比短期响应重要。调整后权重之和必须仍为 100%，且每次调整都应在选型文档里留下理由，否则一年后没人说得清这个分数是怎么来的。

9. 指标滥用与反模式

最后列出实践中最常踩的度量反模式，它们几乎都源于把代理指标当成了目标本身。

用 commit 数或代码行数衡量贡献。这直接激励拆分提交和灌水，同时惩罚了那些做评审、写文档、回 issue 的人。若要度量人的贡献，应改用「评审次数 + 被合并的变更 + 社区支持动作」的组合。

用 star 数做选型决策。star 是营销指标，受发布时机、社交媒体曝光、会议演讲影响极大。它适合做「知名度」的粗略排序，不适合做「可靠性」判断。

只看总量不看分布。总提交数 50000 的项目可能是 3 个人贡献了 90%，也可能是 300 人长尾贡献。前者的 bus factor 是 3，后者是 3，但风险性质完全不同——要同时看分布曲线和 Elephant Factor。

用关闭速度倒逼维护者。当关闭率成为 KPI，最理性的应对就是批量 stale 关闭，问题被隐藏而非解决。度量关闭率时必须同时看「重新打开的 issue 数」与「stale 关闭占比」。

把指标当 OKR 下发给社区。维护者是志愿者或已被雇主的 OKR 占满的人，外部强加的指标只会加速倦怠。度量应当用于自省和选型，而不是用于考核他人。

忽略项目生命周期阶段。用同一套阈值评价一个刚起步的实验库和一个已成熟的稳定库，必然得出错误结论。对成熟库，「活跃度低」往往是优点；对实验库，「活跃度高」也不代表可用于生产。

把「无活动」直接等同于「无人维护」。归档仓库、只做安全维护的 LTS 分支、以及刻意保持稳定的完成态项目，都会呈现低活动特征，需要结合 EOL 政策与安全公告通道来区分。

权衡取舍

常见坑清单

1. 只看最后一次 commit 时间就下结论：一个只改 README 的 commit 会让「最后提交」看起来很新，实际代码已两年未动——应同时看最后一次 release 与最后一次代码目录下的提交。
2. 把 star 数当可靠性指标：star 受曝光影响极大，与维护质量弱相关——改用 bus factor、发布节奏、老化率组合判断。
3. bus factor 用「全部历史提交」计算：创始人的早期提交会长期压低指标——应按最近 12 个月窗口重算。
4. 忽略机器人账号：dependabot、renovate、stale bot 会显著抬高贡献者数与提交数——统计前按 [bot] 后缀与已知账号过滤。
5. 把 stale 关闭算作有效关闭：关闭率因此虚高，掩盖真实积压——统计时单列 stale/wontfix 占比。
6. REST API 逐仓库轮询导致限流：上百依赖时匿名调用很快 403——配置 token 并改用 GraphQL 批量查询。
7. 跨项目横向比较绝对数值：不同规模项目不可比——只比较同一项目的 12 个月趋势。
8. 用「活跃度低」判定项目已死：成熟稳定库本就低频改动——先查是否处于 LTS 维护模式。
9. 忽略许可证维度：许可证不明或与分发方式冲突时其他指标无意义——作为一票否决项前置检查。
10. 把度量结果用于考核维护者：必然引发指标操纵与倦怠——度量只用于自省与选型决策。
11. 只看直接依赖不看传递依赖：传递依赖往往才是真正的爆炸半径来源——按 criticality score 抽样检查。
12. 一次性评估后再也不复评：依赖健康度会随时间恶化——把评分卡纳入季度巡检并记录变化。

小结

开源项目健康度度量本质上是一个证据化决策的流程，而不是一套排行榜。它的正确用法是：先明确消费方（选型、自省还是治理），再跨「贡献者、流程、生态」三类各选少量指标，用统一口径采集，用趋势而非绝对值解读，最后落到一张加权评分卡上得出可采用、需隔离或需规避的结论。任何单一指标都不足以支撑决策，任何可以被低成本操纵的数字都不应当成为目标。

工程上最容易见效的三步是：第一，为你的依赖清单建立一份 deps.txt，跑通本文第 7 节的 gh 命令，把 pushed_at、releases、bus factor、老化率落成一张定期更新的表；第二，按第 8 节的评分卡给每个依赖打分，把高风险项写进风险登记表并指定替代方案；第三，把「48 小时首响覆盖率」「bus factor」「90 天老化率」三条设成阈值告警，只在越线时提醒，避免陷入指标噪声。

如果想继续深入，建议沿着两条线读：一条是维护者侧，从维护者可持续性到 社区运营 ，理解指标背后的组织动力学——为什么留存率低、为什么积压会增长，这些问题的根因通常不在技术层面而在治理结构；另一条是风险侧，从依赖广度与供应链风险延伸到漏洞响应流程与许可证合规，把「能不能用」与「出事怎么办」两条判断链补齐。度量不是终点，它只是让你在依赖决策上少赌一点运气。