方法论：蚂蚁集团关于 OSPO 的思考-05  绩效量化确实很难，但有迹可循

就当前普遍情况来看， OSPO 的工作无法立即显效，而且难以量化和评估，但并不意味着无从下手，仍然有一些可用的指标可以考虑。关键是如何用互联网的方式，小步快跑，快速迭代，总结出一些规律来。

边思康：评估OSPO 工作成效的确很难，且没有那么快能解。开源是需要长期主义精神的一个领域，这是我们必须要接受的一件事。

如果为了做成绩而做开源，则很容易跑偏，比如过度注重发声的频率和影响力。作为开源生态中一部分，OSPO 也要接受这一事实，并在这一事实的制约下去做事。情况是否会变好？我认为是肯定的。当然，这也要靠大家群策群力来形成共识，共同推进。

量化评估一个组织的效果，有三种方式，一种是testing 选定测试维度，另一种是benchmark 明确平均水位，第三种是专家认可。就开源领域而言，第三种衡量方法可能并不适用，所以需要从前两种入手。

测试维度其实很难有个定论，因为连我们提到的“OSPO 工作所涵盖的范围”可能都无法达成共识。

所以我们要对其中的一些维度加以甄别。比如治理水平、项目数量和质量、社区活跃指标等维度，肯定是需要的；但开源统筹水准、开源商业化产出、开源共建值这些，并不一定是每个OSPO都需要。可能我们要做的，就是用互联网公司的方式，小步快跑，快速迭代，看是否能总结出一些规律来。

如果用平均水位来评估，首先要参考我们上面提到的测试维度，其次在每一个维度上，还要比较明确地定义出水位。这就更难了。以项目数量为例，多少算多？一个组件项目和一个数据库项目是否能够等同而论？另外，如果一个项目的社区做得好，如何证明是因为 OSPO 的存在才做到相应水位？

BVP 的研究显示，不同开源类型的项目，活跃度可能会有比较大的差异，泛前端的项目活跃度会两倍于数据库和 AI 工程类型的项目活跃度。这种情况下，benchmark 还是需要考虑到各个社区的自身状态。