Hacker News 中文摘要

RSS订阅

跑路、分叉与开源封建主义 -- Rug pulls, forks, and open-source feudalism

原文链接 | HN讨论 | 2025-09-06 21:04:43

文章摘要

开源软件开发中存在复杂的权力动态，大型云服务提供商往往拥有最大影响力，可能利用其地位压制小型公司和贡献者。用户和开发者通常处于权力链的底端，面临“地毯式拉取”和“分叉”等策略的挑战，这些策略试图改变权力平衡。尽管开源软件强调协作，但实际运作中仍存在类似封建主义的权力不平等现象。

文章总结

标题：开源软件中的权力博弈：Rug Pulls、Forks与开源封建主义

在2025年的欧洲开源峰会上，Dawn Foster探讨了开源软件开发中的权力动态，特别是“Rug Pulls”（突然更改许可证）和“Forks”（分叉项目）这两种策略如何影响各方权力的平衡。

权力动态
Foster指出，历史上权力往往被用来压制弱者。在开源世界中，大型云服务提供商通常拥有最大的权力，而小型公司、贡献者和维护者的权力则相对较小。用户的影响力更是微乎其微。尽管云服务提供商可能不会回馈开源项目，但控制项目的公司可以通过更改许可证来改变权力平衡，但这往往会让贡献者和用户处于更不利的境地。然而，分叉项目也是一种权力手段，能够再次翻转权力格局。

Rug Pulls与Forks
控制项目的公司有权进行Rug Pulls，且往往毫不犹豫地行使这一权力。单一公司主导的项目尤其容易发生Rug Pulls，因为其他方几乎没有应对手段。公司可能会为了增加收入而更改许可证，尤其是在与云服务提供商竞争时。这种Rug Pulls可能导致项目分叉，但分叉并非易事，需要大量资源和人力支持。大型公司或云服务提供商通常有能力推动分叉成功。

案例分析
Foster分析了多个案例，包括Elasticsearch、Terraform和Redis的分叉事件。例如，Elasticsearch在2021年更改许可证后，AWS分叉为OpenSearch，但后者主要由亚马逊贡献者主导。Terraform在2023年更改许可证后，OpenTofu分叉项目迅速吸引了多家公司的贡献者。Redis在2024年更改许可证后，Valkey分叉项目则继承了Redis的外部贡献者，形成了一个强大的社区。

应对策略
Foster建议，贡献者和用户应警惕项目中的权力失衡，特别是使用贡献者许可协议（CLA）的项目，因为这些协议赋予了公司更改许可证的权力。选择中立治理的项目和多元化的贡献者基础可以降低Rug Pulls的风险。此外，公司应鼓励员工参与依赖的开源项目，以增强项目的可持续性。

结论
随着大型云服务提供商的崛起，开源软件中的权力动态越来越像封建主义。虽然公司可以通过更改许可证来对抗云服务提供商，但这也会削弱贡献者的权力。然而，贡献者仍有机会通过分叉项目来重新掌握权力。Foster强调，推动项目走向中立治理和增加外部贡献者是应对这一问题的关键。

评论总结

评论内容总结如下：

  1. 关于自由环境与封建制度的类比

    • 评论1认为将极端自由的环境比作“封建制度”是一个哲学错误，指出大公司如AWS或Google实际上很脆弱，且与历史上的封建起义不同。
    • 引用：“Places like AWS had to pull their head in and the spin offs from that like Rumble or Truth Social haven't gone away, they just partially marginalised when the censorship backed off.”
    • 引用：“That isn't how feudal revolts work in my understanding; typically peasants just got squished by better armed, armoured and organised soldier classes.”

  2. 开源项目的管理与分叉

    • 评论2建议通过从源代码构建软件来减少对供应商的依赖，并强调分叉项目的便利性。
    • 引用：“Building the software you rely on from source by default is one way to reduce the impact these events have on you and shift the power dynamic.”
    • 引用：“Switching your existing build-infra to sync sources from a new remote should be a snap.”

  3. 关于“rug pull”与许可证的讨论

    • 评论5指出，签署CLA（贡献者许可协议）可能导致项目被“rug pull”，尤其是当项目使用Copyleft许可证时。
    • 引用：“If you don't want a rug pull, you should use a copyleft licence and not sign a CLA: nobody can make Linux proprietary because the copyright is shared between so many people.”
    • 引用：“If you use a permissive licence, then a rug pull is part of the deal.”

  4. 对云服务提供商的批评与支持

    • 评论7认为开发者社区过于依赖云服务提供商，导致创新减少，但也承认云服务提供商为开源项目带来了免费宣传和贡献。
    • 引用：“We’ve become lazy and focused on nonsense (‘pretty’/unusable UIs, web gymnastics, llm, ‘productivity’ etc.).”
    • 引用：“The significant contribution that these providers (AWS, et al.) make to these projects is often overlooked - free advertisement.”

  5. 对保护性许可证的呼吁

    • 评论8批评文章未提及Copyleft和保护性许可证，认为这使得文章难以被认真对待。
    • 引用：“A lot of words without any mention of copyleft, protective licenses, GPL. Difficult to take the article seriously.”

  6. 关于AGPLv3与CLA的伦理讨论

    • 评论9引用了Stallman的回复，讨论了使用AGPLv3与CLA的伦理问题，认为AGPLv3总体上更好。
    • 引用：“On balance, using the AGPL is better.”

总结：评论主要围绕开源项目的管理、许可证的选择、云服务提供商的影响以及自由环境的类比展开，观点多样，既有对现状的批评，也有对解决方案的建议。