GreptimeDB 首位独立 Committer Eugene Tolbakov 是怎样炼成的？
"我非常喜爱 GreptimeDB 开源社群，它总能快速回应我的提议或评论，并且非常专业。"来自 GreptimeDB 社区的 首位 Committer，Eugene。
他是 GreptimeDB 社群的首位独立 Committer，对 PromQL 支持、SQL 引擎、InfluxDB API 兼容性等模块均做出了重大贡献。
（p.s. 本次访谈由 Greptime 开发者关系 &增长总监 tison 牵头完成，GreptimeDB 核心开发者夏锐航参与，访谈对象为 GreptimeDB 的首位 Committer：Eugene。本次文字材料和行文记叙视角均为 tison。）
初识 GreptimeDB
Eugene 的本职工作是一家大型国际银行的平台工程师，主要负责开发 Java 中间件。在日常工作以外，Eugene 一直热衷于探索技术创新的新趋势。
近年来，从新型数据库到前端、AI 工具链，Rust 被许多前沿技术创新所采用和信任。GreptimeDB 同样选择 Rust 作为其主力开发语言，实现了一个能够联合处理 Metrics 和 Logs 的开源分布式数据库。
2023 年初，Eugene 寻找值得参与的 Rust 项目时，发现了刚在 GitHub 上开源的 GreptimeDB。GreptimeDB 一经开源就迅速引起了关注，在 GitHub 全球趋势榜上连续占据了几天的榜首位置。出于对 Rust 数据库项目的兴趣，Eugene 决定写几个 PR 来试试 GreptimeDB 社群的水温。
GreptimeDB 团队维护了一个 good first issues 列表，团队成员会实时关注并及时回复对其感兴趣的社群成员的问题，Eugene 也是从一个 good first issue 开始参与的。他解决的第一个 issue 是一个相对简单的重构：
db#855 Remove backtrace from sql::error::Error
如上图对话所示，在参与贡献的过程中，Eugene 还主动提出了许多其他改进建议，并积极和团队沟通讨论。这个 issue 完成后，Eugene 又做了另一个简单的重构：
db#1002 refactor(storage): remove unused FlushIo variant
深入交流，持续贡献
从小处着手，逐渐深入地做开源参与，是开源开发者常见的贡献模式。在此过程中，开源开发者们会衡量社群价值和响应速度，判断社群是否值得自己投入时间参与。通过这几次重构，Eugene 发现 GreptimeDB 是一个响应迅速的社群，并能提供即时反馈和清晰的参与路径。
随着 Eugene 越来越熟悉 GreptimeDB 的代码，他开始上手解决更复杂的问题。Eugene 实现的第一个不一般的功能是 db#1186 支持 to_unixtime SQL 函数：
随后，他为实现了一系列 PromQL 查询函数，极大提升了 GreptimeDB 的 PromQL 兼容性。如今，GreptimeDB 支持超过 82% 的 PromQL 功能，其中不少是 Eugene 实现的。其余部分则由 Eugene 在 GreptimeDB 社群的主要领路人之一夏锐航完成，Eugene 亲切地称呼他为“大师”。
成为第一位 Committer
鉴于 Eugene 长期稳定的高质量贡献，GreptimeDB 团队于 2023 年 6 月正式提名 Eugene 为 GreptimeDB 社群成立以来首位独立 Committer。
我在 GreptimeDB 积极探索了商业开源软件（COSS）项目当中独立开发者者如何参与协作的问题。一般来说，这需要仔细平衡 CODEOWNER 治理风格和基于信任的同侪社群风格。前者是公司为保证软件交付质量所必须采取的策略，因为你从机制上就无法 blame 一个非公司雇员的开发者。而后者则给予了开源贡献者更高的参与感和自由度，更能释放他们的潜能，并鼓励他们承担更多模块的责任，甚至影响项目的方向。
绝大部分 COSS 项目最终逐渐拒绝独立开发者的“外部贡献”。但是，我相信商业组织和个人的协调并非不可能，只是需要作为主导方的企业多做一些制度设计上的投入。Eugene 的经历说明了 GreptimeDB 社群某种程度上是由 Greptime 团队和热情的独立开发者共同构建的。在 Eugene 首次被提名为 Committer 后，Greptime 团队又陆续提名了几位新的 Committer，未来我们也将继续分享他们的故事。
有效的沟通机制
我问 Eugene 对 GreptimeDB 社群有什么感受，Eugene 立马回答到社群响应迅速并且非常专业。
及时响应对社群吸引开源开发者至关重要。我太清楚很多开源爱好者是如何为一个不响应的上游社群所挫败了。没有及时反馈，开源参与者无法确定自己付出时间所做的贡献是否符合上游的需要，或者是否有类似的工作已经在项目内部进行。缺乏响应时效的社群经常将 Pull Request 搁置数月甚至数年。再差一点，有时上游团队的内部成员可能会提交一个类似甚至相同的 Pull Request 并由另一个同伴立即合并（经典的“漩涡事件”）。这基本可以击溃一个独立开源参与者的参与热情。
在 GreptimeDB 社群，我们的共识是将 good first issues 尽量交由独立开发者完成；团队成员尽可能在 24 小时内回应贡献者的问题。当然，如果某个 good first issues 成为功能开发的 Blocker，那么团队成员会直接解决掉，同时在 issue 上及时更新进展。
有一次，Eugene 想接手处理一个与 InfluxDB API 兼容性相关的问题。我先回应了他的请求并一起做了一些调研，在 issue 上同步了一系列有价值的结论。然而，由于其他功能开发任务被这个问题 Block 了，Greptime 的技术 VP 冯家纯接手了这个工作。Greptime 的创始人庄晓丹（Dennis Zhuang）于是在 issue 上明确告知 Eugene 说家纯正在进行内部开发，他可以把时间投入到其他 PR 上，等到家纯的 PR 就绪以后再加入 Review，这样可以避免一些时间投入冲突。
持续进步，共创未来
由于一些本职工作和个人原因的影响，Eugene 从去年下半年开始，有几个月没有出现在社群当中。今年一月份，当 Eugene 重新出现在社群当中并恢复参与贡献时，Dennis 在团队内部兴奋地宣布：“Eugene 回来了！”
随着时间的推移，Eugene 对 GreptimeDB 的代码库越来越熟能生巧，他现在能熟练地调试 SQL 引擎、实现功能和修复查询引擎代码路径中的错误。目前，Eugene 正在实现一个非常有意义的功能：通过允许用户在 CTE 中编写 PromQL 查询来支持 SQL 查询和 PromQL 查询混编（db#3860）。
访谈结束前，Eugene 向我提问了一个开源开发者非常常见的问题：
我能为 GreptimeDB 做些什么？我应该如何进一步参与？
对于这个问题，官方回答通常是：“找到你感兴趣的地方直接参与就行，我们欢迎任何形式的贡献。”然而，这种回答几乎没有意义。因为当开源开发者有这个问题时，他们通常也不知道应该对什么感兴趣。
在我看来，进一步参与开源社群的切入点有两个值得考虑的方向：
首先，如果这个开源软件能够解决你在本职工作或个人项目当中遇到的问题，那再好不过。你是这个软件的用户，在使用它的过程中，发现的任何问题或功能需求，都是最佳的参与切入点。GreptimeDB 将在 v0.9 版本中发布日志处理和分析功能，或许能帮到 Eugene 本职工作中现在用 OpenSearch 的解决的问题，或者成为某种参考。希望 Eugene 在 v0.9 发布后两相比较，向 GreptimeDB 提出问题或者补全短板。
其次，如果开源软件技术含量较高，其中充满各种技术挑战，那么开源开发者可以尝试像解谜一样，将开源参与作为一种业余爱好来锻炼自己的编程技能。GreptimeDB 团队将持续发布 good first issues 和重要不紧急的 help wanted issues，这些都可以作为开源开发者参与贡献的起点。
最后，衷心希望 Eugene 享受在 GreptimeDB 社群度过的时间！也期待越来越多的开源开发者加入我们，享受开源世界的乐趣！
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
专注于 Infra 技术分享 2022-09-23 加入
分布式、高性能、存储计算分离的开源云原生时序数据库
评论