现代开源运动（open-source movement）的一个内在矛盾在于，许多致力于尊重用户自由的软件项目，其自身却依赖于并不自由的专有工具（proprietary tools）来运作。无论是代码托管、团队沟通还是设计协作，社区往往会转向使用非自由软件（non-free software）。在 2026 年的 Configuration Management Camp（CfgMgmtCamp）大会上，Jan Ainali 就这一议题发表了演讲，探讨了开源项目采用开放工具的必要性。他希望能推动新兴和成熟的项目转向开放的替代方案，哪怕只是一个工具的替换，以减少对科技巨头（tech giants）的依赖，并支持社区驱动的基础设施（community-driven infrastructure）。
Ainali 通过他的公司 Open By Default，为维基媒体基金会（Wikimedia Foundation）的瑞典分会 Wikimedia Sverige 提供合同服务。维基媒体不仅提供 MediaWiki 软件，还托管着维基百科（Wikipedia）等众多项目。他表示，在维基媒体的生产环境中，所有的工具、分析系统等几乎都是开源的。“维基媒体运动中，有一种非常强烈的特质（ethos）要求这样做。”
然而，这种对开源的坚持，随着工作流（workflow）从核心开发环节向外围扩展，往往会逐渐减弱。“当你从开发转向更外围的工作时，所使用的工具在开源程度上就越来越低。”例如，维基媒体在设计方面使用专有的 Figma 软件，其年度会议则使用 Zoom 录制演讲并发布在 YouTube 上。他指出，即便是那些有强烈开源动力的项目，也很难做到完全只使用开源软件。
他强调，这次演讲的目的并非抨击那些使用专有软件的开源项目。他完全理解，使用更多开源工具并摆脱专有工具的依赖，这个过程可能充满挑战。对于那些需要与外部合作伙伴协作、且对方有特定工具要求的项目而言，难度尤其大。“尽管我在这里要阐述很多观点，但这都源于对开源的热爱和对改变的渴望。”
工具塑造文化
Ainali 指出，专有工具往往伴随着各种限制。例如，用户在导出数据或针对特定工作流程自定义工具方面可能受到制约。许多开源工具能够轻松实现的功能，专有工具却无法做到；如果一个项目没有修改软件源码的能力，它就很难真正让工具为己所用。
工具的选择，也在悄然塑造着一个项目的文化。起初，可能只是有人建议使用某个非开源的工具。“这绝非出于恶意。通常是因为：‘哦，它有这个我在其他地方找不到的功能’。”但 Ainali 认为，这是一个滑坡效应（slippery slope），一个糟糕的恶性循环。一旦决定采用一个专有工具，下次再做类似决定就会变得更容易。“如果我们的设计指南已经存放在专有软件中，那么工具链中的下一个环节也很可能走上同一条路。你就不再拥有保持开放的相同动力了。”而这最终可能导致部分社区成员被排斥在外。
此外，地缘政治（geopolitics）因素也可能在某些情况下显现威力。他提到了 Organic Maps 项目一度失去对 GitHub 访问权限的事件，据推测是因为该项目有来自俄罗斯的贡献者。“这并非因为 GitHub 对俄罗斯有什么偏见，而是其所在地的法律使然。”另一方面，一些贡献者可能不愿向某个平台提供数据，因为该平台可能被其所在国政府要求上交数据，尤其是当平台位于其他国家时。
即使没有政治干预，过度依赖封闭平台也会带来其他隐患。“它们先试图诱惑你加入，然后将你锁定（lock-in），让你很难离开。”Ainali 表示，开源项目尤其容易受到这种诱惑，因为许多平台最初会提供免费层级（free tiers）或针对非营利组织（nonprofits）和开源项目的特殊优惠。
当然，这里还有一个由 Cory Doctorow 提出的贴切术语：“平台腐烂”（enshittification）。他定义了事物如何随时间恶化的几个阶段。首先，你被诱惑加入；当它们拥有庞大的用户群后，就觉得自己可以从你身上压榨越来越多的价值。这并不是说它们故意想让你变得更糟，但作为用户，你的处境确实会每况愈下。也许它会变得更贵，也许它们会从你身上提取更多数据，也许它们正试图通过销售精准广告将这些数据货币化。这就像单纯地朝着恶化的方向发展。
与此同时，专有的云平台和服务也从开源项目中汲取价值。公司可以获取指标（metrics）、使用数据、错误报告，并可以对外宣称“这个知名开源系统正在使用我们的产品”。项目也可能成为公司商业决策反复无常的受害者。平台可以随时决定终止针对开源项目的免费层级，或者更改其服务条款（terms of service）：“突然间，在新的条款更新中写道：‘哦，现在我们要把你的数据用于训练人工智能（AI）了。’”
还有一些情况是，公司并非有意利用开源项目，而仅仅是做出了一个商业决定，关闭了一个它认为不再盈利的平台或服务。这让依赖它的开源项目陷入困境；如果一个项目一直使用开源软件，它可以轻松地在本地部署并自行维护。但对于专有服务而言，这根本不是一个选项；一旦服务被终止，一切就都结束了。
失去贡献者
Ainali 强调，选择开放工具不仅仅是一场“纯洁性测试”（purity test）。有些潜在的贡献者会因为根本不想使用专有工具而气馁，甚至直接放弃参与。如果一个项目强制要求使用专有工具，那可能意味着某些人字面上就无法参与。例如，一个只支持 macOS 的工具，就自动排除了所有不使用该操作系统的参与者。他观察到，在世界上的某些地区，人们可能别无选择，只能运行开源操作系统，因为其他一切对他们来说都过于昂贵。
无障碍性（accessibility / a11y）是另一个重要的考量因素。许多专有工具“看起来非常华丽，但可能没有良好的无障碍支持”。他指出，开源工具或许外观朴素，但功能通常更加完整和可访问。
即使项目没有完全失去一位贡献者，也可能无法获得其全面的参与。也许这个人会继续提交代码，但不会参加讨论项目方向的视频会议，或者因为项目使用专有产品进行文字聊天而拒绝参与其中。
因此，你正在失去社区中一个重要的声音。他们可能会选择留在值得信赖的老旧邮件列表上。而这些人通常非常有经验，也非常清楚自己的数据会被如何使用。所以他们很乐意用脚投票，不去参与那些环节。他们非常在意自己的自由，也非常在意自己的数据。另一方面，他们通常也非常精通开源，因为他们已经深刻体会到不想被专有工具锁定的重要性。
他鼓励开源项目投资于自身的生态系统，通过部署开源工具、按需添加功能、改进文档、提交错误报告等方式来贡献力量。他预见到了一个常见的反驳：“你会大喊：‘专有工具好用得多，我们根本没法用这些开源的。’” 这其实是陷入了一个便利性的“第22条军规”（convenience Catch-22）。Ainali 承认，有时专有工具从纯粹的技术角度看确实更优。“但它们对你的韧性（resilience）和项目的可持续性（sustainability）都不利。而你本可以帮助改进那些开源工具。”
只要开源项目还在使用专有工具，它们就在为这些工具的改进提供数据和“合法性”背书。如果项目还为专有工具付费，那更是在直接资助竞争对手。“所以，你应该尝试帮助开源社区追赶甚至超越。”他说，如果项目继续将所有使用利益赋予专有工具，那么未来想要摆脱它们将变得极其困难。
Ainali 还预测，人们会以“所有人都在这个平台上”为由，反对离开某些专有平台（这里虽然没有明指，但显然主要针对像 GitHub 这样的专有代码托管平台）。然而，这类平台的网络效应（network effects）并非永恒。“我们见过很多社交媒体平台兴起又衰落，其他工具也是来来去去”，因为它们要么找到盈利模式，要么走向消亡。“而开源工具或许更具韧性，因为它们不需要从用户身上榨取同样的价值来维持生存。”
从小处着手
他认为，项目应该勇于尝试。例如，可以尝试将 Git 仓库镜像（mirror）到更自由的平台上。当项目需要为某项新任务选择工具时，应有意识地优先选择开放工具。最重要的是，项目应该倾听社区的声音，并从对社区最有意义的地方开始转向开放工具。“不要等待。这其实早该开始了，但现在开始也永远不晚。任何时候都是好时机。”他强调，这并非一个非黑即白的命题。项目不必追求一夜之间的“纯洁”，也不必试图一次性切换所有工具。转变可以从很多细微之处开始。
选择一个工具，做出一个改变，然后评估：“这有效吗？”如果行不通，如果事实证明你确实离不开某个专有功能，也不要害怕回退。如果你能向社区清晰地传达进行这项改变的意图和长远益处，通常进展会顺利得多。每个人都能理解：“哦，从长远来看，这是为了我们好”。这会让我们更具可持续性。这是可能的，而且一旦成功，它真的很有感染力。如果你不能一次性完成所有转变，也不要自责。不完美也没关系。
他在演讲结束时总结道，既然项目选择了开源这条道路，那么这种选择也应该反映在项目所使用的工具上。开源不仅仅是代码和许可证：“它是一种文化，一种工作方式，它是社区，也是这些许可证赋予我们的自由。”他认为，项目不应试图将这种宝贵的自由，建立在自己无法控制的基础之上。
[感谢 Linux 基金会（LWN 的差旅赞助商）资助我前往根特参加 CfgMgmtCamp。]
LWN 评论概述：
本文引发了关于开源项目政治性与实用性之间平衡的深入讨论。有评论指出，并非所有贡献者都出于政治动机（如摆脱供应商锁定或对抗技术巨头），许多人选择开源纯粹是因为其在特定场景下的高效。讨论中提到的“滑坡效应”也受到质疑，部分观点认为有经验的开发者往往能有意识地在短期效率与长期自主权之间做出权衡，而非被动受诱。此外，评论还强调了为自由软件工具提供资金支持的重要性，以确保其能与成熟的专有平台竞争，避免因“便利性”而导致的路径依赖。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
发表于 2 小时前
|
查看: 3|
回复: 0
