PureNatural
commented
2 weeks ago 开发者关系（Developer Relations, DevRel）是通过双向沟通开发者与公司产品团队，构建并维护一个健康的开发者生态系统，促进产品推广、开发者支持及反馈收集的专业职能。
详细解释：
1. 什么是开发者关系（DevRel）？
开发者关系（Developer Relations, 简称 DevRel）是一种以开发者为中心的职能，旨在通过与开发者建立并维护紧密联系，支持开发者使用公司产品并提升开发者生态系统的活跃度。DevRel 的主要目标是通过双向沟通，使开发者成为产品的忠实用户和支持者，帮助公司获取宝贵的反馈，促进产品改进，并推动开发者在使用公司产品时能够得到全面的技术支持。
DevRel 的运作方式通常有两种典型模式：一是像 Google 所描述的，DevRel 是开发者与公司产品之间的桥梁，负责双向反馈；二是像 Twilio 所提到的，DevRel 更像是“技术布道师”，帮助开发者学习和使用公司的产品。这两种模式体现了 DevRel 的不同侧重点，但核心都是通过与开发者的沟通与协作，增强开发者社区的活跃度，推动产品的使用与发展。
2. DevRel 的发展阶段
根据 Michael Mahemoff 提出的“DevRel 成熟度模型”，公司在建立 DevRel 职能时通常会经历五个不同的发展阶段：
-
无 DevRel 职能：公司没有明确支持开发者的机制，也没有收集开发者反馈的渠道。此时，开发者支持的工作可能由其他部门如市场或 PR 临时承担。
-
不正规的 DevRel：公司尚未设立独立的 DevRel 团队，部分 DevRel 职能由其他部门（如市场、公关、业务拓展等）分担，产品团队或开发者偶尔承担开发者社区的讲解或演示任务。
-
合作伙伴关系：公司通过与重要合作伙伴建立的关系，隐秘地推动开源产品或新特性开发，合作关系多为大企业间的长期协作。
-
技术布道师：DevRel 团队通过技术布道师向开发者传播公司产品的价值，利用会议、媒体以及在线平台来扩大影响力，支持开发者更好地使用产品。
-
技术推广工程师：这是一个更加成熟的双向关系，不仅推广公司产品，还积极收集开发者反馈，优化产品开发体验，确保开发者在使用过程中获得技术支持。
3. 为什么需要 DevRel？
开发者是技术产品推广的核心用户群体，DevRel 的存在使企业能够与开发者保持紧密联系，帮助开发者更好地理解和使用公司的产品，进而推动产品的成功。没有 DevRel，开发者可能难以获得及时的技术支持，或者对产品的使用体验较差，进而影响其对产品的认知和使用热情。
建立 DevRel 的主要目的包括：
- 推动产品的使用：DevRel 团队通过提供教程、技术支持、文档、社区互动等方式，使开发者能够快速上手并深度使用公司产品。
- 收集反馈，提升产品质量：开发者通常是产品的主要用户，他们对产品的使用体验具有直接的影响力。DevRel 团队可以通过收集开发者的反馈，推动产品的改进和优化。
- 增强开发者生态：通过促进开发者社区的活跃度，DevRel 能够帮助公司吸引更多开发者参与进来，形成一个健康的生态系统，推动创新。
- 减少企业的支持成本：通过构建开发者社区，开发者可以相互协作和解决问题，减少对公司技术支持的需求。
- 品牌推广：DevRel 还可以通过行业会议、博客、开源贡献等方式提升公司品牌在开发者中的认知度，帮助公司树立良好的技术形象。
4. DevRel 的核心工作内容
DevRel 的核心工作围绕“建立并维护开发者关系”展开，主要包括以下几个方面：
(1) 内容创作
内容是开发者关系的基础之一。通过撰写技术文档、博客、教程和案例分享，DevRel 团队可以向开发者展示公司产品的功能及使用方式，帮助他们解决常见问题。
内容形式包括：
- 技术博客：详细解释产品的使用方法、最佳实践及常见问题的解决方案。
- 教程和演示：通过教程或演示视频，帮助开发者快速掌握产品的使用技巧。
- 案例分析：通过分享其他企业或开发者使用产品的成功案例，帮助开发者理解产品的潜力。
(2) 开发者支持和体验优化
DevRel 需要确保开发者在使用公司产品时能够获得顺畅的体验。通过提供技术支持、改进产品文档、优化开发者工具等，DevRel 团队可以帮助开发者更快上手。
- 技术支持：为开发者提供使用产品时遇到问题的解决方案，可能通过论坛、支持邮箱或线上聊天工具进行。
- 工具开发：为开发者构建并维护高效的开发工具，如 SDK、API 文档、代码示例等，帮助他们快速开发产品。
- 开发体验改进：收集开发者的使用反馈，优化产品的易用性，消除技术障碍。
(3) 社区运营
社区是开发者关系的重要组成部分。DevRel 需要负责运营开发者社区，组织活动、在线交流等，维持社区的活跃度和参与感。
- 论坛和社交平台：为开发者提供在线讨论的平台，帮助他们相互解决问题，并从中获取有价值的反馈。
- 线下和线上活动：通过组织 Hackathon、技术峰会、用户见面会等活动，增强开发者的参与感，吸引更多开发者加入社区。
- 开发者奖励计划：对为社区做出贡献的开发者给予认可和奖励，例如公开表扬、赠送礼物等，激励他们继续参与。
5. 不同的 DevRel 模式
DevRel 的具体实施模式因企业目标的不同而异。Twilio 更倾向于通过“技术布道师”的方式向开发者普及产品，Google 则通过“技术推广工程师”与开发者建立双向沟通。这两种方式分别适合不同的发展阶段和策略：
-
技术布道师模式：适合早期企业或希望通过品牌知名度吸引开发者的公司。这种模式更侧重于通过宣传和教育的方式，让开发者了解并尝试使用产品。
-
技术推广工程师模式：适合已经有一定用户基础并希望进一步改进产品的公司。通过收集开发者的使用反馈，企业能够更好地了解产品的实际表现，并推动产品优化。
6. DevRel 的影响与未来发展
开发者关系对于企业而言，已经成为提升产品竞争力和市场影响力的关键因素。通过 DevRel，企业可以扩大开发者群体，增强开发者的参与感，推动产品在市场中的发展和创新。随着技术的不断进步和开发者社区的多样化，DevRel 的重要性也在不断上升。
未来，DevRel 将继续在技术推广、产品优化和开发者社区建设中扮演重要角色，并成为企业与开发者之间不可或缺的纽带。
开发者关系（Developer Relations，简称 DevRel）的角色，是通过双向沟通开发者和公司的平台产品、工程、设计，来创造一个充满活力的第三方开发者生态系统。
Google 使用“the interface between”词眼。表明DevRel期望的是建立产品决策者和开发者（即产品使用者）间的一个双向沟通桥梁。Twilio的态度表明DevRel更像是一个单向的“教育的角色”，帮助开发者使用Twilio产品。
Michael Mahemoff最近写了一篇Developer Relations: A Five-Level Maturity Model. 在这篇文章中他阐述了一个公司DevRel部门发展的不同阶段。从没有DevRel部门到可以完全量化策略的价值。
针对在“如何制定本公司的DevRel策略” 的情境下，需要对Michael的定义做些调整：
根据以上分析，总结：Twilio是以“技术布道师”的方式来运营DevRel，而Google是“技术推广工程师”的方式。
Michael指明：DevRel正确的运营方法取决于公司对于DevRel项目的目标。比如，如果一家公司仅仅是期望品牌知名度的提升、或者参加少量的活动来减少开销，那么该公司应该采取“技术布道”的方式来运营DevRel。如果优先考虑从第三方开发者收集产品的使用反馈的话，采用“技术推广”的方式也许效果最好。
总之，投资DevRel对于公司的各个业务都有促进作用。所以，你策略的目标是什么，就显得尤为重要了。Dave McClure的AARRR模型可以用来作为指导DevRel策略的基石。
DevRel可以增加开发者们对一个产品的认知度，根据传统的营销习惯，在AARRR缩写前再增加一个‘A’；
在DevRel团队日常活动中可能会涉及到开发者们对产品的反馈，为了表明这一点在AARRR缩写后面增加一个‘P’；
这样话就产生一个新的模型：AAARRRP模型。与其仅仅把这个当作DevRel指标，不如把它们当作你DevRel项目的潜在目标（虽然‘如何来度量这些指标’也需要去考虑的，详见：What’s the ROI of Developer Relations）:
在开发者关系这个概念提出之前，企业已经有成熟的经验经营消费者群体和维护企业客户关系。然而，传统的市场营销手段，例如广发推销邮件、投放付费广告或在非技术活动上刷脸，并不能够得到开发者对企业及其产品的青睐。
越是技术氛围浓厚的领域，对 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 社群的案例并向读者介绍案例及其背后的逻辑。 https://devrel.me/536/ https://www.tisonkun.org/2022/08/05/what-is-devrel/