qt的产品级开源项目_开源产品与项目

最新推荐文章于 2024-08-12 09:05:40 发布

cumj63710

最新推荐文章于 2024-08-12 09:05:40 发布

阅读量1.5k

点赞数

文章标签： python java 人工智能大数据区块链

原文链接：https://opensource.com/article/19/11/product-vs-project

版权

文章探讨了开源项目和产品在安全性、组织使用方式、安全修复等方面的区别。重点讨论了作为项目和产品使用QT开源代码时，组织面临的权衡，尤其是安全性的考虑。文章指出，虽然直接使用开源项目具有更多自由度，但安全修复和维护可能带来额外挑战，而选择产品形式可以获得供应商的支持和保障。

摘要由CSDN通过智能技术生成

qt的产品级开源项目

开源是一件好事。对于安全性而言，开源是一件特别好的事情。我之前已经写过有关此内容的文章（特别是在不相信许多人的眼睛假设和开源共同体的情况下 ），并且我将继续对此进行撰写。但是，在本文中，我想谈一谈开放源代码的功能，它既可能是不利的又是好处：项目与产品之间的区别。我会坚定地站在一边（扰流板警报：对于组织而言，这是“产品”），但我想先声明一下。我受雇于Red Hat，而我们是一家通过支持开放源代码获利的公司。我认为这是一件好事，我赞成我们使用的模型，但是我想在本文的开头标记任何潜在的偏见。

开源对安全性有好处的主要原因是，当出现问题时，您可以看到正在发生的事情，并且有机会进行修复。或者，更现实地讲，除非您是出现问题的开源项目中具有特定专业知识的安全专业人员， 否则其他人将有机会解决该问题。我们希望有足够的安全人员具备所需的专业知识，以解决我们关心的软件项目中的安全问题和漏洞。

但是，它要复杂得多。作为一个组织，有两种主要的开源使用方式：

作为一个项目：您将获取代码，选择要使用的版本，自己进行编译，测试，然后进行管理。
作为产品：供应商接受项目，选择要打包的版本，对其进行编译，测试，然后出售对该软件包的支持，通常包括文档，补丁和更新。

现在，无可否认，使用项目“原始”将为您提供更多选择。您可以随时跟踪最新版本，进行编译和测试，并且可以以比产品版本所提供的速度更快的速度获取安全补丁，并选择最适合您的业务和用例的安全补丁。总的来说，这似乎是一件好事。但是，存在一些特定于安全性的缺点。这些包括：

某些安全修复程序带有封锁，只有少数组织（通常是供应商）可以访问该封锁。尽管您可以与更广泛的生态系统同时访问修复程序，但是您将需要检查和测试它们（除非您盲目地应用它们-请勿这样做），这已经由供应商完成了。
进行代码更改的巨大诱惑不一定（或立即）使更改进入上游项目，这意味着您可能正在运行代码的分支。即使您确实设法及时将这些更新发布到上游，在运行更改但又不在上游的期间，也冒着很大的风险，即任何安全补丁都不会立即适用于您的版本。（这是当然的，真正的非安全补丁，但安全补丁通常更迫切。）一种选择，当然，如果你认为你的版本很可能会被别人消费，是使的官方叉项目并尝试鼓励社区围绕这一点发展；但是最后，您仍然必须决定是在内部还是在外部支持新版本。
除非您确保软件的所有实例在您的部署中都运行相同的版本，否则将安全修复程序向旧版本进行任何反向移植都将需要您投资于（或接近于）创建人员的安全专业知识。首先解决问题。在这种情况下，您将放弃开源的“联邦”利益，因为您需要向复制社区技能的专家付费。

项目而不是产品来决定执行项目的内部产品化。您不仅会失去安全修复程序的联邦利益，而且会失去供应商支持的产品模型固有的巨大规模经济 。您可能还会错过范围经济 ：许多供应商将提供他们支持的多种产品，并且将能够以那些核心关注点不在产品支持上的组织不可能的方式在这些产品上应用安全专业知识。

这些经济性体现在使用供应商的联合体的另一个可能的好处中：一个事实：多个客户正在使用他们的产品，这意味着供应商有动机和收益流来花在安全性修复和一般功能上。它们还可以使用其他类型的修复和改进来应用资源，但是熟练的安全专家相对稀缺，这意味着比较优势的原则表明，他们应该处于最有利的位置，以便为更广泛的社区造福。 ^1个

如果您用来提供开源项目产品化版本的供应商破产或决定放弃对该产品的支持，该怎么办？好吧，这当然也是专有软件领域的问题。但是对于专有软件，可能会出现三种结果：

现在，您无法访问软件源，因此无法进行改进。
您可以使用该软件源，但更广阔的世界无法使用它，因此您是自己一个人。
为每个人提供了软件源，但是没有现有的社区可以对其进行改进，并且该社区要么消亡，要么需要大量时间来建立社区。

但是，在开源的情况下，如果您选择的供应商停业，总是可以选择使用其他供应商，鼓励新的供应商采用它，自己生产（并提供给其他组织），或者，如果情况变得最糟，则在寻找可扩展的长期解决方案时采取内部生产路线。

在现代开放源代码世界中，正如开放源代码联盟²的增长所示，我们（社区）已经非常善于管理这些选项。在一个财团中，组织和个人的团体围绕一个软件项目或一组相关项目聚集在一起，以鼓励社区发展，围绕功能和功能的增加，统一的安全性工作以及针对尚未定义好的用例的产品化，一直在尝试利用上述规模经济和范围经济。一个例子就是Linux基金会的机密计算联盟， Enarx项目的目标是该联盟。

选择将开源软件作为产品而不是作为项目来使用涉及到一些权衡，但是至少从安全性的角度来看，组织的经济效益非常明确：除非您有能力聘请足够的安全专家，产品最有可能满足您的需求。

1.注意：我不是经济学家，但我认为这种情况仍然有效。很高兴有评论解释我为什么做错（如果我…）。

2.如果确实需要，则为“财团”。

本文最初发表于爱丽丝，夏娃和鲍勃，经作者许可转载。