本文翻译自 Open Source is Not About You，原载于 Hacker News。
开源的本质
只有运营项目的人才有资格说开源”应该”如何运作，而且他们的权限范围仅限于自己的项目。
仅仅因为某人开源了某些东西，并不意味着他们欠世界一个身份、焦点和努力的转变——比如从发明者变成社区管理者。
作为某个开源项目的用户，你没有任何权利。你没有权利贡献代码，没有权利要求功能，没有权利获得他人的关注，没有权利让你的投诉被重视，甚至没有权利获得这个解释。
期望是你的责任
如果你对他人有未被满足的期望，这些期望是你自己的责任。你需要对自己的需求负责。如果你想要什么东西，自己去创造。
开源是一种许可和交付机制，仅此而已。它意味着你获得了软件的源代码，以及使用和修改它的权利。所有与之相关的社会附加要求，包括”社区驱动开发”的理念，都属于最近发明的神话，几乎没有基于实际运作方式的依据。这种神话以一种近乎邪教的方式，既不支持工作方式多样化，又弥漫着一种社区权利感。
关于 Clojure 和 Cognitect
如果你认为 Cognitect 没有为社区做任何事情，或者没有在倾听社区的声音，你只是错了。但你没有权利要求它是你所期望的努力、焦点或回应方式。我们有权就自己的时间和生活做出自己的选择。
我们在 Cognitect 必须每天工作来谋生。我们从 Clojure 中得不到任何版税收入。我们绝非为了利润而构建 Clojure。Clojure 用户中只有不到 1% 是我们的咨询或产品客户，从而为我们的生计做出贡献。
我们将部分收入——这些钱本可以存入退休账户——用于雇佣人员从事 Clojure 和社区外展工作，其中一些是全职的。说实话，我可以在我的退休账户里使用这笔钱，因为我当初为了创建 Clojure 已经耗尽了它。但我喜欢与团队一起从事 Clojure 工作，并为我们所做的工作感到自豪。
团队的实际投入
Alex Miller 对 Clojure 社区非常关注和投入。他和 Stu Halloway 以及我定期会面讨论社区问题。Alex 在我的指导下，将大部分时间用于为社区开发功能，或评估补丁和错误报告。我花费大量时间设计这些功能——spec、tools.deps、错误处理以及更多即将推出的内容。这些都是从谋生中抽出的时间。
我感激社区的贡献。每个 Clojure 版本都包含许多贡献。绝大多数用户社区不贡献，也不希望贡献。这没问题。开源是一个无附加条件的礼物，所有参与者都应该这样看待它。
保守的哲学
Clojure 的流程不是封闭的，但它是保守的。我认为 Clojure 从这种保守主义中受益匪浅，这与一些具有高变更率和功能膨胀的其他项目形成对比。如果你不同意或另有想法，那就太糟糕了。这是我的生活，我不会把它花在互联网上争论/谈判上。按照你认为合适的方式编写你自己的东西并运营你自己的项目。
我们总是可以做得更多，但声称核心团队阻碍了对 Clojure 的有意义贡献是站不住脚的，因为机会比比皆是：在库开发、外展、培训、教程、文档、演讲、工具构建等方面。
是的，关于核心补丁。你知道吗？大多数补丁/问题都有糟糕的问题陈述，没有计划的描述（读我的代码！），没有考虑替代方案，没有测试，没有设计，并且在某些方面构思不当或存在缺陷。社区分类工作在推动事情向前发展方面非常重要——感谢 Nicola、Ghadi 和许多其他人！
重新审视开源的预想
现在是重新审视对开源的预想的时候了。创作者之间的士气侵蚀是真实存在的。你的预想以及你如何根据它们行事是你自己且仅是你自己的责任。我不会为它们做出回应或向它们负责。
如果 Clojure 的运作方式不适合你——这个流程，矛盾的是，它首先产生了 Clojure——那就这样吧。我相信你更了解编写软件的唯一正确方法。但请在你离开时不要用自私的宣言烧毁社区。是的，每个人都有权发表意见，但是，公地悲剧等等。
我鼓励所有那些对他们认为不能做的事情咬牙切齿的人，相反地，选择一些他们能做的积极事情，然后去做。
Rich
P.S. 我在 Cognitect 的合作伙伴和同事没有被告知这条消息——我确定他们会劝阻我。这些观点仅代表我个人。
P.P.S. 我认为 Clojure 社区中的绝大多数人都是出色和积极的。如果你在上面的信息中认不出自己，那这不是针对你的！
译者思考
Rich Hickey 这篇文章在开源社区引发了巨大反响，至今仍在被广泛讨论。作为 Clojure 的创造者，他的观点虽然尖锐，但揭示了开源世界中一个常常被忽视的现实：
开源 ≠ 社区服务
很多开发者（尤其是新手）对开源项目抱有”产品级服务”的期望：希望有完善的文档、及时的 bug 修复、友好的回应。但现实是：
- 大多数开源项目由少数人在业余时间维护
- 维护者有自己的生活、工作和经济压力
- 开源许可证明确声明”按原样提供，不提供任何担保”
这对中国开发者社区的启示：
- 降低期望，提高贡献 - 如果你需要某个功能，最好的方式是自己实现并提交 PR，而不是在 issue 里抱怨
- 尊重维护者的时间 - 提问前先搜索、提供完整信息、写好 issue 模板
- 理解”礼物”的含义 - 开源代码是别人免费分享的成果，使用时应心存感激
另一个视角：
当然，Rich 的观点也有争议之处。很多成功的开源项目（如 Vue.js、React）确实将”社区驱动”作为核心理念，并因此获得了巨大成功。开源可以只是一个许可机制，也可以是一种协作模式——这取决于项目维护者的选择。
关键在于：这是维护者的选择，不是用户的权利。
核心观点总结
- 开源是许可机制，不是社区义务
- 用户没有权利要求功能、回应或服务
- 维护者有权决定自己的时间和项目方向
- 贡献是礼物，不是交易
- 保守的开发节奏可以避免功能膨胀
- 与其抱怨，不如自己动手