多年来，我一直认为开源软件并不适合我。除了现有的开发者社区职责之外，我并没有加入任何开源社区的打算。
由于对Bluesky上提到的那些关于开源软件的讨论感到好奇，我最近一时兴起加入了npmx的Discord服务器。从最初的旁观者逐渐转变为贡献者，这个过程让我对开源软件有了更多的了解，也让我在参与代码评审时变得更加自信。
在这篇文章中，我将分享自己的经历，希望能为大家提供一些关于如何参与开源项目的见解。
本文将涵盖以下内容：
我在处理拉取请求时遇到的困难
我必须承认，我一直不太擅长进行代码评审。我是个相当追求完美的人，会认真考虑每一个细节，也因此总是把批评当作重点来对待。
如果代码评审持续了好几天，我会很容易感到不堪重负。虽然我喜欢与他人合作共同完成工作，但处理拉取请求中的评论确实让我耗费了很多精力。
我遇到的其中一个问题是，我需要一些特殊支持，但这些支持却很少能够得到。此外，我也亲身经历过代码评审可能会变得多么激烈（即使是在专业环境中）。最后，我当初接触代码评审的方式也对我产生了一定的影响。
在工作之外，我所经历的拉取请求审核往往都很敷衍了事——最多只会收到一条建议，而通常得到的评论也只是“看起来不错”而已。而在工作中，我的代码评审体验却发生了巨大的变化，几乎一夜之间，我就开始面对极其详细的评审。直到现在，我仍然觉得自己还在努力追赶这个节奏。
不过，深入思考每一个建议确实让我成为了一名更好的开发者。在那些有认真进行代码评审的合作环境中，我能够更好地发挥自己的能力。与我合作过的开发者们也告诉我，他们很享受回答我那些“为什么”的问题。
另一方面，我期望我的评审者们能给予我赞美、分享动图，或者进行视频通话。对于那些含糊其辞的评论，我实在无法适应。我花费了大量时间来制定代码规范和评审流程，然而其他人似乎比我能更容易地理解并记住这些内容。
开发者社区帮助我应对了这一切。对于那些想要转变职业方向的人或是刚毕业的学生来说，社区是一种无价的资源。当大家分享自己的经验时，新手就能了解到事情应该怎样进行，哪些行为是不正常的（比如那些充满敌意的代码评审）。
我之前对开源软件的看法
在我谈论或撰写有关开发者社区的内容时，我总是推荐人们加入在线交流社群、参加聚会、技术会议、使用社交媒体，以及写作并将自己的作品发布到网上。但有一件事，我却从未提及过——那就是开源软件。
我第一次真正接触开源软件，是通过一个名为Virtual Coffee的在线交流小组。在参加完我的第一次Hacktoberfest活动之后，我已经掌握了关于开源软件的一些基础知识。
开源软件的基础知识
-
找到一个你感兴趣的项目。
-
查阅相关的贡献指南。
-
选取一个需要修改的问题进行修复。
-
按照贡献指南的要求，创建一个新的代码分支，编写相应的代码，然后提交一份Pull Request。
-
项目维护者会合并你的代码。
-
你就成功完成了！这就是开源软件的开发过程。
开源软件的阴暗面
随着时间的推移，我逐渐意识到了开源软件的一些阴暗面——有些维护者会精疲力竭，用户与维护者之间也会出现矛盾，有些企业还会试图控制开源软件的发展方向（例如WordPress、Ruby等案例）。此外，维护那些被大家广泛使用但却没有人愿意为此付费的开源项目，也是一份既辛苦又令人沮丧的工作。
说实话，我开始把开源软件的维护者想象成《怪物公司》里的罗兹——她们确实应该对那些不懂得感激的人强加给她们的额外工作感到愤懑。
与这些开源项目的维护者当面交流后，我发现他们的经历与我的看法并无矛盾。他们每个人都讲述了关于开发者倦怠问题以及资金不足的困境。我开始认为，那些对开源项目充满热情的人，其实只是参与时间还不够长而已。
……因此，当我突然宣布自己加入了npmx这个开源项目时，我的朋友们都感到非常惊讶。
开始使用npmx
最初让我对npmx项目产生兴趣的，并不是关于它的任何介绍或报道，而是一个网络迷因Daniel Roe已经有一段时间了，知道他非常聪明。我喜欢向比自己更聪明的人学习。
我联系了Patak，并得到了邀请，加入了npmx的Discord社区
这就是我想要的！终于可以享受提交代码修改请求的过程了。 于是我进入了npmx的GitHub仓库
Jono热情地邀请我参与他的分支项目，帮忙编写博客页面的相关内容。但在尝试在本地运行这个仓库以及设置预提交钩子时，我遇到了很多令人沮丧且奇怪的问题。有很多人试图帮我解决问题，但他们也同样搞不清楚这些问题的原因。 第二天，Salma加入了团队。第三天，她负责对外联络工作，并让我写一篇博客。然而后来由于一些其他事情的干扰，我没能按照约定将代码更新到新仓库的功能分支中。最终，我觉得自己能为这个项目做出的贡献，仅仅只是修改了博客页面上的几行文字以及写了一篇博客而已。 更糟糕的是，我对自己刚开始写的这篇博客并不满意。于是我就不再继续写了，只是在Discord频道里偶尔参与一些讨论，有时也会帮忙解决一些与可访问性测试相关的问题。 几天后，Knowler审阅了我的初稿，于是我之前所有的焦虑又都回来了。我觉得这次提交的Pull Request一定会非常完美。在我准备好为自己所做的修改进行辩护之前，谁敢先来看这份代码呢？看到那些我从React复制过来、尚未完成移植到Vue中的代码，别人会怎么评价我的能力呢？想到有人会看到我这种状态的代码，我真的感到非常尴尬。 在这种尴尬感的驱使下，我开始加紧工作。在剩下的有限时间里，我反复修改了那段代码，终于在三天后让它达到了令我满意的状态。现在，是时候将这份Pull Request提交给其他人审阅了。 有几十条评论出现了。面对这些评论，我感到有些不知所措，但我想起了自己当初确实是提出了这个修改请求的。我解决了其中大部分问题，并留下一条评论，表示会在早上处理剩下的那个问题，也就是强制颜色模式的相关修改。由于对强制颜色模式的代码感到不满意，同时也因为自己忘记了一些细节，我决定去和朋友一起玩游戏放松一下。 几小时后，丹尼尔给我发来了一条私信。他提供了一些代码，用于完善我的Pull Request。我对他所提出的所有修改意见都表示认同，同时也发现，在我完全忽略项目其他部分代码的这段时间里，竟然还有人添加了一个完整的工具提示信息。（我相信自己有能力通过合并或重新编写代码来解决任何问题。） 由于同时要处理Enshrouded项目的相关工作，还要与丹尼尔进行交流，我感到有些力不从心。我知道第二天就能完成强制颜色模式的修改工作，但添加工具提示信息这个任务似乎还是让人感到有些畏惧。不过，我还是觉得必须把这两件事都做完。 然后我想起来了：这其实并不属于工作内容，也不会被纳入绩效评估中。我并不是唯一一个这样做的人——Knowler和Daniel也专门花时间帮我合并这些代码更改，因为他们确实是出于自愿才这么做的。我有机会与一些非常优秀的人一起合作，看看他们是如何完成同样的工作的。 所以我克服了自己的完美主义倾向，不再过分追求细节，还让Daniel把他的修改提交过来，并告诉他我会在早上审阅这些代码。 在审查Daniel的代码时，我发现他也忽略了一些小问题，和我之前犯的错误一样。前一天晚上让我感到非常困扰的那段代码，确实让人很头疼。在Mac上模拟强制颜色显示的效果导致出现了一些奇怪且矛盾的结果。我需要在Windows系统上进行测试，才能最终解决问题。 终于，在提交这些代码更改六天后，我成功地将它们合并到了项目中。我感到无比兴奋——在我的假期之前就为这个项目做出了贡献，而且还收到了很多表扬。现在，我知道该写什么内容来记录这次经历了。 当你寻找一个自己感兴趣的项目时，代码并不是唯一需要考虑的因素。在我职业生涯的早期，我总结了三条评估软件工具的标准。 查看最后一次更新的日期，确认该项目是否还在得到持续维护。 看看相关文档是否是最新的，以及是否容易理解。 了解这个项目的社区氛围：人们提出问题后能否很快得到回复。 加入npmx之后，我发现这些标准同样适用于评估开源软件项目。只需稍作调整，就可以应用到这些项目中。 查看最近的一些问题报告和代码提交请求，就能了解这个项目的开发进度。如果进展缓慢，那么在GitHub上提出问题应该比较容易；如果发展迅速，那就先了解一下社区的氛围以及他们是如何处理问题的。 一定要检查该项目是否有行为准则、贡献指南以及足够的文档资料。同时也要评估这些问题报告：贡献者是需要自己寻找解决方案，还是会有明确的指导要求？维护者们又是如何回应用户评论的？ 了解这个项目的社区氛围——一个活跃且包容的社区会让参与开发变得更加有趣。 现在，我对开源软件的看法已经变得更加复杂和全面了。的确，开源软件整体上存在一些问题，但人们之所以想要解决这些问题，也是有着原因的。开源软件完全可以是一种协作性强、能激发灵感且使用起来令人愉悦的工具。 人们往往低估了提交代码请求的人与审核者之间关系的重要性。一个高效的开源代码审核流程绝不是在孤立的环境中形成的，它需要提交代码请求的人、审核者以及整个项目社区共同努力来维护。 很长一段时间里，我都认为审核者的责任就是让提交代码请求的人感到舒适（比如给予表扬或发送一些有趣的图片）。但请不要误会我的意思——我认为，对于一位资深开发者来说，提供具有建设性且可行的反馈才是最重要的职责之一。 然而现在我意识到，提交代码请求的人自身的主动性以及他们的学习意愿同样非常重要。 所谓的“主动性”，其实就是对自己所采取的行动及其可能产生的结果拥有控制感。换句话说，提交代码请求的人必须觉得自己能够掌控自己提交的代码内容。在参与npmx项目之前，我对这一点理解得还不够深入；我总是会追问“为什么这样做？”因为我不愿意在自己不理解或不同意的内容上署名。我也曾经告诫过我的初级开发同事，让他明白让自己的代码得到审核并最终被合并是他的职责。 在业余时间亲身经历过一次深入的代码审核之后，我才终于明白了：提交代码请求其实是一个完整的流程。进行审核的目的就是为了达成共识，因此“完美”这个标准其实比我最初想象的要主观得多。交流的目的是为了寻求共识，而不是给出一个简单的评分。 也许将来我会选择忽略一些琐碎的细节。 强烈的学习意愿会让人更容易接受审核者的建议和要求。在我第一次参与npmx项目的时候，正是由于我的学习欲望超过了想要证明自己的冲动，我才开始真正享受这个过程。 今天是2026年3月3日，npmx刚刚发布了alpha版本，能够成为这个项目的贡献者和社区的一员，我感到非常自豪。 我期待着从Patak那里学习关于开源软件的知识，从Daniel那里学到一些巧妙而实用的编码技巧，从Salma那里了解到如何更好地进行项目推广，同时也能向Knowler学习有关代码可访问性的相关知识。我相信，除了这些方面之外，我还会学到很多其他的东西。我很庆幸自己并不是这个团队中最聪明的人，也终于能够开心地参与到提交代码请求的工作中来了。Alex
合作比追求完美更重要
我目前对开源软件的看法
给提交代码请求的人和审核者的建议
结论