增长真实性 — inspect.software 知识库

GitHub 星标是开源领域被阅读得最广泛的信任信号，也是其中唯一没有签发方的信号。星标可以公开批量购买，每个只需几分钱，复刻、关注者与粉丝同样如此，而数字本身无法把买来的与挣来的区分开。

任何计入星标的评估都继承了这个问题。增长真实性是方法论中处理该问题的部分：每份报告收集的逐日星标与复刻历史会被读取，以找出其形态不是自然关注所能产生的增长；一旦此类增长得到确认，那些可购买的输入将被折减，而不是被采信。

其结果回答一个范围很窄的问题：

这个仓库的流行度历史，看上去像是自然发生的，还是像被交付的？

它不回答是谁所为，也不回答是否有人为此付费。此处的每一项发现都只是关于公开事件发生时间的陈述，仅此而已。

为何时间形态会暴露差别

项目挣得的关注经由人而来，而人是不规则的。一次发布、一次登上 Hacker News 首页、一场会议演讲或一则简报提及，会产生逐小时起伏不均的突增；它在带来星标的同时也带来复刻，因为总有读者会打开代码；并且会在随后一周里，随着链接传播直至停止而衰减。

被交付的关注不具备上述任何性质。它按排定的节奏到来，来自从不查看该仓库的账户，并在订单完成的那一刻结束。计数器无法分辨其中的差别，历史可以。

报告首先寻找突增日——当天新增星标既达到 25 个以上，又达到该仓库自身活跃日中位速率的 12 倍以上。连续的突增日会合并为一个窗口。

突增本身绝不构成一项发现。真实的项目也会突增，而一套把每次爆发都视作可疑的方法论，会对每一次成功的发布发出警示。只有当至少两项独立信号 相互佐证时，一个窗口才被确认：

信号	观察到的内容
星标集中度	最忙的五天占据了所收集全部星标的 80% 及以上。在 502 个普通仓库上实测，中位数把 6.9% 的星标放在其最忙的五天里，且没有任何一个达到 80%。该项针对的是整段历史而非单次爆发，因此它为每一个窗口提供佐证。
节奏平直	在连续三天或更长时间内，每日新增几乎没有起伏。受众是不均匀的，交付排期不是。
复刻无响应	该窗口的复刻与星标之比低于仓库自身长期比值的四分之一——这些关注从未触及代码。
无衰减	爆发之后七天的总量不超过爆发量的 5%。真实的突增有尾部；完成的订单则戛然而止。
从未发布过版本	该项目从未发布过任何版本。此项刻意做弱：大量正当的项目本就什么都不发布。该信号的早先形态把发生在项目首次发布之前的爆发视为证据，而首轮对照测量中的全部误报皆由它产生——先公开、再吸引关注、随后才发布版本，本就是寻常项目的运作方式。

折减作用于流行度的星标与复刻两个组成部分——即供应方能够售卖的那两项输入。关注者不受影响，因为它们不在该异常所佐证的范围之内，其他任何类别也完全不受触动。流行度占总指数的 7.2%，因此算术上的影响是刻意保持轻微的。发现本身才是产出；调整只是让报告不再断言一件它有理由怀疑的事。

不存在向上的调整。干净的历史无法提高评分，正如干净的司法辖区结果无法提高安全态势。

当仓库没有收集到星标历史、星标数少于 100，或已收集窗口跨度不足 60 天时，其结果为无法核验。它不带任何形式的扣分。

这是最常见的情形，它是证据的界限而非一项判定。历史收集是有边界的—— 报告捕获的是星标与复刻事件的近期窗口，而非一个大型项目的全部生命历程——因此早于该窗口的操纵在此处根本不可见。无法核验意味着该问题未能得到回答，绝不意味着答案是干净的。

一项发现针对的是一种形态，而非某个人。星标可能由竞争者、推广方、仓库的前所有者，或维护者素未谋面的人购买。本项评估不指认任何行为主体，也绝不暗示维护者曾参与其中。
一项发现并不使软件变差。它只是使关于该软件的一项证据变得不可靠。报告其余部分的工程、治理与安全证据不受影响，各自独立成立。
没有发现并不等于一纸证明。跨越数月、缓慢分散的购买不会形成突增，本项评估看不到它。

不存在任何可施加于仓库以改善该结果的手段，而这正是要点所在：本项评估读取的是已经发生的历史。增长本就真实的项目，读出来就是自然增长。