开发者关系简明指南
随着信息化和数字化的发展，传统企业的业务发展在软件的帮助下突飞猛进。软件技术日新月异，几乎每隔几年就会有全新的技术和产品颠覆过往业务开展的方式。然而，掌握前沿软件技术的人相对于全行业的需求可谓是凤毛麟角。为了规模化前沿技术的价值，越来越多的软件服务公司如同雨后春笋一样不断出现。
顾名思义，软件服务公司主要以提供高质量的软件或软件服务来提高其他企业开展业务的效率。随着软件技术日益复杂，采用何种软件服务逐渐从以往的 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? 网站为开发者关系工作者提出了七条建议。
- 展示胜过讲述。尽快让开发者使用软件，而不是喋喋不休地吹嘘它有多好。如果开发者能用起来并且确实解决了问题，他们会付出更多的时间仔细了解。
- 功能胜过利益。同样的，你应该告诉开发者能用这个软件做什么事情，而不是试图说服开发者能得到什么利益。开发者会自己评估软件的价值。
- 提供真正的帮助。关注问题解决，让用户文档、样例视频和代码能够轻松地被开发者找到。让开发者能够轻松地向你寻求帮助。
- 直接一点。大多数开发者都是非常务实的人，直截了当地沟通能够快速推动问题解决并产生真正有价值的内容。
- 考虑开发者工作以外的需求。不是每一个开发者都迫切地要在工作当中使用你的软件，许多开发者有成长的需求和自己的项目。如果开发者在参与工作上的选型决策之前已经了解你的软件，那么它会更有竞争优势。
- 重复利用创作的内容。多媒体时代下相同的内容可以在不同的渠道以不同的载体重复利用，这能够大幅提高创作成果的传播效率。网站建议尝试“推特→博客→视频→演讲”的流水线。我自己就是这么做的，除了还有从演讲到文字稿的另一条转化线。
- 提供一个可用的玩具。例如 Timothy 编写的 FLiPN 框架，它能够直接被用在生产环境。虽然可能在很多方面成熟度只能称得上是一个玩具，但是开发者将真真切切地看到 Pulsar 是怎么在一个流处理框架中被使用的。
我个人推荐 Jono Bacon 的两本著作《社区运营的艺术》和《People Powered》。它们全面介绍了建设一个社群所需关注的主题，以及如何实施一个社群战略计划。毫无疑问，这里的社群主要指的就是开发者社群。
What is Developer Relations? 网站还推荐了其他的书籍、博客和播客，我没有仔细看过，这里就不做复述，可以到网站上自行查阅。