fork 和 distribution 有什么区别?

开源软件 distribution 和 fork 并不相同。了解它们之间的区别和潜在风险。
355 位读者喜欢这篇文章。
Forks and spoons, Open Office and Libre Office

Jason Hibbets 拍摄

如果您接触开源软件有一段时间了,您会听到 fork 和 distribution 这两个术语在对话中随意使用。对于很多人来说,两者之间的区别并不清楚,所以在这里我将尝试澄清这种困惑。

首先,一些定义

在解释 fork 与 distribution 的细微差别及其潜在陷阱之前,让我们先定义关键概念。

开源软件 是指满足以下条件的软件

  • 在某些 许可 约束下,可以自由分发
  • 允许在某些许可约束下查看和修改其源代码

开源软件可以通过以下方式使用

  • 以二进制或源代码格式下载,通常是免费的(例如,Eclipse 开发环境
  • 作为供应商的 distribution(产品),有时用户需要付费(例如,Red Hat 产品
  • 嵌入到专有软件解决方案中(例如,一些智能手机和浏览器使用开源 freetype 软件 显示字体)

自由及开源软件 (FOSS) 不一定是指“零成本”的“免费”。自由及开源仅仅意味着软件可以自由分发、修改、研究和使用,但需遵守软件的许可协议。软件分发商可以为其附加购买价格。例如,Linux 可以免费以 Fedora、CentOS、Gentoo 等形式提供,也可以作为付费 distribution 提供,如 Red Hat Enterprise Linux、SUSE 等。

社区 指的是协同开发开源项目的组织和个人。任何个人或组织都可以通过编写或审查代码、文档、测试套件、管理会议、更新网站等方式为项目做出贡献,前提是他们遵守许可协议。例如,在 Openhub.net 上,我们看到政府、非营利组织、商业组织和教育组织 为一些开源项目做出贡献

一个开源项目是这种协作开发、文档编写和测试的结果。大多数项目都有一个中央代码库,用于开发代码、文档、测试等。

一个 distribution 是开源项目的一个副本,以二进制或源代码格式提供。例如,CentOS、Fedora、Red Hat Enterprise Linux、SUSE、Ubuntu 等都是 Linux 项目的 distribution。Tectonic、Google Kubernetes Engine、Amazon Container Service 和 Red Hat OpenShift 是 Kubernetes 项目的 distribution。

开源项目的供应商 distribution 通常被称为产品,因此 Red Hat OpenStack Platform 是 Red Hat OpenStack 产品,它是 OpenStack 上游项目的 distribution,并且仍然是 100% 开源的。

主干 (trunk) 是社区中开发开源项目的主要工作流。

开源 fork 是开源项目的一个版本,它沿着与主干不同的工作流进行开发。

因此,distribution 与 fork 并不相同。Distribution 是上游项目的打包,由供应商提供,通常作为产品。但是,distribution 中的核心代码和文档都遵循上游项目中的版本。Fork——以及任何基于 fork 的 distribution——都会导致代码和文档的版本与上游项目不同。Fork 上游开源代码的用户必须自行维护,这意味着他们失去了上游社区协作带来的好处。

为了进一步解释软件 fork,让我们使用动物迁徙的类比。鲸鱼和海狮从北极迁徙到加利福尼亚和墨西哥;帝王蝶从阿拉斯加迁徙到墨西哥;燕子和许多其他鸟类(在北半球)向南飞过冬。成功迁徙的关键在于,群体中的所有动物都团结在一起,跟随领头者,寻找食物和住所,并且不会迷路。

独自行动的风险

一只脱离群体的鸟、蝴蝶或鲸鱼会失去与群体保持在一起的好处,并且不知道在哪里找到食物、住所和理想的目的地。

同样,fork 并修改上游项目并自行维护的用户或组织会面临以下风险

  1. 他们无法根据上游更新他们的代码,因为他们的代码有所不同。 这被称为技术债务;对 fork 代码进行的更改越多,将 fork 代码重新基于上游项目所需的时间和金钱成本就越高。
  2. 他们可能会运行安全性较低的代码。 如果在上游的开源代码中发现漏洞并由社区修复,则 fork 版本的代码可能无法从该修复中受益,因为它与上游不同。
  3. 他们可能无法从新功能中受益。 上游社区利用来自许多组织和个人的输入,创建新功能,以造福上游项目的所有用户。如果一个组织 fork 了上游,他们可能无法合并新功能,因为他们的代码有所不同。
  4. 他们可能无法与其他软件包集成。 开源项目很少作为单个实体开发;相反,它们通常与其他项目打包在一起以创建解决方案。Fork 代码可能无法与其他项目集成,因为 fork 代码的开发人员没有在上游与其他参与者协作。
  5. 他们可能无法在硬件平台上获得认证。 软件包通常会获得在硬件平台上运行的认证,因此,如果出现问题,硬件和软件供应商可以协作查找根本原因或问题。

总而言之,开源 distribution 只是由供应商销售和支持的上游、多组织、协作开源项目的打包。Fork 是开源项目的一个单独的开发工作流,并且有无法从上游社区的协作努力中受益的风险。

标签
User profile image.
Jonathan Gershater 自 1996 年以来一直在硅谷生活和工作,主要专注于云计算和虚拟化。他在 VMware、KVM、HyperV、AWS、OpenStack 和 CloudStack 技术方面拥有丰富的经验。在 Red Hat,Jonathan 专注于 Red Hat 虚拟化和 OpenStack 解决方案的竞争差异化。

2 条评论

Fork 的另一种描述。Fork 就像道路上的岔路口。如果您采取不同的方向,到达同一个地方会更困难,但并非不可能。您只需要弄清楚如何到达同一个地方,以及是否值得不遵循单一路线。

Distribution 很难。我非常确定大多数 distribution 都在维护自己的补丁,同时也受益于从主线拉取,他们也为主线做出贡献。我不相信他们默认跟随群体,而是会弄清楚他们是否同意群体。

更令人担忧的是,distribution 经常难以跟上主线项目的步伐,这给一些用户带来了问题。这有点像第 22 条军规。如果您不使用 distribution,您可能需要大量支持,这在时间和金钱上都很昂贵。

如果您使用 distribution,他们将不支持非 distribution 功能,因此您会失去控制权。这就是为什么一些大型公司的技术看起来落后了许多年。他们已经决定,支付超出 distribution 的费用是令人望而却步的,并且不符合他们的目标。通过这样做,他们确实使自己容易受到对该 distribution 的买入的影响。

对于桌面和普通消费者用户来说,这种模式从一开始就存在问题。

我记得在 90 年代,我问别人如何制作启动画面,他们斥责我说我应该关注 init 过程,并对角落里的 tux 图形感到感激。

硬件通常几个月都无法工作。快进到现在,设备供应商正在与开源社区进行出色的合作,以推出驱动程序,确保支持(和销售)。但这是一种脆弱的平衡。您可能会获得像 ARM SBC 这样的设备,它运行在 Linux 的 sunxi fork 上,或者您无法刷机或控制的智能手机。

通常这些设备在几个月后就被遗弃,并且永远不会再更新。像 hardkernel、sparkfun,甚至 Raspberry Pi 基金会这样的公司发布的硬件,如果没有他们的参与就无法完全支持。

我建议添加到本文中的部分是解释现代基于 git 的工作流中“坏 fork”和“好 fork”之间的区别。“在 git 中 fork 我”出现在项目上会加剧这里的困惑。

如果在 git 中 fork 的开发者正在处理一个侧分支,并打算将其合并回主代码库,那么 fork 在 git 中可能是一件好事。这种“好 fork”是社交编码精神的一部分,git 工具链的质量使其变得非常容易。

除了 Jonathan 在本文中描述的“坏 fork”之外,还有将 fork 用作“核选项”的情况。也就是说,社区使用 fork 权作为一种迫使与任性领导者达成共识的方式,否则社区将简单地带着他们的球去别处玩。这是第三种类型的 fork,本身既不好也不坏,但它通常表明发生了不好的事情,社区正在对此做出反应。

© . All rights reserved.