参与开源，就从今天开始吧

昨天得知成为 Apache DolphinScheduler的Committer，此时此刻内心依然十分激动。

在我的价值观体系里面，对于一个程序员来说，能够成为Apache Committer，能够拥有Apache邮箱那绝对是至高无上的荣耀。

如下图所示，这是一张Apache 基金会的金字塔结构:

从下至上，这就是一张打怪升级的路线图:

Users: 开源软件的用户, 当使用了某个Apache开源软件，我们就成为了它的用户。

Contributors: 进一步的，如果我们对这个软件社区做贡献，将会成为贡献者。贡献的形式包括贡献代码、编写文档、发布issue 、宣传布道等各种形式。

Committer: 当贡献度到一定程度，PMC可以提名贡献者升级成为提交者。到这一步，你算是迈进Apache的大门了，此时你将拥有该项目Merge代码的权限，并且拥有Apache域名的邮箱，在Apache官网的Committer列表也能看到你的大名。

PMC: 提交者再往上即是项目的PMC成员，他们引领这个项目的发展方向，版本的发布、可以参与重要的决议投票，提名Committer等等。

ASF Member: 到这一步，相当于大佬级别了:)。目前全球活跃的ASF Member只有约700多名，其中华人约20多名。Member拥有ASF董事会的投票权，也可以推荐某个项目进入Apache孵化器。

今天想和各位聊聊我对参与开源的几点感悟。

第一点感悟，做同样的功获更大的利

很多人，包括我在内，在很长时间内都一直停留在Users这一层。其实大家一直都在使用开源软件，但却很少与社区互动。

我想各位也一定会有以下类似的经历:

比如说，在使用开源软件的过程中我发现了一个BUG，自己默默的把它修复了，然后就没有然后了。

再比如说，写了一篇使用心得或者部署文档，在公司内部给同事传阅，然后也没有然后了。

如果换一种思路，完全可以做同样的功获更大的利。

比如说，同样是发现了开源软件的一个BUG，你修复BUG了以后用PR回馈给社区。首先你还是解决了自己的问题，但同时还无形中帮助其他人解决了BUG。反过来，如果其他人也依照此逻辑，他们是不是也能解决你的BUG。

再比如说，你还是写了一篇使用心得或者部署文档，但是将它发表到社区传阅。首先这样还是能够满足你同事的阅读需求，但同时数以千计、万计的其他人也能分享到这些信息。反过来，如果其他人也依照此逻辑，你是不是能获得到更多的信息。

从某种角度来看，这就是一种互惠，是一种双赢。我们在满足自己诉求的同时，也能帮助到更多人。反之，你也能得到更多人的帮助。

当你迈出了互惠的第一步的同时，恭喜你破圈了，现在你已经成为了Contributor。

第二点感悟，做贡献 ≠ 写代码

很多人，包括我在内，在很长时间内一直以为只有提交代码才算做贡献，其实并不是。贡献的形式是多种多样的，包括代码、编写文档、社区问题答疑、提issue、宣传布道等各种形式。所以找到你擅长的领域，持续输出、持续贡献即可。

你看给ClickHouse写文档做贡献，也能成为它的Contributor不是？

第三点感悟，参与开源可以 "各怀鬼胎"

从小的英雄主义教育我们，英雄到最后很可能都是会受伤、要牺牲的。所以很多人，包括我在内，在很长时间内认为搞开源是件很神圣的事情，不能带有杂念，只能利用个人时间付出、不能有收益，否则就是“不纯洁”。

其实并不是，经验告诉我们，一件事情如果没有利益驱使，是无法持续长久的。只靠一时激情，也就只能换来三分钟的热度。

所以说，参与开源是可以"各怀鬼胎"的，是可以带着明确目的来的。比如说成为了Committer以后:

• 有Apache邮箱，可以出去装X;
• 在公司吵架嗓门可以更大声一点;
• 可以免费申请JetBrains 全家桶(价值1000多块呐);
• 可以更多的参与到项目的建设。

等等等等...

这些都可以是你为了成为Committer的利益驱使理由。

第四点感悟，学习规则很重要

每个地方都有着自己的游戏规则，ASF也不例外，既然我们要参与其中，认同并遵循它的文化理念自然很重要。ASF遵循精英自治，投票文化，具体的建议各位去网上找 Apache之道 来看一看。

就我个人的参与感受，有几点感受很深。

首先，用英语交流。 ASF是一个国际化的基金会，自然而然的，旗下的这些开源项目面对的是全球用户，所以日常的书面交流都必须使用英语，包括代码注释、邮件、Github issue等。

其次，邮件列表讨论。ASF有两句至理名言:

1. 社区大于代码

2. 如果一个提案没有在邮件列表讨论，那么就当没有发生过

社区大于代码 ，表明ASF认为一个开源项目想要得到好的发展，其决定性因素不在于代码的好坏，而在于社区。坏代码、好社区，代码也是能够逐渐变好的；而好代码、坏社区，则项目可能就会衰竭。

而社区的发展，需要聚拢全球范围内的高共鸣度开发者和用户。这些人可能属于不同的时区，旧的人可能会离开，新鲜的血液又会进来。

如何在这样一个全球范围内、步调不一致的分布式大团队内，有效的传递信息、沉淀知识、跨时空的交流呢?

邮件列表就是一个最为古老、又最为有效的工具。

邮件列表有很多好处，例如：

1. 面向全员，订阅者皆可知。
2. 不可修改。
3. 倒逼写作者进行深度思考、梳理逻辑。
4. 保留所有的讨论轨迹、知识可沉淀传递。

等等...

但是在国内，我们更多的喜欢使用微信、QQ这样的实时工具，所以这一点必须扭转过来。其实大家尝试一下，就会发现基于邮件列表沟通相比即时消息是一种更有效的方式。

即时聊天, 快却是慢

1. 即时聊天发送消息成本很低，很多人发消息是不经思考的，关注这类消息的成本很高。
2. 消息爆炸，你出去上个厕所回来可能被刷了几百条了，而聊天话题已经被带到了西班牙，爬楼就得累死。
3. 历史消息基本是石沉大海，无法沉淀。

邮件列表, 慢却是快

1. 写邮件，会自带一种仪式感，能倒逼行文更加的结构化，思考也会更加深刻。这样一来，每封邮件的信息量和含金量都会高很多。
2. 邮件可以有效利用碎片时间，是一种拉消息的模式。你可以按照自己的节奏，利用合适的时间阅读回复。
3. 所有过程都会被保留，且方便查阅。

最后一点感悟，迈出第一步很重要

很多时候，我们总是停留在设想（YY）、规划（自嗨）阶段，迟迟不愿有所行动，殊不知迈出第一步是何等的重要。这是破圈的开始，站在圈外观摩，和身在其中是完全不同的体验。

所以请赶快迈出你的第一步吧，这第一步，

就从关注 Apache DolphinScheduler 开始吧

Apache DolphinScheduler(海豚调度) 是一个分布式去中心化，易扩展的可视化 DAG 工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。它拥有诸多的优势，例如：

• 高可靠性

去中心化的多 Master和多 Worker, 自身支持 HA 功能, 采用任务队列来避免过载，不会造成机器卡死。

• 简单易用

DAG 监控界面，所有流程定义都是可视化，通过拖拽任务定制 DAG ，通过 API 方式与第三方系统对接, 一键部署。

• 丰富的使用场景

支持暂停恢复操作. 支持多租户，更好的应对大数据的使用场景. 支持更多的任务类型，如：Spark、Hive、 MR、Python、Shell、子流程等。

• 高扩展性

支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长。Master 和Worker 支持动态上下线。

已经有大量知名企业和科研机构在使用 Apache DolphinScheduler。

Github地址: https://github.com/apache/incubator-dolphinscheduler

最后的最后，能成为Apache DolphinScheduler Committer非常荣幸，这既是一份喜悦，也是一份责任。我将以终为始，继续打怪升级 ：P