如何更好的运转一个开源项目?Community Leadership Workshop 小记

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

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

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

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

ylqcg5

国内的 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 中,作为你的项目的开始!

  1. 构建社区,而不是拉群

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

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

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

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

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

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

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

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

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

总结

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

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注