数据库 频道

Apache DolphinScheduler PMC:我在社区里如何玩转开源?

参与开源已经快3年了,这次在Meetup上没有分享纯技术的话题,其初衷是想带这大家从一个开源社区维护者的视角来看开源,希望大家能从中获取到一些感悟,当然这次的话题有些观点可能抱有主观看法,大家多多包涵。


钟嘉杰
白鲸开源数据工程师
Apache DolphinScheudler PMC

什么是开源


我在这里说的开源特指开源软件(open source software, 缩写 OSS), 又称开放源代码软件, 是一种源代码可以任意获取的计算机软件,一些开源软件被发布到公有领进行托管, 如GitHub, GitLab, Gitee 等。

常见的开源软件有:
操作系统: Linux Kernel, Chrome OS, 基于 Kernel 的各种发行版等
数据库: Postgres, MariaDB,MongoDB, Redis 等
编程语言: JavaScript, OpenJDK, CPython 等
中间件: Nginx, Apache HTTP, Moby(docker) 

开源的组成形式


一家生产饮料的公司,有一个非常独特的配方,生产出来的饮料大家都喜欢喝, 配方层层保密,就是整个区域整个国家甚至是全球,只有它才能生产出这样的饮料,我说的这家公司就是可口可乐,这种模式导致传说这个配方比公司的市值还要高。

我有好的idea。这个idea在市场上适用性很高,在以前经济主体中, 会希望将这个idea层层保密, 将它作为我的商业秘密保存, 类似可口可乐。

在开源中却不是这样的,比如我开发了一个有趣的东西,我想的更多的是把它开源出去,希望更多人来使用/参与,希望大家对他提点意见。

在这个过程中部分作者认为,在他将产品开源过程中, 能获取荣誉感,产出是被人认可的。而从我的角度来看,是一个既能解决我的问题,又能解决别人问题的过程,让我的代码变得更有意义。

项目的控制力。饮料公司配方就是集中式的体现,公司不希望有很多人了解这个事情,不希望别人知道有秘方的存在。同时, 之前的软件行业也是如此,有些软件会暴露一些SDK让用户去基于SDK开发插件 ,但是从来不会把他们的代码给开源出来,他们希望自己是产品的控制者,其他人只是参与者。

但是开源就不一样,他不仅会告诉你如何去写插件,你也可以看项目核心的代码,可以修改核心的代码,如果修改是正确,社区维护者会接受你的修改。在开源里控制权不再是一个个体, 公司, 或者国家, 它是被社区控制。这里说的控制指的是发展方面,以及修改合并的审核,并不是对软件和参与者的控制。

人员的组成。在我刚参加工作的时候,有不懂的就会去问我的leader。但参加开源之后会发现,这里更加倾向在公共领域抛出问题,而非点对点交流。当有问题的时,在邮件列表,或者slack/微信群抛问题,你会发现有用户来帮你解决问题了,社区的贡献者回复的有时没有用户的快,这就是人员组成的问题。

社区往往是一群人在努力奋斗,能收集更多用户场景,能将产品打磨使其适用性更加广,在3、5年前,小海豚用户还没有这么多,会面临适用性问题, 随着用户数量和反馈越来越多,小海豚的适用性越来越广,很多公司基本上刚接触就可以直接一键部署,除了一些OA 或者特殊的鉴权,整个业务就能很快就能跑起来。

在局中


很多小伙伴可能都觉得开源可能离你很远,我个人觉得这是一个错误的观点,其实大部分人都已经身在其中。只要你在使用开源的软件,无形中你就已经成为整个开源大厦当中的一部分,你是社区的用户,又或者今天来参加社区技术活动、参加Meetup也是社区的参与方式,开源并没有离我们很远。

有库写入权


除了Apache基金会旗下的开源项目,Google、Facebook、阿里等企业开源出来的项目,只要你在里面贡献代码,并且有获取写入权限,你就算是一个开源项目的维护者了甚至自己写了一个小工具,并且在细分领域非常有用,并且开源出来有人在使用,有人star,你也是属于开源维护者,算得上是一个在深度参与开源的小伙伴了。 

贡献过代码


如果你在开源项目中贡献过代码,不管是文档还是代码,都是被归属为贡献者人群。其次是参与社区讨论,比如海豚调度会有邮件列表和对应的 GitHub issue,我们会在邮件列表讨论问题,如果参与其中讨论问题的讨论,甚至是在微信群/slack群讨论内容,那你就算是一个深度的用户,并且在参与推动开源反馈的过程。

这里补充一点,反馈对一个开源软件来说很重要,我们需要持续的深入去挖用户的场景,甚至海豚调度到今天来说还会不断地去做用户访谈,挖掘有哪些未解决的痛点,社区从哪些维度优化改善提升!特别是很多用户都在反馈同一个痛点的时候,开源的维护者就会不断去推动落实,说不定未来的3.5或者4.0发版的时候,这个痛点问题被解决了。

使用过项目-用户


还有一类用户,经常使用但是不参与任何讨论。我们看到上面的漏斗图,会发现这个用户群体在社区里面是最大的群体,也是最重要的一个群体。我见过有些开源软件,它代码写得不错,但是没有用户使用或者是它的用户群体太小众了,我认为它可能是一个开源软件,但它算不上伟大,用户群体的多寡很可能会决定产品是否伟大。

贡献者入权


接下来我们会发现社区里面第二大的群体就是Contributor。如果说用户是很重要的话,那Contributor可能就是正向推动整个开源的核心力量。比如他在使用DolphinScheduler发现了一些可优化点,提个 PR修改源码或者文档,作为维护者或者作为核心贡献者,都会非常的高兴去采纳他,并且还会一起沟通、协商如何把这个PR给merge到分支去,这些贡献者的存在,才能让社区欣欣向荣。

维护者


开源社区的维护者就是拥有代码的写入或者修改权限的人。但是在这里想特别说明一下,漏斗图里面仅仅是说明了数量的变化,并不上表示区分社区不同角色的重要程度。正如刚刚所说,虽然我是DolphinScheduler的PMC,但我并没有觉得我这个身份比任一的用户更重要,海豚调度在早期没有用户的话,那海豚调度这个项目也就走不远了。

开源有趣的事儿


我目前是白鲸开源的数据工程师,就是可能有部分小伙伴了解到白鲸开源主要干的事是基于DolphinScheduler去做商业化。有的小伙伴就会认为你是这个公司的员工,是不是会专注海豚调度社区,应该有更多的时间投入社区,帮大家去解答问题,去实现大家的一些想法。当然这个想法是正确的,但又不完全正确,因为我的时间投入可能不比大家的多太多。

时间分配


其实在一家开源商业化公司做工程师,在时间上并没有大家想象中的那么充沛。在日常处理中,大家 70% 的时间都是在处理公司的业务需求,只有 30% 时间专注在开源上面。当然这里并不是说我只有 30% 的时间才去贡献 DolphinScheduler 代码,日常工作中我和同事大部分代码是贡献到 DolphinScheduler 的,但是这也存在时间节点,就如同大家在公司开发项目一样。比如为了扩展用户,我们做了部分SaaS 相关组件以及Python API相关的支持,这部分代码我们全部贡献到 DolphinScheduler 仓库中,但是我会将其归结为公司的日常工作,因为这是公司的业务相关,且又期望时间节点的事情。

现实情况就是,需要将公司分配的任务完成之后,才能去做社区review代码等一系列事情。 

而在剩下的30%时间,我也不都是在看issue跟PR,大部分时间会关注到我个人在社区负责的模块,我目前主要是负责Python API以及文档模块,当这块有特定的 PR 提交上来的时候,会第一时间@到我,我就会提前去 review 这一个部分,我认为这是我对社区的职责,并不是我对公司或者任何一个人的责任,是我觉得我做了社区一份子应该做的事情,换个角度说,我觉得这是社区每个参与维护或贡献的小伙伴都需有这种责任心,这样才能保证社区繁荣发展。

如果有小伙伴往 DolphinScheudler 提交 PR 的时候,会发现你提交 PR 的时候他会立马去要求几个小伙伴去看,这就是他们在社区所负责的范畴。

当你发现你的 PR 或者是 issue 没有被人及时回复的时候,你可以手动 at 他,我相信他也会立马去帮你 review,如果他看到没有回复,可能真的是不小心看漏消息。

发版所需要的时间


我还有 20% 时间要处理发版的事情。之前社区有小伙伴说发版的频率不是很高,其实社区的发版远比大家想的要复杂。首先每个发版人有一定的压力,因为这个版本是经过他的手发出,他需要保证新版本能够高效稳定的运行。其次Apache 基金会发版有一套发版流程。单投票这一个环节就需要三天,你会发现你可能啥都准备好了,但是走测试流程、走发版流程也可能需要消耗个把星期,才能把版本发出来!

另外10% 的时间我才会处理大家让我去做的一些需求,比如小伙伴在在 slack 或者 微信让我帮忙看看代码, 我看到都会点进去瞧瞧, 如果太忙我会在 Github 简单评论, 并说晚点我看看。然后只有 10% 的时间我会主动地去检索我们目前 issue PR 列表。

一个issue、PR需要的时间


有人会说我们 issue 的 PR request 时间长或者是邮件列表/Slack响应不及时,比如有个用户很着急,可能是个线上问题,可能上手的时候卡住不能往下进行,而社区没有人第一时间去回复,可能隔了半天或者是隔了一天才去回复,大多数情况都是因为时间并没有大家想象中的这么多,所以大家可以尽量把时间预留出来。

Issue处理的流程及时间
简单(1-5min): 通过文档指引, 文字解释能解决
中等(6-20min): 本地复现,
困难(20min以上):
  • 确定各个版本的差异
  • 确定环境
  • 确定用户是否能稳定复现
  • 定位代码
  • 解决问题

提了一个bug、PR怎么感谢我
这是一个非常有意思的点,我发现会有些人向社区提了一个Bug/PR,他感觉就是说社区应该感谢他。其实这是对开源的理解有误,并不是说提交一个东西是对谁好,社区是一个团体,而开源软件是一大群人在干的事情,并不是说个人要解决的事情。当然如果你提了PR去解决特定的问题,我个人的角度会由衷地感谢。但如果你觉得自己提了PR之后,然后可以去邀功的,我觉得大可不必。

提了很久没有实现
其实我们都会将收集到的问题记录在issue列表或者是discussion里面。就是你提issue或PR的时候,我们会有一个机制,你可以提前去搜索一下是否有类似的issue,如有的话应该去对应的issue上面评论,社区会定期review,当发现这个需求是很多人都在反馈,可能会在下一个版本实现它。

但如果这是个特定的需求合作只是个别需求,可能只在你们公司几个小伙伴里面才有的话,那社区可能就不会去实现这一个特别的需求。因为海豚调度的定位就是要做一个通用的平台,当然也会尽可能满足大家的需求,而不是全部的需求。如果你想去实现它,我们也是非常欢迎你贡献代码的。

PR处理流程及时间
简单(1-10min): 一眼看懂并给出建议
中等(11-30min):
  • 判断原始 issue、修改合理性
  • 是否有更好的方式
  • 是否影响别的功能
  • 单元测试、文档是否完善

困难(30min以上):
  • 中等的全部
  • PR拉到本地不断校验测试
  • 一个 PR 根据修改模块重要程度, 可能需要多次、多人 review 保证其正确性

开源层级


有意义的开源


我认为能解决一小部分人的需求,就算一个有意义的开源。它容错性非常高,甚至它可以不及时更新或者是几乎不怎么维护,很少发版。都可以被称为一个有意义的开源。

前段时间我的个PR,使用了发版频率很低的一个库,已经1年没有发版,但确实能很好地解决我的问题,所以依然会去使用,我觉得这也是一个有意义的开源。

好的开源


能解决一个领域的问题,解决一大部分人的需求,有一定业界知名度的开源项目。日常聊天中同行大概知道这个软件,在用户中口口相传了,并且这个开源项目是与时俱进的,就像今天的DolphinScheduler,我们会有更长远的规划,比如增加k8s、增加对 SaaS 服务的支持等等,这也是我们最近在做的事情。 

成功的开源


从业者大部分都知道这个开源项目,已经积累到一定口碑,愿意说服公司来使用它,甚至主动会为这个产品做站台,包括今天参加 Meetup的各位讲师,都是为海豚调度站台的人,我也非常感谢大家对海豚调度的支持。我认为成功的开源还有个特征,就是它的迭代也会比较快,发版也会持续不间断,这也象征着项目背后的维护者也会有很多。

我认为,目前DolphinScheduler应该是处在好与成功之间,我们希望能把它做到一个成功的开源项目,希望当有人说到调度,都觉得海豚调度是一个很好的选择,并且在选型对比的时候,海豚调度一定在对比的行列中。

Flask社区的小故事

Flask社区的维护者在前一段时间,整个 Flask 的仓库的issue跟 PR 都被清零了,站在我个人的角度上来说,这是个非常了不起的事情,因为这是一个拥有5W+Star和每月7000 多万下载量的项目,可以说他们的维护者做了很大的努力。

但是我也看到有一些人在下面评论,说有很多时候提了 issue,他们这个社区并没有很好的解决方案,直接把它 close 掉了,有人觉得这是不对的,我没有办法去评论他做得对不对,但是我觉得他这是个非常牛逼非常伟大的举动,他们付出的努力可能远比我想象中的多。 

 Praquet社区PMC的感慨

最近看到这个社区新的 PMC chair 圈已经被选举出来了,然后新的PMC发圈感谢老一辈的付出。

这也是我前一段时间说在整个开源社区,它是一个不断叠加、不断滚动上升的过程。

我们不可能要求几年前参加社区贡献的小伙伴还留在社区,因为每个人的发展轨迹或者是成长轨迹,都会有不一样的关注点,可能他前一段时间还在 A 公司,专注于DolphinScheduler二次开发,去B公司之后可能就干别的活了。

我们不能要求他换了公司之后,你还要投入社区,但我们心里还是非常希望他持续投入,当这些暂时离开的小伙伴再次回归,我们自然是非常欢迎的。

整个社区是在滚动交替的过程的,我们会有老一辈的贡献者,会有新一辈的贡献者,人才辈出,长江后浪推前浪,整个社区不断繁荣,不断壮大。

以上就是今天的全部分享。谢谢大家。


0
相关文章