之所以说它失败，是指从功利的角度来看。不管是市场占有率，还是软件的可用性，用户友好性，以及生态上，都是失败的。直到2020的今天，以 Ubuntu 为代表的厂商在不断地向竞争对手学习，但仍然不足以和后者相提并论。当然，从自由以及民主的角度来看，它是有成功之处的，开源软件的流行，对于用户隐私以及自由的尊重，这一切的努力都值得我们敬重。

从表面上看，如果我们细数其失败的现象，很容易列出以下几点:

  1. 生态太差，没有多少厂商愿意开发 Linux 平台的软件。而进一步的原因则是用户基数少，以及开源社区天然对商业软件的不支持态度
  2. 用户不友好。偏技术化，普通用户难以方便地使用。

造成这种现状的原因很多，不一而足。其中人和制度自然是重点因素。

从 Linux 桌面的相关开发人员来看，有相当一部分人是满足于现状，并且不愿意 Linux 桌面朝着 Mac OSX 和 Windows 的方面演进，因为它是 Linux, 是自由软件的核心，似乎不应该走那样的路。这一部分人满足于目前 Linux 的生态，并沉迷于从技术角度去使用和解读 Linux，同时和普通用户区分开来。另一部分人，在努力地丰富 Linux 应用的生态，但却走入了一个怪圈。到今天，我们有几百个发行版，几十个桌面系统，几十个文件管理器，Terminal应用，音乐播放器，数种不同的 GUI SDK 框架。他们共享了一个 Kernel, 使用起来功能也大同小异，一样的不如商业软件好用。但所有人都似乎相信自己所选择的框架/方向是对的，至少相对于其他选择是有一定优势的。假设这些精力能集中起来，会不会更好？

没有假设，因为没有这个可能。与当世的民主制度一样，开源软件的开发流程大体上遵循了同样的模式，也遵循了同样的制度性缺陷。它防止了最大的恶(隐私，对自由的侵犯)，但却受制于其极低的效率。作为一个开发人员，你发现了一个应用的 BUG，或者有了一个新的 Idea 或者非常好的 Feature 想要合并进去，可能目前这个项目的 Owner 太慢了没时间处理，或者暂时不认可你的想法，那么你要么搁置你的 idea 或者 bugfix, 要么狠心下来自己 fork 一个新的版本。或者你直接掠过沟通这一步，直接开始自己的新项目。这就是 Linux 应用生态的开源项目的常态。

这个怪圈有没有逃出的方法，有，而且很成功。只是，他的价值观显的不那么普世罢了。这样的例子很多。GNU/Linux 二者的创始人便是。可惜的是，后面的一票人都走偏了。这个方式现在有一个专业的词汇，叫终身仁慈独裁者(Benevolent Dictator For Life).

我们很熟悉日常新闻上的 Linux 本人，经常骂这个骂那个，言辞粗暴，但其地位和声誉却未受影响。因为:

  1. 他本身水平之高有目共睹，是 Linux Kernel 和 Git 的创始人.
  2. 他领导下的 Linux Kernel 项目发展顺利，效率高，质量好

就这，就足够了。就是这个仁慈独裁者，能保证一个产品拥有稳定的内部结构，统一的 interface, 和高效率的产出节奏。而 Linux 应用层恰恰缺少这么一个人，来决定大方向和开发流程，造成了现在的局面。

当然，应用层本身的特点也不太可能推选出一位仁慈独裁者。这时候，开源世界历史上最为成功的项目之一–Kubernetes(它的仁慈独裁者是 Google) 所采用的 SIG GROUP 方式就值得借鉴了。在应用层划分若干个领域，每个领域再推选领导。由他来决定开发方向和领导开发流程。这样，才能防止应用层的开发力量进一步分化，而陷入无休止的 fork 和重复造轮子中。

当然，文化对人的思维定性影响之大，除非经历重大的变革，这样的改变是不太可能发生的。甚至曾经有过这样的惨烈教训: systemd. 它让作者收到了很多死亡恐吓信，让 Debian 的领导层因此产生了分裂。一个远远优秀于 Linux 现存各种 init 系统的替代品，其面临的如此遭遇充分昭示了开源项目本身所面临的非技术层面的文化问题。

如此看来，UOS 反倒有可能成为一个强有力的改变。结果如何，不得而知，但就方式而言，相较于过去的发行版，或许真的可以拿各国的抗疫政策以及结果来做对比。