2023 年，在 DevRel 领域值得我高兴的事情有三：

其一，是今年继续召开的 Dev.Together，又一次和国内从事 DevRel 的小伙伴们一起交流经验，看看大家的生存情况如何，都在做什么事情。

其二，是好友 Richard 翻译的新书：《开发者关系：方法与实践》的出版。作为一个 DevRel 的从业者，开发者的身份能够让我深刻的感知到开发者的痛苦，从而帮助开发者解决问题。但我没有系统的思想，来指导我更加高效的解决问题。

其三，是 Community Leadership Workshop 的召开，可以让我学习到一些过去我不曾思考，或不曾注意到的开源社区和开发者社区问题，帮助我补全自己认知中的空白，更好的服务于开发者。

国内的 DevRel 的从业者们没有太多的资料和经验可以参考，全靠摸索，因此，我也希望通过这个小记，帮你可以看到关于 DevRel 、关于开源社区的一些现状，帮你更好的处理自己的工作。

Community Leadership Workshop 简介

在进行下面具体的内容之前， 先简要介绍一下 Community Leadership Workshop ，这个是在今年的 Apache Con Asia 的会前会，由 @姜宁 组织，@Tison 和 @Richard 参与建设的小规模研讨会，主要介绍他们在企业中从事开源工作和开发者工作的经验，帮助大家更好的理解开源、开发者工作。

从主题上来讲，@姜宁 介绍的主要是企业为什么要做开源；而 Tison 则介绍了他自己在运营一些开源社区过程中的最佳实践（这部分我非常有收获），以及 @Richard 介绍的 DevRel 从业者面临的一些问题。

下面的一些问题，也会围绕着这些主题来介绍，大家可以猜猜哪些内容都是谁讲的。我从 8 小时的分享中，提供出来几个我最有收益的问题，与诸君分享。

从一个问题开始：OpenAI 的 ChatGPT 爆火，应该开源么？

这个问题直击企业开源的根本：为什么要开源？

作为一个开源人，我的下意识觉得 ChatGPT 应该开源，这样可以让他运行的更好，但理智告诉我，OpenAI 不会将 ChatGPT 开源。即使 OpenAI 已经开源了一些能力（比如 Whisper），但对于 OpenAI 来说，目前 ChatGPT 和背后的大模型，依然是其企业营收的重要组成部分。

在大模型是其核心护城墙的时候，他不会选择将其开源，就如同我们看到众多的开源企业，其核心护城河并不是其开源的产物，围绕开源产物的服务才是其真正提供的价值。

而在这部分 @姜宁 也给出了答案：

绝大多数时候，开源的往往不是行业龙头老大，而是行业的第二名，通过开源来实现差异化的竞争：「我可能不是最好的，但我是最好的开源平替，你可以低成本的将其用起来」。就如同 Meta 开源了 LLAMA，通过 LLAMA 来和 OpenAI 竞争。

你的企业到底在开源生态中的生态位是什么？

不同的企业在开源生态当中有不同的生态位，有的企业是开源项目的发起方，比如 Meta 之于 LLAMA，比如 OpenAI 之于 Whipser。有的企业则是开源项目的贡献方，比如 Red Hat 之于 Linux Kernel。

对于项目的发起方来说，他们便是整个开源项目的上游，他们通过开放源码，来在市场中占据自己的一席之地，通过设定不同的 Paywall ，来赚取收益。或者是通过提供官方的 SaaS 服务之类的，来帮助客户解决问题。

而对于项目的贡献方，则是开源生态中的下游，下游的服务一开始可能是基于上游的版本来提供服务，但随着提供的服务不同，下游的企业则需要逐步向上游提供贡献，将自己的代码贡献给上游，以避免自己维护太多的支线版本，造成比较大的维护成本。下游的企业也可以通过逐步贡献，成为一个项目的核心团队，影响项目的发展。

如果你的企业围绕着一个开源项目做事，可以好好想想自己的企业的生态位到底是什么？自己如何为项目贡献、自己如何获取收益？

开源项目的 Default 配置是什么？

我自己也是一些开源项目的维护者，也会试图去围绕开源项目去做一些事情。而在这个过程中，到底哪些是应该做的，应该如何推进，这些问题其实一直我都没有特别成型的理论框架，而这次的 Workshop，在这个问题上给我了很多建议和总结，帮助我更好的去推广项目。

1. Home Page / 主页是最重要的一件事

很多开发者在开发项目的时候，代码放在 Github 上，就结束了自己的开源工作。殊不知，这只能算是你的代码公开可获得（Source Avaliable），如果你没配置 LICENSE，那就不算开源。

而配置了 LICENSE，也仅仅是解决了你的项目的合规问题。如果你有更高的预期，则需要做更多的工作。这里最重要的便是一个项目首页。项目首页决定了开发者如何找到你的软件和内容。开发者们会通过你的首页来了解最新的更新。

如果你的项目没有首页，那就做一个简单的 Landing Page ，并放在 Github Pages 中，作为你的项目的开始！

2. 构建社区，而不是拉群

国内因为「私域流量」的存在，大家搞运营喜欢先弄一个微信群，但微信群的问题在于信噪比太低，里面大量重复和无意义的内容。相比之下，建设一个简单的论坛可能是更好的选择。

通过在社区中的引导，你可以让开发者们可以自助交流起来，并尽可能的复用内容，减少内容的重复建设问题。

如果你没有时间和人力去建设一个论坛，那就用 Github 自带的 Discussion 来运行一个论坛吧～

3. 区分不同类型的开发者

在我之前看来，开发者就是开发者，是不区分类型的。但 Tison 提到，其实开发者也是分类的，有的开发者是核心开发者，有的是集成开发者，有的是应用开发者。

核心开发者往往是因为被你的开源软件的理念所引导而来的，只要软件本身的理念不发生变化，开发者们就会继续使用。

集成开发者则是在不同的系统之间构建集成，他们关注的是你的系统本身的易用性和稳定性，他们往往带着不同的目的来到你的软件当中，你需要通过 Blog、 教程、Workshop 之类的工具，帮助他快速完成集成，从而完成他的业务目标。集成开发者的开发完成后，可以帮助你的业务快速扩张，其集成的特性决定了做的是水管的工作，水管一旦建立，便源源不断的有用户进来。

应用开发者的类型和集成开发者类型差不多，不同的是应用开发者不是构建和现有系统的水管，而是挖出一个新的水池，成本和投入更大，但也能建造出更适合你的业务的水池。也是一个不错的选择。

区分这三种不同类型的开发者，对征下药，可以帮助你有效的完成开发者社区和关系的建立，从而让你事半功倍！

总结

Community Leadership Workshop 的内容实在太多了，对于我来说，每一点都值得细细的分析、拆解和理解，但毕竟文章总是要有尽头的，所以这一篇就先从这里结束啦，后续的内容，且等我拆解成一篇一篇的细节，分享给大家～