夜天之书 #94 开发者关系的指标与价值

随着软件行业持续发展，企业构建软件系统的复杂度日益上升，系统不同层次和不同方面的分工日益精细。许多公司不再完全自己生产所有需要的软件，而是转向大量采购技术产品来满足自己的软件需求。

除了核心业务逻辑需要独立实现以外，支持业务逻辑的软件平台和服务都可以甚至应该采购，开发业务逻辑本身也能够藉由采购开发工具和平台来进行加速。前者的例子包括传统商业软件和云服务等，后者的例子有 Copilot 和 Retool 等。

这个潮流当中，开发者已经成为公司购买技术产品决策过程中的重要参与者。他们既影响了技术的发展，也是技术产品的使用者和创造者。于是，开发者经济蓬勃发展，开发者本身成为重要市场客户，企业面向开发者的一系列工作应运而生。这就是 Developer Relationship (DevRel) 即开发者关系发展的背景。

关于开发者关系的定义和详细论述不是本文要涵盖的内容，可以参考我此前的文章《开发者关系简明指南》和《开发者体验的基础设施》，以及 Richard 翻译的《开发者关系：方法与实践》^[1]。

本文讨论的是开发者关系工作，作为商业公司的一个职位，可以采取的工作成果衡量指标。

虚荣指标

在循序渐进的讨论可行的衡量指标之前，我先介绍一下最常见的错误：虚荣指标。

虚荣指标是《精益创业》提出的概念，指的是反馈表面数据的指标。这些指标往往数据量级很大，看起来效果很好，但是唯独不能告诉企业指标对应的具体价值。

典型的虚荣指标包括点击量和下载量，放在如今开源运动盛行的开发者关系工作上，还有软件代码仓库的 star 数等等。

这些指标共同的实际问题在于信息量太少。例如要做 star 数的指标，我们做过去几年中反复看到，被分配此项任务的运营人员用小礼物在各式活动现场以扫街地推的方式引诱开发者点击 star 按钮。对于单纯的下载量指标，我很清楚自动化流水线会对此产生多大的噪音，以至于使用这一指标的团队完全无法从一个每月下载几万到几十万的数据当中得到任何有用的信息。

信息量太少的原因是行为太简单或者说成本太低。任何一个路人，即使不是开发者，也可能为了小礼物而点击 star 按钮，或许他点完 star 拿了礼物，还会顺手再按一次取消。不加区分的页面点击量和下载量也是如此，除了作为某种谈资，很难指导开发者关系工作的开展。

Star 数这个指标没什么额外的变化空间，唯一能想到的价值是在做广告宣传时跟同类产品做比较，给到一个虚假的直观印象。但是，页面点击和下载行为是可以通过一些精细化的分析来增强的。

针对页面点击行为，简单的有 Google Analytics^[2] 分析点击来源的不同地区、不同源网站，分析各个页面的跳入跳出率。复杂一点的有 ReadMe^[3] 做的访客全路途分析，甚至集成到 API 页面调用和结果反馈。在数字指标以外，类似 Vercel 和 GitHub 的官方网站尤其是文档，都会添加交互反馈的小组件。这些指标或组件的目的都是优化网站内容的组织呈现，改善用户访问体验。

针对下载行为，主要增加信息量的途径是区分下载的来源和目的，尤其是：

• 具体下载了什么构件？

• 下载来自什么地区？哪些公司？

• 手动下载还是自动化流水线下载？

Scarf.sh^[4] 试图提供基于下载量的数据分析，不过这个工作还在探索当中，并没有被证明是实际有效的。同时，Scarf.sh 增强下载量数据的方式，需要引导用户通过 Scarf.sh 提供的 Gateway 下载构件，这一点并不容易做到。

实际上，Google Analytics 能够采集到丰富的信息，依靠的是页面访问 URL 中带上 utm 系列参数等。这个方向往下做，总会涉及到需要用户配合提供信息的种种问题，例如用户拒绝提供、信息伪造等等，甚至可能触犯某些地区的信息安全法规。

市场声量

虽然上一节的后半段我讨论了改造“虚荣指标”使得它们产生某种价值的基本方法，但是这些简单行为组成的指标仍然不适合作为开发者关系工作开展的北极星指标。北极星指标也叫唯一关键指标，应当牵引整个开发者关系工作的开展方向。

开发者关系工作含义广泛，某种程度上是目前面向开发者应当开展的工作尚未进入分工而产生的一个笼统的指代。它可以涉及开发者营销、开发者布道、开发者技术推广、开发者技术支持、开发者体验、开发者培训、开发者成功、开发者社群运营和开发者关系项目管理等等。

这其中很大一部分工作跟市场工作相关。例如，公司推出的软件服务或开发工具应当被开发者所认知，应当促进开发者的使用。这就需要有足够多的人谈论公司推出的技术产品，从而引出技术产品的市场声量这一衡量指标。

然而，市场声量指标的一大难点是缺乏统一的定义，如果把它又定义成为单纯的点击量或阅读量，就落入了虚荣指标的陷阱当中，而且容易牵引出变形的运营动作。

最简单的一个市场声量数据就是 Google 指数^[5]，但是在如今的自媒体多媒体传媒时代，单纯看 Google 指数很容易掉进坑里，尤其是当项目刚刚起步的时候，很少有开发者是通过 Google 进入到你的范围的。

某些细分领域有成熟的市场声量定义，例如数据库领域的 DB Engines 排行榜^[6]。它详细地说明了分数的计算因子^[7]，同时提供了细分领域的排名。重要的是，数据库领域内部对比和用户选型时，真的会把 DB Engines 作为一个参考指标。对于一个新兴的数据库软件来说，可以先确定自己所处的细分领域，主要的竞争对手，在多长的时间内要超越哪些对手或者进入到前几名的位置。

其他领域如果没有类似的市场声量指标，可以参考上面提到的计算因子列表自己定制和对比主要竞争对手。这其中我认为最有价值和能够牵引其他工作的渠道，是 Twitter 的提及次数或 HashTag 引用次数。因为这个指标的生成方式对应到了具体人的具体行为，从而具有产生化学反应的可能。这一点在介绍另一个指标模型时会展开。

除了跟竞争对手横向比较，市场声量指标还可以在私域做纵向比较。

目前，市面上有着 Orbit^[8] 和 CommonRoom^[9] 等社群工具能够收集技术产品相关社群的私域行为数据，拿到数据以后可以自定义市场声量算式并做不同时间点的纵向比较。同样，这些指标背后的每一个行为在这个模型下是可以溯源的，根据聚合指标的变化情况，可以开展影响对应原始行为的开发者关系工作。

最后提醒两点，市场声量衡量的目标，不一定只是技术产品本身。很多时候，市场声量的评估要跟具体的市场营销动作相结合，尤其是跟今年主推的市场概念相关联的声量。进行横向对比时，也不一定是只在竞争对手产品这个粒度上做全域比较，进一步细分领域和平台能够更精确地衡量工作效果。

成员数量

开发者关系工作本身是面向开发者的，其核心工作方式是帮助开发者利用技术产品取得成功，从而实现技术产品自身的成功。这项工作围绕开发者开展，自然也应该是以人为本的。于是，定义好技术产品相关社群后，社群成员数量就是一个很好的北极星指标。

这个指标在几年前就被 Apache SkyWalking 的作者吴晟使用。他当时在不同场合使用 SkyWalking Contributor 的数量来替代 Star 数介绍项目的健康情况和发展情况。

当然，对于商业公司当中的开发者关系工作来说，开源软件代码仓库上的 Contributor 很可能不是工作的重心。这主要是因为公司技术产品的核心代码未必开源，或者开源核心后主要开发工作实际由公司员工负责，在企业软件工程的模型上套一个开源协同的模型，且不说实现起来并不容易，实际上对公司商业成功带来的价值也很难周期性地衡量。

当然，这并不是说商业开源公司都应该完全放弃开源协同的模型。实际上，良好运作的协同模式和生态发展，长期看来是公司产品技术增长和用户增长的巨大杠杆。但是作为开发者关系工作的北极星指标，它并不合适。直白点说，一旦 Code Contributor 数量或参与度成为北极星指标，很容易发生揠苗助长的运营行为，并且很容易跟企业软件工程模型发生摩擦，最后两败俱伤。

商业公司当中的开发者关系工作，作为其北极星指标的社群成员数量，应该是更广阔的相关社群当中的参与者。这里的参考模型仍然可以从 Orbit 和 CommomRoom 这样的社群工具当中获取灵感。

• Slack

• Discord

• Discourse

• Redit

• Stack Overflow

• YouTube

• Twitter

• LinkedIn

• GitHub

当然，这里一定不是说技术产品的社群建设要覆盖上面所有这些渠道。实际上，对于一个刚起步做开发者关系的产品来说，先在少数几个关键渠道上取得突破，再把经验和内容传播到其他渠道上，尤其是配套的扩大开发者关系队伍来应对渠道增加后的工作量，才是一个比较健康的模式。

所谓关键的渠道，首先是即时通讯工具选定一个，论坛看人力选择一个或放弃。Twitter 必须运营，LinkedIn 和 Stack Overflow 看情况覆盖。其他单方面发布内容的渠道，视目标开发者主要获取信息的渠道和团队的内容生产能力决定。

不同类型的渠道有不同的参与者。例如 Slack Workspace 和 Discord 是加入的成员，Discourse 是注册会员，各种社交平台是关注的人和参与讨论创作内容的人。在定义北极星指标时，可以先把一些低成本的行为排除出去，计算一个笼统的社群总体人数。然后再看各个渠道进来的人具体的行为，划定一个基准定义活跃社群成员。

在一刀切的统计全渠道社群成员数量之外，进一步改良北极星指标的方式就是从这些社群成员当中发现真正可以促进公司商业成功的人。这就是下一节要讨论的指标。

DevRel Qualified Leads

我没有为 DevRel Qualified Leads (DQL) 找到一个合适的翻译，直译下来这是“开发者关系认证的潜在客户”，但是不如英文直观地表达它的意思。

DQL 的概念大致是 DevRel Qualified Leads: Repurposing A Common Business Metric To Prove Value^[10] 博文提出的。下面讨论的时候我会大量引用这篇文章的内容。

首先说明一点，在技术产品的社群刚起步的时候，实际上社群成员的人数非常少，如果你在这时使用 DQL 指标，就会进入跟使用 Code Contributor 作为指标类似的问题。不是说他们不好，而是在社群起步阶段，这些人可遇不可求。早期能够成为某种“潜在客户”的人，一定有某种特殊性或巧合性，而不是某个策略带来规模化效果的一部分。

直白点说，社群规模小的时候，定这个目标可能完不成，或者为了完成牵强附会。即使在开发者关系工作顺利开展的情况下，往往几个季度也只有个位数 DQL 出现，而且其出现往往很不规律，把它作为北极星指标会打乱开发者关系工作的方向。只有社群初具规模以后，DQL 才能通过一定的内容生产和运营动作来产生。

当然，即使在社群规模小的时候，也可以把 DQL 作为某种补充指标来引导社群人数增长时具体关注哪些人，实行哪些后续动作。

我们先阐明 DevRel Qualified Leads 的含义。

所谓的 Leads 在市场营销领域内是被广泛理解的。在一次市场营销活动中，目标对象往往会被邀请填写某种表单或者登记自己的相关信息。一旦你在这种场合登记了自己的信息，甚至有一些具体的期望或反馈，那么你就是这家公司的市场合格潜在客户。换句话说，市场团队制作了有意思的内容，吸引潜在客户登记信息。然后，他们审核这些信息，确保潜在客户符合公司的标准或期望，然后将这些信息交给销售团队。销售团队会在未来与这些潜在客户联系。市场团队由此完成了他们填充销售流水线的工作。他们不负责确保潜在客户真的成为客户，这是销售团队的责任。

把这个概念移动到 DevRel 工作当中来。

当然，这不是说 DevRel 团队要有销售指标。前面提到过 DevRel 的核心工作方式是促进开发者成功，这是一种真诚的人际关系。如果直接跟销售指标挂钩，那么 DevRel 的工作会一下变得非常混乱难以开展。因为已经有市场营销团队定位在填充销售流水线上，这不是 DevRel 的工作，而将金钱关系直接带入到开发者关系当中是不持久的：某些公司在过去几年中实际上是在期待用几个小礼品换取开发者的技术选型偏好或大量时间投入，这是非常荒唐的。

Leads 这个概念在 DQL 指标模型当中指的是能够以某种方式为公司做出贡献的人，而不一定是潜在客户。

再次回到 DevRel 的核心工作方式定义上来：帮助开发者利用技术产品取得成功，从而实现技术产品自身的成功。商业公司要从这个模式当中获益，需要有人从开发者角度考虑问题，理解什么是开发者成功，达成这个目的需要如何动员公司各个职能部门的力量。而在现有商业公司架构当中，通常没有一个部门会以这种方式考虑问题。

这就是 DQL 引入的契机：DevRel 团队从开发者角度考虑问题，告诉各个职能部门如何与产品社群当中的开发者合作，最终“以某种方式”为公司带来利益。

下面举几个具体的例子。

市场部门

面向市场部门的常见 DQL 是案例或用户创造的内容。

华为云是 Kafka on Pulsar (KoP) 的早期使用者和合作者。KoP 是 StreamNative 推出的一款基于 Apache Pulsar 系统的兼容 Apache Kafka API 的技术产品。在华为云成功使用 KoP 实现自身需求之后，StreamNative 与华为云开发者共同创作并发布了 From Kafka to Pulsar: Creating A Comprehensive Middleware Platform to Power HUAWEI Mobile Services^[11] 博文。此文向大量观望 KoP 技术的开发者证明了这项技术确实是可行的，为该产品的市场营销做出了直接的贡献。

类似地，StreamNative 在 Flipkart^[12] 和 Discord^[13] 顺利上线之后，也分别推出了专题分享，证明公司的技术产品在电商领域和在线学习技术方向上是可行的（Discord 的场景是泛化的在线学习，而不是核心业务逻辑）。

如果缺少与开发者的深入沟通，这些用户故事很可能沦为一个简单的证言，即“我们用了这个产品挺好的”，但是说不出具体的技术挑战和应用场景。开发者们看到“相互认证”式的市场营销，很难对技术产品本身产生信心。

产品部门

面向产品部门的常见 DQL 是使用反馈和 Beta 测试。

TiDB 的用户论坛 AskTUG^[14] 上每天都会有很多用户使用 TiDB 相关产品的反馈。当然很多反馈本身是使用姿势问题，论坛在发展出良好运作的版主制度以后成为一个志愿的 TiDB 支持前线。但是也确实有一些产品反馈是产品本身的设计缺陷或者存在优化空间的地方。TiDB 相关产品大多有从用户论坛上反馈出来的问题。

PingCAP 的社群团队建立起了版主制度，让 AskTUG 成为一个能自服务解决问题的论坛，而不用大幅占用内核研发的时间解答用户问题。这是用户能够提供足够使用反馈的前提。否则一个论坛问问题没人回，那么根本就不会再有用户参与，遑论从中得到有价值的产品反馈。进一步地，该团队可以建立起用户反馈问题的报表，以及确认是产品部门待解决问题的清单，推动用户开发者实际参与到改良产品的流程中来。

当然，PingCAP 的社群团队也不会忘记可以引导开发者参与 Beta 测试，例如 TiDB v7.1.0 荣誉体验官^[15]活动就是一个例子。

同样有送礼品的环节，PingCAP 送出的奖品比起换赞的量级所能承受的小礼品要高级许多。与之相对应，作为这个“荣誉体验官”所要做的工作也比点个 Star 要复杂，但是确有指导手册和技术讲解的支持。PingCAP 没有期待参与测试体验的开发者此后就一定会选型 TiDB 到线上环境，也没有期待他们会投入额外的时间做测试指导手册要求以外的工作。因此，奖品和交换而来的产出是相对应的。而这个过程当中参与的开发者总之是花了时间了解 TiDB 等产品，那么从长期主义的角度来说，他们会投入更多时间就是有可能的，同时选型时也至少对 TiDB 有更全面的了解。

研发部门

面向研发部门的常见 DQL 是报告缺陷和修复问题。

如果是开源软件，这个问题可能有 Contributor 会直接解决。否则至少用户能够提供出现问题时的环境配置和复现步骤，这些对于研发部门来说都是重要的输入。

一般而言，软件产品刚开始开发的时候，研发部门的开发者们自己就能够处理外部开发者进来的输入。此时往往也不会有太多的报告缺陷和志愿修复问题的人。但是随着软件产品走向销售轨道，研发部门需要花更多的时间解决客户问题，这种来自于社群开发者的声音就很容易被忽略。而且早期由研发部门经验丰富的开发者亲自指导问题掩盖的信息沟通问题会快速显现，尤其是随着软件变得日益复杂，所有想要报告缺陷和修复问题的人都缺乏相关的知识正确推进事情解决。

DevRel 团队能够改善这个状况。我帮助了来自丹麦的开发者完成 Apache Pulsar C# 客户端的自动发布，完善了 API 文档和发布文档。我帮助了 pulsar-rs 的开发者取得 StreamNative 维护者的代码评审，并最终合并和发布他们提交的补丁。

这个过程当中主要的挑战是 DevRel 团队需要有建立起信赖的研发团队合作者，或者本身就了解一些具体的研发知识。否则只是充当一个传声筒，像个监工一样催促研发部门的开发者“处理”这些输入，而不能说明这些输入具体做了什么，有什么价值，需要他们提供什么帮助，那么他们就会像忽略开发者的邮件提醒一样忽略掉 DevRel 团队传来的同样没有额外附加值的信息。

商业拓展

面向商业拓展的常见 DQL 是集成和伙伴关系。

TiDB 的 Flink CDC Connector 维护在 Ververica^[16] 的仓库上，StreamNative 维护的 pulsar-spark^[17] 集成得到了 Databricks 开发者的参与。这些合作伙伴开发集成的主要动力，是他们的用户希望能够将这两个应用结合起来用。

Airbyte 的成功高度依赖第三方开发者创造的集成。一个 DevRel 团队能够跟集成开发者保持沟通，确保软件提供的扩展点是易于实现的，相关文档是齐全的，甚至有开箱即用的测试套件来支持集成开发。所有这些事情并不都需要 DevRel 团队的成员实施，但是 DevRel 团队能够将这些工作的必要性和优先级说清楚，以推动它们得到公司的投资并最终能够交付，从而帮助集成开发者和依赖集成的应用开发者成功。

人才招聘

这个不用多说了。尤其常见于商业开源公司，从开源社群当中接触到的完全懂这一行的开发者，如果他认可这项技术，那么就很有可能会加入公司一起创造。许多有名的商业开源公司都是由此聚集起来最早的一批员工。

潜在客户

回到 Leads 在市场领域当中的含义，DevRel 团队当然也能从开发者关系工作中发现潜在的销售线索。实际上，我工作过的某公司的相当部分订单，就是开始于甲方开发者从某个社群渠道接触到公司的技术产品。

结语

上面介绍了几个可用于开发者关系工作的衡量指标。应该说，目前 DevRel 的工作缺少一个行业范围内通用的单一指标。从事这一工作的人要么过分强调长期主义，以至于表现出来的就是在任意期限内都没有可交付的成果；要么模糊的说 DevRel 的指标要看情况，实际是做了什么就说是什么。这都对 DevRel 工作取得广泛认可和推广产生了阻碍。

上面除了作为反面教材的虚荣指标，我所罗列的也不是某个单一指标。但是这些指标之间是有联系的。从 DevRel 工作的独特价值来说，DevRel Qualified Leads 是可以作为最终的北极星指标的。但是从我实际开展 DevRel 的经验来看，如果社群刚开始建设，为了保证 DQL 准确定义了为公司做出贡献的阈值，使用社群成员作为北极星指标是一个比较好的替代。而市场声量是特定在开发者营销方向上一个能够用于横向比较的指标，如果当前公司的优先事项是提高开发者的认知度，提高公司技术产品和理念的触达，那么可以使用这个指标来作为牵引。

相比较而言，DQL 着重体现了 DevRel 工作者在催化公司各个部门与开发者的连接上能够为公司带来收益的独特价值。DevRel 的工作经常与社群工作联系在一起，因为帮助开发者成功，催化开发者之间、开发者与公司部门之间的链接，本身就是在建立一个开发者社群。

关于这项工作开展的具体细节，除了上面提到的《开发者关系：方法与实践》，还可以参阅 Jono Bacon 的《People Powered》^[18]，以及关注 Jono Bacon 的 Youtube 频道^[19]。如果有可能，我也会在接下来的时间里详细介绍上述 DevRel Qualified Leads 指标的具体实现方式和其中的细节。

参考资料

[1]

《开发者关系：方法与实践》: https://book.douban.com/subject/36337667/

[2]

Google Analytics: https://analytics.google.com/

[3]

ReadMe: https://readme.com/

[4]

Scarf.sh: https://about.scarf.sh/

[5]

Google 指数: https://trends.google.com/trends

[6]

DB Engines 排行榜: https://db-engines.com/en/ranking

[7]

计算因子: https://db-engines.com/en/ranking_definition

[8]

Orbit: https://orbit.love/

[9]

CommonRoom: https://www.commonroom.io/

[10]

DevRel Qualified Leads: Repurposing A Common Business Metric To Prove Value: https://www.marythengvall.com/blog/2019/12/14/devrel-qualified-leads-repurposing-a-common-business-metrics-to-prove-value

[11]

From Kafka to Pulsar: Creating A Comprehensive Middleware Platform to Power HUAWEI Mobile Services: https://streamnative.io/success-stories/huawei-device

[12]

Flipkart: https://streamnative.io/success-stories/flipkart

[13]

Discord: https://streamnative.io/success-stories/discord

[14]

AskTUG: https://asktug.com/

[15]

TiDB v7.1.0 荣誉体验官: https://asktug.com/t/topic/1006975

[16]

Ververica: https://github.com/ververica/flink-cdc-connectors/blob/master/docs/content/connectors/tidb-cdc.md

[17]

pulsar-spark: https://github.com/streamnative/pulsar-spark

[18]

《People Powered》: https://book.douban.com/subject/35531548/

[19]

Jono Bacon 的 Youtube 频道: https://www.youtube.com/jonobacon