前段时间，在社交群见证了一场姐妹情谊的死亡，于是callback了跟阿姨们相处时的回忆——我把“在没有死亡的关系里，明明已经吵过的话题，反复拿出来重新争吵，看上去是在吵当下的话题，但所有的心结都来自于一个历史事件的行为”称之为“社交鞭尸”

鞭尸的爽在于，可以不负责任地释放情绪。且可以通过调整“吵架赛道”的方式维系这种不平等的身份。对方在谈论解决方案时，鞭尸者可以回到情绪价值上吵；对方也被点炸开始释放情绪的时候，鞭尸者可以马上变得理性指出对方正在无理取闹；当两个人好不容易吵到同频的事情上时，鞭尸者则可以把问题引导到没有解决方案的哲学命题上。“社交鞭尸”享受的就是持续保持上位者的身份以获得被关注、拉扯感、甚至是自我圣洁化。

好在结束关系可以避免社交鞭尸。甚至被鞭尸的人可以通过煽动“弱者有理”的情绪，让自己重新回到道德制高的位置。

今早遛狗，观察到了另一种更可怕的“鞭尸”——血脉鞭尸，或者说是血脉凌迟。小姑娘骑着滑板车跟奶奶散步，奶奶推着的是家里的男宝二胎。小姑娘手里提着一个玻璃制品，看样子她非常喜欢。结果她还是把它摔坏了。接下来的时间里，奶奶开始对这个泣不成声的孙女持续“鞭尸”。正好遛狗，就听了下面的对话。（感谢苹果耳机的通透模式）

“每次给你买的礼物你都不珍惜，几天就玩坏了。”

“奶奶给你买礼物，是多希望你长大之后拿出来再看，那个时候会说这是我奶奶买的礼物，我长大了要报答她。”

“爸爸妈妈给你买的礼物也是，玩几天就不玩了，到最后也扔。”

“奶奶出门玩都想着你，要给你带这样带那样，你出去玩的时候有想到过奶奶吗？”

“妈妈买的礼物你就喜欢，你就要放在玻璃柜里，奶奶买的礼物拿出来玩坏了就玩坏了。”

“听话也是，奶奶说的你都不听，都听妈妈的。”

显然，老太太有点刹不住车了，从礼物被摔，已经上升到了婆媳关系。小姑娘没办法反抗，只能哭。哭到没办法再继续鞭尸下去——因为他们要回家了，于是奶奶开始安慰小姑娘。这一安慰，小姑娘哭得更惨了。

整个过程我还观察到一个细节，婴儿车里的弟弟，听到奶奶鬼诵的全过程，在手舞足蹈地大笑。

家庭伦理正义警察先别着急出警，我又没说弟弟是因为姐姐被骂而开心。他还是个孩子，对吧？

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

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

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

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

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

虚荣指标

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

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

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

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

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

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

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

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

• 具体下载了什么构件？
• 下载来自什么地区？哪些公司？
• 手动下载还是自动化流水线下载？

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

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

市场声量

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

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

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

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

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

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

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

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

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

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

成员数量

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

这个指标在几年前就被 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 博文提出的。下面讨论的时候我会大量引用这篇文章的内容。

首先说明一点，在技术产品的社群刚起步的时候，实际上社群成员的人数非常少，如果你在这时使用 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 博文。此文向大量观望 KoP 技术的开发者证明了这项技术确实是可行的，为该产品的市场营销做出了直接的贡献。

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

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

产品部门

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

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

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

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

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

研发部门

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

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

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

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

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

商业拓展

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

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

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

人才招聘

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

潜在客户

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

结语

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

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

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

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

今天，在许多开源软件项目乃至任何稍带开放性的项目的宣传中，我们经常能看到营销内容包含“共建”的字样，似乎说了这个魔法的词汇，项目就能迎接纷至沓来的“共建者”，其乐融融地“一起做大蛋糕”。

然而，现实情况却是作为被营销对象的开发者日渐对这个词失去兴趣到产生反感。一眼看到某个项目营销言必称“共建”，心里就默默给它扣分拉黑甚至拉黑。共建的神话是如何产生的，为什么这个口号今天不能吸引和凝聚开发者呢？

“共建”一词的释义是：共同建设，体现共同参与，发挥自身优势和潜能，形成新的合作优势。

商业公司起初提这个词的动机，我想是成功的开源协同案例大多社群生态丰富、成员活动频繁。公司希望自己发起的项目也能一步到位整出一个人见人爱的社群，于是直接无差别宣传拉人共建，企图跨过中间阶段直达结果。

我曾经把共同创造价值作为开源社群发展的重要指导理念。为了做到共同创造价值，你需要回答潜在的用户和开发者他们能为你做什么和应该怎么做到的问题。

今天许多项目“共建”的营销内容，上来先说的是自己如何如何的牛逼，或者庆祝完成了一二三四五件事情，到底期望营销的对象来共建个啥，全凭自己领悟，其画风大致如下：

• 我出弹药，谁能帮我打下这个山头？
• 我指出这个山头，谁能自备弹药帮我打下这个山头？
• 我也不知道哪里有山头，谁能自备弹药和地图，帮我找到和打下一个山头？

一份有号召力的“共建”宣言，应当形如以下模式：

1. 一个新的产品或功能发布，期待用户给出反馈或使用测试报告；
2. 一个新的集成点已经就绪，诚邀生态项目和开发者评估并支持集成；
3. 一个新的技术难题被攻破，欢迎同领域的专家评鉴、探讨和改进；
4. 一个新的标准由权威机关提出，号召相关项目和开发者参与认证；
5. 一个新的组织或活动立项，介绍清楚纲领或目的之后招募成员。

可以看到，这些模式在包括事实的基础上，明确了“谁”是我们的营销对象，我们希望给你带来“什么价值”，期待你做“什么具体的事情”。否则，所有可以“共建”的点，在营销文案里都不存在。要么说某个组织已经成立了，但是跟我有什么关系呢？要么说某个功能已经完成并发布，那还要我共建什么呢？

这样漫无目的的“共建”营销，只会让被营销对象走向两个极端：

1. 完全不知道你要做什么，只能理解为我需要自己发现问题并解决问题，你在期待有人 freework 无偿提供 idea 及其实现；
2. 拉人头“共建”是吧？我来了，什么时候打卡发小礼物？

最后简单总结一下，社群需要成员共同建设以持续发展，但是在营销的时候，应该明确『共同创造价值』理念中的谁、为什么、做什么、怎么做的问题。否则只是喊一嗓子就坐等社群爆火共建者纷至沓来，是不可能实现的。反证假设今天真的就有一大群“共建者”出现了，恐怕你自己也不知道，他们是来干嘛的。

随着信息化和数字化的发展，传统企业的业务发展在软件的帮助下突飞猛进。软件技术日新月异，几乎每隔几年就会有全新的技术和产品颠覆过往业务开展的方式。然而，掌握前沿软件技术的人相对于全行业的需求可谓是凤毛麟角。为了规模化前沿技术的价值，越来越多的软件服务公司如同雨后春笋一样不断出现。

顾名思义，软件服务公司主要以提供高质量的软件或软件服务来提高其他企业开展业务的效率。随着软件技术日益复杂，采用何种软件服务逐渐从以往的 CTO/CIO 决策转变为不同领域的一线开发者根据自身的能力和喜好选择。因此，软件服务公司需要专门制定开发者关系的策略，以在新形势下继续赢得客户订单。

本文将以 What is Developer Relations? 网站的介绍和 Ubuntu 前任社群经理 Jono Bacon 的视频 Developer Relations: A Complete Guide to what it is, how it works, and whether you need it 为基础，讨论开发者关系将为企业带来什么价值，开发者关系的从业者到底在做什么工作，以及从事开发者关系工作需要具备什么样的能力。

开发者关系的价值

在开发者关系这个概念提出之前，企业已经有成熟的经验经营消费者群体和维护企业客户关系。然而，传统的市场营销手段，例如广发推销邮件、投放付费广告或在非技术活动上刷脸，并不能够得到开发者对企业及其产品的青睐。

越是技术氛围浓厚的领域，对 buzzword 和 lingo 越不感冒。古怪新奇的词藻包裹出的新概念或许能够吸引看客带来一知半解的讨论，但是技术开发人员如果发现包装之下的软件毫无新意甚至水平有限，那么戳破这些 buzzword 只会对软件实质的推广带来阻碍。

开发者群体是一个务实的群体，夸夸其谈并不能赢得他们的关注和支持。要想经营好开发者关系，必须理解开发者希望与人建立什么样的关系，取得什么价值，并且像一个开发者一样加入到关系当中去。这就需要一个不同于市场营销部门的专业团队来完成开发者社群的建设工作。

除了上面提到的这些必要性，经营好开发者关系，可以帮助企业打开软件产品知名度，并吸引开发者使用和参与协同开发。

众所周知，软件行业的开发者总在不断学习。但是，一个人能掌握的技能总是有限的。好的开发者关系和技术品牌，让开发者发现软件的价值，相信软件的未来，进而成为它的学习者、使用者和拥护者。公司采购软件服务的时候，一线开发者乃至技术主管和 CTO 都了解你的产品，这是最强的竞争优势。

阿里巴巴的强势站台和紧接而来的技术推广及案例分享，让 Flink 一跃成为有状态流处理领域的明星。再加上 Flink 本身过硬的技术水平，很快在国内就替代了 Storm 和 Spark Streaming 等软件成为事实标准。反观国外，Flink 生态的知名度与 Databricks 的大数据湖生态相比仍有明显差距，许多用户不知道有 Flink 这个选择，或者已经深度绑定在 Spark 的生态上，不了解如何替换整个解决方案，于是选型 Flink 的企业也就明显减少。

除了提高产品的知名度，经营开发者关系还能促进开发者参与到产品使用、生态开发乃至内核开发。

开发者应该都有过请教其他同行如何使用某个软件解决具体问题的经验，从业务怎么设计、性能怎么调优到为什么系统起不来和各种疑难杂症。开发者希望建立的关系是一种同行互助的关系，而不是单方面地被塞进一个软件，告诉他可以去用了。也就是说，开发者关系与传统营销最大的不同，就是强调交互和反馈。这种交互基于对技术和需求的理解，从一个开发者听说某个软件，到他能够真正用起来，这个旅程并不轻松。这明显不同于广播营销信息或者群发推销邮件，指望用户点击或注册就算完成任务。

PingCAP 为 TiDB 及其生态建立起了 AskTUG 论坛，刚开始时主要是 PingCAP 的员工在解答问题。随着论坛用户体系的完善，如今 TiDB 的用户已经日常相互解答问题，其中活跃的成员还会成为“版主”参与论坛治理。同时，PingCAP 发起的 TUG 企业行和推动各地发起 TiDB 本地社群，这些动作强化了 TiDB 用户的相互连接，启发了开发者之间的交流，自主解决技术问题，分享案例。

分布式系统为了对接不同的业务，往往需要提供不同编程语言的客户端。云原生消息平台 Pulsar 除了与服务端相同语言的 Java 客户端，还在开发者社群的支持下提供了 C++、Golang、Python、.NET、Node.js 和 Rust 等多种客户端。其中 Golang 客户端是由 StreamNative 的开发者牵头完成的，Node.js 客户端主要是雅虎日本的开发者在维护，Rust 客户端一开始是个人作品，随后作者精力有限，就联系 StreamNative 共同维护。这种跨越不同公司组织和个人的协作，以及某一方退出以后继续维护和开发软件的“奇迹”，与主要参与者重视开发者关系，积极协调各自的需求，并解决某位具体的开发者的困难是分不开的。

ClickHouse 的主要作者 Alexey Milovidov 是一个极度活跃的维护者，他总是能够很快地回应开发者的建议和提交的补丁。参与内核开发的开发者往往一开始并不具有直接提交代码的权限，而是需要经过同行评审后由维护者代为提交。Alexey 的活跃印证了前面提到的开发者关系强调交互和反馈的观点，他的热情感染了众多开发者，带动了一大批开发者为 ClickHouse 在性能和稳定性等多个方面做出了显著的贡献。

开发者关系到底做什么

开发者关系的工作重点在于“关系”。这个关系的一端是开发者，另一端可以是软件产品、其他的开发者或者提供软件服务的公司，或者用一个词概括，就是围绕软件产品形成的社群。

为了建立、维持和强化开发者与社群的关系，开发者关系的从业者可以从内容创作、产品使用和开发体验优化以及运营社群三个方面开展工作。

不过，无论从什么方向上入手，宣传和布道都是必不可少的。这也是为什么有时开发者关系（Developer Relations）会和开发者布道（Developer Advocacy）交换使用的原因。

宣传和布道建立在对核心软件的理解之上。Pulsar 的布道师 Timothy Spann 非常熟悉消息队列和流处理生态，他能够抓住每一个可以与 Pulsar 发生联系的话题，向开发者介绍 Pulsar 的价值。例如，在 ApacheCon Asia 上 Timothy 就以 FLiPN Awesome Streaming with Open Source 为题介绍了 Pulsar + 其他开源软件组成的流处理框架。

具体的宣传手段可以是多样的，但是这种深刻的布道热情是独特的。开发者关系工作的起点，就在于是否发自内心的认同核心软件，并在各种场合向开发者介绍它，就像我在本文当中可以随时找到 Pulsar 社群的案例并向读者介绍案例及其背后的逻辑。

内容创作

数字时代，内容的复制和传播几乎是零成本的。要想高效地触达开发者，内容创作必不可少。

技术博客是一种经典的载体。TiDB 2016 年的三篇博文《说存储》《谈调度》《说计算》直到今天仍然是分布式数据库系统入门的优质材料。PingCAP 也凭借着早期的技术内容输出，包括 TiDB 和 TiKV 的系列源码阅读，得到了大量开发者的青睐。许多后来实力强悍的新开发者，在校期间就通过这些文章接触了 TiDB 的技术，进而加入 PingCAP 公司实习。无论是留在 PingCAP 工作，还是后来把 TiDB 的知识带到了其他的企业当中，都是 TiDB 社群开发者策略的成功。

出版书籍是这一方向的另一种手段。如今，流行的软件没有一本《权威指南》都有些不好意思。比起单独的一篇篇博客，书籍是系统地介绍软件产品或背后理念的优质载体。例如，从《流式系统》接触流处理的开发者，自然会对 Google Dataflow 和 BigTable 更加熟悉。如果在线上要选择一套流处理系统来实现业务，他也更有可能尝试用 Dataflow 的模型来解决问题。

多媒体时代的内容当然不止文字。Materialize 在 YouTube 上上传了一系列与其他系统集成的业务案例，完美匹配和开发者在使用一个软件的时候最高频的问题“我要如何用软件 X 实现 Y 功能”。不同于文档往往体系化地记录了所有的情况，案例视频为开发者介绍了完成一项工作的 happy path 是什么。很多时候，开发者只有先快速地启动业务，才有可能稍后再去针对具体的定制需求和问题寻求答案。如果开发者一上来解决不了自己的问题，或者发现先要读散落在各地的十几处几十处的文档才能搞明白怎么开始，那么这个软件就会被开发者搁置考虑甚至直接抛弃。

Databricks 在此基础上更进一步，和在线教育平台 edX 合作推出了一系列 Spark 教程，教授开发者使用 Spark 解决各种各样的大数据分析问题，并见缝插针地推广 Databricks 的产品，告诉开发者直接使用产品可以降低他们的工作量。无独有偶，阿里巴巴牵头 Flink 社群录制了几个系列的 Flink 学习材料，从入门安装启动使用，到进阶调优原理剖析，再到场景化的实例分享，覆盖了不同开发者群体的需要。

内容创作的基本点是对品牌的认识，也就是主打的方向和核心软件解决的主要问题。例如，Pulsar 一直将自己定义成云原生消息平台，“云原生”强调了 Pulsar 在基础软件上云时代的适应性，拥有云服务的全部优势，同时还是云中立的，“消息平台”则体现了自己支持消息队列和消息流的主要作用，同时暗含了统一处理所有消息的技术优势。再例如，Flink 主打的是有状态流处理，所以能够抓住 Flink 流计算能够支持丰富的状态，并且在此基础上还能容错和提供恰好一次语义，才是一个好的 Flink 布道师应该有的认识。

从内容想要达到的目的来看，可以分成长期有效、做好 SEO 的内容，比如前面提到的“如何用软件 X 实现 Y 功能”。例如 Bytebase 团队写作的如何在 Docker 环境里启动 ClickHouse 就是 Google 搜索的第一个有效结果，甚至超过了官方文档。这样开发者在解决了自己的问题之后，就有可能关注到 Bytebase 提供了管理 ClickHouse 数据库的能力。既然这个团队对 ClickHouse 的使用如此了解，那么不妨尝试一下它们的软件产品能不能改善我运维 ClickHouse 的体验。

另一类内容是版本发布、功能发布类的短期内容。这类内容的要点是说清楚新版本、新功能的核心价值，解决了以往的什么问题，如何升级到新版本或者用上新功能。如果有合适的主题会议，比如 Pulsar 的 Pulsar Summit 或者 Flink 的 Flink Forward 这样的，那么新版本和新功能也很可能在会议 keynote 上发布，并展示 show case 来赢得第一批用户。

不同于面向消费者的市场营销的点击或注册即可的短路径，开发者关系的内容创作和发布只有能让用户成为社群的一部分才算成功。而到开发者由于内容的影响，在某个技术选型和采购决策上为软件产品带来收益，整个过程就更长了。因此开发者关系的成果衡量不是一时的，也不是点击量一类的指标能够很好的体现的。社群成员的增量，参与程度和下载、使用的情况，会是比较好的关注指标。

运营社群

在开发者关系的工作单独被考量之前，往往社群运营就涵盖了所有开发者关系的工作。不过，运营这个词本身很难包括内容创作、体验优化和协同开发的内涵，所以现在也被单独拿出来讨论，包括组织活动、治理社群平台和收集用户反馈等工作。

组织活动是维持和强化开发者关系的重要手段。对于一个软件社群的活动来说，除去组织任何活动都需要的安排场地和寻找参与者等工作，还有一件重要的事情，就是让参与的开发者强烈的感受到这是一个关于某软件的活动。Apache、Perl 和 PostgreSQL 这样的成熟社区在记录如何组织一场活动的时候，重点也是强调这个问题。参与者必须清楚的知道他在参与的是 Apache 的活动，是 Perl 的活动，是 PostgreSQL 的活动，这个品牌的印象才能被强化，活动当中发生的事情才能与品牌相结合。

Pulsar 社群在疫情期间有段时间每周都举办一次 TGIP (Thanks God It’s Pulsar) 活动，由核心开发人员或者标杆用户分享技术知识和使用经验。固定的时间和高质量的内容，以及极具特色的活动名称和主题，极大地帮助了 Pulsar 品牌的传播和吸引开发者关注活动。

除此以外，社群运营还在最大程度上维持了与开发者的日常联系。面对社群成员的冲突和摩擦的时候，社群运营如果保持了其他成员的日常联系，往往能够居中调停消除误会，或者对明确违反社群守则的成员，也能清楚地援引规则进行封禁。社群是由人组成的，社群的问题归根结底是人的问题。社群运营是在一线和开发者打交道的群体，因此他们就是维护开发者关系首当其冲的负责人。

渠道的建设和维护是难的。太多的渠道会分散开发者的注意力，导致每个渠道上都没有足够多的关注度，提问者得不到反馈，资深成员疲于追踪诸多渠道上的信息，最终会让社群的活力日渐萎缩。在中国，还要专门考虑即时通讯也就是微信群和钉钉群长期存在带来的沟通习惯。不拉微信群实在是瞧不起这个国民应用，但是动辄十几个五百人群，管理负担不小，能带来什么价值真不好说。

保持与开发者的日常联系，能够逐渐取得开发者的信任。有了信任基础，开发者才会愿意反馈在社群当中遇到的问题，尤其是以往以为不会得到回复的问题，或者批评意见等比较敏感的问题。社群运营需要收集用户的反馈，并且理解反馈代表的实际问题，充当社群成员与公司，或社群成员与其他社群成员之间的桥梁。这也要求开发者关系工作需要理解开发者的文化和诉求，否则只是简单地搬运反馈，只会让自己成为一个两头受气的传声筒，而非促进沟通的协调员。

由于身处社群当中，直接与其他社群成员接触，社群运营还会处理跟生态合作相关的工作。某些社群成员不只是个人参与，也隐性地代表着他所在的公司或组织。软件品牌的建设需要用户的站台，而站台的分量是由用户的分量决定的。KOL 和合作社群或公司的署名评论和 logo 都是这方面工作的重要产出。

此外，联合举办活动也是一种很好的合作手段。过去两年间，Apache 项目在中国的联合 Meetup 数不胜数。对于软件服务公司来说，尤其是基于开源软件的软件服务公司，客户购买的从来就不是一个二进制文件，而是一个完整的解决方案。通过联合举办活动来启发不同社群的开发者将两个或多个软件结合在一起产生解决方案的灵感，能够让潜在的客户看到购买软件服务提供的价值和无穷的可能性。

优化体验

如果说内容创作能从技术写作迁移经验，社群运营能从用户运营迁移经验，那么优化产品的使用和开发体验，就需要实打实的开发者视角和开发经验了。

围绕软件产品的体验可以分成两种，第一种是直接使用软件或解决方案的用户体验，第二种参与到软件本身开发的开发者体验。

开发者关系范畴下的用户体验，用户本身也是开发者。如果像是 iPhone 和 iPhone 的用户构成的社群，那是不同的工作。开发者使用软件，往往是为了实现自己的业务逻辑，我们可以把这种开发者称为应用开发者。

以 Kvrocks 为例，一个典型的应用开发者旅程，可以是他想要寻找一个 Redis 接口的持久化存储系统，通过搜索引擎找到 Kvrocks 以后，他首先会阅读项目文档，试图把系统跑起来，确认 Redis 常用的功能能够跑通，然后再将自己的业务从 Redis 迁移过来。在这个迁移的过程中，可能会碰到各种疑难杂症。于是，他首先试图从文档里查找答案。如果找不到，从 Google 或者 StackOverflow 再找。如果还是找不到，他可能会在 Discussions 论坛或者邮件列表提问。如果问题解决了，业务逻辑跑起来了，那么他会进一步调优或者添加其他逻辑，如此往复，直到基于 Kvrocks 和其他软件完成自己的业务需求。

上面描述的是一种相对流畅的开发者体验，其实每一步都有可能出问题。例如，搜索引擎优化做得不好，用户可能根本就找不到这个软件；项目文档缺失或不准确，给到用户软件不可用（破窗）的印象，用户可能根本不会也无法尝试；遇到各类具体问题找不到答案、不知道上哪问问题或无人理睬，如果软件源代码不可得，或者用户无法理解代码逻辑，那么他只能寻找其他的替代品。

可以看到，好的用户文档是关键。文档详略得当，结构清晰，能够解决用户问题，则用户继续使用和扩大使用都是大概率事件。

MySQL 和 PostgreSQL 的参考文档非常齐全，绝大部分使用问题都可以在文档当中找到答案，甚至从中可以理解关系数据库是如何建模和解决问题的。除了参考文档，代码示例和快速开始的脚手架也非常重要。Spring 是其中的佼佼者，它提供了用 Maven 或 Gradle 十五分钟创建一个 Spring Boot 项目的示例，对于所有常见的软件，都提供了最小集成案例。Apache ECharts 作为网页图表绘制库，有一个包含了所有常用的图表的样例及其代码的文档，覆盖了网页图表制作的绝大多数场景。用户不需要阅读详细的参考文档并自己得出如何实现自己需求的方案，而是把现成的方案直接拿来用，再针对性的改一改配置就可以满足需求。

不过，文档很难解决用户在种种环境因素相互影响下出现的疑难杂症。社群生产的问答和博客往往是解决这类问题的补位材料，而社群运营的论坛等渠道则是回答随机问题的最后兜底机制。开发者关系工作者需要发现目前影响开发者体验的主要问题，并主动解决问题。我们虽然把开发者关系的工作内容分成几个部分，但是它们显然是紧密联系的。开展开发者关系工作时，几乎总是要在这些角色当中来回切换，既需要发现问题，也需要去解决问题。

当然，用户体验从根源上还是一个软件质量的问题。如果软件本身不怎么出问题，不用手动调优也有不错的性能，出现问题报错信息清晰地指出问题甚至提供解决方案提示，那么需要用户读文档或者进一步寻求帮助的情形就更少了。这是软件易用性方面的提升，如果你具备开发能力，那么可以直接改善软件本身的使用体验。否则，就需要准确理解开发者的需求，与内核开发者沟通改进。

应用开发者当中有一类比较特殊的群体，我们可以称之为生态开发者。不同于其他用户直接使用软件搭建业务，生态开发者关注不同软件之间的生态连接。例如，Airbyte 社群就聚拢了一大批开发对接不同数据系统的连接器的生态开发者。用户在使用软件搭建业务的时候，几乎不可能只使用单一的软件。例如大数据生态下往往需要同时使用多个软件完成数据的导入和不同场景的分析，即使真有分久必合的一天，前端的展示和应用的监控也是一个完整系统不可分割的一部分。

生态开发者同样需要完善的文档，尤其是用于对接其他软件的接口文档或插件文档。同样，现有的对接案例能够缩短降低开发的周期。例如，开发 SkyWalking Python Agent 时，需要文档说明 SkyWalking 支持的上报方式，同时可以参考 Java Agent 的实现方式，把基于 JVMTI 的实现手法替换成 Python 直接修改方法对象的手法，就有了基本的实现思路。而有了 Python Agent 以后，如果有人想实现 Ruby Agent 则可以直接把元编程的过程做一下语言语法的翻译就能实现。

当然，实际实现的时候也会有各种各样的挑战，这就回到了有社群平台支持的方面。不过生态开发者往往同时会碰到两个软件的问题，通过生态开发者联系起两个社群，是一种很好的合作方式。例如，我从 Flink 的高可用需求做到了 ZooKeeper 项目，又从 ZooKeeper 做到了 Pulsar 项目，再由评审 Pulsar Flink 连接器的补丁参与到 Flink 和 Pulsar 的整合。能和现有生态友好相处的软件，往往才是开发者在做技术选型的时候的首选。

至于参与到软件本身的开发者体验，这种需求只会出现在开源软件的开源协同当中。毕竟对于闭源软件来说，连代码都看不到，遑论提交补丁合作开发。而对于源码开放的专有软件，或者虽然软件是开源协议，但是内核开发完全由一家公司控制，也不打算与其他人协作的情况，不属于开源协同的范畴，也就不存在专门讨论内核开发者体验的必要。

其实，所谓内核开发者的体验，实质上是软件工程和项目管理的范畴。如果不涉及开源和开源协同，公司组织当中一般由研发部总裁或者技术主管设计和实施即可。就算到了开源协同的环境当中，也是由开发者关系成员根据自己协调不同组织背景的开发者的经验，为参与者和维护者提供建议，或者直接参与到软件开发管理当中。

要想提供良好的开发者体验，可以抓住两个基本点。第一个是确定开发讨论的渠道并保证问题回答的速度和质量，第二个是把开发过程当中积累的共识和知识总结成开发文档。细心的读者可能已经发现，优化开发者的体验和优化用户的体验在结构上是相似的。只不过开发者有开发者喜欢的渠道，例如邮件列表和 GitHub 胜过微信群。开发文档会记录软件发布的流程，提出和处理 issue 和 pull request 的方法，代码风格的约定，以及内部实现的解析等等。

开发者关系需要会什么

前面介绍开发者关系都会做什么的时候已经暗含了需要掌握的技能，这里做一个集中的罗列。

首先，要想经营开发者关系，必须了解开发者文化，如果软件是由开源协同的方式制造出来的，那么还需要了解开源文化。了解文化不需要你本身就是开发者，当然，如果你是本领域的开发者，理解起来会快上许多。无论你是否是开发者出身，都应该谦虚地了解社群当中的开发者的需要。一般而言，开发者关注的就是写代码，或者说成制造软件和解决问题。好的开发者往往是问题导向的，他们希望通过写代码解决自己碰到的问题。如果在解决问题的过程中能够有人一起交流，问题解决以后有人分享喜悦，有同行给予认同，那就更好了。

其次，一个好的开发者关系工作者必然是了解技术的。当然，你不一定需要是个技术专家，也没有人能够在所有方面都是技术专家。但是起码你需要掌握你所宣传和布道的软件的核心知识，理解相关的技术是什么，解决了什么技术问题。例如前文提到的 Pulsar 是一个云原生消息平台，我就做出了具体的解释。这不是背诵定义或者话术，而是你真的理解每句话是什么意思，并且相信它的价值。要说那种布道最为打动人心，那只能是自己也完全相信的真诚的布道。

再次，开发者关系是与人打交道的工作，你需要知道如何与人沟通。这不仅仅是如何遣词造句的问题，还是清楚每个开发者包括自己的角色的问题。知道什么问题什么时候可以找谁，应该找谁，面对不同人的提问和评论应该如何反应，这些知识通过长期观察和思考得出以后，努力使之成为社群的共识，这样才能够根本上提升社群沟通的效率。

最后，你应该懂得如何讲好一个故事。模仿是人的天性，讲好一个故事，激发开发者成为故事当中的角色，是一种很稀缺的技能。我在介绍为什么开发者应该参与到 Apache 孵化项目的时候，就讲了还是大学生的 @PragmaTwice 通过积极参与成为 Kvrocks 的 Committer 并基于 Kvrocks 实践自己的 C++ 技能的故事。那些希望参与工业级软件开发，磨炼自己技艺的在校生和应届生会受到这个例子的感染参与进来。

这些技能的目的，是支持开发者关系工作者解决开发者在使用软件和参与开发的过程中可能遇到的种种问题。内容创作能够提供案例，社群运营鼓励互助解决问题。整体提升开发者体验也是这个目的。关注问题解决能够让开发者关系工作者脚踏实地。你不需要把软件吹得天花乱坠，能解决所有问题，你只需要解决目标开发者碰到的问题。

工作建议与参考资料

What is Developer Relations? 网站为开发者关系工作者提出了七条建议。

1. 展示胜过讲述。尽快让开发者使用软件，而不是喋喋不休地吹嘘它有多好。如果开发者能用起来并且确实解决了问题，他们会付出更多的时间仔细了解。
2. 功能胜过利益。同样的，你应该告诉开发者能用这个软件做什么事情，而不是试图说服开发者能得到什么利益。开发者会自己评估软件的价值。
3. 提供真正的帮助。关注问题解决，让用户文档、样例视频和代码能够轻松地被开发者找到。让开发者能够轻松地向你寻求帮助。
4. 直接一点。大多数开发者都是非常务实的人，直截了当地沟通能够快速推动问题解决并产生真正有价值的内容。
5. 考虑开发者工作以外的需求。不是每一个开发者都迫切地要在工作当中使用你的软件，许多开发者有成长的需求和自己的项目。如果开发者在参与工作上的选型决策之前已经了解你的软件，那么它会更有竞争优势。
6. 重复利用创作的内容。多媒体时代下相同的内容可以在不同的渠道以不同的载体重复利用，这能够大幅提高创作成果的传播效率。网站建议尝试“推特→博客→视频→演讲”的流水线。我自己就是这么做的，除了还有从演讲到文字稿的另一条转化线。
7. 提供一个可用的玩具。例如 Timothy 编写的 FLiPN 框架，它能够直接被用在生产环境。虽然可能在很多方面成熟度只能称得上是一个玩具，但是开发者将真真切切地看到 Pulsar 是怎么在一个流处理框架中被使用的。

我个人推荐 Jono Bacon 的两本著作《社区运营的艺术》和《People Powered》。它们全面介绍了建设一个社群所需关注的主题，以及如何实施一个社群战略计划。毫无疑问，这里的社群主要指的就是开发者社群。

What is Developer Relations? 网站还推荐了其他的书籍、博客和播客，我没有仔细看过，这里就不做复述，可以到网站上自行查阅。