超越星标和分支：为什么开源需要更好的协作指标

在开发“开源入门”课程时，我们注意到新贡献者面临的最大痛点之一是，他们的 PR 没有在他们认为合理的时间内被合并，这让他们感到非常沮丧。他们做了研究，找到了问题，被分配了任务，然后……就没了下文。没有反馈，没有合并，只有一片寂静。

这真是个老生常谈的故事。我经常听到贡献者说：“我的 PR 已经提交两周了，一点消息都没有。” 我完全理解。这种情况发生的原因有很多，包括倦怠、项目被放弃、运气成分等等，而且很少是出于恶意。所以我总是建议贡献者在提交代码之前先加入社区。这能帮助你了解项目的节奏、如何与维护者沟通，以及社区是否欢迎新成员。

如果你读过我过去五年写的文章，就会知道我非常关心开源社区。但我们传统的项目评估方式和指标并不能充分展现其中最有意义的部分。很多时候，这些指标——比如星标数、分支数、下载量和 DORA 指标——都忽略了故事中最关键的部分：人们是如何协作的。

一种不同的开源指标方法

自从OpenSauced 关闭以来，我一直在探索不同的方法来理解协作问题。Collab.dev并非
OpenSauced的替代品，但它讲述了故事中另一个（也是重要的）部分，并捕捉了人们如何协作。它揭示了代码背后的人性模式，例如代码审查的响应速度、贡献者的分布以及合并动态。像 DORA 这样的行业认可指标对于理解软件交付性能很有价值，但在人性方面却作用有限。它们可以告诉你代码部署的速度有多快，但无法告诉你贡献者是否感到被支持、被欢迎，或者是否被冷落。开源不仅关乎发布，也关乎人际关系，我们需要能够反映这一点的指标。

协作可见性差距

问题不仅仅在于我们目前的指标不完整。虚荣指标一直被吹捧为衡量项目健康状况的重要指标，但坦白地说，它们根本没那么重要。

如果我们考虑维护人员每天面临的挑战，就会发现通常很难做到以下几点：

• 确定哪些贡献者最有可能成为长期参与者。
• 准确找出审核流程停滞或崩溃的环节。
• 了解社区环境是否真正对新来者友好。
• 区分可持续增长和问题性规模扩张。

对于潜在的贡献者来说，这条路也并不明朗。他们常常难以确定：

• 项目是否积极审查和合并社区贡献。
• 稿件通常需要多长时间才能审核通过。
• 哪些维护者在贡献者感兴趣的领域反应最迅速？
• 如果核心团队和更广泛的社区的贡献之间能够保持健康的平衡。

对我们许多人来说，我们必须决定将时间和精力投入到哪里。如果我们投入了时间，却发现做出了错误的选择，最终一无所获，那将非常令人失望。例如，我最近想了解更多关于Cognee（一个 AI 内存管理框架）的信息，所以我创建了一个Collab.dev 上的 Cognee 页面，以便了解正在进行的合作项目。当你第一次在 GitHub 上查看Cognee时，它​​看起来像是一个正在发展中的开源项目，拥有相当数量的 star、活跃的 issues 和定期的提交。但是，查看 Collab.dev 的控制面板，你会发现它远不止于此。

Cognee 的数据通过 Collab.dev 讲述的故事

贡献者分配

当我们思考开源项目中的良好贡献者分配时，通常意味着责任、活动和知识不会集中在少数人手中。这种分配有助于降低倦怠感，增强项目韧性，并营造更友好的环境。Cognee 就是一个很好的例子，它真正实现了贡献者的平衡。核心团队贡献了 51%，社区贡献了 49%，Cognee 在不放弃维护者责任的前提下，真正实现了社区的归属感，并营造了协作的氛围，激发了社区成员更高的项目支持积极性。

公关生命周期指标

情况变得越来越有趣。审核流程显示，88% 的 PR 会收到审核，其中 85.2% 获得批准。如此高的批准率充分体现了项目的质量控制和贡献者体验。这表明，要么项目拥有完善的贡献指南，帮助用户提交高质量的 PR；要么维护者积极帮助贡献者改进工作，而不是简单地拒绝。此外，审核响应速度也很快，中位响应时间为 1.9 小时，42% 的审核在一小时内完成。用户无需等待三周才能收到审核结果。维护者通过这种快速响应，营造了积极的贡献者体验。

这告诉我们关于人类故事的什么信息

作为维护者，我曾遇到过无法立即回复贡献者的情况，有时他们甚至要等上几周才能得到我的回复。显然，这并非理想之选。通常情况下，对方要么已经不再参与，要么干脆不再回复，或者以后不太可能再做贡献。但从 Cognee 的数据来看，他们似乎没有遇到同样的问题。

当用户为 Cognee 贡献代码时，他们无需担心自己的努力是否得到认可。他们能快速获得反馈，从而保持参与度并快速迭代。Cognee 的审核周期（1.6 小时）有效地鼓励了用户持续贡献代码。此外，平均合并时间为 19.5 小时，这向贡献者表明他们的工作能够产生真实且立竿见影的影响。而且，他们还能看到自己的贡献已被用户看到。

协作模式

综合这些指标来看，它们展现的是一种精心设计的协作模式，一种充分考虑贡献者和维护者体验的模式。他们创建了相应的系统和习惯，使协作既高效又有价值。这些数据也揭示了哪些事情没有发生。我们没有看到任何未审核的 PR 堆积，审批和合并之间也没有巨大的时间差，更没有发现贡献者感到沮丧或维护者不堪重负的迹象。

这个协作案例意义重大，不仅因为它展现了 Cognee 是一个不错的贡献平台，更重要的是，它能成为一个可复制的模式。其他项目可以学习如何让参与的贡献者感受到协作的乐趣。我们可以分析数据和项目，更好地理解是哪些系统和实践造就了这些模式，还可以联系我们欣赏的项目的维护者，请教他们：如何构建既全面又高效的审核流程？如何在保持质量的同时，积极响应社区的贡献？

协作质量不必靠猜测。我们可以通过数据了解更多信息，并找到那些能够接受社区成员贡献的项目。（如果您感兴趣，collab.dev 也提供了一个很棒的比较工具。您可以查看我做的mem0 与 cognee 的比较。）

纵观全局：衡量真正重要的指标

我们正处于开源发展的一个阶段，复杂的人际关系决定着开源项目的成败。协作指标有助于取得更好的成果。当我们有效地衡量协作时，我们可以：

• 通过识别不堪重负的维护者来减少贡献者的倦怠
• 通过引导早期贡献者参与响应式项目，提高首次贡献的成功率。
• 通过了解健康的协作模式，构建更可持续的项目。
• 建立反馈机制，帮助项目改进其社区实践。

在开源领域，我们已经证明协作开发可以创造巨大的价值，但我们不能忽视可持续性挑战、维护人员的倦怠以及扩展人类协作的难度。

更清晰地了解协作模式有助于我们理解开源的未来发展趋势。我们需要一些工具，不仅能帮助我们了解现有的代码，还能帮助我们了解人们如何高效地协作创建和维护这些代码。

开源的本质始终是人们的协作。我们的衡量标准应该体现这种有意义的工作。