尽管我们经常说代码贡献并不是唯一的开源贡献方式，参与讨论，Review RFC 也是参与开源的良好途径。但是很多同学仍然会有疑虑：我不是项目的 Maintainer/Committer/Reviewer，我有资格 Review 别人的 PR 吗？本文以我在 envd 中的实践来阐述这样的观点：开源，无禁止即可为。

关于 envd

envd 是 tensorchord 发起的开源项目，旨在解决机器学习开发过程中环境难以部署的问题，主要团队成员包括 @gaocegege，@terrytangyuan，@kemingy，@VoVAllen 等。

受 @gaocegege 的邀请，我参加了 envd Open Source Preview：以非正式团队成员的身份加入 tensorchord ，提前看到 private 的代码，模拟开源后的流程。这是一个非常有意思的实践，RisingWave 在开源之前也组织过类似的活动，以后有机会再跟大家分享。

开源，无禁止即可为

有不少同学提出这样的问题：我想参与 Databend 项目，是不是要先学一下 Rust/Database？

实际上并非如此，Contributor 不必是资深开发者，资深开发者不是一个由外人授予的头衔。我在之前的文章中也反复强调：

开源共同体本质上都在奉行基于开源贡献的精英主义原则

资深开发者之所以资深，是因为他们有了足够的贡献；刚加入项目的贡献者如果积累同等的贡献，他们也能成为该项目的资深开发者。所以我们不必等待项目所有者的授权/批准/许可来提交代码或者 Review PR。

在 envd 的项目中，我对机器学习一无所知，Golang 已经好久没写了，Python 更是半吊子，但是这并不妨碍我参与项目特性的讨论和做出其他的非代码贡献。

总的来说，项目的新贡献者可以从以下角度参与贡献并逐步了解项目

  • 阅读并参与 Proposal 的讨论：新贡献者可以从阅读 Proposal 开始，提出自己看不懂的地方，要求作者予以补全或者进行追加解释。这其实也从侧面呼应了项目维护 Proposal 的重要性：Proposal 是新贡献者了解底层实现细节最好的途径。
  • 迁移复用自己的经验：新贡献者往往在有过其他项目的参与经验，他们可以将这些已有的经验和最佳实践迁移复用到新的项目中来。比如说新贡献者过去是 Python 的熟练使用者，那么他可以为项目与 Python 有关的模块中提出自己的改进。
  • 避免已有知识的诅咒：新贡献者对一个开源项目最直接的价值体现在他对这个项目一无所知。TiDB 社区有个著名的彦青测试就是邀请不懂项目，甚至不懂开发的运营同学来提交 Issues 和 PR，以此来检验自己项目的文档和基础设施是否健全。新贡献者往往能够发现很多特别基础而容易忽略的问题，探索项目整体的易用性和使用感，进而改进整个项目的开发体验。

开源项目中也会存在着一些保留或者明确禁止的行为。

比如说，涉及到人身攻击，种族歧视等行为，社区的维护者需要行动起来，根据已有的 Code of Conduct 规范采取相应的行动。当维护者自己存在此类的行为时，社区成员可以提出反对意见，或者选择退出这个社区。

有的开源项目会制定明确的贡献规则，只接受某些特定的贡献。比如 benbjohnson/litestream 出于简化维护负担的考虑，决定只接受文档或者 bugfix 的贡献，不接受增加新的 feature。此时贡献者也需要尊重项目维护者的意愿，避免为维护者带来困扰。

此外，发布 Release 和设定 Roadmap 等项目管理性质的操作我们通常会交由项目的维护者来执行，因为他们往往掌握最多的信息，对整个项目有更多的了解，更能代表整个开源共同体的意愿。但是贡献者仍然拥有着自由的评论和建议权利，在 Discussion 或者 Issues 中提出自己的看法。

当社区成员们对项目未来的发展有强烈冲突时，可以选择分支出一个独立的项目来进行为维护。这在历史上发生过无数次，比如说 gogs 的部分成员不满单一维护者的管理模式，决定分支出 gitea 来支持更加开发的，更快速的模式(后续：gogs 目前也成立了独立的 gogs 组织来维护)。这与前面一直在强调的无禁止即可为是不冲突的。

总结

无禁止即可为感觉像是不言而喻的事实，但是大家在实践的过程中还是很容易陷入专有软件协作模式的窠臼，没有充分发挥开源项目的开发协作价值。希望大家能够摆脱来自身份和职位的自我束缚，更积极主动地加入到开源讨论中去~