Erda 开源的迷失和反思

前言

Erda 是我从2018年初加入上家公司直到今年初离开的四年时间里一直在做的一个云原生 PaaS 平台。在开源之前，Erda 在公司内部的名字代号是 D ，在21年初改名为现在的 Erda 进行开源，并且在国内的云原生领域产生一定的影响。但可惜的是，由于一些不可知的原因，在近期前公司决定停止 Erda 的维护并且毕业了一些之前的同事。在这篇文章里我将从个人的视角来聊聊 Erda 开源的一些故事。

Erda 为什么要开源？

在21年之前，Erda 只是公司的一个内部 PaaS 平台，Erda 平台负责支撑公司业务团队的日常研发，和跟着业务一起项目一起打包售卖给客户。

但随着公司的业务转型（想从做交付转型到做ToB产品）和融资的需求，从老板的视角，Erda 的定位不能仅仅是作为内部支撑系统，Erda 和 Erda 部门被要求去承担公司的几个产品线（ Erda、Trantor、Gaia）中第一个去做商业化的尝试。

我觉得公司老板对开源的想法大概至少从19年就开始了，因为我19年晋升评审时老板就问了对我开源的看法相关的问题。我猜测有几个原因

和公司做在同一个赛道上做企业服务的其他厂商，都多多少少有一些开源的东西
在老板看来，国内对开源的热度是有利于公司估值的
但老板自己应该也是一直都想不清楚开源对公司会带来什么实际的好处，但又不想错过这波开源的热度。

然后21年初一次部门负责人 Y 给老板的工作汇报会议上，这个会议上 Y 做的产品方案被否决了，并且老板直接提出了 Erda 开源和商业化的问题，然后就这样拍板了开源。

这个时候老板对 Erda 开源的支持力度还是很大的，给 Y 充足的权限招聘、也可以 Erda 自己有销售和运营。

在公司层面，营销部门的几个实习生也开始维护 Tech 公众号，在公司里有偿投稿（不过这个稿费最后意料之中的被鸽了）。扯远了。。

回到故事的主题，在21年3月份 Erda 开始了轰轰烈烈的开源大业。。

Erda 对开源的定位是什么？

我觉得在开始做开源的时候，Y 和老板都没有想清楚开源的定位是什么。可能最开始的想法就比较简单，通过开源吸引开发者和提高公司在国内 ToB 和云原生领域的知名度。

同时开启的还有 erda.cloud 云平台，在21年初的 OKR 目标上，只定了产品力提升、开源项目 Star 和 Cloud 用户数几个目标。Y 在这个时候说的是，他会顶住老板压力，前期先不做营收只做用户。

这个阶段的开源就是公司打的一个招牌，通过开源和运营去吸引人才，吸引开发者和潜在的用户，还有一个目的我想应该是，Erda 开源顺便也响应了国家的十四五计划，通过 Erda 拉了一波公司的估值，让公司在去年顺利拿到两轮10亿的融资。

到了21年下半年，我觉得公司层面老板开始对 Erda 开源有了一些态度的转变，很明显的一个信号是老板觉得 Erda 产品能力很差，开始缩减 Erda 开源运营的经费和活动限制。但是开源的牌坊已经立出去了，Y 只能让 Erda在开源上继续往前走，但这个阶段整体上对开源的投入逐渐减少，而且开始急功近利去想收割前期积累的一些有使用意向的开源社区开发者。

还有一个转变是运营开始从影响力和社区运营开始转向ToB侧，对开源开始有一种让其自生自灭的态度，过渡透支了开源的活力。

Erda 开源社区和运营上做过的一些尝试和反思

这一段我从时间线上来说，Erda 确定开源后做的一些工作

Erda 全部代码从内部搬到 github 上面，为了开源做了一些重构和提高代码质量的措施
参加业界大会，GopherChina、gdevops、ArchSummit 等
参加了3~4次线下 meetup
组建运营团队，运营公众号、外部技术网站、知乎、直播等
1. 几次开发者互动的活动
运营微信社群

不能否认的，这些工作对 Erda 在业界的知名度是起到了很大的正面作用。但也不得不说，Erda 的开源到目前为止，还是没有起到太多的效果。

从我的经验上看，这些活动都没有问题，也是必须要做的。相反我觉得开源没有达到预期的原因应该归结到公司态度的摇摆和团队负责人Y 对开源的认知和坚持都不够。

先说一下坚持的问题，公司高层对开源的投入产出产生质疑的时候，Y 没有能继续拿出可以说服高层的故事/说法，导致了让整个团队也产生对开源的投入质疑。但毕竟大家都是出来打工的，说服不了老板虽然很可惜，但也不是不能理解的。

然后说一下认知的问题。我的印象里，Y 对开源的看法一直是作为商业化的辅助，这个思路要说也不是什么问题，但问题是开源本身就是一个需要长期投入和吸引人来互动的事情。

我们不说其他人的问题，来说一下我对开源的理解。开源本身确实不是公司来做只投入没收益的慈善事业，不管是作为商业补充还是长期战略都没有问题。

但开源的核心是社区，而社区的核心是社交和互动。每一个成功的开源项目必然不是开发者或者厂商的独角戏，都需要核心开发者、贡献者、使用者一起来组成社区和维持社区的热度。

从开源项目的生命周期来看，冷启动时期可能只有关注者，和一部分的尝鲜者。这个阶段如果开源项目的核心成员有社区影响力，可以通过个人影响力来带动项目快速渡过。这个阶段的运营动作需要持续不断的在社区和外界去曝光开源项目，Erda 之前做的大部分也是这个事情，在这个阶段我认为是没什么问题的。通过持续曝光来吸引更多的开发者到自己的社区中。

下一个阶段在开源项目产生一定的热度后，会有部分关注者开始转化为使用者，这个阶段开源运营需要对这些使用者提供足够好的支持，支持包括，使用文档的完善程度，issue 的响应速度，和在社群里的问题解答。目前 Erda 就处在这个阶段的初期。这个阶段对公司来说，是一个投入产出比很差的时间段，是要坚持投入人力和精力开始去积攒初始的深度用户。在项目的初期，尝鲜使用者会相对看中项目团队对用户的支持程度。运营在这个阶段要做的是更多和使用者进行交互，从使用者中挖掘使用场景(可以输出真实用户案例 or 标杆)和开始建立用户墙。

第三个阶段是从使用者之中转化贡献者，在上个阶段产生的深度用户中，很大概率他们会遇到开源项目不满足需求的场景，这个时候开源项目运营团队需要开始完善项目的开发设计文档，和贡献指南。另一个很重要的事情是要开始考虑建设开源项目的社区管理架构（Contributor -> Committer / Reviewer -> Maintainer/PMC ），能够让外部贡献者也能够有途径开始参与和管理开源项目。对开源项目的团队，这个时候要转换心态，能够放出一部分权限给社区参与者。

根据我的经验，社区的贡献者之间是可以产生裂变的，一些核心的贡献者也会不遗余力的去帮我们宣传推广项目。

最后，贡献者不一定是写代码，参与社区交流、写文档、和布道的都可以是贡献者。

再下一个阶段，随着贡献者增多，我们可以开放小部分的 Maintainer/PMC 权限给社区（但公司可以保留过半的投票权来保证对项目的掌控，这个是没问题的），这个时候开源项目开始进入社区自治的阶段。很多大型的 feature 可以让社区参与者来主导和完成开发。如果在这个阶段，我们可以认为开源项目已经具备了足够的活力/影响力，我们可以借助社区的力量来让项目走的更快。比如目前的 TiDB 已经迈过了这个阶段（毕竟开发一个分布式数据库只靠 PingCAP 公司招聘的人是远远不够的。

那运营可以在每个阶段能够去做什么事情呢？

这里我认为核心就是两个事情，一个是维持开发者关系，让开发者持续的对开源项目产生兴趣（吸引更多的开发者、留住社区的开发者），第二个是关注每个阶段不同身份参与者的转化率。但具体的做法我还没有很成熟的建议，这个也不是运营同学自己的事情，可以再思考一下。