参与开源已经快3年了，这次在Meetup上没有分享纯技术的话题，其初衷是想带这大家从一个开源社区维护者的视角来看开源，希望大家能从中获取到一些感悟，当然这次的话题有些观点可能抱有主观看法，大家多多包涵。
什么是开源
我在这里说的开源特指开源软件**(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公司之后可能就干别的活了。
我们不能要求他换了公司之后，你还要投入社区，但我们心里还是非常希望他持续投入，当这些暂时离开的小伙伴再次回归，我们自然是非常欢迎的。
整个社区是在滚动交替的过程的，我们会有老一辈的贡献者，**会有新一辈的贡献者，人才辈出，长江后浪推前浪，**整个社区不断繁荣，不断壮大。
以上就是今天的全部分享。谢谢大家。
