Creative & Hackable

已经记不清我是从几岁时对计算机产生的兴趣了，但最初是从沉迷那个叫 Ballance 的游戏开始，通过贴吧获知了自制关卡的存在，也了解到有人给这个游戏开发各种各样的小工具，于是就“好神奇，我也想做”为契机，从一款游戏开始了我的计算机旅程。Virtools、3DS Max、Virtual Basic、Free Pascal、Lazarus、Flash、Qt Creator，接触的东西越来越多，也越发觉得好像每个东西都很有趣。我做了很多现在看来几乎没卵用的小玩意儿，但也因为这些经历了解到了很多各种各样的技术，也尝试过各色各样的新奇小工具，并且能利用这些技术和工具来满足我的奇奇怪怪的需求。

我还记得头一次接触 Qt Creator 是为了瞎改一个别人拿来充当结课作业的播放器，当时很喜欢 osu! 这个游戏，尽管人菜但是很喜欢挂机听歌，后来就基于那位的结课作业瞎改了一个仿 osu! 主界面右上角播放控制栏的悬浮窗迷你播放器，配合扫描 osu! 曲库的功能拿来听我 osu! 里的曲目。东西本身不是个很新奇的玩意儿，但满足了我的奇怪需求，好用！这是在对我对“开源”软件所知并不多时对“开源”¹项目进行所谓源码级的利用的体验。对于“大体用起来很棒但其中一些功能不太顺手”的情况，相比闭源程序的“那只能忍了”而言，“开源”给了我完全控制程序行为并使之为我所用的能力。

后来，我也开始试着使用 Qt 来搓一些自己觉得会很符合自己使用习惯的工具，比如我很喜欢古早版本 QQ 内置的看图程序——透明窗口，能看 gif，方便的切换上下一张图片，双击消失——可惜它不是独立的看图程序，于是就有了菠萝看图²——它没有很复杂的业务逻辑或“技术含量”，但我可以利用 Qt 所提供的特性来快速定制出具有我想要行为的程序。后续开发过程不乏碰到一些 Qt 自身的问题，由于其开源，我也能够直接通过阅读和修改源码来解决我的问题。嗯，这使我更加相信“开源”所能带给我的“自主可控”之力。

我已经记不清今年是我使用 Linux 桌面的第几个年头了，而“开源”是我使用 Linux 桌面的契机之一。我仍然还记得我最初会尝试各式各样的桌面布局和主题来把桌面摆成想要的样子，把玩着果冻窗口甚至酷炫的 Compiz 特效等等。KDE 桌面环境的灵活性使我可以做我想做的大部分事情，而对于我不习惯的地方，我也可以修改相关小组件或是其他开源程序的源码来使之符合我的习惯。这种“Hackable”的体验可以认为是站在巨人的肩膀上，使工具可以为我所用，从而能更高效率的做更有意义的事情。

但是…开源软件真的等于“自主可控”吗？

Wayland…again

今天刷推的时候时间线冒出一个视频，内容是一个用户使用 MateEngine 制作的 OneShot Neko 桌宠站在任务栏上，跟随 WACUP 播放的音乐做出相关的动作。

https://twitter.com/Mmmtttbbb2/status/2005332661234245830

这个视频所演示的内容并非很新奇的内容，而很遗憾的告诉你——这个视频所演示的内容在现如今的 Wayland³ 上是做不到的。因为：

1. WACUP（山寨 WAMP）播放器的小窗口可以边缘吸附在主窗口上一起移动
2. MateEngine 桌宠可以获知你任务栏（以及事实上也支持其他应用程序窗口）所在的位置并做出响应（“站在”任务栏上）
3. 桌宠是置顶显示的，位于其他所有普通窗口之上

这些问题（除了获知其他程序窗口位置外）在之前的博客中也有提到，而这里并不是希望再“喷” Wayland 一次，而是因为这是一个绝佳的关于“开源 != 自主可控”的例子。那么假设我们是 MateEngine 的开发者，让我们看看如果希望我们的程序能在自己的 Wayland 会话下支持上述功能之一“置顶显示”，我们需要做哪些事情：

1. 检查当前所使用的 Wayland 合成器是否有自己的独特协议来支持窗口置顶，如果没有，需要添加此类协议，无论是插件形式还是脚本形式还是修改合成器本体的形式
2. 修改 MateEngine，使用合成器自己的独特协议或是我们所添加的协议来声明窗口置顶属性

其中第二条是不管放在什么平台都要做的事情，也就是“适配目标平台的 API”。而第一条则比较有趣，是让我们自己来给“平台”添加原本所不具备的功能——嗯，我们自己甚至可以给平台添加新的原本并不支持的行为，好像更自主可控了？

等等！还记得我们是谁吗？我们是 MateEngine 的开发者。等等！这里的“平台”是谁？是“当前所使用的合成器”而不是“Wayland”。这意味着什么？我们作为 MateEngine 的开发者，如果希望对 “Wayland” 用户提供包含窗口置顶功能的桌宠，就要：

1. 对我们用户可能覆盖到的所有 Wayland 合成器逐一实现用于窗口置顶的插件/脚本/patch
2. 编写文档，告诉用户我们的“插件/脚本/patch”怎么用
3. 面对“用户不知道我们给的东西到底怎么用”的场景，毕竟最终用户不一定是“电脑高手”

诚然，作为写过“开源自由软件 - 你也应当参与进来”这么一篇博客的人，似乎更应该推荐“参与进来”的解决方案，让大家参与进相关的讨论，推进相关特性到上游。但很遗憾，首先我们是“应用程序”开发者，即便我们假定我们有充足的精力在应用开发这一本就耗时的工作之外能腾出参与讨论的时间，我们还需要对要参与讨论的话题有足够程度的理解和认知，而即便如此，也如之前博客所提到的，ext-zones（以及其前身）打了数年的口水仗仍然处于未合入的状态，前段时间这个 MR 甚至因为有 YouTuber 发布相关视频随后有开发者参与讨论而导致 MR 本身被锁定了三周之久。这意味着我们可能要针对一个特性就投入巨量的精力，而最终可能不会有任何实质性的改变。

还记得第一部分中提到的迷你播放器浮窗，以及菠萝看图吗？仅仅是这类平凡的播放器与图像查看器也包含了由于 Wayland 限制而无法实现的特性，而我无法在 “Wayland” 下对用户提供这些功能——我没有精力参与长达数年的扯皮。我所能做的，大概只有关注相关协议的讨论，并偶尔给出一些参考回复罢了。

Endless bikeshedding

事实上，类似的事情其实并非只在 Wayland 中出现过。例如被马一龙接管后的 Twitter 变得越来越烂之时，很多用户选择涌入 Mastodon⁴，却发现平台缺少很多人常用的“带引用转推”的功能。这个功能被开发者和部分用户主张不应当被引入，因其可能被导致"被挂人"之类的"bad act"。这个讨论也因此被讨论了非常久，我甚至也以提出 proposal 的形式参与了讨论。当然结果很有趣：Mastodon 的主力开发者后来想通了，于是最终 Mastodon 引入了这个功能，而包括我在内的相关 proposal 事实上没起到太大作用。

当然除 Mastodon 外也有其他的例子，例如 Blender 应不应该把右键选择改成左键选择、Godot 是否应当自己手搓 3D 物理引擎轮子并持续维护、Firefox 是否应该支持 PWA 之类。好在其中相当一部分并不会拖“非常”久。于是，如果一个项目由“社区主导”，那么这类细节问题在开源项目发展的大方向上，事实上就免不了演变成长时间甚至无休止的 bikeshedding，直到真的有一方被说服，或者真的有人站出来拍板，但这反而会衍生一些其他层面的问题。对于真的能等到社区自发讨论出结果的一天的情况，漫长的等待必然会导致部分人因为“耗不起”而转向其他替代方案，而对于最终等到“大爷拍板”的情况，一方面“社区主导”能由个别人有拍板的权力时，它是否还是真正的社区主导一事就变成非常存疑了，而另一方面，如果拍板的结果选取了比较“激进”的方案（后述），那么势必会导致一部分用户或者开发者不得不选择放弃相关的开源项目，或者干脆 hard fork 自己玩自己的。

“因噎废食”

如果…选取了比较“激进”的方案

这一小段虽然有点算题外话，对于前面的这个描述，我觉得还是比较需要快速提一嘴的。前述的 Wayland 和 Mastodon 两个例子都有一个共同之处，即“通过完全禁止某种用法的方式，来达到’为了你好’的目的”。因为有人通过设置窗口绝对位置以及置顶的方式做坏事⁵所以认为这种用法不安全，为了用户的安全所以完全不允许你设置窗口位置或者置顶窗口。因为有人通过转推的形式“挂人”所以认为这种用法对用户不安全，为了用户的安全所以完全不允许“带引用转发”的用法。

其实这种“我这么做都是为了你好”的做法并非没有解决方案，例如 Capabilities 之类通过设置细力度权限的方式控制，想不想用、应用能不能用由用户做主才是更合适的解决方案。一刀切的“激进”做法会导致什么问题，相比能不需要翻译机即可流畅阅读本文的读者可能早已有了很深的切身体会了。

Balance

于是我觉得应该把话题拉回“自主可控”之上了。毕竟“开源”项目，很多人也会做出“大不了 fork 出来自己干或者另起炉灶”的建议，并且可能会附上 Linus 老爷子很出名的一句“talk is cheap, show me your code”，但…有没有觉得哪里不对劲？

• Talk 真的是 cheap 的吗？
• 我最初用开源项目图的是个啥？
• Grab my keyboard and start hacking 真的是合适的方案吗？

回到上面的两个例子，Wayland 无法由应用移动自身窗口位置并非 Wayland 无法实现相关功能，Mastodon 无法带评论转发也并非 Mastodon 技术上无法实现相关功能。同样是开源项目，却陷入了“show me the code”完全无法解决问题的困境，而 talk 也变成异常困难——你需要了解相关的背景知识，阅读超长的历史讨论，然后…“talk”…或者说…参与到可能永无休止的 “bikeshedding” 之中，于是真的 “cheap” 吗？以及，即便我们这么做了，当话题得到实质性结论之前，我们电脑上跑在 Wayland 会话内的一般程序仍然无法移自己的窗口位置，Mastodon 仍然无法带评论转发。“可控”在哪里？

我还记得我头一次知道 Office 的替代品 LibreOffice 的时候，决定拿它作为替代品的尝试场景——糟糕的 UX，惨不忍睹的 office 文档兼容性——诚然这些问题的“锅”不应当都甩给 LibreOffice，但作为最终用户（，即便同时是开发者）的我们不可能仅仅因此就放弃手上的活，抓起键盘给 LibreOffice 改代码。我也还记得我用包括 Kdenlive 在内的很多开源项目时，发现大体体验都还可以⁶，于是遇到一些小痛点，很乐意的拉下来代码定位问题和修复，但我也不得不说，每次尝试在 Kdenlive 中插入图像和复杂文本或是创建稍微复杂一些的动画都是一种痛苦，而真正要从根本解决这些问题要投入的精力就已经不是一星半点了，我不可能为了这个痛点就魔法般的变出大块的时间来理清架构问题，推敲修复方式并实际推进修复到上游。即便对于有编码能力的我而言是如此，于是，“抓起键盘开搞”真的是面向大众的合适的答案吗？

理所当然的，我们应当在做决定前做更多的考量。开源不等于一定好用，开源方案也不等于一定总是完全可控，选择无论开源还是闭源方案都意味着我们需要根据需求本身做更多的调研与尝试，去了解我们所选的方案是否真的能为己所用，把”可控“的可能性交给用户。而作为开源项目维护者或者说开源生态的建设者而言，也意味着我们需要在维护项目时做出对应的思考，思考我们要站在哪些角度看问题，思考如何定义安全的边界，思考如何定义可控的边界，思考如何寻求这些问题之间的平衡。

Wrap it up

于是写到现在，我想我应该可以很明确的说出我的结论了：开源不等于自主可控。当然事实上我的结论也仅限如此而已。

我们是否仍然应当考虑参与到开源项目中？我仍然建议，因为仍然是开源给了我们可控的可能性，而即便上面提到的 bikeshedding 问题实际也是参与到其中才有望解决的，而对于不存在这类问题的开源项目，在有时间和精力的前提下，参与到改善之中基本是百利而无一害的。

如果 x11 不再可用时 wayland-protocols 仍然在 bikeshedding 这些基础功能的话，我只能一声长叹，say goodbye to my Linux desktop journey, and move on.

最后，惯例：2026年1月5日20点40分⁷

• Wayland
• 开源