译自 Dries Buytaert 博客原文：The 60-second procurement test（2026 年 9 月 9 日）。
我认为，任何一个背后有商业或机构资助生态的开源项目，都应该发布一份官方的贡献记录：谁在贡献、贡献了多少、在多长时间内、做的是哪类工作、在项目的哪些部分上工作，以及在披露的前提下，谁为这些工作付了钱。
判断一份记录好不好的测试很简单。采购方应该能在大约一分钟内回答三个问题：这家厂商到底贡不贡献？和其他厂商比贡献多少？他们做的是我在意的那些部分吗？
一份好的记录对双方都有用。采购方拿到可以核实的答案，真正做贡献的厂商则得到那些常常没人看见的工作所应得的认可。
当然，贡献并不证明这家厂商能交付。它只是采购时的一个因素，和交付能力、专业水平、价格并列。
厂商的自述难以核实、也难以比较
假设你正在为你的 Drupal 站点、你的 Kubernetes 集群，或者你用的任何开源软件找服务商，有两家公司来投标。两家都说自己深度参与这个项目，而且按他们各自对"深度参与"的定义，两家可能都没撒谎。
如果没有项目方的记录，核实这些说法往往意味着你得自己把每家厂商的贡献历史重建一遍。
代码仓库看起来是显而易见的起点，但即使只是按厂商统计提交数都不简单。项目必须把一个个贡献者，和雇佣或资助他们的组织对应起来，而这些关系会随时间变化。
更重要的是，开源贡献可以包括文档、支持、组织活动、治理工作、宣传等等。这些工作很多发生在代码仓库之外，或者记录形式不是采购方能轻易解读的。数据可能都是公开的，但公开不等于可用。贡献记录存在的意义就是补上这个落差。
哪些贡献算数，项目方最有资格判断
Drupal 从 2015 年起就在统计贡献积分，依据的是我在 2014 年提出的方法，现在由 Drupal 协会治理。这套系统记录的不只是代码，而且不止给个人贡献者记分，也给资助他们工作的组织和客户记分。
并非每份贡献的分量都一样。对 Drupal Core 或某个战略计划的贡献，比对一个鲜有人用的模块的贡献得分更高；被更多站点依赖的贡献项目，其工作得分也更高。
原始贡献数据不会告诉采购方哪些工作对项目最重要。项目本身才有上下文去判断什么推进了它的优先级、不同贡献该如何加权。它的记录应该公开这些规则，链接到背后的具体贡献，并说明错误是如何被纠正的。
在 Drupal，贡献积分流入 Drupal.org 市场，采购方可以在那里查机构、做比较。我们基础不错，但要让它更容易被找到、被理解、被比较，还有很多事要做。
记录是项目的责任，不是厂商的责任
一个合理的反对意见是：这把负担压在了错的一方。如果厂商声称自己有贡献，应该由厂商来证明，项目不该消耗稀缺的时间去追踪贡献。
设想前面那两家公司都提交了证明材料。各自按自己最体面的口径证明了自己的数字，可谁记录更好，仍然不清楚。采购方到处都遇到这个问题，这也是采购要依赖第三方的原因：审计师、认证机构、行业分析师、客户推荐人。
就厂商贡献而言，项目本身往往就是天然的第三方。工作发生在项目里，所以项目有数据，也处在独一无二的位置上，能就某家厂商贡献的价值和战略影响表达意见。
贡献记录是项目认可"创造者"（Makers）的一种方式，也是项目表明"我希望谁中标"的一种方式。它还把一个为每个采购方都要重复的问题一次性解决掉，而不是让每个采购方各自去审每一份投标。
当发布记录符合项目自身利益时，项目就该承担这份负担。让贡献可见，会把商业机会导向那些支撑项目的厂商，而正是这些工作为贡献买单。于是项目得到更多贡献，而公开的认可则是项目回馈贡献厂商的方式。
项目可以从一份简单的记录起步
不是每个项目都想要或需要一套像 Drupal 这么精巧的系统。一个项目需要多重的记录，取决于它周围的服务是怎么买卖的：有几百家公司抢活干的项目，需要的比只有几家已知服务商的项目更多；完全没有商业生态的项目，可能根本不需要记录。
对一个小项目来说，在官方仓库里放一个文本文件，列出它认可的组织贡献者以及他们做了什么，作为第一版就够了。
更复杂的生态可能需要给厂商分类、支持按地区搜索，或者给不同种类的贡献加权。无论采取什么形式，记录都必须容易找到、用起来快。
所以，如果你维护一个有商业或机构资助生态的开源项目，开始发布贡献记录，并持续改进它。
如果你购买基于开源的服务，去要项目方的贡献记录。在采购一开始就决定贡献在你的决策中占多少分量，然后拿投标方的说法去对记录。
最后，如果你在资助开源，用这份记录去找那些正在你想支持的部分上工作的贡献者。
在采购方和资助方能够考虑贡献的地方，我预计记录清晰的项目，会比只靠呼吁的项目，把更多商业机会导向自己的维护者。
特别感谢 Henry Poole 对本文的贡献，以及 Sachiko Muto、Tiffany Farriss、Tim Lehnen 和 Amandine Le Pape 的审阅。