从开源社区的运营到社区基础设施产品的设计
2020 年 4 月份回到华为参与 openEuler 操作系统社区的开源运营，我来说是有极大的挑战。“开源社区运营” 是一个新的名词（职位），所做的工作内容和界限是没有界定的，一切对于我来说大都是陌生的。当然经过两年的工作，对开源社区运营有了自己的认知，全然不是对这个词的定义，只是流水简述我这两年的思考。
大多数人理解的开源社区运营，就是组织一些开发者活动，线下的 Meetup 也好或是线上的直播，甚至更大规模的开发者会议等等。我妄自猜这可能来自于现在很多互联网公司的开源项目运营工作，大多是由公司市场部门的人担当，所以传统的市场工具加上开源社区传统手段，就组成了普遍意义的开源社区运营工作，也许再设计几个新晋 “网红” ，就算没有可圈可点的结果，也能说的上中规中矩。 当然我觉得这也是开源运营的一部分，但并不能是全部。在我个人的理解，以上都是手段而已，是完成公司内部各种 KPI 指标方法。最近由于有了更多的空闲时间，所以经常思考开源社区运营的核心目的是什么，是各种 star、fork 或者是 contirbutor 数量，还是帮助项目获取更多的商业客户？翻看之前仅存的一些文字资料，这一次演讲（ 开源社区与运营 - 2021 上海计算机教育年会演讲稿 ）中随口说的话也许正是我的初心。
“我的工作就是让这些人(开发者)能够在社区产生更深层次的活动，产生新的想法并且鼓励大家把它变成现实”
当我们把 “开源” 和 “社区” 两个词叠加在一起，就得到了一个组合。华为内部有个黑话可以解释这种组合，这个词就是 “正交” 。对于 openEuler 社区来讲，这个共同感兴趣的实体就是 openEuler 开源操作系统，这个社区就是属于下载安装使用的那些开发者、在 gitee 上提交代码的开发者、参加社区会议的开发者、还有那些看到 openEuler 各种宣传但因为拖延症晚期还没有去尝试更深入了解的人。我的工作就是让这些人能够在社区产生更深层次的活动，产生新的想法和 Idea 并且鼓励大家把它变成现实。
在做开源社区的运营时，首要的就是分析你要运营的开源社区，它的核心技术是什么。我在运营 openEuler 操作系统社区的同时，还负责管理 openGauss 数据库社区和 openLooKeng 大数据引擎社区两个项目的运营工作。 从技术角度上来说，openGauss 数据库和 openLooKeng 大数据引擎是技术领域非常直接的开源社区，使用它们的开发者和能参与到开发的开发者画像是非常清晰的。这部分人群相对容易锁定，运营工作相对就容易 “聚焦”（专注）。但是操作系统是非常传统的技术领域，社区演进之慢可以用十年作为单位，而且操作系统涉及到技术领域非常多，很难说一个问题是属于操作系统的问题还是某个特定技术领域。我们传统的认为操作系统的开发者是 Linux Kernel 开发者，其实对于他们来讲，操作系统的发行版来讲并不是他们关心的事情，在 Linux Kernel 上游开发对于任何一个发行版都是收益的。从事操作系统维护的开发者工作说出来是有些无聊，是把各种上游开源软件打包成操作系统指定的包格式（ 对于 openEuler 操作系统来讲是 rpm 格式的软件包 ）。 一个操作系统社区的维护能力，并不是有多少人参与到软件包的维护过程，而是能和上游有多少链接能力，能够快速获取上游的 CVE 漏洞信息，参与到软件的开发中。从这个角度去看，一个真正的操作系统社区其实范围并不大，而且活跃度不高。在国内做这方面工作的开发者并不多，主要是之前国内的操作系统厂商、互联网厂商使用操作系统都会选择 CentOS 或 Debian ，从上游获取软件包就可以，何必要自己去编写软件包的 Spec 。
所以把 openEuler 建设成为一个活跃开源社区的路径就剩下一个比较现实的路径，就是扩大社区的范围，引入一些其它的开源项目也就是 “创新项目” 进入社区。其实在 Fedora 社区也是有类似的方式，譬如当时 Fedora 开始做 Atomic ，虽然后来收购了 CoreOS 就融合了（放弃了）。openEuler 里面有一系列的项目，其实里面不乏非常有意思和有价值的项目，譬如我个人最看好的 StratoVirt ，这是一个基于 rust-vmm 的项目，但是并没有激起人们参与的热情和动力。 也许是这个技术领域的门槛太高，或许是 Rust 的开发太难，希望有一天我能静下来的时候可以去仔细分析它的发展路径。
回到事情的本质，我们都希望通过开源项目帮助我们的商业融入一个生态或者创造一个生态，我们经常理所当然的认为我们的开源项目会得到关注，理所当然的认为别人会对项目欣然接受和追捧，现实往往是相反的而且是残酷的，多数情况我们的项目并不被人接受，甚至各种负面和诋毁的舆情充斥互联网。为了战胜负面的信息，经常会大举进行宣传，宣传的同时就一定有虚假的部分，然后就进入死循环中。也同时造成了运营和 Marketing 的工作界限越来越模糊，要不沦为工具人要不变成边缘人物。
在内困外乏的处境下，需要先解决最基本的问题，对于初期的核心开发者，是否能够相互顺畅交流决定了这个社区是否能够顺利起步的关键。 openEuler 最早的困境是大部分开发人员是华为的雇员，另外一部分贡献者是国内主流几家操作系统厂商的雇员。由于大部分人不习惯使用邮件列表这个传统的通信方式，造成了相互之间的信息隔离，很多在华为内部的信息在无意的情况下不能传递到整个社区，社区的讨论和决策华为内部无法获取。2020 年因为疫情突发，大家相对熟悉在线会议的形式进行沟通，打破华为内部的闭环通信系统和非华为开发者之间会议通信壁垒的时机成熟已经趋于成熟。为了统一社区的通信交流方案，同时要适应国内开发者的使用习惯，最终设计了一个 openEuler 小程序，通过它调用 Zoom（华为工程师可以接入的唯一外部会议平台）的 API 创建会议来实现社区会议统一创建，实现了华为开发者和外部开发者会议预定及信息获取统一，避免了使用不同的会议系统造成无法信息互通。在一年半的时间里面，举行了 672 次会议，共 676 个小时、3124 位开发者参与过这些会议。社区中大多数的 SIG 组都已经习惯按时组织会议沟通进展，讨论技术路线。当然现在邮件列表的使用还是没有得到普及，国内的更习惯在一些封闭的环境下进行交流。
这个小程序并没有后续再做更多的功能，只是增加了 Meetup 的组织、报名和签到的基本功能。主要是由于我对产品设计的理念，不喜欢做 All In One 这种平台，希望能够随着实际需求发展产品以帮助社区。这种节制我认为是一个产品经理的最基本要求和能力，当然也是最难把握的事情。甚至在小程序的基本功能中，我都做了一些取舍，譬如采用手工的方式维护订阅会议的权限（目前只有 Maintainer 才能预定相关 SIG 的会议）。可以通过在微信中搜索 “openEuler” 来体验这个半成品，虽然未尽的想法无法实现，但是坚定了在后续的工作中以 “开源基础设施产品” 的方式来运营开源社区的思路。
在即将离开 openEuler 开源社区运营工作的时候，在 Twitter 上看到有 暑期系列 活动的一个 Tweet 。暑期系列活动其实没有什么新意，完全是在国内照搬 Google Summer of Code （GSoC）的活动，可能也就是比国内其它的高校竞赛做的更用心一些。活动最初是由中国科学院软件研究所提出的，希望在国内高校培养在校生参与开源的能力和热情，第一年（2020）年的时候从 4 月初开始一起策划 暑期 2020 ，到 7 月份学生进入开发阶段有些匆忙，但是和软件所的团队一起完成了任务收集、学生招募同时还组织了直播活动。而后又经过扩大规模的 暑期 2021 ，第一年在流程中遇到的问题在流程中得到了解决，更多的学生积极参与进来，尤其是这一年有一些海外的学生报名了活动。经过 2021 年的活动，国内的各种组织机构或几家大型公司都看到这个活动并争相模仿，2022 年类似的活动就有 6、7 个。当然对于广大的高校学生来说，即使这样的规模再扩大 100 倍也无法覆盖相关专业的所有学生。看到能激励学生通过参与开源社区更好的学习和实践，能勇于探索课程外的技术和社区，我想暑期系列项目的目标就达到了。也许暑期系列的竞赛活动，是我这两年运营工作留在社区最好的财富，一个 “正能量” 的事情，一个曾经激励过别人的事情，一个被大家认可的事情，没想到我还能 “阴差阳错” 的做出一个让我内心觉得感动的事情。
暑期系列活动是在特定时间内的活动，暑期中的任务也是有限的，当然我也想去影响那些没有被比赛覆盖到同学，希望他们一样能够通过其它的活动获得机会。所以策划了 “开源社区高校实习” ，参与的学生可以通过参与社区开发、测试或者其它社区活动获得积分，通过积分换取实习证明，有一些学校已经承认这些实习证明。这样的一个开放的活动，能够容纳更多有兴趣的同学。但是这个活动还没有像 暑期系列 活动被同学所知道。目前社区里面参与这个活动的开发者还不多，没有足够的导师在社区中帮助参与的同学。这是一个正循环的轮子，启动的时候需要很多动力。我不再从事社区的运营工作，希望未来可以投入更多的时间到辅导学生的工作中，这也是我在社区里面能继续做下去的事情。当然这个活动也很快被复制到部门运营的其他几个开源项目里面，AI 相关的项目学生参与度远远高于操作系统，这也是基础软件这几年衰败的原因之一吧。
如何能让社区覆盖其余没有参与社区的学生呢，再苦苦思考之后最终选择采用 “MOOC” 的形式来最大限度的把开源社区推广到学生群体中，所以有了 MoocStuido 的这个产品（当然它也被快速的复制到部门运营的其他开源项目中）。 其实在名字上这个事情是非常纠结的，最后加上 Studio 是希望把这个平台的开放性变成现实。制作一个课程是非常简单的，只要按照标准格式（其实是 markdown 格式的衍生）就可以制作课程，提交到社区审核后就会上线到平台。 整个产品没有设计的创新，基本都是参考 KataCode 平台。当然就在这个过程中，听到了 KataCode 即将关闭的消息。对于社区要维护一个平台为开发者服务，背后的成本不止是服务器的费用，还有很多工程师的辛苦工作。KataCode 的关闭，对于如何将来运营 MoocStudio 让我产生了很大的焦虑，一个为开源社区服务的产品（平台）不为盈利，这样的平台能存活下来多久。
当我做了很多尝试如何去激活这个开源社区，回顾起来我好像在产品和社区之间迷失了。这是一个操作系统的开源社区，还是需要围绕操作系统来思考。一个操作系统社区的核心是维护软件包，无论塞进去什么创新项目，本质并不能发生变化。维护软件包的人相对比较固定，怎么让更多的人了解到这个最传统的领域从而参与进来呢。Debian 是最社区化的操作系统，有 200 多个衍生版本基于 Debian 制作的，Ubuntu 早起也是基于 Debian 系统发展起来。无疑这是一个扩大社区，扩大影响力的最佳方式，让更多的人参与 openEuler 操作系统的衍生版本制作。所以有了 OmniBuildPlatform 这个开源项目，把构建一个衍生版的工作做成一个服务，让所有人都有机会做自己的衍生版，它还在持续的改进中，有临时的 测试平台 可以访问最新的版本，但是并不稳定并不能保证结果可以运行。这个系统做稳定还需要一段时间，不知道我离开当前工作后这个项目是否还会持续，遗憾的是没有用 Rust 开发这个平台。 当然这是个开源的项目，我会竭尽让它继续运转下去。
很多事情会打破已有的规则和生态，但有时候需要打破已有的平衡才能建立新的世界，在新秩序建立的过程中，会有合适的产品（项目）成为大家的选择。在这个过程中希望有人能站出来成为开源项目的领导者，带领大家走出一条别样的路来。
谨把这篇文章献给这两年一起工作过的同事和朋友，我没有留下来什么有意义的 “胶片” ，只留下一些产品设计的思路。希望开源基础设施的发展越来越好，成为开源的一个亮点（新星）。并不是 Leader 才需要 Leadership ，希望有一天我能回来讲一个关于开源 Leadership 的新故事。