PDF核心开源
John Hubbard，苹果电脑
在真实世界的软件产品中使用开源：优点、缺点和不足
开源开发模式并非全新事物。几十年来，各个工程师一直将开源作为一种协作开发方法。然而，现在它已引起高层和中层管理的关注，最终被公开承认为商业工程的倍增器，以及避免重大软件开发成本的重要选项。
换句话说，面向对象编程通常承诺的“代码重用”，开源软件肯定正在实现。当然，这并非没有一定的成本和潜在的陷阱。本文描述了一家典型的商业软件公司采用开源的过程，并讨论了任何对开源作为工程选项进行评估时应包含的一些更重要的检查清单项目。
粗略地说，此检查清单包括以下内容：调查、评估、采用和沟通。
调查
世界上有大量的开源软件，而且每天都在增加，因此确定它是否可以帮助您的项目的第一步是仔细研究已经可用的内容。您不想重新发明一些昂贵的轮子。
以下示例中包含了对苹果电脑如何使用各种开源代码的引用，以展示一个或多个软件如何找到“机构相关性”。然而，公司使用开源软件的例子比比皆是，对于任何开源软件产品，调查过程的一个重要部分是了解还有谁在使用它以及为什么。这些例子可以作为您自己工作的宝贵路线图。
一些著名的开源软件来源
加州大学伯克利分校
在 1970 年代后期，加州大学伯克利分校的计算机系统研究小组开始了对操作系统的开创性研究，以及当时将相当年轻的 Unix 操作系统扩展为更通用的任务。这项工作的成果是 Unix 的伯克利软件发行版 (BSD)，以其强大的网络功能而闻名。
BSD 世界不仅限于操作系统，还包含各种库、工具和通用代码，这些代码在非常宽松的 BSD 许可下分发。此许可证基本上允许代码用于几乎任何目的，封闭或开源，并且不会对使用它的第三方代码产生“负担”的许可影响。最初的 BSD 发行版催生了许多独立项目，例如 FreeBSD、NetBSD 和 OpenBSD，所有这些项目都继续进行创新工作，并在相同的 BSD 许可下发布。这使得 BSD 软件成为商业软件和硬件供应商的热门选择，他们因此可以自由创建其产品的闭源变体，而不会受到不必要的限制。此类产品包括苹果公司的 Mac OS X 操作系统，其命令、库和部分内核在很大程度上基于 FreeBSD。许多商业网络设备（路由器、防火墙、服务器）和硬件设备也在嵌入式操作系统角色中使用高度跨平台的 BSD 操作系统。
Apache 软件基金会
Apache 软件基金会 (ASF) 可能以其广受赞誉的 Apache Web 服务器而闻名，但此后已扩大其授权范围，涵盖 Java 开发工具（尤其是在基于 Web 的应用程序 (servlet) 开发方面）和基于 Java 的构建工具。ASF 产品被广泛认为是同类最佳产品，并且基本上已接管 Web 服务器市场，其市场份额远远超过其他任何公司。Apple 在 Mac OS X 中同时包含 Apache 和 Apache2。
ASF 生产的软件根据 Apache 许可证发布，该许可证在精神上与 BSD 许可证相似，允许封闭和开源使用，限制极少。有关更多详细信息，请参阅本文后面的评估部分。
GNU 项目
自由软件基金会在 1984 年启动了 GNU 项目，最初的目标是创建一个完整的操作系统环境（GNU 系统）。它可能没有成功创建主流操作系统，但在此过程中确实创建了一些出色的工具。其中包括 Emacs 编辑器、GCC (GNU C 编译器) 和 GDB (GNU 调试器)。后两者实际上已成为各自领域的实际标准。GNU 项目还创建了许多通用库和工具，以简化创建跨平台软件的过程。这些库和工具可以大大减少许多类型的软件开发工作量。Apple 在其 Mac OS X 操作系统中附带了相当多的 GNU 软件，包括但不限于 GCC、GDB、make、Emacs 和 bash。
使用 GNU 项目软件的最大警告可能是其许可条款。GNU 软件主要根据 GPL（GNU 通用公共许可证）发布，其中一些软件根据限制较少但仍然强大的 LGPL（GNU 宽松通用公共许可证）发布。任何有兴趣在其自身产品中合并 GPL 或 LGPL 许可软件的人都应务必阅读本文中有关评估许可证的部分。
GNOME 项目
GNOME（GNU 对象模型环境）于 1990 年代中期启动，旨在为 Linux 操作系统带来先进的桌面环境，此后已发展成为众多通用工具和库的重要来源，用于执行从解析 XML 到处理音频数据的所有操作。GNOME 项目倾向于采用非常高级的方法来解决一般问题，这在其提供的软件中可见一斑。Apple 在 Mac OS X 中包含 GNOME 软件，例如 libxml2（XML 解析库）。
GNOME 项目的大部分（如果不是全部）产品均根据 GPL 或 LGPL 许可，因此同样的警告适用。
KDE 项目
KDE 桌面环境是另一个于 1990 年代中期启动的项目，旨在为 Linux 操作系统带来复杂的桌面环境，在此过程中也创建了各种通用工具和库。其中包括 Web 浏览器和办公效率套件，以及用于图像处理和解析 HTML 的库。Apple 在其 Safari Web 浏览器中包含了后一个库，称为 KHTML。
KDE 项目的大部分（如果不是全部）产品均根据 GPL 或 LGPL 许可，因此同样的警告适用。
SourceForge
SourceForge 自称是“世界上最大的开源开发站点”，在撰写本文时托管了超过 74,000 个项目，这可能并非仅仅是夸大其词。如果您能想象得到，您很可能在 SourceForge 上找到它。访问每个项目的信息和其他资源相对容易。如果使用 SourceForge 有任何警告，那仅仅是提供的搜索材料数量庞大。可以公平地说，在这 74,000 多个项目中，相当一部分要么处于休眠状态，要么除了想出一个漂亮的项目名称并创建一个 SourceForge 项目之外，没有取得太多进展。尽管如此，免费就是免费，SourceForge 绝对值得在任何研究考察中停留一下。
SourceForge 项目根据各种许可证发布，因此每个项目都应作为您评估的一部分进行单独研究。
Google 和 Slashdot
虽然与其他选项相比，Google 等搜索引擎上的简单关键字搜索更分散，但通常是提取空中参考资料的非常好的方法，这些参考资料通常是高度晦涩的项目。您显然需要对您要搜索的内容有一个相当清晰的概念，但诸如“qsort 算法”或“3D 库”之类的搜索字符串可以在很短的时间内生成令人惊讶的相关结果。
如果您有更多的时间并且愿意浏览无数关于从火星着陆到未决加密诉讼的新闻文章，Slashdot 新闻站点会报道 Apple、BSD 和 Linux 社区的持续发展，并且可以成为您可能错过或不知道要查找的信息的良好来源。
评估
因此，您已经完成了初步调查，并且找到了一些有望满足您需求的开源软件。您的检查清单上的下一件事显然是更深入地评估该软件，以查看它是否真的合适。
许可证
正如前面简要提到的，评估检查清单上的第一项是许可证。一些开源软件许可证带有重大约束，对于任何考虑在商业产品中使用开源软件的商业实体，必须由 компетентный 法律权威机构进行审查。此处提供的各种简要摘要仅旨在粗略了解每个许可证的含义，如果您决定继续使用相关软件，则任何摘要都不能替代对实际许可证文本的法律审查。
BSD 许可证。 这是更宽松的许可证之一。加州大学的原始版本包含三个条款，大致总结如下
1. 不要从源代码中删除我们的版权声明和免责声明。
2. 如果您发布二进制文件，请在二进制文件的某个位置包含版权声明和免责声明。
3. 未经事先书面许可，您不得使用我们的名称来认可或宣传您的产品。
一些 BSD 项目（例如 FreeBSD）甚至已从其自身版本的此许可证中删除了第三条条款，基本上仅要求对其工作给予一定的认可，并声明对其使用或误用不承担任何责任。作为许可证，律师倾向于将此许可证列为他们的个人偏好列表的顶部。
MIT 联盟许可证。 MIT 联盟许可证有时也称为 X11 许可证，非常宽松。它也是一个非常简短的许可证。实质上，它赋予您充分的许可将软件用于任何目的，只要您不要在软件崩溃时起诉作者或在您的广告中使用他们的名字即可。它通常被认为在“道德上等同于”BSD 许可证，尽管它对根据其许可的软件施加的限制甚至更少。
Apache 软件基金会许可证。ASF 许可证与原始 BSD 许可证非常相似，但增加了两个附加条款，这两个条款基本上都旨在加强以下观点：未经 ASF 事先书面许可，您不得使用 Apache 或 Apache 软件基金会条款来认可或推广您自己的产品，或在任何衍生作品中使用这些条款。此处的基本意图似乎是为了防止 Apache 品牌被淡化或在 ASF 董事会不批准的情况下使用。如果您在您的产品中使用 Apache 代码，但将您的产品称为其他名称，则您没事。
ASF 正在修订此许可证，并且可能在本文发布时完成。有兴趣的人士绝对应该访问 Apache 网站，以获取有关此许可证（或任何其他许可证）更新的更多信息。
GNU GPL/LGPL 许可证。 鉴于 GNU 许可证附带重大限制，因此绝对需要进行认真的法律审查。大致总结一下，这些限制是
GPL。 只要您自己的代码也根据 GPL 许可，并以相同的条款（基本上是免费的，并且以源代码形式提供）提供给最终用户，您就可以在自己的代码中使用 GPL 许可的软件。
LGPL。 您可以链接到 LGPL 许可的库，而无需使您的代码在相同的许可下（因此，Lesser，因为它的限制较少）。这并不意味着您可以自由地“借用” LGPL 许可库中的代码并将其散布在您自己的代码中，或者您可以免除向最终用户提供 LGPL 许可代码的源代码的要求。
同样，这些是这些许可证的极其简化的版本，因为每个许可证都有数千字，因此请务必仔细阅读每个许可证的全文。
双重用途许可证。 使用开源软件的最大潜在陷阱之一是可怕的双重用途许可证。此许可证允许其他开源软件使用该软件，但对闭源或商业软件构成某种“毒丸”。在这种情况下，将调用一个特殊条款，该条款通常要求用户支付软件许可证或软件所涵盖的某些专利的使用权。
有时，即使是商业用户也可以在不支付此类软件费用的情况下逃脱，如果他们构建其使用方式，以便他们可以放弃其自身使用它的源代码，从而符合许可证的开源定义。然而，这很棘手，尤其是在涉及库时。如果您是操作系统供应商，并且您发布了一个存在双重许可证的库，确保您的此库的客户端以源代码形式提供，那么您的客户可能会将其自身产品与此库链接怎么办？显然，您不想将您的客户置于他们可能甚至没有意识到的潜在地雷中。在讨论属于专利范围的软件时尤其如此，因为专利通常更容易在无意中侵犯。
值得重申的是，对于您打算使用和在许多情况下它反过来使用的任何和所有开源软件的许可证，绝对没有替代适当的法律审查的方法。很容易陷入认为您有资格获得使用某些特定软件的许可证的陷阱，但仔细检查后才发现它反过来又需要您没有资格获得许可证的另一款软件（至少不是没有大量美元投资）。
双重用途许可证是开源开发世界中一个有争议的部分，因此此处不会给出此类软件的具体示例，但请放心，它们确实存在。
另请注意，根据双重用途许可证发布的软件与双重许可的软件（例如 Perl、Mozilla 和 Qt）非常不同。对于双重许可的软件，用户可以选择限制最少或在其他方面最合适的许可证。这已成为一些希望提供其软件的“商业版本”的公司的一种流行选择，通常具有完整的技术支持，同时仍然免费提供给那些愿意按原样接受软件而无需此类支持的人。
代码质量
在您完成许可证审查后，评估检查清单上的下一个重要项目是对代码质量的难以捉摸的确定。可悲的是，并非所有开源软件在质量方面都是相同的，评估创建它的项目的一般跟踪记录和在该领域的时间长度是衡量其代码可能有多精细的一种有用（但并非万无一失）的方法。您还应该尽力了解代码的维护活跃程度（上次修改是什么时候？为什么？）以及代码在其生命周期中拥有多少维护者；经常在不同人手中传递的软件通常会因每个新维护者的经验不足和学习曲线而受到影响。
社区
接下来，您需要评估围绕该软件的用户社区有多大。有用户社区吗？其成员对邮件列表或 Web 论坛上其他人的问题和/或错误报告的响应程度如何？新的贡献是否及时合并，还是似乎石沉大海？积极维护的代码显然更有可能安全且功能齐全，因此所有这些都是在承诺使用开源软件之前要权衡的关键因素。您最不需要的是继承一堆被遗弃的软件，您随后可能会痛苦地发现该软件被遗弃是有充分理由的。
安全性
另一个重要但有时被高估的统计数据是针对该软件发布的安全公告的数量。使此指标棘手的是，有缺陷但不是很流行的软件不太可能发布许多安全公告，仅仅是因为没有那么多人使用（或试图攻击）它。相反，非常流行的软件经常受到攻击，并且可能会在安全公告中不成比例地出现。这显然是一个判断性决定，但如果某个软件似乎以惊人的频率出现在安全公告中，您最好寻找同样功能强大的替代方案。
好的，您已经完成了调查，您已经找到了一些合适的软件，您已经评估了它并发现它很好，所以艰苦的工作已经过去了，对吗？不幸的是，并非如此，因为下一步是...
采用
将开源软件代码集成到您的产品中具有其自身的内部成本；在这方面，它绝不是真正的“免费”。您应该在管理、技术和社区领域考虑一些重要的内部检查清单项目。这些将有助于确保开源软件在您的公司中能够并且将会成功。
管理：内部宣传
工程师可能出人意料地不愿采用相对成熟的产品，而不是从头开始开发自己的产品，即使后一个选项构成的工作量明显更大。即使您克服了较少合理的自我问题和满意度丧失问题，这两者都可能是重要的障碍，工程师也可能担心不容易消除的问题：代码质量、可以轻松修改代码的方式以及外部开源软件开发人员可能对他们的期望。除非您的工程师已经非常看好使用开源的想法，否则完成此过程的这一部分可能需要大量的对话和技巧。
您的营销人员通常会喜欢使用开源的吸引力，但是，如果要大量利用开源，您可能还需要明确的差异化点，以证明您产品的商业价值。管理层和法律部门还需要清楚地了解代码的来源、附加在代码上的限制以及对工程部门的持续义务的期望。
技术：移植
开源软件代码可能无法直接在您的平台上运行。假设需要一定量的移植和/或适应您的需求。
社区：流程和关系管理
随着您在代码库方面取得进展，将您的更改捐赠回开源软件社区是建立信任、使未来与外部开源软件代码库的合并更容易（且成本更低）以及帮助向许多可能影响您产品购买决策的同一社区中的意见领袖宣传您的存在的绝佳方式。这也是在开源软件开发通常代表的易货经济中建立一定量“信用”的重要组成部分。开源软件社区中的志愿者工程师更可能帮助那些已证明他们致力于开源软件整体开发过程的成功的人。即使只是保持沟通渠道畅通，无论是否有代码贡献，也具有重要价值；大多数开源软件工程师对他们的代码被用来做什么非常感兴趣。
完成所有这些工作的重要性怎么强调都不为过。如果您建立了一个声誉，无论是公平还是不公平，作为一个“索取者”，对回报任何东西甚至与开源软件社区真诚沟通都没有兴趣，那么您会发现自己身处一个您可能永远无法爬出的深渊，您的声誉受损，并且其影响可能比您想象的要广泛得多。就软件工程而言，这是一个小世界，尤其是在现在每个人都联网的情况下，工程师显然是任何高科技公司的命脉，因此从中得出的结论非常明显。
Apple 自身也在此处吸取了一些重要的教训，创建了额外的沟通/协作渠道，例如 OpenDarwin 项目，并允许工程师在明显传统的沟通机制过于严格或无效时更公开地沟通。承诺在必要时不断评估和改进沟通流程也大有裨益。
沟通
您已成功将开源软件集成到您的产品中，您已将相关更改返回给开源软件社区，并与他们建立了合理的融洽关系。现在是部署您的产品的时候了。检查清单上的下一步是什么？对于某些人来说可能很明显，但可悲的是，并非对所有人来说都很明显，那就是沟通，无论是在初始阶段还是在部署后维持您的产品时。
初始阶段
营销。 首先也是最重要的是，您的营销人员将（或应该）希望准备好关于您使用开源的消息，即使只是为了回应可能出现的任何问题。确保他们也知道足够多的信息以做出正确的断言，否则您可能会在 Slashdot 上付出代价，因为他们中的一个人在公开场合就谁提供了技术或将其归因于其他人而犯了一个令人尴尬的错误。
工程。 工程部门还需要了解，公司外部的人员会对您使用开源持自己的看法，无论是负面的还是正面的。个别工程师如何与这个外部社区互动（或不互动）将对这种正面/负面看法的平衡产生很大影响，因此在您公开之前，请确保每个人都在同一页面上。
法律。 您的法律部门必须理解并推动与部署此软件相关的基本义务（如果有），例如分发或提供 GPL 代码的源代码。不要假设工程人员有带宽或理解力来独自完成此操作 - 法律部门的某个人应该确保这种情况真正发生。
部署后维持
真正利用开源软件也意味着理解和承认公司外部的工程师对于您当前和未来的可交付成果可能与公司内部的工程师一样重要。考虑到他们对每个人的工作习惯的控制程度差异很大，许多公司发现这个概念很难掌握。尽管如此，从总体上来说，这是事实，并且在管理您未来的开发流程（在您的产品发布后）时需要考虑许多因素
NDA（保密协议）问题和公司安全肯定会使与开源软件社区的沟通变得棘手，但通过适当的指南，它仍然是可管理的。一个更大且更普遍的问题是，由于工作量和/或推动其沟通重点向内的截止日期压力，工程师只是选择根本不与外部沟通。明确允许他们何时何地进行沟通以及“期望”进行沟通可以在很大程度上缓解此问题，并防止与开源软件社区疏远。
征求和理解开源软件社区对您已集成的产品（们）的目标是保护您自身未来利益的重要组成部分。定义并尝试向开源软件社区传达您自己对产品的需求也肯定会影响他们自己的方向，并且公开声明您自己的意图也有助于搭建与社区的桥梁，因为它很清楚您正在努力将他们视为同行，而不仅仅是免费劳动力的来源。
管理过渡和维持工程也是部署后的关键项目，因为健康的开源软件绝不会停滞不前，而商业产品周期可能相当漫长。您必须预测并将同步成本纳入您的时间表。
最后，当涉及到招募技能娴熟、积极进取的工程师时，开源软件社区可能是一种宝贵的资源，这些工程师对您的产品至少某些方面具有现成的理解。这就是从一开始就发展和维持与开源软件社区关系如此重要的原因之一，并且还应该理解，从这个社区招募的开源软件工程师将对这个社区有剩余的忠诚度。维护您与社区关系的一种好方法是允许这些工程师继续在开源软件公共代码库上进行一定量（现在是补贴）的工作。他们获得更好的代码，您获得更好的代码，双方都赢。
社会秩序和工程 дисциплина
开源不仅仅是一种获得免费代码的方式；它本身既是一种社会秩序，也是一门完整的工程学科，如果您想在那里取得任何成功，就必须尊重其非正式的“道路规则”。然而，它也是当今最令人满意的软件工程方式之一，它允许小型工程团队应对以前被认为对于他们规模的团队来说根本不可能的各种挑战。它还极大地扩展了以前在小型和大型公司中存在的工程“孤岛社区”——这些社区非常封闭，并且缺乏充分接触到许多可能更好、更便宜且质量更高的工作方式。一家公司不可能聘请世界上所有最优秀的工程师，但通过积极参与开源社区，它不再需要这样做了！
开源软件来源
FreeBSD
https://freebsd.ac.cn
NetBSD
http://www.netbsd.org
OpenBSD
http://www.openbsd.org
Apache 基金会软件
https://apache.ac.cn
GNU 项目
https://gnu.ac.cn
GNOME 项目
http://www.gnome.org
KDE 项目
http://www.kde.org
SourceForge.net
http://sourceforge.net
Google
http://www.google.com
Slashdot
http://slashdot.org
Apple Open Darwin
http://www.opendarwin.org
Mozillazine（有关 Safari Web 浏览器的信息）
http://Weblogs.mozillazine.org/hyatt/
开源软件许可证
BSD
https://open-source.org.cn/licenses/bsd-license.php
MIT 联盟
https://open-source.org.cn/licenses/mit-license.php
Apache 软件基金会
https://apache.ac.cn/LICENSE.txt
GNU GPL/LGPL
https://gnu.ac.cn/licenses/licenses.html#GPL
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
乔丹·哈伯德（JORDAN HUBBARD） 是苹果公司核心操作系统工程团队的 BSD 技术经理。他负责 Darwin 的 BSD 技术基础，Darwin 是 Mac OS X 的基于 Unix 的核心。在 2001 年加入苹果公司之前，哈伯德曾担任风河系统公司的首席技术专家，负责 FreeBSD CD-ROM 产品线。他是 FreeBSD 项目的联合创始人，该项目始于 1992 年。哈伯德于 20 世纪 70 年代开始了他的软件职业生涯，从事小型计算机工作，并在包括加州大学伯克利分校和数字设备公司在内的组织中担任过各种工程和管理职位。他是开源社区的常客，自 1982 年以来一直编写自由软件，从 comp.sources.unix 档案的第 1 卷开始，并继续为 MIT 的 X Contributed Software 集合做出各种贡献。
© 2004 1542-7730/04/0500 5.00 美元
最初发表于 Queue vol. 2, no. 3—
在 数字图书馆 中评论这篇文章
更多相关文章
阿曼达·卡萨里（Amanda Casari），茱莉亚·费拉奥利（Julia Ferraioli），朱尼珀·洛瓦托（Juniper Lovato） - 超越代码仓库
关于开源的大部分现有研究选择研究软件仓库而不是生态系统。开源仓库通常指的是版本控制系统中记录的工件，偶尔包括围绕仓库本身的交互。开源生态系统指的是仓库、社区、他们的互动、激励机制、行为规范和文化的集合。开源的去中心化性质使得对生态系统进行整体分析成为一项艰巨的任务，社区和身份以有机和不断发展的方式交汇。尽管存在这些复杂性，但对软件安全和供应链日益严格的审查使得在进行关于开源的研究时，采取基于生态系统的方法至关重要。
格温娜维尔·奥尔德里奇（Guenever Aldrich），丹尼·曾（Danny Tsang），杰森·麦肯尼（Jason McKenney） - 致仍然不理解的项目经理的三部曲
本文研究了系统采购工具箱中的三种工具，这些工具可以加速开发和采购，同时降低项目风险：OSS、开放标准和 Agile/Scrum 软件开发流程都是 DoD 采购项目管理工具箱的强大补充。
杰西·弗拉泽尔（Jessie Frazelle） - 开源固件
开源固件可以通过使固件的行为更可见且更不容易造成危害，从而帮助将计算带到一个更安全的地方。本文的目标是使读者感到有能力向可以帮助推动这一变革的供应商提出更多要求。
马歇尔·柯克·麦库西克（Marshall Kirk McKusick），乔治·V·内维尔-尼尔（George V. Neville-Neil） - FreeBSD 5.2 中的线程调度
繁忙的系统每秒会做出数千个调度决策，因此调度决策的制定速度对于系统的整体性能至关重要。本文——摘自即将出版的书籍《FreeBSD 操作系统设计与实现》——使用开源 FreeBSD 系统为例，帮助我们理解线程调度。最初的 FreeBSD 调度器是在 20 世纪 80 年代为大型单处理器系统设计的。尽管它在今天的环境中仍然运行良好，但新的 ULE 调度器是专门为优化多处理器和多线程环境而设计的。本文首先研究了最初的 FreeBSD 调度器，然后描述了新的 ULE 调度器。
© 保留所有权利。