DevRel: 开发者关系和技术布道

我写这篇文章的动力其实很简单。最近，我有幸与几位中文区的 DevRel，如 Steven、dai 老师、uvd 和 George，进行了交流。同时，我也时不时与我的前老板交流，发现中文区的 DevRel 人员并不多。基于我自己积累的一些 DevRel 工作经验和体验，我想借此机会分享我的见解。DevRel 是一个既复杂又年轻的职业，有时我也不确定自己是否走在正确的道路上。但有一点我相信：DevRel is a lifestyle。

特别谢鸣：Jenks @ filecoin 和 Rod @ Ledger，我的两位导师，也谢谢前老板。

PS: 太多可以说了，写不完了啊啊啊啊

一些简介#

我最早接触布道是在 seedao，那时候我参与主讲了一门课程。后来，也在 Rebels 和小幽灵社区进行过 Web3 知识分享，当时可能还没到 DevRel 更多是作为讲师的身份。我的专业背景偏向技术（专攻超算，研究课题与区块链相关），这段背景可以帮助我更好地进行输出。同时，根据费曼学习法，简洁的语言向他人清晰解释一个概念，可以检验自己是否真正理解了这个概念。在 Rebels 进行分享时，我发现自己能够用简单的语言清楚地解释技术概念。逐渐地，我开始更深入地学习 web3 和区块链，为我的毕业设计做准备。

在学习过程中，我接触了 LearnWeb3 和 Alchemy Learn。Vitto（现在在 Cyfrin 工作）对我影响很大，因为通过他，我了解到了 DevRel 这个职位。也是因为开发社区，我了解到了开源和技术布道。后来，我加入了 BNB Chain，担任 DevRel，感谢我的前老板 Zoe 和 Yian。在 BNB Chain 期间，我主要研究 Greenfield 存储链。之后，我加入了 FLock，选择这里是因为逻辑自洽，同时匹配我的背景。

虽然我个人觉得我的编码能力不算强，肯定不如很多人，我最多只能编写 MVP，对于更深层次的逻辑框架确实不太擅长。但是我有一项能力，那就是能够把复杂的逻辑简单化。这个能力不是很多人具备的，我会根据听众或是聊天对象的背景来进行简化，改变我的叙事方式。例如，对于非技术人士，我会更追求高层次的概述。而对于对 web3 技术感兴趣的人，我会更多地提到区块链方面的知识。对于对 AI 感兴趣的人，我则会重点解释联邦学习。

我相信，作为一个 DevRel，除了技术背景外，沟通和解释能力也非常重要。这就是为什么我努力学习如何用简单明了的语言向他人传达复杂概念。我会根据对方的背景和需求来调整我的叙述方式，以确保他们能够理解和接受我的讲解。

总结下来

技术背景
愿意对外输出
上下兼容的沟通和解释能力
研究能力
一腔热情

什么是 DevRel#

DevRel 的历史与演变#

在我们进入正题之前，我觉得我们应该先了解什么是 DevRel 以及其具体的职责。DevRel 一词最早起源于 1980 年代的苹果提出，当时的情况是电脑和软件的起源。那时候苹果发现，苹果的理念过于新颖，很多人没有办法理解他们是什么，或是说 macOS 的好处。因此他们需要一个懂技术又懂市场营销的人去做一些引导和指导的工作。教导和指引大家什么是 macOS 和苹果产品并使用他们。随着更多的技术公司的出现，大家发现产品不再是主要的关注点，而是如何集成成了主要问题。由此，DevRel 走向了大众，越来越多的人成为 DevRel。许多公司通过 DevRel 打造了属于自己的生态，并通过生态伙伴逐渐变强。例如 Twilio 和 Spotify，关于这个我们会在下个章节继续详谈。

在 DevRel 的定义中，不仅仅是教导和指引，还包括了与开发者社区的互动、建立关系以及提供支持。通过与开发者社区建立密切的联系，DevRel 能够更好地了解开发者的需求和问题，并提供相应的解决方案。这种互动还可以促进开发者之间的合作和知识共享。因此，DevRel 不仅仅是一种市场营销手段，更是一种与开发者共同成长的过程。

另外，随着技术公司越来越多，DevRel 也越来越重要。技术产品的竞争越来越激烈，仅仅有好的产品已经不够，还需要通过 DevRel 来传达产品的价值和优势。通过与开发者社区的合作，技术公司能够更好地推广自己的产品，并吸引更多的开发者使用和支持。

现在 DevRel 在技术行业中扮演着非常重要的角色。它不仅仅是一种市场营销手段，更是一种与开发者社区紧密合作的方式。通过与开发者社区建立良好的关系，DevRel 可以帮助技术公司推广产品、解决问题，并促进开发者之间的合作和共享。在下个章节中，我们将深入探讨 DevRel 的具体实践和案例。

这个 quote 我觉得挺经典的，确实是说明了一个 DevRel 的 Daily norm 是什么，(一个全才 ((不是，具体感觉是 dev + mkt + prod 的融合。

Generating leads, taking over the documentation, being a partner to product management, on-site consulting, organizing conference booths, budgeting, create marketing materials, participating in product development, creating and running weekly workshops, maintaining integrations into other products, travelling your geo region up to 80% of the working time.
—— Alexander Reelsen

Dev Evangelist, Dev Advocate, Dev Relations#

这里解释一下，这三个工种，很简单，在我看来大家都差不多。不过功能性可能因公司而异

通常能够进行这种分割的公司通常是大型公司，在小公司中很少能够实现这种分割。据我了解，Polygon、Circle 和 BNBChain 都有明显的分工。Circle 在 DevRel 方面分为 3 个部门在 MKT 下面（这个之后会聊），DevRel 团队的创始成员是 Twilio 的 DevRel 团队的成员。（Twilio 的 DevRel 是业界公认的一家做得很好的公司）Circle 的 Dev 社区的引入将由 Dev advocate 负责。Evangelist 将负责进行研讨会和演讲。最后，Dev Relations 将负责文档和演示代码。这是大公司的做法。其他中小型公司不会划分得太细。

在 BNB Chain 的时候，我们也有解决方案架构师和 DevRel，很多时候根据活动地点派遣不同的人员。例如，我的上级在迪拜，他会参加迪拜、印度和中东地区的活动。解决方案架构师在欧洲，EthCC 就由他去参加。我恰好也在欧洲，所以也曾在 eth Lisbon 的演讲中客串过。

Code, Community, Content：DevRel 的三大支柱#

不过接下来的段落，我会按照更科学的方法解释 DevRel 的主要职责。我们可以通过三个 C 和 5 层金字塔来进行细分。三个 C 主要指的是 “code”，“community” 和 “content”。让我们先聊聊这三个 C。

Code#

Code 代表 demo repo，live coding，以及一切和代码相关的内容。目前，我看到了几个比较好的例子，例如lensV2和Jarrads的boiler template和视频。代码范例和 live coding 可以快速帮助开发者集成各种服务。这一点非常重要，因为好的代码范例能够让生态系统内的开发者事半功倍。代码范例通常会与文档关联，而 live coding 则是社区和活动的一部分。因此，很多时候在业内讨论时会说，DevRel（开发者关系）不需要太强调代码。然而，我认为这个观点是不正确的。只有当我们了解开发者的开发路径，我们才能够更好地编写文档，并通过使用 demo/SDK 来更好地辅助开发者加入生态系统。

Community#

在 DevRel 领域，"社区" 这一概念涵盖了两个主要部分：开发者生态和活动（线上和线下）。

开发者生态#

首先来看开发者生态，传统上，管理开发者生态通常是开发运营（developer operations）的任务，这与 Docker 和 CI/CD 等 DevOps 工作不同。以 BNB 为例，他们在 BNB Discord 上设有专门的开发运营团队，负责处理开发者面临的各种问题，如节点设置和 Greenfield 开发。而我们在 DevRel 中的主要职责通常是对外技术讲解。然而，在规模较小的公司中，DevRel 和开发运营的职责往往重叠，社区中遇到的任何技术问题通常都由 DevRel 来解决。例如，在 Lens 的开发者社区中，Nadar 会亲自介入解答问题，这增加了社区互动的亲切感。

活动#

另一个重要部分是活动，包括线上和线下活动。线上活动包括 Community Call、AMA 和 Workshop 等，DevRel 人员基本都能胜任这些活动。从之前的数据和体验来看，技术社区通话是促进讨论和展示项目活跃度的有效方式。AMA 既有外部主导的，也有内部主导的，具体取决于需求。例如，我曾参与 ZetaChain 和 Greenfield 的 AMA，并每周主持一个 AI x Web3 的 AMA，邀请各项目方参与讨论。线上和线下工作坊的最大区别在于听众热情的感知。线上活动由于常常涉及多屏操作，可能无法及时获得反馈，而线下活动则可以让大家直接在现场互动，容易感知和回应观众的情绪。线上工作坊的优点在于，它帮助那些社交恐惧的人更轻松地参与（如 starkastroCN、LW3 和 Developer Dao 所举办的线上工作坊）。

至于线下活动，比如黑客马拉松（hackathon）、开发者大会（devcon）和 ETHCC 等，情况就更加多样。在这些会议上，DevRel 通常会负责展位，帮助与会者更好地理解技术和产品。在黑客马拉松中，DevRel 的作用尤为重要，因为我们最了解如何向外界展示，并且最能帮助参赛者解决问题。在这些会议上，你几乎总能遇到一些常驻的 DevRel，如 Nadar（Avara，Lens/AAVE）、Simon（Edge&Node，The Graph）、Kevin（Polygon）和 Mirko/Francescco（Consensys&MetaMask）。DevRel 形成了一个紧密的小圈子。此外，线下的 talk 和 workshop，如 HackerHouse 分享会和各种活动中的演讲，通常也是由 DevRel 负责。技术的对外传播是我们的重点任务之一。

Content#

在 DevRel 中，内容创作是不可或缺的环节，主要包括两大类：文字和视频。

文字内容#

文字内容涉及多种形式，包括技术分析、文档、教程、Course 以及 Thread。以我的个人经验为例，我比较喜欢编写文档、教程和 thread。通常，我们官推的 thread 的撰写会由我们的 technical writer 负责，而我主要负责写一些自己做的研究和 DML 相关的内容。这里我也分享一下我在维护文档方面的一些经验：很多时候 dev 并不喜欢写文档，但是好文档才是开发者入门的敲门砖。如何写的更容易理解和及时更新是关键。同时撰写文档不仅仅是记录步骤和解释，更要以引人入胜的方式组织叙事，让每个信息点都能连贯地串联起来。为此，我每个月都会专门花费 3-4 天时间来思考如何改进我们的文档，使其更加有效和吸引人。教程这块则是，请把你自己当成新人，按照理解逻辑，如果初学者都能理解的话所有人也都能。我自己写文档首先会去想主题，这个教程想要达成什么，接着分解代码，决定篇幅。最后着手开始写。写完后一定要把自己定位成初学者多跑几次，做好测试集，不断的优化和改善内容。

视频内容#

视频内容的制作是另一个关键领域。从业界领先者如 Patrick Collins、Nadar 和 Jarrods 的视频制作方法中，我学到了很多。YouTube shorts 的制作通常强调在 60 秒内完整地讲述一个概念或故事。而常规视频内容则更为广泛，通常围绕 demo 和集成使用方法。例如，workshop 和 panel 的录制视频是宝贵的学习资源。尽管我个人更倾向于直接阅读代码，但考虑到不同的学习风格，结合视频和 Git Repo 的方式是一个很好的选择，尤其是在受众群体不明确的情况下。对于 How to 类的内容，视频是更合适的介绍方式，因为它可以通过视觉效果直观地展示如何使用我们的产品以及注意事项。

金字塔#

以上是我对 3C 的理解。在写文章的时候我也做了一些调研，发现还有一个更细分的解释。这个解释实实在在的说明了一个 DevRel 的大致工作任务，其他的杂活就放 misc 了。就像我上面说的 DevRel 通常会和 technical BD/product marketing 很接近但是很多不同。身为 DevRel 的首要原则是对自家产品的融会贯通，知道产品技术原理，用户逻辑和执行逻辑。接着通过不同的手段把这些信息和优点转化为所有人都能听懂的语言。手段可以是活动，可以是 workshop，也可以是内容输出。但是重点是让大家能理解我们在做什么，为什么要用，怎么去用。

events
workshop & webniar
education content
Community support
Documentation & onboarding

Developer first & Developer Plus#

在 DevRel 的世界里，我们将公司分为两种类型：Developer First 和 Developer Plus。

Dev First 是以开发者为主要用户的产品，通常以开发者工具、开发工具和开发辅助为主。比较著名的例子有 Vercel、MongoDB 和 Twilio。这类产品的目标是让更多的开发者使用 SDK 或服务进行开发。它们致力于为开发者提供优秀的开发体验，帮助他们更高效地开发和部署应用程序。这些产品通常提供丰富的文档、示例代码和支持，以及与其他开发工具和服务的集成。通过满足开发者的需求并帮助他们取得成功，Dev First 公司能够建立起强大的开发者社区和忠实的用户群体。
Dev Plus 是开发者作为次要目标或锦上添花的产品，而不是主要聚焦的中心。这些公司的核心业务通常是面向企业或消费者的产品。虽然它们也提供开发者工具和支持，但开发者并不是其主要的用户群体。相反，它们的产品更注重于满足企业或消费者的需求，提供解决方案和服务。著名的 Dev Plus 公司包括 Apple、Google 和 Microsoft，它们在不同的领域拥有强大的市场地位，并通过创新的产品和技术吸引了广大用户。

在 DevRel 中，Developer First 和 Developer Plus 都扮演着重要的角色。它们共同推动着开发者生态系统的发展和创新。Developer First 公司通过提供优秀的开发者体验和工具，吸引了大量的开发者，并促进了开发者社区的繁荣。而 Developer Plus 公司则通过面向企业和消费者的产品，推动了技术的应用和推广，为开发者提供更广阔的市场和机会。

无论是 Developer First 还是 Developer Plus，DevRel 的目标都是与开发者建立良好的关系，理解他们的需求并提供支持。通过参与活动、举办工作坊和分享知识，DevRel 可以与开发者进行深入的交流和合作，帮助他们解决问题、提升技术水平，并促进产品的创新和发展。总的来说，Developer First 和 Developer Plus 在 DevRel 中都扮演着重要的角色，各自有着不同的定位和目标。无论是专注于开发者的产品，还是将开发者作为辅助目标的公司，它们都为开发者提供了丰富的资源和支持，推动了开发者生态系统的繁荣和创新。

Mkt or Ops or Dev? 我应该在哪里！#

经过与众多 DevRel 的交流和几家公司的面试后，我发现不同公司对 DevRel 的理解和定位差异巨大。这其中并没有对错之分，只有实际效果的考量。一些公司将 DevRel 视为市场部门的一部分，而另一些公司则认为它应归属于技术部门，还有的公司认为 DevRel 更偏向于运营角色。这些不同的视角在很大程度上决定了 DevRel 的整体策略和职责定位。

很明显，采取中庸的立场在这里并不可行。相反，DevRel 的多面性恰好与我们之前提到的 “三 C” 原则相呼应。其中，“内容（Content）” 对应市场（Marketing），“社区（Community）” 对应运营（Operations），而 “代码（Code）” 则与开发（Development）相联结。每个公司根据自己的业务需求和战略目标，对 DevRel 角色的理解和期望各不相同。

传统和 Web3#

由于我没有从事过传统 web2 的 DevRel 工作，这段主要以我采访的 web2 转 web3 DevRel 和我收集的资料为主。

在传统的 DevRel 和 web3 的 DevRel 之间，内核没有太大的区别，主要的事务也是相似的。然而，web2 的 DevRel 更加商业化，而 web3 的 DevRel 更加注重社区的发展。

"web2 companies are actually profitable lol so it's much easier to see exactly how devs translate into profit, which in turn makes it easier to measure and plan devrel" - cat

这段引用来自我的一位 DevRel 领域的朋友，Aztec 的 Cat。她的话揭示了 Web2 和 Web3 公司在 DevRel 重视程度上的不同。在 Web2 公司，由于采用订阅制和产品付费制，他们能够更直接地观察到各种开发者关系活动对营收的影响。相比之下，在 Web3 领域的 DevRel 工作，跟踪 KPI 和制定 Metric 更具挑战性。举例来说，我们可能依赖于链上交易量和客户端下载量这样的直观数据指标，但这些并不能直接体现在营收上，尤其是在产品处于测试网阶段时。

在伊斯坦布尔，我有机会与多位 DevRel 深入探讨 Web3 领域的情况。有一个观点特别令我印象深刻：“在 Web2 时代，我负责的开发者人数可能在 1 万到 10 万之间，难以深入了解每个人的情况。但在 Web3 时代，开发者社群规模较小，成员在各种活动中经常互动，形成了一个紧密的小团体。” 实际上，根据 2023 年 10 月的Developer Report数据，Web3 领域的月活跃开发者数量为19,279人，估计全职开发者约6,279人。这表明，与 Web2 相比，Web3 开发者社群相对较小，但这正是它能形成独特关系网络的原因。

我的另一位朋友 Rod 曾说：“Web3 的开发者就像一个小家族，经常在各种黑客马拉松活动中相遇。这种环境促进了特殊的人际关系，为交流提供了机会。” 相对于 Web2，Web3 中的沟通更为亲密和个性化，因为参与者数量较少。这种亲密感是我特别喜欢 Web3 的原因，它给人一种大家庭的感觉。

心得感受#

自 3 月开始在 BNB Chain 做 DevRel 到现在也小半年了，感觉仿佛过了 2-3 年。Web3 一天如人间一年真的没有问题。今年飞了很多地方，说实话 10 年英国我除了回国以外，基本没怎么出去过。今年一年，有 25% 的时间在参会，也算是达标 DevRel 25% travel 这个标准了。4 月的 ETH Lisbon，7 月的 EthCC，8 月 GHH，9 月 Token2049，11 月 Devcon。这 10 个月真的做了很多不同的尝试，不断的试错，总结，改善，进步自我。今年做的一些事儿，也做个总结。

今年参与筹备了 2 个线下活动，token2049 的 What the flock，ETH London 的 DML night
Judge 了 3 个 hackathon，BNB Chain 的 Zero2Hero（协助），HomeDao Hack 和 ETH London
参加了 4 个 hackathon，ETH Lisbon，ETH Paris，ETH Singapore（谢谢 Card3 团队），ETH Istanbul
跑了 50 + 活动，做了 5 + 线下 workshop，10 + 线上分享
内容这块写了很多在备案中，陆续会更新出来！

总体体验下来，DevRel 是一个很复杂的工种，我更愿意称之为 lifestyle（生活方式）。除了 3C 之外，DevRel 的主旋律是出差，尤其是大型 hackathon 和聚焦开发的 conference (devcon，edcon) 在不断出差中，DevRel 逐渐变成一种生活方式。去到各地和当地的开发者进行接触，了解痛点，解决痛点。对我来说今年去了很多地方，看到了很多有意思的趣事。

研究和叙事#

除了 DevRel 的基本职责之外，我会自己做些研究工作。我认为，对于 DevRel 来说，探索新趋势和技术是至关重要的。这不仅涉及对新叙事的理解，还包括将这些叙事与现有技术框架相结合，进行创新性尝试，以吸引新的开发者群体。

在巴黎听完 bob, the solver 后我立即思考如何将我们的产品技术与他的观点结合起来，如何不再依赖 classifier 而是 ai agent
DAO 和 ai agent 的结合，William（42 Agents）和 safe 目前也都在看这个方向。我个人也十分看好。趋于自动化的投票托管，从而提高投票效率。
研究内部发起的学术研究，ZK 的结合或是去中心化算力的结合

很多时候，因为 DevRel 和 technical BD 很接近，因此参会聊的很多项目也会由我去跟进和 review 文档。日常是 DevRel 参会时是 BD 说的就是我吧。对于文档的审核来说，这是一项挑战重重的任务。我需要彻底了解项目的内容、操作方式、使用的 SDK，甚至是否有自己的专用语言，然后基于这些信息构思潜在的合作方案。这不仅要求我对我们自己的技术了如指掌，还需要洞察市场趋势和理解合作伙伴的项目愿景及技术实现。例如最近在看我们如何和去中心化算力进行合作，允许用户租借算力，只需要贡献数据即可。一个好的 DevRel 必然是使用过自己产品并且对自家产品非常熟悉。

黑客松#

我最喜欢的部分来了 hackathon。hackathon 是一个奇妙的场景，汇集了众多 hacker，提供了极佳的交流和学习机会。作为 DevRel，我认为参与 hackathon 是最佳的学习和互动场景。在这里，你会看到许多 DevRel 协助 hacker 构建产品，这个过程中充满了创造和协作的氛围。

我参与 hackathon 或担任评委的原因很简单：只有深入了解整个流程，我才能更有效地指导和支持其他参与者。DevRel 在 hackathon 中的主要 KPI 是项目数量 —— 我们希望尽可能多的项目使用我们的技术，这样才能为后续的数据分析提供充足的样本。例如，在 ETH London 上，我主要做了两件事：一是简化教程，我们的 Bounty 主要关注应用创新，因此我希望参赛者不要花费太多时间在集成我们的代码上。我直接展示了接口代码和返回数据，让集成过程更直观、更简单。二是，我会在每天 1 点到 2 点之间巡视会场，了解开发者的进展情况，同时推广我们的奖金赏金任务。我发现，在凌晨 1 点到 3 点这段时间是参赛者相对空闲的时段，因为大家在高强度工作后会有一段休息时间，这是与他们交流的最佳时机。

基于我的经验和实践，最终的反响非常积极。共有 12 个项目接入了我们的模型 API，这远超出了我们的预期。在 hackathon 中吸引参与者在某种程度上类似于地推活动，特别是在这种高密度的开发者集结场合，利用评委的身份与开发者进行深入交流，推广我们的奖金赏金任务和产品，并协助他们解决问题，这有助于进一步构建深厚的关系。这次的一个 compliment：“Thanks Tim, definitely the only one stayed up with us during the battle, thanks for the support”。这让我感到自己所付出的努力是值得的。

活动，workshop 和 AMA#

先聊聊参会，今年我参与的各种活动和会议，时常感觉自己才是那个 BD。我这一年的经历告诉我，能够真正吸引开发者参与的活动并不多，开发还是得去 hackathon 前后寻找。因此，针对性的推广或加入特定的小型群体成为了关键。在这方面，ElectricCapital 的 Developer Report 对我帮助极大，它像是 DevRel 领域的圣经，为我们提供了对开发者生态的深入分析。通过这份报告，我们可以清晰地了解当前开发者社群的状况。当然，从开源的视角来看，如果项目本身不是开源的，这些分析也就失去了意义。

总体来说，组织和参与活动、workshop 和 AMA 是一项颇具挑战的工作。我需要不断思考如何进行有效沟通，确保参与者能迅速理解我们的工作内容。在 AMA 上，快速记录嘉宾的发言是必不可少的，每轮回答我会去 echo 一下，提高观众对嘉宾回答的记忆。Workshop 的准备则类似于教师的备课，要深思熟虑如何教学和讲解。开发者的需求各异，因此在构建优秀的开发者社区时，并不存在一成不变的答案。只有通过不断的尝试、接触和激发讨论，才能逐步建立起社群。没有快速建立社区的捷径，一切都需要时间和持续的努力。但可以肯定的是，持续举办活动和工作坊绝对能展现我们的努力，并有效吸引开发者的参与。

总结#

最后想说 DevRel 也太复杂了，真的痛并快乐着。希望开发者能变的越来越多，也希望我们能吸引更多开发者入圈。这里主要是从项目方的角度出发，结合我看到的，我做的去聊。其实还有纯开发者社区的做法，这块我就不太熟悉了。

timtimtim