2019 年 4 月 ,Apache 软件基金会宣布 Apache SkyWalking (以下简称“ SkyWalking ”)毕业,成为 Apache 顶级项目。2021年 3 月,Apache SkyWalking 创始人吴晟成功当选 Apache 软件基金会董事,成为 Apache 董事团队中的首位中国人。目前,已有超过 100 家公司公开宣布在使用 SkyWalking,来自于数百家公司的超过 550 位源码贡献者活跃于 SkyWalking 社区。

12月,腾源会荣幸地邀请了吴晟加入成为腾源会导师,试图聊聊他的开源理念和最佳实践。在这篇访谈内容中,我们虽然讲述的是他在开源中的“偷懒”学,但实则传递的是他这几年基于 SkyWalking 项目和社区运营所沉淀的最宝贵的实践方法论,以及他对开源社区管理最深刻的理念和认知。

PART ONE
前言:“懒”是创造力的源泉

我很喜欢用「懒」这个词。因为在我看来「懒」其实是很多创造力的源泉,因为“懒”得走路,所以有人发明了车;因为“懒”得写字,所以有人发明了语音;正因为很多东西「不方便」,所以才会促使我们去解决问题。

我会认为我一天应该只工作8个小时,甚至更少的时间,但最好能挣一样甚至更多的钱,这是我做所有事情给自己预设的条件。所以我希望我能以最少的时间去创造更大的价值。因为第一身体是自己的,第二只有休息的时候才有创造力,而工作的时候是很难有的。

PART TWO
“偷懒”学招式一:让项目实现高度模块化

很多开源团队在做社区运营的时候都会遇到一个问题,项目使用者虽然很多,但最终真正愿意反哺贡献给社区的人却十分的稀少。

这个问题需要我们从两方面看待和反思。首先我们要明白,人的意识是需要培养的。任何一个使用你的开源项目的人,并不会在刚开始就存在“我想要向你贡献代码”的意识,因为他本身基于这个项目的二次开发可能仅仅只是为了公司的服务,所以这并不能促使他产生要去反哺社区的想法。

但是作为项目核心人员来说,有两件事却是我们必须需要做的:第一个是在技术层面,你需要去审视你的项目是否适合被贡献。现在很多项目从设计上看都比较“内聚”,当改动项目中的一行代码,就有可能会影响到整个项目的代码和逻辑。这就意味着使用者在更改项目的任何一处地方前都要去考虑社区所有的用户的所有的需求。所以除非他是一名职业开发者,否则根本就不可能考虑完全,这就会从某种程度上变相地提高了项目贡献的门槛。

所以可以看到,不管是 Linux,Istio 还是 SkyWalking ,都有一个很大的特点:当项目被「高度模块化」之后,贡献者就会开始急剧的提高。

绝大部分好的开源软件,都经过了十分精良的设计,有着大量模块化的设计思路,以确保这个项目在修改某个区域的实现的时候,不会影响到其他区域。这对于项目最初的创造者和项目人员来说,有着非常高的设计和技术要求。

核心共建者有多长时间,项目就可以发展多少,这不是我们想看到的事情。尽管我们知道项目将来可以运用到非常多不同的场景中,但我们只会做好一个场景,并开放接口,预留给其他开发者去创新和拓展的空间。这需要核心共建者在不停的去审视整个行业,保持项目的前瞻性。而有些项目创造者会更执着于实现项目的功能,而没有提供给其他开发者创新和拓展的空间,这就会导致最终也只能由自己去做进一步维护和修改。

目前 SkyWalking 已经进入了不需要我去监管,放心让它自运行的阶段。我们为它建立了一整套从代码模块规范、自动化检查和各种规模的自动化测试,来保证它不会将任何意外代码合并起来,几乎可以保证每一个提交后的代码都可以被用于生产服务。所以这也是为什么 SkyWalking 只需要 2-3 个人 Review 代码,就能将这个庞大且复杂的社区运营起来的原因。


图注:Apache SkyWalking 项目基础介绍

PART THREE
“偷懒”学招式二:
被“逼”出来的项目贡献者

总有人说中国的开源环境不好,在我来看,是因为中国很多开源项目都把大家服务的太好了。

目前 SkyWalking 几乎没有给开源社区用户提供太多的技术支持。我们认为 SkyWalking 已经为开发者提供了足够多的项目文档,去支持他们了解项目,解决问题以及对它进行进一步的拓展和开发。除非问题已经影响到了项目原本的功能,我们可能会提供比较积极的帮助。

如果大家在 SkyWalking 社区里,不管是QQ群还是其他渠道,我们的维护者们(也包括我自己)都很少回答来自社区的各种提问。我们认为,文档已经给到用户了,他要 Report 就走正常的渠道,但即使 Report 的是一些真真实实存在的问题,也不代表社区会帮助去修复。

如果我们认为用户反馈的这个问题确实影响到了项目本身功能,我可能会相对比较积极的帮助,但如果是一个弱关联或无关紧要的问题,可能我根本就不会在意这是不是一个bug。

这是我们在北美公司一贯惯行的原则,我们花精力在开源项目里面,是为了更好地为商业公司服务。而花在开源社区里面的时间,更多是在下班之后我的业余时间。

当我以这样的心态看待时,我并不会在意其他人是否会喜欢这个开源软件,因为我并没有责任和必要去花自己的时间解决遇到的所有问题,这本身就不是商业服务的范畴。

事实上,中国在享受全世界最好的开源项目的服务,甚至比商业项目还多,但 SkyWalking 社区并不会这么去做。长久来看,实际上这会对开源项目“共建性”造成极大的伤害。因为从某种程度上来说,社区贡献者是需要被“逼”出来的,当项目不提供其他技术支持时,你唯一的选择就是要么贡献,要么就忍着。

PART FOUR
“偷懒”学招式三:
“The Best Thing as the Perfect
Founder is Disappear
and Enjoy My Vacation”

我认为好的管理者一定要学会放权,尤其在开源社区中。做开源项目非常重要的一点就是,你能不能做到一个Ownership的转移,以及Share。

每一个大型开源项目都不是一个个人的开源项目,作为项目创始人,也许你可以永久享受这个项目“ Founder ”的头衔,为这个称号感到荣幸,也很高兴曾经创造了一个项目,能为大家来用,但是也仅仅如此。你的开源项目今天、明天能做的一切,以及十年后是不是能活下来,这一切仰仗于社区其他人。

所以我作为项目的 Founder ,我可以去休假,可以短暂地从项目里消失,至少社区中每天日常的 Review 并不一定要由我去处理。大家可能会发现我可能很积极会去回,那是因为我有时间,但并不代表一定要我去回。SkyWalking 中有 30 多个子项目,都有不同的人在Review,不同的 PMC 在管理着这些子项目,以及这些子项目对外的集成。

中国有很多的项目,嘴上说着希望大家来贡献,但是心里面却想着我不想把这个程序让你来干,这其中的原因大多来自于“我并不想把代码的控制权交出去”。
本质上,这确实可能是一个很难的心理过程,因为我们的成长环境都让我们形成了一种无形“潜意识”,如果你是领导就是你说了算,下面的人没有决策权。但如果在开源社区中,不构建人人平等的理念,不把自己的所属权放出去,把代码的所属权放出去,是很难调动大家的主动性的。

另外,对于早期的项目来说,你需要思考的第一个问题是谁需要你,而不是你想做什么。

这个边界是其实很清晰,但是对于很多人来说可能很纠结的一个事情。你想做什么,也许你心里有一份技术方案。但如果你不仅仅是以娱乐为目的,而是真的想让你的开源项目有更多人使用,就需要你在项目初期就想清楚你的项目的定位,它要解决什么样的问题,去看看别人需要你是什么,需要你去考虑当前这个行业共性有什么。而你所做的项目是否有共性,将决定你以后是否能走向一定的高度。

在想清楚这些问题后,你需要给项目设立一个明确的目标。每一个版本的迭代都是在不同的时期围绕项目的不同目标去做不同的事情,所以每一个小的版本号都有着明确的目标。通过不停的去试错、更新版本才能将它进一步的完善。这需要你对时间有着心里准备,因为大家所熟知的好的项目,都是经历了很多年的迭代,慢慢熬出来的。

另外,其实 SkyWalking 出海容易的一个原因,就是因为通过朋友的介绍。关于“走出去”这件事情,对于我或者项目来说,与其让我去雇很多人来做运营,我更愿意让项目的几位核心的贡献者去保持非常强的社交的能力,能与更多人去交流和沟通,才能项目真正地将项目带出去,而不仅仅是完全凭借自己的一个人的力量去推动。

PART FIVE
精彩 QA 回放集锦

Q:2017年前,SkyWalking 可能都不是一个能引爆流行度的开源项目,但它今天获得了规模化应用。这其中的突破临界点是什么?是什么原因?

在2017年之前, SkyWalking 都只是一个玩具。所以 2017 年是它突破的临界点的时间。

我们正式决定做这个事情是在 2017 年的 GOPS 大会上,当时的版本号是3.2.6,跟今天依然差距很远。但是在今天看来,3.2.6是我们第一次决定让 SkyWalking 在生产中运行,而在3.2.6之后,我们决定采用很多以前只在商业环境里面采用的设计,把它变成一个真正适合运维的 APM产品。

因此,SkyWalking 其实从 2017 年- 2019 年才开始流行起来和得到比较广泛的应用,所以从第一行代码到这个项目真的被运用,其实花了将近4~5年的时间,而大家看到的是一个指数级分布,反而从2019年到现在,是一个最不重要的时间点,因为那是一个正常的传播效应。

当达到一个临界点的时候,那是一个正常的传播效应,只是说还是快还是慢,仅此而已。

Q:SkyWalking 从进入 Apache 到毕业成为顶级项目仅用了一年半的时间。Apache 顶级项目的标准是什么?那一年半 SkyWalking 经历了什么?

其实这个问题的根本是,你对自己的项目团队的认知,或者说你得知道什么叫做健康的开源项目。

Apache 基金会里其实有很多项目并不一定社区很大,或者有很多参与,现在大概有300多个顶级项目,可能绝大多数中国人连听都没听过,然后有一些项目里面可能就只有三五个人,这都很正常。

那么在我看来,顶级开源项目并不等同于有多火,Star数有多高。而是:

第一,像上面提到的需要营造一个公平的环境,不应该是某家公司或者某个人在控制着这个项目,如果你要控制一个开源项目,你在公司开源就好了,没有必要放到基金会来。

第二,你是不是能够非常好的认可你的开发者们,当他们对项目做出了大的贡献的时候,你是不是能够吸纳他们进来,给他们权力,让他们提交和审核别人提交代码。

第三,你是不是能够建立一个基本良性的社区,有人贡献,有人提代码,有人提议,有人用。

最后,你的项目知识产权是不是清晰,这可能是最难的一件事情,因为很多开源项目不完全都是自己写的,会有大量的组件层面的依赖,关键就是你是不是合理合规地使用了这些依赖,基金会会对此会有非常严格的审查。
采访嘉宾介绍:吴晟,Apache 软件基金会首位华人董事,开源 APM 项目 SkyWalking 创始人,分布式追踪与诊断技术专家,骨灰级开源社区爱好者。先后在大唐软件、亚信中国、华为从事技术工作;2018 年 5 月,加入 To B 级混合云外企 Tetrate,成为公司创始工程师。

腾源会(WeOpen)是腾讯云成立的汇聚开源项目、开源爱好者、开源领导者的开放社区,致力于帮助开源项目健康成长、开源爱好者能交流协助、开源领导者能发挥领袖价值,让全球开源生态变得更加繁荣。

03-05 14:22