PDF开源适合你吗？
商业软件商店中开源的虚构案例研究
David Ascher，Activestate
媒体经常将开源软件描绘成商业软件的直接竞争对手。这种描述，通常将大卫（Linux）与歌利亚（微软）对立起来，使周末报纸的阅读变得有趣。然而，这在很大程度上忽略了开源对开发组织的意义。
在本文中，我使用 GizmoSoft（一家虚构的软件公司）的经验来介绍关于在软件开发商店中使用开源软件的影响的一些观点。我的目的是帮助管理者、架构师和开发人员回答以下问题
• 为什么我们应该使用开源软件？
• 我们应该在何时使用开源软件？
• 我们应该如何使用开源软件？
• 使用开源软件将如何影响我们的工作方式？
让我们走进 GizmoSoft 的大厅，了解人们对公司使用开源软件的看法。（注意：以下描绘的事件和人物均为虚构，不代表任何在世或已故人士。八卦也是虚构的。）
在电梯里：公司意向声明
乔安娜（营销总监）： 你知道吗，我第一次喜欢我们的员工会议。我很高兴乔 [CEO] 愿意公开声明我们的软件开发实践比竞争对手更好。从营销的角度来看，能够利用围绕 Linux 的热议真是太好了。它确实使我们与众不同。当 Web 服务对我交谈的几乎所有人来说都如此无聊时，让“Web 服务支持”变得性感一直很困难。
弗朗西斯（内部律师）： 是的。这提醒了我，我需要和苏珊 [开发总监] 谈谈。我们必须解决法律问题。我真的很担心许可问题。
乔安娜很高兴，因为 CEO 宣布董事会已决定“公开”一项内部倡议，以积极在公司的软件开发实践中使用开源。私下里，董事会希望它可以削减开发成本，并使公司更具收购目标吸引力。
乔安娜看到媒体因为“整个 Linux 事件”而蜂拥而至开源，她认为公司可以从搭上这股潮流中获益。另一方面，弗朗西斯因为同样的员工会议而心情不好。他见过一些开源软件许可证，他一点也不喜欢它们。它们含糊不清，由不了解法律的理想主义者撰写，这让他非常紧张。过去，他主要处理知识产权所有权明确的合同和许可问题；现在突然他需要教育开发总监关于不正当许可的风险。似乎没有人意识到，如果风险管理不当，他的工作就会受到影响！
在开发区：实施开源
这是开发活动的中心。有八名开发人员在两个项目上工作。一个项目处于早期规划阶段，大家都很开心。另一个项目已经晚了两周，拐角处的按摩治疗师从该团队那里赚了很多钱。
斯图加入公司只有两个月——他是员工中最年轻的开发人员，生活很美好。他被分配到在 GizmoSoft 的主要产品之一的下一个版本中构建目录功能。斯图最近从大学毕业，他对构建一些真正的软件感到非常兴奋，而不是他在学校做的玩具项目。周末，他决定正确的方法是使用 OpenDir。毕竟，他了解它，他在学校见过它工作，他很乐意参与工作中的开源项目。那太棒了。
问题是斯图的导师约翰想到了另一个解决方案，基于他多年前编写的代码，称为 BorkDir。现在是每周状态会议的时间了
约翰： 你在确定使用哪个目录系统方面做得怎么样了？
斯图： 不错！我认为 OpenDir 可以正常工作，就像我上次说的那样。
约翰： 嗯。我一直在看他们的发布计划。他们似乎一直在发布软件——在过去的七年中发布了大约 50 个版本。这给我的印象不是真正可靠的软件。
斯图：呃，好吧，你知道，其中大多数是，比如，补丁版本，你知道吗？
约翰： 我猜是吧。使用 BorkDir 有什么问题吗？并不是说我希望我的代码不惜一切代价被使用，但如果我们的代码足够好，为什么不使用我们的代码呢？
斯图： 我不知道 BorkDir 有什么问题。你上周不在，我找不到公司里其他人告诉我它是如何工作的。
约翰： 啊，对。你确定 OpenDir 会满足我们的一切需求吗？
斯图： 差不多吧。BeHeMothCo.com 在他们的系统中使用它，所以我无法想象它不适用于我们。
约翰： 好的，好吧，让我们试一试。
这段对话突出了值得评论的一些问题。
斯图，刚从他在大学里拥有的协作环境中出来，渴望加入“开源运动”。约翰更不情愿。他的不情愿源于他对一种陌生的工作方式感到不适，这种方式对他来说太公开和公共了。此外，约翰还担心软件质量。对于斯图来说，频繁的发布表明动态开发；对于约翰来说，它们表明流程失败。
斯图和约翰都部分正确。确实，开源项目倾向于在其生命周期的后期（或者有时根本没有）发展流程（发布定义、发布管理、质量控制等）。另一方面，商业软件和开源软件之间“合理发布率”的定义指标有所不同。商业软件必须应对营销成本、增加的客户支持以及新版本发布时的收入延迟。开源项目——尤其是在 SourceForge.net 等管理基础设施支持的情况下——可以相对容易地生成次要或微型版本。
如果您决定在商业产品中使用开源软件包，请计划评估软件包的每个版本，以了解哪些版本“值得”集成。这些评估需要在软件开发过程中的适当时间（风险可以容忍时）进行，并且应包括各种标准，例如：您的项目重要的错误是否已修复；“升级”涉及的预期开发人员和 QA（质量保证）工作量是多少；以及考虑到更改的性质以及测试和 QA 计划等，对整个系统的风险影响是什么。有了适当的决策框架，评估频繁发布充其量只是一个小问题；在发布非常频繁的情况下，这些评估可以批量进行。
然而，发布频率很可能在此案例中是一个转移注意力的点——OpenDir 和 BorkDir 之间的比较不仅仅是开源软件包和专有软件包之间的比较。它也是流行的开源项目和由将决定使用哪个软件包的人员内部构建的组件之间的比较。这为约翰创造了一种情绪化的局面，他很可能至少会暂时患上 NIH 综合症（即认为非本地发明的东西本质上更糟）。
然而，约翰在“问题”（为 GizmoSoft 产品构建目录功能）以及更重要的是，在正在构建的系统的总体需求方面拥有丰富的经验。忽视他的经验将是一个严重的错误。一个好的方法是约翰与斯图一起分析开源软件包。这将使约翰的经验应用于该问题（因为许多开源项目在企业环境中并不适用，仅仅是因为它们不是在这些环境中成长起来的）。此外，此过程将教会斯图如何批判性地评估软件，这项任务在未来可能会变得更加重要。
这样的评估可能会揭示 BorkDir 具有开源等效物所缺乏的关键功能。总的来说，开源项目可能更完整，并且肯定比内部代码（如果使用过，可能以前只在一个应用程序中使用过）经过更广泛的测试。在这种情况下，约翰和斯图应评估将关键功能添加到开源项目所需的工作量。然后，他们必须做出艰难的选择，是将这些功能贡献回开源项目还是保密。（这将对他们未来使用代码产生影响，详见后续章节。）
在作战室：开源在行动
项目延期了。每当项目经理看到 CEO 时，他都会感到肩上熟悉的重担。CEO 努力不每天都问，“准备好了吗？” 他真的不需要问；他的肢体语言已经说明了一切。
现在是时候审查昨晚的构建，看看是否可以发布了。回归、新错误、性能问题和安装问题等常见问题都需要确定优先级、修复或记录。但今天在“发布决策”状态会议上出现了一个新的意外转折：产品开源组件中的一个严重错误。
山姆（开发人员）： 呃，昨晚晚些时候发生了一些事情，我认为我们应该讨论一下。我们认为是我们代码中的错误实际上追溯到了小部件本身，您还记得它是 MyToolkit 开源库提供的。这里有人了解该代码吗？ <沉默>
桑迪（项目经理）： 谁拥有该代码？ <沉默和摇头>
桑迪： 呃哦。是谁签入的？
汤姆（首席架构师）： 我想是斯泰西六个月前做的，那时她还在做前端工作。我不知道是否有人跟进了 MyToolkit 项目。问题可能已得到修复。[汤姆用他的新平板电脑在 SourceForge 上检查项目，只是为了炫耀。] 是的，好吧，我们代码中的版本是 2.14.a，当前版本是 3.0.4。2.x 分支中还有更多版本。我不知道我们的问题是否已得到修复，或者，如果已修复，是在哪个版本中修复的。
桑迪： 好吧。汤姆，你能和山姆一起回答这两个问题，并在今天结束前给我们一份状态报告吗？这是最高优先级，伙计们，因为这个错误是一个阻碍因素，而且就我所知，我们不知道修复它需要多长时间。QA 组大概也需要在修复后对用户界面进行全面审查。 <叹气>
发布延迟已经够糟糕了；在这种情况下，阻碍性错误存在于开源代码中的事实突出了开发过程中的一些常见失败
1. 因为软件组件是在大楼外编写的，所以它没有像 GizmoSoft 员工编写的软件那样受到彻底的监控。如果一个组件足够重要，可以阻止发布，则必须定期监控它。多个 MyToolkit 版本（可能解决了许多已记录的错误）被“错过”这一事实表明，没有人认为 GizmoSoft 软件会继承这些错误。正如前面讨论的那样，升级到开源组件必须被视为 GizmoSoft 发布计划的一部分。给开源作者的提示：具有最新单元测试的开源项目更有可能被大公司采用，因为“客户”可以比较版本之间的单元测试，以查看实际更改了什么。这比信任文档更好，文档通常滞后或不完整。
2. MyToolkit 软件的关键开发人员确实存在；他们只是恰好不在 GizmoSoft 工作。汤姆和山姆必须找出升级 MyToolkit 组件是否会解决问题，但他们不了解代码。如果 MyToolkit 项目的关键开发人员通过合同关系或仅作为顾问随时待命，那就容易得多。那个人可能在 30 秒内回答这个问题，而且，与大多数商业软件商店不同，知识渊博的工程师和他们的电话之间可能没有支持人员的防火墙。如果您关心一段代码，那么即使他们不“属于您”，也值得与该代码的主要作者建立关系。请注意，在这种情况下，您可能需要能够快速开支票，即使金额相对较小。对于希望有效使用开源的公司的一个建议是，建立相当于软件修复的办公用品零用基金。
在苏珊的办公室：法律影响
以下交流非常有希望。弗朗西斯认真对待他作为组织法律监护人的责任，足以预测使用开源可能出现的问题。他与苏珊讨论了这些担忧，苏珊是最终负责 GizmoSoft 软件内容的人。苏珊尽其所能地分析了一组许可证，并将该分析传达给了她的团队。因此，公司不太可能在不知不觉中违反许可证条款。
弗朗西斯（内部律师）： 苏珊，关于这个开源的事情——我没有意识到我们实际上计划在我们的产品中发布开源软件。我对此有点担心。
苏珊（开发总监）： 啊。你看到我十一月份的电子邮件了吗？我讨论了似乎可以包含在我们软件中的许可证类型。我确信你收到了那封电子邮件的抄送。我基本上将其分为三类：我们可以在内部使用的项目；我们可以在自己的产品中使用的组件（使用我的法律术语版本，以便开发人员可以理解他们必须做什么）；以及我们根本不应该接触的代码。如果你愿意，我可以再次向你发送该列表。
弗朗西斯： 是的，请这样做。我接到一位董事会成员的电话，他非常担心，考虑到 SCO 诉讼等等。我讨厌非律师开始告诉我应该注意哪些法律风险。突然之间，每个人都成了赔偿和版权法方面的专家，只是他们不了解基本的合同法。
苏珊： 我知道你的感受。每个人都认为他们知道编写软件的最佳方式，但他们以前从未在特定的某一天发布过软件。我希望我们不必扮演律师的角色，但不幸的是，开发人员和我最终会花很多时间阅读软件许可证。对了，你觉得为开发团队做一场关于知识产权法、许可证以及所有这些的自带午餐讲座怎么样？
弗朗西斯： 听起来不错。即使没有别的，他们也应该知道我是谁，以便他们在有疑问时可以问我问题。星期五怎么样？
苏珊和弗朗西斯显然彼此信任，会做对组织正确的事情。鉴于法律专家（他们有时将风险视为必须不惜一切代价遏制的邪恶）和技术狂热者（他们有时将缺乏风险视为无聊至死，并且他们热衷于使用“新事物”）之间的哲学距离，这可能很难实现。
理想情况下，苏珊和弗朗西斯会建立流程来简化开源使用并防止许可证违规。例如
• 新开发人员入职培训应包括关于许可证和知识产权法其他方面的简报，以便新员工了解情况。
• 项目经理的职责应包括许可证检查，以便进行适当的检查以避免，例如，将具有“病毒式”许可的开源代码添加到专有产品中。还应该有人分析包含
每个软件组件（或通常，每种许可证类型）的下游后果（例如文档要求）。
在山姆的办公室：宣传
首席技术官（山姆）和产品经理（苏珊）正在与下一代产品的首席架构师（汤姆）会面，该产品预计在明年某个时候推出，但尚未确定。汤姆是最有责任让 CEO 在上次员工会议上说出“开源”这个词的人；他越来越擅长向上层管理人员推销想法。今天他的目标很明确：他已决定（纯粹出于哲学原因，但他永远不会承认这一点）公司的下一个产品应至少包含 50% 的开源内容。他很清楚从业务角度来看这是一个愚蠢的目标，因此他转而谈论其他好处。
汤姆： 让我们在 Apache 的东西之上构建它。Apache 最出名的是其 Web 服务器，但提供了各种各样的软件包，主要基于 Java。它真的很好！
山姆： 我不明白。我们去年刚收购了 SmallCo，因为它据说在该领域拥有良好的技术。那个计划发生了什么？
汤姆： 你最近和那些家伙谈过吗？自从 Grisha 离开后，很明显，该代码是用胶带拼凑起来的，后端由蚂蚁农场驱动。我认为团队真的很棒，他们能够用他们不得不处理的代码做很棒的事情，但我真的不想在那个基础上构建我们的新旗舰产品。
山姆： <咕哝>。你没有对那个代码库进行尽职调查吗？
汤姆： 我怎么可能在一个星期内，在发布期间做到这一点？
苏珊： 让我们不要重提旧事，没意义。你能告诉我更多关于这个 Apache 的东西吗？
汤姆： 是的，它已经开发了好几年了，但最近变得非常稳定，尤其是在 IBM 参与之后——它在符合标准方面真的做得很好。我还听说诺基亚在幕后参与其中，如果我们最终推出我们的移动战略，这可能会很好。
山姆和苏珊同时说： 酷！
苏珊： 我假设那会推迟我们的发布日期，对吧？
汤姆： 什么？不，不，绝对不会。事实上，我一直在构建一个原型，只是为了感受一下，我很确定我们可以比我们目前计划的更早发布 alpha 版本。
苏珊： 为什么更早？
汤姆： 因为我们的基础将比其他情况下的测试更好。另一个很棒的事情是，我插入了另一个开源项目，并免费获得了一种非常好的内置脚本语言，这应该使原型制作更快。
还有一件事... 我认为我们应该在该社区中寻找我们一直在面试的团队负责人。如果我们的员工中有人非常了解该代码，鉴于其重要性，那将非常好。
山姆： 听起来不错。但要确保你没有找来一个狂热的反资本主义者。
汤姆： 对——我听说 IBM 和诺基亚是狂热的反资本主义的温床。
苏珊： 请找一个洗澡穿鞋的人。
在这里，汤姆非常敏锐地展示了使用开源软件组件作为产品开发计划一部分的潜在（并且在对话的这个阶段，一切都与潜力有关）好处
久经考验的软件。 像 Apache 软件基金会运营的许多信誉良好的软件项目，往往在许多类型的环境中都经过了实战检验（事实上，在许多比您可能可用于测试的环境更多的环境中）。
标准合规性。 尤其是在处理 Web、Web 服务、XML 等互联网技术时，开源项目通常高度符合标准。开源标准似乎吸引了开源开发人员的自豪感。开放标准为项目目标设定了绝对目标，这些目标比模糊的概念（如“良好的用户体验”或“用户友好”（商业软件商店往往做得更好））更容易量化和验证。
未来系统的可见性。 您今天可能没有在嵌入式设备或前沿平台上进行开发，但其他人正在这样做。如果他们接受开源模式，他们可能会将其工作（补丁、文档、经验）贡献回项目。因此，当您的业务需求将您带到该设备或平台时，大部分基础工作都已为您完成，这在自研系统中永远不会发生。
通过这些论点，汤姆通过暗示质量、降低风险和可定制性来吸引产品经理苏珊。他通过暗示“轻松”移植到新平台和标准合规性来吸引首席技术官山姆。
未来——GizmoSoft 将走向何方？
GizmoSoft 最终会遇到使用开源软件的其他缺点。其中大多数可以通过积极主动的规划和管理来缓解。
没有或文档不足。 许多人免费编写开源软件。几乎没有人免费编写开源文档。文档的缺乏（尤其是对于不成熟的项目）可以通过两种方式补救
1. 阅读源代码。毕竟，许多工程师在商业软件方面有糟糕的经历后，无论如何都不会相信文档，并且宁愿从程序源代码中推断功能。
2. 运用您的企业资源。开源项目通常包括可以编写文档但没有动力这样做的人员。金钱可以获得核心文档的编写，这些文档通常会由项目持续免费维护。这是“种子资金”的明智之举。
该软件不符合您的需求。 这个问题没有通用的补救措施，但一些分析通常可以提供帮助。可能是问题域不适合开源软件解决方案。在这些情况下，最好尽早意识到这一点并提出替代计划。
然而，有时，开源项目领导者专注于他们自己感兴趣的问题，但如果他们知道您的问题，他们愿意将重点重新放在您的问题上。当商业公司采用开源项目时，开源软件开发人员可以获得信誉并提高其专业声誉。因此，不要害怕与项目的贡献者交谈。项目解决您的问题可能只需要了解您的问题。
或者，一些项目愿意接受赞助工作，您可以通过赞助工作来支付添加特定功能的费用。但是，不要假设您可以与其他公司分摊成本；这很少可行。
软件项目消亡。 当责任过度集中在一个或两个人身上时，可能会发生这种情况。为避免这种情况，最好在采用项目之前评估项目的长期前景。如果主要作者放弃项目，您可能别无选择，只能自己接管它。
您使用了开源项目，进行了一些更改，但没有将更改贡献回项目。也许您担心保护您的知识产权；也许您担心竞争优势；也许您很懒惰。项目继续前进，现在您的维护负担越来越重，因为您想要主团队对“主干”所做的增强功能，但您也想保留您的更改。（换句话说，您“分叉”了代码。）在这种情况下，您应该重新审视将更改分开的明智之处。这里没有简单的答案，特别是如果您的更改中存在“竞争性知识产权”，但值得批判性地评估该知识产权的真正价值，并将其与持续分叉维护的真正成本进行比较。
在大多数情况下，没有 1-800 电话可以拨打。虽然一些组织确实提供支持合同，但这对于大多数开源项目来说肯定不是真的。总的来说，您获得及时支持的能力将取决于您让志愿者关心您的需求的能力——如果您从不知情但热心的帮助者那里得到相互矛盾的答案，您不应感到惊讶。
如果仔细整合，开源软件组件可以为商业软件开发贡献速度、稳健性和适应性。为确保这种积极的结果，值得了解组织应预期哪些变化作为这种努力的一部分。正如我们在本文中看到的那样，最大的影响实际上并非在源代码级别（毕竟，代码不知道它属于哪个许可证）。相反，因为使开源代码“开源”的是贡献者之间关系的性质和围绕开发的流程，所以这些是使用开源将影响您的组织的领域，在开发的每个阶段都是如此。
最新更新： 传闻 GizmoSoft 新产品的迅速成功，加上公司在其传统领域的稳固地位，使其成为 BeHeMothCo.com 收购的理想对象。事实证明，在这种情况下，开源的好处不在于降低成本，而在于更快地生产出更好的产品。
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
DAVID ASCHER 是 ActiveState 的首席技术专家，该公司为语言、语言发行版和企业支持服务提供开源编程工具。作为 Python 书籍的作者和 Python 软件基金会的董事，他在将 Python 和 Mozilla 等开源项目集成到商业产品方面拥有丰富的技术和业务经验。
© 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、开放标准和敏捷/Scrum 软件开发流程都是 DoD 采购项目管理工具箱的强大补充。
Jessie Frazelle - 开源固件
开源固件可以通过使固件的行为更加可见并减少造成危害的可能性，帮助计算走向更安全的地方。本文的目标是使读者感到有能力要求可以帮助推动这一变革的供应商提供更多支持。
Marshall Kirk McKusick, George V. Neville-Neil - FreeBSD 5.2 中的线程调度
繁忙的系统每秒做出数千个调度决策，因此做出调度决策的速度对于系统的整体性能至关重要。本文——摘自即将出版的书籍“FreeBSD 操作系统设计与实现”——以开源 FreeBSD 系统为例，帮助我们理解线程调度。最初的 FreeBSD 调度器是在 20 世纪 80 年代为大型单处理器系统设计的。尽管它今天在那种环境中仍然运行良好，但新的 ULE 调度器是专门为优化多处理器和多线程环境而设计的。本文首先研究了最初的 FreeBSD 调度器，然后描述了新的 ULE 调度器。
© 保留所有权利。