参与开源有一个正确的方法

最近有很多关于贡献开源的声音。许多开发者出于各种原因参与开源项目，包括为招聘人员建立他们的提交历史或通过徽章获得可见性。然而，经验丰富的开源贡献者观察到一个令人不安的趋势：贡献被视为一种义务和荣誉勋章，当它不直接时会导致挫败感。

我的同事丹妮拉最近分享了她关于贡献开源有多么困难的想法和经验。我承认：这对我来说很难读下去。我感觉自己作为一个高级开发人员、导师以及开源社区的长期成员都失败了。然后我开始思考开源的现状，丹妮拉写的内容很有道理：对于新手来说，一切似乎都受到炒作、星标数、点赞数、粉丝数的驱动。我们有技术影响者、技术摇滚明星在会议上发表主题演讲，我们还有招聘人员扫描 GitHub 个人资料。

今天的贡献是为了可见，而不是为了有帮助。我认为我们这一代开发者应该为此负责。

在这篇文章中，我想总结一下丹妮拉的故事，并进一步阐述我对她的回应。

对于初学者来说，挣扎是真实的

丹妮拉遵循了所有常见的最佳实践。她开始她的旅程，向同事寻求建议，最常见的回答是寻找标记为“初学者”或“需要帮助”的问题，可能在她已经在工作中使用的项目仓库中。不幸的是，在深入研究了许多 GitHub 仓库后，她发现它们要么没有标记“好的首个问题”的项目，要么已经被分配了。

然后她搜索了不太知名的库，但只找到了她回忆为“复杂的任务，即使标记为初学者，也意味着你必须非常了解代码库才能修复即使是很小的东西。” 在这个时候，她放弃了。

几个月后，她再次尝试了 Hacktoberfest，再次从初学者列表开始。猜猜怎么着？又一次，每一项都已经被认领了。她进一步尝试了基本的 CSS 修复和文档，但也都失败了。

最终，她遇到了一位 Qwik（一个流行的 JavaScript 框架）的贡献者和 Qwik 库的维护者。在他的帮助下，她设法处理了一个问题，起草了一个拉取请求并将其合并。最后，她得到了她想要的，但想知道是否值得。毕竟，她花了很多时间寻找可以做的事情，然后不得不寻求帮助才能完成。最终，她意识到“为了贡献而贡献”或因为害怕错过而贡献是不值得她花时间的。

她的结论是什么？她会建议新手做他们真正想做的事情，不要感到被迫为了做而做，而是做一些对他人有益的事情，而不仅仅是对自己。

贡献的真正含义

你可能已经注意到她话语中的一种模式。驱动力似乎是需要拥有一些“可证明的”东西，比如 GitHub 上的提交，因此任何其他开源活动都完全不在考虑范围内。我想将重点转移到我认为贡献开源意味着什么。

如果我们坚持开源促进会 (OSI) 的定义，该定义源自 Debian 对自由软件的定义，我们只讨论源代码如何被访问以及管理软件分发的许可证应该如何编写。

但是当我们谈论开源时，我们不仅仅是在谈论代码。我们正在谈论一种对待软件的方式，设计它、开发它、分发它、传播它，使其成为对每个人都有益的东西。因此，在这种背景下，作为一名开发人员意味着将软件视为一种公共物品，而贡献意味着使其变得更好，如果更好意味着更有用、更易访问、更安全、更强大、更稳定和更易于使用，那么很明显，我们不仅仅是在谈论编写代码。

列出所有非代码贡献是没有意义的，我只想指出参与创建指南、文档和翻译的团体，那些试图传播最佳实践的团体，或者所有处理标准化的工作组。但是想想 GitHub 问题中产生了多少有价值的讨论，这些讨论导致了更好的软件。这些活动都不会在你的 GitHub 个人资料的贡献网格中生成绿色方块，但每一项都有助于改善整个生态系统。

你为什么要贡献

当我在 2000 年代初在博洛尼亚开始上大学时，我接触到的第一个社区是一个非正式的 Linux 用户小组，他们组织了安装节，也就是更有经验的用户指导新手完成安装和运行的日子。

除了引导我们完成 Gentoo（不是随机选择）的安装过程外，他们还就当我们遇到问题或注意到可以改进的地方时该怎么做提出了建议。你可能已经猜到，这包括发布到我们的新闻组、在官方 Gentoo 论坛上发起讨论，甚至使用邮件列表。这种方法使我和我的同伴们很自然地想到，每当有机会出现时就与社区的高级成员沟通，起初只是作为琐碎问题的提出者，然后更精细，最后作为解决方案或改进的提出者。

结果呢？我可能从未向 Gentoo 代码库提交过代码，但当我回答同事关于如何通过创建一个指向错误路径中的库的符号链接来修复编译错误的问题时，我感到对社区很有用。

几年后，我开始使用 Drupal，它是最大、对我来说也是最美丽的自由软件项目之一。在问题跟踪器上与其他用户互动、建议补丁和报告错误对我来说感觉很自然。当然，从自动化测试中获得上传补丁的绿灯是一种很好的感觉，当它合并时，我觉得我可以像平等的人一样与 丹尼斯·里奇 交谈——所以我对这种奖励机制并不陌生。

然而，驱使我贡献的不是奖励。这成为了一种必然，因为我经常离向客户交付工作只有几个错误之遥，然后我觉得我至少必须回报别人我所得到的，所以我发现自己回应那些遇到我懂得如何克服的问题的人，或者有时只是通过提供可能帮助他们理解如何重现错误的环境来提供帮助。

对我来说，这曾经是，现在仍然是，一种商业动机。“不要重复发明轮子”是我的座右铭，在别人已经引入和完善的基础上再接再厉，使其变得更好，参与塑造技术未来的倡导团体以及开源世界的许多其他方面，这些方面由 OSI 等组织以及 Linux 基金会 或 Drupal 协会 编纂和监管，所有这些方面都直接影响着我们的工作，从而影响着我们的业务。

阅读丹妮拉的文章让我有了一种完全不同的体验。与她交谈后，我首先意识到她没有找到我在大学环境中找到的那种宽容和欢迎的条件，后来她也没有从找到我找到的社区中受益。

因此，驱动我的以及我认为我周围许多人的社交、功利和归属感动机都缺失了，剩下的只有奖励。当然，认可一直有助于区分社区的活跃成员与其他人，但它从未产生如此强大的压力，以至于驱使某人仅仅为了可见而贡献。我似乎在拼命寻找可以贡献的项目中看到了这个问题，任何项目，只要它受欢迎并且公开承认贡献，尤其是当它在 GitHub 上时，GitHub 在这里变成了衡量开发者受欢迎程度的社交网络。

游戏化、徽章、点赞，这些都是好事，我们喜欢它们（让我们不要虚伪），但如果它们是今天人们贡献的主要原因，那么我们就有一个问题，而且可能是我们自己造成的。我们创造了一个环境，在这个环境中，可见比有帮助更重要，我们已经将这个信息传递给了新一代开发者，但我们今天告诉他们，这些动机是错误的。

所以我认为重申做开源意味着什么很重要。
让我们从这个基础开始，尝试调整焦点。

如何以正确的方式贡献

让我们从一个基本概念开始：你不必贡献！

有很多很棒的程序员，他们在公共 GitHub 仓库中没有提交过代码，但他们每天都在使用开源项目。有时专注于工作，或者可能忙碌的个人生活，使得很难找到时间贡献，这不是问题，不应该让我们感到内疚。
帮助同事使用一项技术，并通过在你的同龄人中传播使其更易于访问，这些都是真正有益于整个生态系统但不会让你获得徽章的活动示例。

但是，如果在提出所有这些观点之后，仍然渴望出现在项目的 CHANGELOG 中，因为它使我们在招聘人员眼中更受欢迎，或者因为它使我们在社区中感觉更重要，这些都是我完全理解的事情，那么我可以尝试就如何贡献提供一些进一步的建议。

• 从你使用的东西开始。你可能每天都在使用库或框架，现在你已经很了解它们了；这些是完美的入门项目。如果你需要自定义某个功能以使其对你的项目更有用，或者你发现了一个错误，或者你看到某些文档可以改进，这就是你的机会。
  
• 没有所谓的“愚蠢的贡献”。如果你认为你有一个解决问题的方案或改进某些东西的想法，不要害怕分享它。如果你不确定，请征求反馈，但要知道每一项贡献都是有价值的，可能发生的最糟糕的事情是被拒绝。
  
• 不要害怕提问。如果你不明白某些东西或不确定该怎么做，请提问。有很多渠道可用，从官方文档，到问题跟踪器，到社区论坛，到聊天，到邮件列表。大多数（希望所有）社区都热情好客，乐于助人。
  
• 不要忽视非代码贡献。你可以帮助翻译、文档、测试（顺便说一句，测试也是编码…），甚至只是通过传播项目的消息。
  
• 超越 GitHub。许多开源项目不在 GitHub 上，但它们仍然需要关爱。问问 Drupal 就知道了。
  
• 参与讨论。GitHub 上的 Issues 和 Discussions 是最受欢迎的，但不是唯一的入门方式。你可以从这些讨论中学到很多关于项目的信息，评论可以提高你的知名度和社区参与度，并且通常可以带来代码贡献。

结论

开源不仅仅是代码。这是一种思考软件的方式，贡献意味着使其变得更好。
你没有义务贡献，我希望将来我们能够为新的贡献者创造一个更受欢迎的环境，并且奖励机制将改变以反映努力和奉献精神，而不仅仅是提交。

感谢您的阅读，如果您有任何问题或意见，请在 Mastodon 或 LinkedIn 上联系我。