在开源社区被骂了两千条，我反而找到了新方向

2024年，我第一次给开源项目提PR。

被maintainer骂了整整两个月，评论区的讨论串加起来超过两千条。

现在回想起来，那是我职业生涯里最重要的一段经历。

起因：一个"小"功能

我是阿May，一个后端开发，平时写Java，偶尔摸Python。

那时候我在做一个数据同步工具，用的是GitHub上一个叫DataX的开源框架。用了三个月，我发现有个痛点——它的配置只能写JSON，但我的团队都是YAML选手，每次都要手动转换，太麻烦了。

我想，那就提个PR呗，加个YAML解析支持。

我以为这是个"小"功能。

第一轮：你不懂，别乱改

我花了一周写代码，提交了PR。

第二天，maintainer回复了，洋洋洒洒写了一千多字，总结下来就是："你不懂DataX的架构设计，别乱改。"

我不服。我仔仔细细读了他的评论，发现他说得有道理——我确实没考虑到某些边界情况。

于是我改，改完再提。

他又回了一千字，这次指出了更多问题。

我再改。

他又回。

那段时间我每天下班回家就是改代码、改文档、写测试。整整两周，我提交了12个commit。

第二轮：更大的冲突

改到第12个commit的时候，我遇到了一个问题——我引入了一个新的依赖库，但这个库的License和DataX不兼容。

maintainer直接在评论区说："你这个PR不能合并，原因很清楚。你要么换依赖，要么自己维护一个fork。"

我开始觉得委屈了。

我花了两周帮他写功能，结果他说不能合并？我的第一反应是愤怒："你为什么不在一开始就告诉我不能引入这个依赖？"

我在评论区回了一句："如果一开始就这么说，我根本不会做这个功能。"

maintainer的回复更直接："如果你在提PR之前仔细读过 CONTRIBUTING.md，你会知道我们不推荐引入新依赖。"

我去翻了 CONTRIBUTING.md，发现他说的没错。

对了。顺嘴提一句，技术大厂，前后端-测试机会，全国一线及双线城市均有 坑位，待遇和稳定性还不错，感兴趣看看。

第三轮：最狠的一刀

改到第18个commit的时候，maintainer说了一句让我破防的话：

"你的代码质量不错，但你的沟通方式需要改进。"

他说："在开源社区，我们不只看你提交了什么代码，还看你怎么和别人讨论问题。你之前的每一条评论，语气都很防御——'我不是这个意思''你误会我了''我查过了'。"

"开源社区的协作，不是'证明我是对的'，而是'一起找到最好的方案'。"

我后来的转变

这句话让我沉默了三天。

我开始反思自己为什么这么防御。

我发现，我从小受到的教育就是"正确答案只有一个"，考试要拿满分，错了就要改。这种思维迁移到工作里，就变成了：被指出问题 = 被否定 = 我不行。

但开源社区不是这样的。

开源社区的逻辑是：被指出问题 = 有人在帮你改进 = 这是合作，不是竞争。

我调整了我的沟通方式。我开始说"我没想到这个角度，谢谢你的建议""你这个思路很好，我来试试看""这个地方我确实没想清楚，能展开讲讲吗"。

maintainer的态度也变了。他开始叫我"contributor"而不是"你"，开始主动帮我review代码，开始在我遇到问题时主动给建议。

转折：一个意外的收获

PR合并后的第二个月，maintainer给我发了一封邮件：

"阿May，我们团队正在招聘，需要一个对中国市场熟悉的贡献者。你有兴趣吗？"

我做梦都没想到，一个被骂了两个月的PR，最后变成了一个工作机会。

现在我在做什么

我现在是DataX项目的核心贡献者之一，主要负责社区运营和新用户引导。

我做过最有成就感的一件事，是帮一个新提PR的开发者翻译了一份"如何正确提PR"的指南——因为我也被骂过，我知道新手最需要什么。

有时候我会翻回那条两千多条评论的讨论串看看。

那两千多条骂我的话，我现在想起来，都是恩情。

给想参与开源的程序员一句话

如果你也想给开源项目贡献代码，记住三件事：

先读文档，再提问题。maintainer的时间很宝贵，别用"我没有仔细看过文档"来浪费别人的时间。


被批评是成长的开始。开源社区的批评是最直接、最有用的技术反馈，珍惜它。


沟通方式和技术能力同等重要。代码写得好不好决定你能不能进来，沟通方式好不好决定你能走多远。

开源社区不是"证明自己厉害"的地方，是"和一群人一起做一件有意义的事"的地方。