创建开源策略的最佳实践

以前的 123. 第2页 下一个

• 确保所有请求的快速转动。如果批准过程需要数周，开发人员将跳过它，因为他们需要下载开源软件并完成工作。您的批准过程应最多需要一两周或两周。
• 确保所有评审委员会成员都致力于这一过程。你应该做好准备，当最初的成员转向其他兴趣或发现他们没有足够的时间时，替换他们。
• 有一个非常好的“预先批准的开放源代码列表”。您可以通过许可证、包名称和/或使用模型预先批准。
• 获得很多律师。虽然可能有审查委员会的律师，但如果您有涉及团队的律师将有帮助。他们最好能够了解如何使用开源软件，并且他们可以帮助野外问题。随着时间的推移教育这些律师。
• 创建一个异常流程，但要尽可能地将其设置为最小化异常使用的方式。
• 在您的组织内公开所有开源请求以及评审委员会的结果。如果人们可以看到哪些请求以及某些包被批准或拒绝的原因，他们就可以适当地调整自己的请求，从而为您节省大量时间。
• 为您的组织定义一些标准的业务原因。根据您的开源策略，这些策略可能会有所不同，从“通过使用现有技术节省时间”到“通过消除许可费用节省资金”，再到“通过让技术采用者了解产品是如何开发的来获得他们的支持”。

审计

虽然您的策略可能需要通过定义的过程审查并批准所有开源软件，但是无法通过蛮力开源软件执行，可以轻松且自由地从互联网上下载。为了确保您的批准过程有效，员工遵循它，您需要定义审计过程。

下面的流程图说明了一个典型的开源审计过程:

采购

您的策略应该明确说明允许员工获取开源软件（采购）以及如何确定特定开源包是否是作业的正确软件（选择）的网站和方法。谁可以下载软件？他们在哪里可以下载它？他们在下载前是否需要许可？在使用之前？在分发之前？

许多公司允许开发人员下载软件并在通过审批程序之前试用。律师通常对此感到不舒服，因为员工可以在审查许可之前使用该软件。然而，企业通常会在这种关注与风险相对较小的事实之间进行平衡，而开发人员只是在评估软件。

大多数公司最终采用了免费的开源下载和维护程序——每个需要开源软件包的团队都被允许下载它，并找出他们自己的支持选项。这是非常低效的，并且经常导致这样的情况:公司使用同一软件包的许多不同版本，并且每次发布新版本时都重复评估和升级过程。

其他公司采用了开放源代码存储库的想法，其中存储已批准的开放源代码包。需要使用开源软件的员工需要从资源库下载，而不是从Internet下载。虽然这是一个很好的想法，但这种方法经常会导致失败，因为不从事开放源码软件业务的单个公司很难创建和维护一个全面的开放源码存储库。存储库经常会过时，并丢失许多有用的开源软件包。如果采用这种方法，您将需要一个非常好的流程来处理向存储库添加新的开源包或版本的请求。或者，您可以使用第三方提供的开放源代码存储库，例如OpenLogic交易所(OLEX)从OpenLogic。

定义员工如何以及从哪里获得开源软件的政策可能是这样的:

或者，当涉及到采购时，你的政策可以允许员工做出判断:

请注意，虽然许多律师建议在许可证审查和批准之前不要下载软件，但这很少被遵循。在律师有机会审查之前，您的政策需要考虑到下载软件进行测试或试用的法律风险。添加这样的条款可以帮助降低风险:

选择

选择是决定一个特定的软件包是否满足您的需求和质量标准的过程。除了已经具备的任何测试和标准流程之外，您可能还需要考虑评审开源软件的其他方面，例如:

• 支持：有许多选项支持开源软件，但是可用的选项和应该选择的选项可能因包而异。
• 社区：包装是否有活动开源社区？虫子是否快速修复？
• 质量：软件包是否可靠？它是如何与类似的开源包进行比较？

有关其他因素的列表，需要考虑Open Source包选择，请参阅OpenLogic认证过程白皮书。

一个策略可能会用这样的语言来解决开源选择的问题:

您的策略还可以概述在开源项目“结束”或叉子的情况下该做什么。例如，策略可能定义一个时间框架，其中团队必须找到不同的开源包来替换原始包：

合并和收购

别忘了在你的政策中包含一节关于合并和收购的内容。在目标公司被收购之前，企业通常不会调查开源的使用情况或政策。事先检查一下更有意义。您需要确保公司的合并和收购团队了解内部开源政策，以及在完成任何收购之前调查目标公司的开源政策和使用的必要性。开源工具，比如FOSSology那OSS发现,oss深度发现可以运行以识别部署在目标组织中的开放源码软件。

一项政策可能会用这样的语言来处理并购问题:

支持

开源世界的技术支持令人难善的声誉。虽然许多人认为没有用于开源软件的支持，但实际问题是开源软件支持太多的选择 - 而且它们中的少数人像在专有世界中习惯了什么。

选择有多种，从自己动手(通过遵循邮件列表，甚至自己修复关键bug)到向第三方支付完整的支持和维护合同。下表显示了一些常见的选择:

开源策略可能会以这样的语言解决技术支持问题：

维护

一旦决定使用开源，下载它并让它工作的过程往往是富有挑战性和令人满意的。然而，跟踪项目进行安全更新、解决问题并确定何时升级到新版本可能会令人沮丧。

你的开源政策应该通过解决以下问题来为维护提供指导:

• 安全更新:谁将负责跟上安全更新的步伐?这通常需要订阅邮件列表。
• 新版本：当您应该升级到新版本时，谁将弄清楚？决定何时升级可能很难，因为开源软件项目经常发布新版本。虽然一些项目非常好地指定新的东西，改变了什么，而且已经消失了，其他人不是。有人必须评估每个释放并决定是否升级。此外，您需要一个过程，以确保仅在公司内部署一个或两个版本（或尽可能少）。特别是，您希望确保公司不会落后于开源项目的最新版本，因为社区很少支持长期以来的版本。
• bug:当发现bug时，如何将其报告给开源项目?您的策略还应该指定员工何时以及如何修复bug，并向开源项目提交bug修复。(您可能希望提供一些关于如何最好地创建和提供补丁的培训，因为确保上游接受补丁对您最有利。)

开源策略的维护部分应该指定公司员工是否可以修改开源软件。虽然您可能希望鼓励人们不要修改开源软件(除非他们正计划修复一个bug或添加一个新特性来为上游做出贡献)，但有些包可能需要修改才能在您的环境或过程中工作。您的策略应该指定何时允许这样做，以及如何记录更改以进行维护。

开源政策可能会解决使用如下语言进行持续维护的问题:

贡献

您的开源策略应包括明确声明，了解员工是否可以为开源软件项目贡献代码更改。有几种情况，您可能会希望员工贡献。例如，如果员工修复错误，您将希望他或她为项目贡献修补程序，以便您不必通过每个版本升级维护唯一的补丁。此外，通过贡献代码，您的公司可能会在开源社区中获得可信度。如果您的公司积极贡献项目，则社区将更有可能认识到员工并在出现问题时快速回复其电子邮件。

当考虑员工是否可以为开源软件项目贡献代码更改时，需要考虑的情况包括:

• 员工可以在邮件列表上发布问题和答案吗?虽然许多公司担心员工可能会在邮件列表上不小心泄露信息，但最好给他们进行保密方面的适当培训，然后让他们在邮件列表上工作。他们不仅会为自己和公司建立信誉，而且这通常是解决问题的最好方法之一。禁止员工在邮件列表上投稿将妨碍员工使用和支持开源软件解决方案。
• 员工可以发布错误报告错误跟踪系统吗？除非有很好的商业理由不，否则您应该允许员工发布错误报告，以确保它们可以及时修复，以便为本公司工作。
• 员工可以修复bug并提交补丁吗?员工经常需要修复一些简单的bug，以便让事情正常运行。当他们这样做的时候，确保以项目可以接受的通用方式修复漏洞，以便将其提交给上游，这对公司是最有利的。这将简化长期的支持，并有助于建立公司的信誉。
• 员工可以为开源项目贡献特性吗?他们能成为项目贡献者吗?
• 员工可以在空闲时间从事开源软件项目吗?和他们在办公室做的项目是一样的吗?在不相关的项目?你如何判断一个项目是否与公司业务无关?

开源政策可能会用这样的语言来解决开源贡献的问题:

一些开源政策规定，员工只能使用个人电子邮件地址，而不是公司电子邮件地址与开源社区进行交互。请注意，如果您将此规则包含在您的开源政策中，您的公司将永远无法在社区中建立任何信誉。

沟通

尽管许多公司试图隐瞒他们使用开源软件的事实，但这很少成为秘密——特别是对于那些决定使用内部资源提供自己支持的组织。最好是为员工应该如何与开源社区和其他感兴趣的团体沟通建立一个策略，即使您打算尽可能地限制关于开源使用的沟通。

你的开源政策应该通过解决以下问题来提供沟通指导:

• 员工如何与开源软件项目进行沟通?(有关此主题的更多信息，请参阅上面的维护部分。)
• 员工如何在会议上就开源的使用进行沟通?员工很可能希望参加开放源码软件会议，这为他们提供了与开放源码项目维护者见面的绝佳机会。如果员工可以谈论他们正在使用的开源包，甚至提供案例研究，这将帮助他们遇到正确的人，并为您的公司赢得信誉。开源软件社区喜欢听到他们的产品是如何被使用的。
• 员工如何在文档中就开源使用进行沟通?如果您交付的产品包含开放源码软件，您可能必须在产品文档中显示开放源码软件许可(取决于许可)。您可能还想告诉终端用户您正在使用什么以及为什么使用，这取决于终端用户的类型。例如，如果您销售使用开放源码软件的电视机，您可能需要显示一个或多个许可证，以遵守它们，但您可能不需要花很多时间讨论安装在电视机上的软件。另一方面，如果您为软件开发人员分发工具包，您可能希望在文档中留出更多的空间来讨论您正在使用的开源软件，以及为什么它是工具包的一部分。

总结

一定要在您的开源策略总结中保持积极的态度——毕竟，您希望您的员工这样做想跟随该策略同时也清楚地说明了开放源码软件的使用何时以及如何触发审查。例如，公司开源政策的总结部分可能是这样的: