第 19.8 节 重提 FreeBSD 与大败局
首先不知道何为 FreeBSD 大败局的建议阅读下以上 2 篇文章，当然当初我很快给出了我粗浅的回应：
文不加点，当时写得很快，不到两个小时就写完了，而且并没有动什么脑子。可能就是意气用事，为了反驳而反驳吧。当然我也没打算说他在现在就是正确的了。我只是觉得现在更加值得花时间来在文档和代码之外来谈论一下这些更加吸引人的东西。
看过上一篇文章《还有人记得 Linux 之前，那个理想又骄傲的 BSD 吗？》的读者都知道， BSD 是 Unix 最重要的一个开源分支，这一本该坐上 “开源头把交椅” 的操作系统家族承受了一场足以记载史册的浩劫。时间倒回三十年前。1993 年，那时候 BSD 正处于水深火热，Linux 刚诞生没多久，Meta 杂志 问 Linus Torvalds：能不能推测一下 Linux 在市场上对 Unix 的影响？当时，Linus 的回答是：I have gotten various mails and seen some newsgroup messages about persons who have switched over already or would like to switch over once Linux is able to run commercial binaries, but at least so far, I doubt Linux has dented the real Unix market very much.尽管我已经看到一些人已经或者想要切换到 Linux，用于运行商业二进制文件。但目前为止，我不认为 Linux 已经严重削弱了 Unix 的市场。彼时，Linux 初出茅庐，尽管锋芒毕露，但谁也不知道以后到底会发生什么。须臾三十年，形势调转，Linux 现在的地位有目共睹。另一边，BSD “灾后重建” 且大受欢迎的 386BSD 因为内部意见不同出现问题，其中三个补丁包协调员 Nate Williams、Rod Grimes 和 Jordan Hubbard 另起炉灶，于 1993 年创建了 FreeBSD。尽管还有 NetBSD 和 OpenBSD，但后来的事实证明，FreeBSD 发展最好、走得最远，是 BSD 世界里的 “扛把子”。
在之后的日子里，FreeBSD 没能重现 BSD 的往日荣光，反而一直生活在 Linux 的阴影之下。“Linuxism” 成为 FreeBSD 内部常常挂在嘴边的一个词，其中透露出酸酸的比较之味。一方面，FreeBSD 坚定地沿袭 Unix 的一些传统，坚决地想要与 GNU/Linux 保持距离；另一方面，FreeBSD 也在积极地寻求更长足的发展，想要至少在某些方面保持优势。世事如棋局，得势者得天下。以势定夺，怎么看 FreeBSD 领到的剧本都是一个 “大败局”。
Linuxism（Linux 主义/歧视）真的只是一种 FreeBSD 吃不到葡萄就说葡萄酸的牢骚话吗？光阴荏苒，时光如梭，自由软件运动持续了半个世纪有余，能够留存至今并真正意义上具有使用价值和能力的操作系统寥寥无几，更遑论开源操作系统了。自由软件运动所推崇的操作系统或者说内核（实际上是微内核） GNU Hurd，反正我是没用过……
如果你使用了 systemd 还实现了所有的 Linux ABI，并且用了一 大堆的 GNU 软件，而且你的内核也实现了所有的 Linux 特性，只有包管理器不一样，那么你究竟是 Linux 呢还是你自己的操作系统呢？这看上去是一个忒休斯问题。实则并不难回答。
而今几乎所有的 GPL 软件都使用 Linux 作为自己的开发测试平台，并且结合了越来越多的 Linux 特性，乃至于让 Eclipse IDE 这种 java 软件都失去了可移植性。他们只会说你的系统我们并不关心，你自己打补丁就是了，因为我们只用 Linux。他们与 Linux 内核的某个特性紧密结合，并且死死捆绑。仿佛这些软件不依赖 systemd 就活不下去一样，比如 todesk——他们认为“（todesk）没必要兼容 init，反正我用的 systemd，谁还在用那玩意”，他们官方 Linux 版本 QQ 群里的管理员就是这么说的。
FreeBSD 恪守古老的 UNIX 法则，坚持其 BSD 开源哲学，坚持基本系统去 GNU 化。这意味着你不会遇到用包管理器就卸载了所有内核或者 glibc（C 库）这种蠢事。基本系统的软件都由 FreeBSD 项目统一维护，Linux 则没有基本系统这个概念，或者说 Linux 系统就是由一个个软件包拼凑起来的，如果你用过 LFS/Gentoo/ArchLinux 就会有明确的体验。一切命令/二进制文件都是由软件包或者 shell 提供的，也就都可以用包管理器来管理，比如说卸载……所以不难理解包管理器卸载内核这件荒唐事。
FreeBSD 去 GNU 化是贯彻其 BSD 哲学的实践。FreeBSD 项目认为基本系统中的 GNU 软件（很多常见的比如 grub vim nano tar 等）都会阻碍人们对 FreeBSD 的充分利用，因为人们被迫接受了 GPL 这一强制性开源的协议，不利于其更加自由的使用。这是出于 BSD 与 GPL 观念上的不同——GPL 强制开源（虽然也有很多方法隔离污染，比如 Android 所做的），而 BSD 则允许闭源（比如 Chromium）。但是这并不意味着 BSD 强制性的要求用户不能使用 GNU 软件，它只是基本系统（你安装好的系统）中去 GNU 化。你完全可以自己替换（实际上也不难，用包管理器一个个安上就是了），毕竟 FreeBSD 完全是自由的。
事实上，并非是 FreeBSD 在去 GNU 化，而是 Linux 本身在 GNU 化， 同时这也阻碍了 FreeBSD 的现有技术优势的组件无法进入 Linux 内核，比如 ZFS。
但是我看不出 FreeBSD 能有何出处了，这也是现实——引以为豪的 TCP/IP 远远落后于 Linux，BBR 移植了数年仍然性能低下；驱动问题更是难以解决，甚至放弃了对自己的英特尔驱动的维护，转而使用了 linux drm；zfs 更是已经被引入了使用人数最多的 Ubuntu，不再是 FreeBSD 等少数系统的专属了。
或许 FreeBSD 真是一个败局吧？
01 成也 BSDL，败也 BSDL正是我们的许可证，使得我们独一无二。与 GPL 尤其是 GPLv3 相比，BSDL（BSD 许可证）对很多厂商来说是非常重要的。他说得没错。许可证是 BSD 一族与 GNU/Linux 最显著的不同，它彰显了 FreeBSD 所继承的、与 RMS 提倡的 “Free” 完全不同的 “Libre” 哲学态度，使得以 FreeBSD 为代表的这些开源软件自成一派。在 GNU 理念里，软件本该自由，专有软件不应该存在。因此，GPL 被设计得具有传 染性，并且要求所有修改后的代码都要返回上游，当初 Linus 选择 GPL 正是看重后面这一点。而 BSDL 则更接近于 “公共领域”（公共领域的作品属于公有文化遗产，任何人可以不受限制地使用和加工它们），几乎给了使用者最大权限的自由，不但可以自由地使用、修改源代码，不需要返回任何修改，还可以将修改后的代码作为开源或者专有软件再发布。我们并不认可 GPL，它是一种政治宣言。我们想要将我们的许可证与政治分开。 GPL 会吓跑很多潜在用户，这只会适得其反。—— FreeBSD 创建者之一 Jordan HubbardFreeBSD 的这种身份主张无可厚非，但从现实层面来考量这两个许可证，就是另一码事了。当程序员放弃代码的版权，或者选择 BSD 许可证，他可能认为自己做出了世界上最无私的行为。很大程度上，事实确实如此。但是，我们要知道，这个世界是一个商业利益占主导的世界。一旦发生像甲骨文拥有 MySQL 这一类的事情，你的代码的价值将大大削弱，大公司先是免费利用它们，然后再设法推出取代它们的私有产品。你以为自己奉献了爱心，但是实质上变成了为大公司无偿打工。从这个角度看，GPL 是更好的开源许可证。它保证了自由始终是自由，既无法被剥夺，也不是一种圈套或陷阱。
实际上，该博客的这篇文章是有一些问题存在的。
作者阮一峰指出：
即使 mysql 闭源一定会有其他人接手，继续推出 MySQL 的后续版本…但是只要代码完全兼容…
如果闭源了并推出新产品，那么如何还能做到代码完全兼容？就拿如今红帽 RHEL 的代码授权来说，红帽把开源的代码水平降级到了 CentOS stream，你即使有 rockylinux、欧拉、阿里龙蜥等一堆系统，你的兼容级别也是次于 RHEL 的。
第二种情况：甲骨文公司决定，MySQL 的后续版本不再开源，或者整体并入 Oracle 数据库，会怎么样？答案更简单，不可能发生这种情况。因为根据 GPL 许可证，只要发布基于原代码的新产品，就一定必须开源。
GPL 不是用来限制作者或者版权方自己的，否则按照这个逻辑，没必要 fork 出来 MariaDB。版权持有者完全可以决定后续版本的开源与否。
严格来说，GPL 是由开发者对其他人发布的的许可证，用于这些人使用、发布和改变该程序。开发者本人并不受到许可证的限制，所以无论开发者做什么，这都不是“违反”GPL。见 https://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate
让我 们再来假想一下，如果 MySQL 的源码处于公共领域，或者 BSD 许可证之下，那会怎样？那样的话，许多站长恐怕都会感到大难临头了。他们不得不做出选择，将来到底是升级到第三方小公司推出的、质量没有保证、支持力量薄弱、互相不兼容的基于 MySQL 5.x 版本的各种衍生数据库，还是升级到甲骨文公司推出的、与 Oracle 兼容的、号称具备各种新功能和最佳性能、并且广告满天飞的 MySQL 6.0 版本。
在类似 BSD 许可与 MIT 许可的 PostgreSQL 许可下发行的 PostgreSQL 为什么没有发生作者博客所提到的问题呢？反而实用性更超 MySQL。
GPL 是更好的开源许可证。它保证了自由始终是自由，既无法被剥夺，也不是一种圈套或陷阱。
那么问题来了，GPL 究竟保障的是人们的消极自由还是积极自由呢？见仁见智。此外，绕过 GPL 的事情以及技术手段不在少数。作者阮一峰博客底下评论的 Android 就是一例。而且根据已逝 VIM 作者 Bram Moolenaar 的话“它（GPL）事实上是通过限制自由来实行自由的”，也即 GPL 是一种“伪式开源”，并非真实的开源。
FreeBSD 的贡献者就常常被调侃为 Apple 公司的无薪员工。Apple 将社区工作都纳入了 FreeBSD，在其基础上进行了一些更改，就变成了一个专有的、非自由的操作系统。糟糕的是，Apple 还对内核和其他部分进行了分叉，并将其命名为 Darwin，这一系统基本就远离了 FreeBSD 的传统。而且，由于 Apple 支付了版税，他们可以合法地将其称为 Unix，但这笔钱也没有流向 FreeBSD。
实际上有不少 Apple 开发者同时是 BSD 开发者。Apple 也是 FreeBSD 基金会的赞助商之一。
更过分的是，相较于 Netflix 等，同样是 FreeBSD 受益者，Apple 为上游做贡献的积极性也不足（因为 BSDL，贡献上游这事就全凭自觉了）。但 FreeBSD 的人对此倒也看得开：“我不会因此而责怪他们。FreeBSD 是一个 BSD 许可的项目，而不是 GPL。”John Baldwin 表示。BSD 许可证就是一个复制中心，可以为所欲为，但我们不在乎。—— Marshall Kirk McKusick ，他亲身参与了 4.3BSD 和 4.4BSD 的开发和发行，后来又深度参与了 FreeBSD因为 GPL，这种事永远不会发生在 Linux 身上。在 GPL 许可下，任何人都可以使用 Linux，但是有一个强制要求，如果修改后的版本要出售或者提供给他人，则必须根据相同的 GPL 许可把完整源代码对外发布。如此一来，GPL 可以确保 Linux 永远不会成为专有产品，所有开发者做出的贡献最终会回到社区，Linux 可以得到更好的发展。
实际上并非如此，比如 Ubuntu 很多情况下都在重复造轮子。Linux Kernel TTY 中文补丁一直不被接受。开发者只会按照自己的意图改造软件，面对用户的需求往往充耳不闻。Linux 是不是会成为专有软件我不知道，但是我知道他离改名叫 Systemd OS 那一天不远了。也早已经放弃了自己以往的 UNIX 哲学。
另外关于开源，源代码是可以以售出方式开源的。
Linux Kernel 的开发相当地封闭，你如果有内核补丁要提交必须挨个按照脚本上给出的邮件地址去询问，看看谁愿意接受你的补丁。而 FreeBSD 则是真正任何人都可以参与开发。
在 Linus 眼里，GPL 就是他想要的，而不是 BSDL。许可证是 Linux 成功的决定性因素之一，因为它强制你必须回馈。如果你真的想创造更大的东西，如果你想围绕它创建一个社区，BSD 许可证不一定是很好的许可证。它（BSDL）会让开发人员觉得大公司在利用他们的工作。
BSD 认为开源的最大目的并非是出于所谓自由，而是让代码尽可能地被复用，以产生尽可能大的社会效用。而不受任何限制。
02 “好东 西都给 Linux 了” Linux 赶上了好时候。Internet 开始风行之际，Linux 的开发者及爱好者正好能透过 Internet 实时地发布新闻、想法、提问、讨论、递送程序代码及进行错误回报。这种由 Internet 连接起来的分布式合作方式带给了 Linux 惊人的活力。这种生命力直接将 Linux 送上了可以与 BSD 分庭抗礼的位置。与此同时，在 Linux 现身之时，刚好是人们开始买得起个人计算机时。那是还没从诉讼中缓过劲的 BSD 对于当时的个人计算机所使用的 80386 硬件的支持度非常不好，Linux 几乎成为当时大众的第一选择。这一波路人缘，Linux 收割得很漂亮。BSD 缺位，Linux 趁机发展，刚从灰烬里重生的 FreeBSD 碰上的局面就很残酷：Linux 占据主导地位之后，已经形成马太效应，之后的态势呈现出强者愈强、弱者愈弱的趋势。
硬件方面，Linux 可以在许多不同的平台上运行，而 FreeBSD 则不行。硬件设备制造商更愿意为 Windows、Linux 等主流的操作系统提供驱动程序，IBM、戴尔和惠普直接支持在其服务器上运行 Linux，但处于主流之外的 FreeBSD 可能不在它们的考虑范围内。
FreeBSD 支持的架构难道很少吗？那不如试试 NetBSD 吧。
此外，Linux 的开发者数量比 FreeBSD 多出数倍，这意味着 Linux 拥有更多的贡献者和测试新硬件的机会。长期下来，最终导致 FreeBSD 的兼容性和硬件支持远远不如 Linux。比如，用户需要定期更新图形驱动程序，Linux 可以更早、更快地提供支持。软件上，Linux 软件包存储库的数量远超过 FreeBSD ，具有更大的灵活性和可用性，虽然 FreeBSD 也提供了预编译的软件包，但它仍然无法与 Linux 可用的资源进行比较。其实，这都是互为因果关系的 —— 因为 FreeBSD 市占率比 Linux 低多了，开发者少，很多软件对其的支持度就不如 Linux，这又反过来加剧了其市占率的下降 —— 一个 死循环。
FreeBSD 有 Linux 兼容层，所以理论上软件数量应该远超 Linux。另外上边已经讨论过，专属依赖于 Linux 的软件越来越多，这并非一件好事，这会导致所有软件丧失独立性和可移植性，出现共同的故障点。自由软件运动如果再这么进行下去，那想必所谓“开源”开不开已经没有多大意义了，因为离开了 Linux 或者 Systemd 软件根本跑不起来，也无法移植。
有人评论很是贴切：“所有的好东西都给了 Linux”。看着 FreeBSD 如今的现状，用户都着急了。2020 年 3 月，一些用户开始在推特上催促 FreeBSD 基金会尽快赞助 FreeBSD，以推进对 802.11ac 支持的开发工作。要知道这个时候， Windows 和 Linux 都提供了对 802.11ac（"WiFi 5"）的良好支持，并且已经开始将重心放在 802.11ax （"WiFi 6" ）上了。
03 FreeBSD 没有布局 Linux 内核是个操作系统 “半成品”，企业支持的重要性不言而喻。支持 Linux 的著名企业有 RedHat 、SUSE、IBM 、Canonical 等等，它们不仅贡献了许多实用性很强的发行版，如 Fedora、Ubuntu、Arch Linux、Debian、Linux Mint 等，同时确保操作系统实现快速更新。有人认为， RedHat 是 Linux 快速进入商用市场的关键性因素之一。因为对于大型企业而言，或许授权费用的多寡并不是重点，他们要的是能够说服上司及股东的解决方案。透过 RedHat 所提供的技术支持，信息部门有了底气将 Linux 列入解决方案之中。这项优势几乎是 FreeBSD 所难以匹敌的，因为 FreeBSD 几乎没有商业支持。
如今看来似乎并非如此？红帽的商业布局如今让开源界啼笑不止。Linux 的确是快速进入商用市场了，但是给开源界带来了什么呢？红帽的商业布局就是为了使 Linux 世界变成 systemd 世界。红帽及大型公司已经在事实上把控了 Linux 的开发的上下游。
因为缺乏商业公司运作的商业版本，为 FreeBSD 提供支持的企业屈指可数，没有大量企业为终端用户提供大规模的技术和服务支持。在 FreeBSD 13 发行之后的那场采访中，当被问及商业模式问题时，John Baldwin 这样回答：有很多来自像 Netflix 这样的公司，内部会有 FreeBSD 专家团队开发功能，这些工作直接进入上游 FreeBSD。还有一些资源来自学术和业余爱好者。最近越来越多的工作由 FreeBSD 基金会承担，基金会接受捐赠资助。可以看出，一些接受了 FreeBSD 恩惠的企业的确在以某种方式去推动 FreeBSD 的生态发展，但与 Linux 所得到的商业支持，完全不能相提并论。就像有人说得那样：“尽管 Netflix、Apple 和 Juniper Networks 等公司都在支持 FreeBSD，但它们并没有像 Canonical 和 RedHat 等公司那样投资它，共荣共生的传奇只发生在了 Linux 上 。”
04 “大独裁者” 未必是坏事One of the major problems with 386BSD seems to be the lack of co-ordination: that may sound weird coming from the Linux background, but in fact the 386BSD project seems to suffer from a lot of people working on the same thing due to the long release cycle.The NetBSD project may be a step in the right direction, but I think 386BSD has been hurt by the way it has been developed.386BSD 的主要问题之一似乎是 缺乏协调管理：尽管我以 Linux 的角度和身份来看很奇怪，但事实就是这样，因为较长的发布周期，386BSD 里大量的人都在做同一件事情。NetBSD 可能走对了方向，但是 386BSD 已经因为这种开发方式受到了伤害。1993 年，Linus 一语成谶。很快，386BSD 分裂成为 FreeBSD 和 NetBSD。
当时有人总结到：“BSD 走的是教堂式的学院派路线，而 Linux 则是代表了市集式的骇客精神。” Linus 是著名的独裁，而 BSD 对 “独裁者模式” 的嗤之以鼻是一以贯之的。
有一个古老的笑话是这样的：如果你把 10 个 BSD 开发人员锁在一个房间里，当你打开门时，你会发现比萨饼不见了，BSD 开发人员死了，还有 11 个 BSD 的新变种。
这句话如今形容 Linux 颇为恰当。
虽然有点自负，但我认为只要我愿意充当傀儡，我本可以阻止社区分裂。当时我在那个位置上已经 10 多年了，我觉得是时候将衣钵传给他人了。老实说，我没想到会这样（指分裂），我以为会出现很多不同发行版而已。McKusick 曾这样表示。在他看来，Linux 的独裁者模式一样不可取，一旦 Linus Torvalds 离开，就会酿成灾难，Linus 在试图创造超越他自身的一些东西，而 “如果我被公共汽车撞了， BSD 不会真正受到太大影响。”这样左派又带点傲气的观点，真是典型的 BSD 的啊。而 FreeBSD 之后出现的管理和开发方式问题，多多少少也带了一些遗传在身上。从开发过程上看，FreeBSD 与 Linux 最大的不同就是 —— 没有一个大独裁者。FreeBSD 有一个核心团队，相当于公司里的董事会，他们通过授予、撤销修改、提交新代码到代码库等权利来控制访问，其首要任务是确保整个项目处于良好状态并朝着正确的方向前进，并每 2 年选举一次。“我们主要用邮件列表进行协作，这与 Linux 内核邮件列表相同。但是，FreeBSD 基础系统是一个单一的存储库，内核、C 库以及工具链，所有基础系统实用程序，如 ls 和 shell，都在一个单一的存储库中，一起构建和发布。” FreeBSD 基金会项目开发总监 Ed Maste 在 2021 年表示。这种 “核心小组” 型的模式最大的缺点就是很难达成共识，从而延误时机。FreeBSD 核心团队成员 Benno Rice 就曾探讨过这个问题：开发项目的源代码是其核心资产，必须妥善保管。所以项目需要一个源代码管理系统。最初，FreeBSD 使用 CVS，这在当时是一个合理的选择，但直到 2008 年 FreeBSD 还在使用 CVS。为什么呢？因为大家对于应该用什么来代替它没有达成共识。考虑过 BitKeeper、Git 和 Mercurial，最后都无疾而终了。很多社区都会反复出现长期的争论，FreeBSD 也不例外。2008 年，经过八年的争论，Peter Wemm 强行推进了向 Subversion 的转换；从那以后，抱怨声相对较少了。相比之下，Python 从 CVS 开始，2004 年转移到 Subversion，2009 年转移到 Mercurial，现在又转移到 GitHub。在 Python 社区中，一旦 PEP 获得批准，就可以继续进行了，而 FreeBSD 没有这样的机制。而 Python 社区，又是另一个以独裁者领导而著称的项目。其实，“核心小组” 模式并非只有 FreeBSD 一家，GNU 项目 、Apache Web 等也都采用这种模式。但很明显，FreeBSD 的这个核心团队，并没有做好这份工作。
这里我要提一下，我也持相同观点，FreeBSD 不仅仅是核心团队，其有权限的 committer 也都没有做好自己的工作。他们的观点是大家都是志愿者，因此没有任何可指责的地方。但是我实在是很难认同闭门造车，做任何大的改动都不会在邮件列表讨论一下乃至提一句说我要这么干了。
比如把默认 root shell 从 csh 切换到 sh，我竟然一年后多才知道这件事。这意味着所有的 handbook 教程以及我们社区的教程都需要重新编写以兼容他的操作。这是一件很小的改动，只涉及了几个字母，但是对于下游或者用户来说，是灾难性的。
这种事情，绝不少见：FreeBSD 的安全公告使用了在文件夹名 Windows 下无法支持的冒号“：”，这导致的后果也是灾难性的，你甚至都无法 git 下来项目以参与贡献。但是这种严重的 Bug 似乎并不能引起他们太多的重视。
比如著名的 “ Matthew Dillon 事件”（下文会详细说），他们不但没有及时 引进相应的行为准则来规范大家的行为，更是对开发者互相掐架、成员参与 “Gamergate” 在线骚扰活动等恶劣行为无能为力。又比如，因为缺少保证质量代码的审查流程，他们还差点让 4 万行有缺陷的代码混入 FreeBSD 内核里。
05 “FreeBSD 不会再年轻了” LWN 是这么评价 FreeBSD 的：这是一个伟大的项目，但它确实存在一些问题，特别是三点：FreeBSD 很大，它很旧，而且它行动迟缓。FreeBSD 不会变得更年轻了，它难以改变 一些根深蒂固的态度。的确，从 1993 年 11 月开始，FreeBSD 出生就自带故事，而且它基于的代码非常古老。Benno Rice 说，直到 2017 年 FreeBSD 开发人员才发现自动化测试，而要进行自动化测试，软件必须具有正确的结构，但 FreeBSD 这个 “老家伙” 并不具备。因此，当他在一场活动中看到 Rust 社区有关自动化的演讲时，他就在想：为什么 FreeBSD 不能有这么好的东西？不光是古老，FreeBSD 还失去了活力。FreeBSD 联合创始人 Jordan Hubbard 曾经是社区最为活跃的核心人物之一，2001 年他离开了 FreeBSD 社区，去了 Apple 公司，帮 Apple 捣鼓 Darwin。在他的辞职信中，他这么说：Another reason, and I hate to say this but it probably needs saying, is that being in core is honestly not what it once was. For a old-timer like myself, who was used to a core team that was far more cohesive and generally on the same page, it's simply a painful experience a lot of the time.Perhaps this is due to overly rose-colored recollections of the old core on my part, and I do certainly recall us having more than our share of disagreement and inefficiency in the past, but on the balance core still feels too much like the pre-WWII Polish Parliment sometimes, where we're fully capable of arguing some issue right up to the point where tanks are rolling through the front door and rendering the whole debate somewhat moot.还有一些原因，我本不想但不得不说，老实说核心团队已经不像从前了。作为一个老前辈，我习惯了那样的核心团队：更加团结且大家都是一条心，一起经历了许多艰难的日子。或许是我对旧时光的滤镜太重了，在回忆里我们过去的确有更多的分歧和低效，我们的核心团队实在太 “反应迟钝” 了（这里用了一个典故，二战时德国都已进入波兰，而波兰国会还在商讨对策）。我们完全有能力解决问题，但就是这样：坦克都已经在门前了，一切辩论都毫无意义了。Jordan Hubbard在这副古老的身躯上，当我们掀开 FreeBSD 那袭表面华丽的裘衣，又会赫然发现上面还爬有一些不那么体面的虱子和臭虫。在圈子里，总是会有一些有关 FreeBSD 的 “小差评”：FreeBSD 是一个很棒的操作系统，但 FreeBSD 论坛是我见过的最刻薄的论坛之一。有人在里面寻求帮助却被贬低，并让其滚回到 Linux 社区。FreeBSD 论坛成员都是 FreeBSD 的狂热分子，当话题涉及到在 FreeBSD 作用不大的组件时，就会被攻击为 “Linuxism”。BSD 论坛一点也不友好。不要在那里问，他们只会让你去阅读手册。你只能靠自己。在 FreeBSD 论坛寻求帮助，得到的回复往往都是：一定是你做错了，因为 FreeBSD 永远不会错。当然，人无完人，每个社区都会有这样那样的差评，这些差评或许并不能说明些什么，但是当一些群体性事件爆发出来，FreeBSD 在 文化和风气 上的短板就暴露无疑了。其中最著名的就是前文曾提及的 “Matthew Dillon 事件”。Matthew Dillon 是 1994 年就加入 FreeBSD 的明星成员。之所以说他是明星，是因为这哥们确实实力过硬，但不合适团队合作，不怎么在乎别人的辛苦成果，是个 “Rock-star” 式的人物。当初还在更新 FreeBSD 5 （现在都已经 13 了）的时候，Dillon 想打破 FreeBSD 里一个很大的内核锁，John Baldwin 也想过，于是俩人就一起干了。不出意料，两人在关键部分出现了分歧，Dillon 一意孤行地提交了更改。这引发了非常激烈的争论，在长达一个月的争吵之后，Dillon 退步了，核心团队取消了他的提交权限，他最终也离开了 FreeBSD。这不是 FreeBSD 里的孤例，还有很多类似的事件发生过。而这件事直接引起了 FreeBSD 核心团队的反思：如果 FreeBSD 当时有既定的行为准则，会不会得到更好地处理呢？Dillon 走后，Gamergate 事件直接促成了 FreeBSD 的行动。简单来说，Gamergate 是一个与性别政治有关的运动，最开始是一个已经离开的 FreeBSD 成员写了一个 Perl 脚本来阻止 Gamergate 参与者的活动，并惹怒了那批人，使得 FreeBSD 惹火上身；再后来又有 FreeBSD 成员加 入 Gamergate 并开始在 Twitter 上攻击那个前成员，这下完全把 FreeBSD 拖下了水。这一事件不仅引起了激烈的讨论，攻击者随后还将对话日志泄露给了 Breitbart，核心团队别无选择，只能参与进来。2018 年， FreeBSD 确立了社区行为准则（Code of Conduct，CoC），这一准则从 LLVM 衍生而来，要求社区开发者友好耐心、热情好客、体贴、相互尊敬、对他人友善、注意不要乱说话、持不同见解时多换位思考。这是一项 “修补的紧急工作”，我们最初仍然诚实地认为 “精英” 意味着 “包容”。从那以后，我们学到了很多其他东西。—— Benno Rice
关于文中提及的社区问题及社区的 CoC，我建议大家先去看看 linus 喷了多少次提交代码的开发者，以及他们的内核邮件列表有多少辱骂他人的词汇。Linux 已经说过了——The Linux community is now a dirty quagmire（泥潭）。不全文翻译了大家自己体会吧，懂的都懂。为此我专门撰写了一篇文章。
06 结语 2022 年 1 月，FreeBSD 基金会制定了一份时间跨度近 5 年的技术路线图，决定从面向终端用户的改进（特指笔记本和台式机）、商用服务器、工具和应用和虚拟化和容器 4 个方面为重点，以扩大和增强技术团队的实力。这份蓝图代表 FreeBSD 仍在努力朝更好的方向进发，正如 Jordan Hubbard 所说的那样，现在的 FreeBSD 应该是年轻人 的天下，这样才会更具活力。早在 1990 年代我就用过 FreeBSD，当时我没什么钱，住在政府为低收入者提供的房子里，是 FreeBSD 帮助我摆脱了贫困 —— 在雅虎找到工作是因为我会用 FreeBSD，而 WhatsApp 也是用 FreeBSD 服务器为数以亿计的用户提供服务。—— WhatsApp 联合创始人兼 CEO Jan Koum
我确信这才是一种回馈 BSD 的好的方式，不论是你在商业上的成功也好，还是你只是靠 BSD 养家糊口。而不止局限于所谓代码的强制开源与否、你不可否认，BSDL 为商业公司快速发展提供了不竭的动力。而最终，商业公司也会回馈于 BSD，而这不是出于强制性或者是可怜 BSD，这同样是出于商用利益考量，将商业公司所需的基础注入到 BSD 系统中，会使得他们的开发迭代更加高效，FreeBSD 的开发者也乐意这样做。而不是让人看着就很难受，有代码却因为许可证原因不能复用，又去造无用的轮子。
你必须承认这个世界是由利益驱动的，因此 FreeBSD 绝不是错误的使用了一种错误的许可证，而这是为了真正的自由，为了更加远大的理想——让所有人不受限的在最大利益上使用 FreeBSD 的代码。这才是自由软件运动真正的目标。BSDL 给了人们最大的自由，而不是让人们想着如何逃避 GPL，如何再去重复造轮子，浪费人力物力。
GPL 在实际上严重阻碍了代码复用，产生了大量不利于环境保护的垃圾。从这个观点来看，阻碍生态环境良性循环是 GPL 的阿喀琉斯之踵。
不管 FreeBSD 这盘棋下得多么艰难、多么不得势，但它给世界带来的一切是如此精彩。