开源项目维护者眼中的开源-钟嘉杰

1 . 2022 维护者眼中的开源 — 以 Apache DolphinScheduler 讲师: 钟嘉杰, Apache DolphinScheduler PMC, 白鲸开源数据工程师 

2 .目录 CONTENTS 01 什么是开源 02 开源社区的组成 03 有趣的事 xx 

3 . 01 什么是开源 

4 .什么是开源 此处特指开源软件(open source software, 缩写 OSS), 又称开放源代码软件, 是一种源代码可以任意获取的计算机软件. 一些开源软件被发布到公有领进行托管, 如 GitHub, GitLab, Gitee 等, 常见的开源软件有: • 操作系统: Linux Kernel, Chrome OS, 基于 Kernel 的各种发行版等 • 数据库: Postgres, MariaDB,MongoDB, Redis 等 • 编程语言: JavaScript, OpenJDK, CPython 等 • 中间件: Nginx, Apache HTTP, Moby(docker) 等 

5 . 02 • 反模式 开源社区组成 • 在局中 • 组成 

6 .反模式 • 有好的 idea: 保密 → 公开. 公开域交流问题, 提出建议. • 项目控制力: 垄断集中 → 开放分散. 从单国家, 单公司到任何人. • 人员组成: 一夫当关 → 集体智慧. 开发人员单箭头, 到集百家所长. 

7 .在局中 以为与开源很远, 殊不知你已经在局中了. • 有库写入权: 开源组织项目, 或公开私人项目. • 贡献过代码: 参与公开项目代码、文档等贡献. • 参与过讨论: 创建过 issue, 邮件列表、issue、discussion 甚至私下讨论. • 使用过项目: 使用过开源项目, 或者推荐项目给别人. 

8 .组成 • 用户: 使用项目, 但没提交代码、文档、对issue分类梳理, 但有部分会提交 issue • 贡献者: 向项目贡献过代码、文档, 或者参与 issue 分类, 但是还没有项目写入权限 • 维护者: 除了贡献项目外, 还需要审核、合并项目 PR, 有项目的写入权限 注意: 此处漏斗进说明数量, 和角色变化切换, 并不代表重要性 

9 .03 有趣的事 

10 .我的时间分配 总时间 纯开源时间 自由浏览 10% 纯开源 30% ask 20% 负责 50% 公司 70% 发版 20% 

11 .部分疑问解答 • issue、PR review 时间长 • 邮件列表、slack、微信群响应不及时 • 1-3: 时间没有想象的多 • 私聊没有及时反馈 • 4: 对开源理解有误 • 提了一个bug、PR, 怎么感谢我 • 5-6: 很可能只是个别需求 • 提了建议很久还没有实现 • 7: 发版比想象中要复杂 • 这么经常的用法, 为什么你们没有 • …… • 怎么这么久还没有发版 • …… 

12 .一个issue、PR需要的时间 PR Issue • 简单(1-10min): 一眼看懂并给出建议 • 简单(1-5min): 通过文档指引, 文字解释能解决 • 中等(11-30min): • 中等(6-20min): 本地复现, • 判断原始 issue、修改合理性 • 困难(20min以上): • 是否有更好的方式 • 确定各个版本的差异 • 是否影响别的功能 • 确定环境 • 单元测试、文档是否完善 • 确定用户是否能稳定复现 • 困难(30min以上): • 定位代码 • 中等的全部 • 解决问题 • PR拉到本地不断校验测试 一个 PR 根据修改模块重要程度, 可能需要多次、多人 review 保证其正确性 

13 . 我认为开源层级 好 成功 有意义 能解决一个领域问题, 解决一个领域问题, 并与时俱进 能解决小部分人的需要 该领域从业者都知道, 且有站台者 可以: 更新不及时, 几乎不维护, 很少发版 或者解决大部分人需求 可以: 更新较慢, 维护较少 更新迭代快, 持续发版, 维护者多 Parquet PMC Chair 感慨新老交替 Flask 维护者将 issue 和 PR 清零 

14 . THANKS！ Ending