点亮 ⭐️ Star · 照亮开源之路

GitHub:https://github.com/apache/dolphinscheduler

参与开源已经快 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 公司之后可能就干别的活了。

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

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

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

参与贡献

随着国内开源的迅猛崛起，Apache DolphinScheduler 社区迎来蓬勃发展，为了做更好用、易用的调度，真诚欢迎热爱开源的伙伴加入到开源社区中来，为中国开源崛起献上一份自己的力量，让本土开源走向全球。

参与 DolphinScheduler 社区有非常多的参与贡献的方式，包括：

贡献第一个 PR(文档、代码) 我们也希望是简单的，第一个 PR 用于熟悉提交的流程和社区协作以及感受社区的友好度。

社区汇总了以下适合新手的问题列表：https://github.com/apache/dolphinscheduler/issues/5689

非新手问题列表：https://github.com/apache/dolphinscheduler/issues?q=is%3Aopen+is%3Aissue+label%3A%22volunteer+wanted%22

如何参与贡献链接：https://dolphinscheduler.apache.org/zh-cn/community/development/contribute.html

来吧，DolphinScheduler 开源社区需要您的参与，为中国开源崛起添砖加瓦吧，哪怕只是小小的一块瓦，汇聚起来的力量也是巨大的。

参与开源可以近距离与各路高手切磋，迅速提升自己的技能，如果您想参与贡献，我们有个贡献者种子孵化群，可以添加社区 Leonard-ds ，手把手教会您( 贡献者不分水平高低，有问必答，关键是有一颗愿意贡献的心 )。

添加小助手请说明想参与贡献。

来吧，开源社区非常期待您的参与。

< 🐬🐬 >