使用开源软件大多数企业知道他们需要一个开源的政策方针。然而，当涉及到创建策略的公司往往不知道从哪里开始，并花费数月辩论政策的细节和研究各种选项。本指南旨在帮助你写一个开放源码软件的政策。但或许更重要的是，它也将帮助你找出谁在策略创建过程包括让你的公司很可能议定并使用开放源码软件的政策一旦它被写入。
为什么你需要一个开源软件的政策？
一开始，许多公司质疑开源软件政策的必要性，主要是因为他们认为开源软件政策太难创建了。策略创建确实需要大量的工作和合作，但是通过遵循本指南，您应该能够在不到一个月的时间内创建并推出开源软件策略。
使用开源软件策略的一些主要好处包括:
- 确保公司在如何使用开源软件上达成一致。企业往往开始起草一个开源的政策，当有人在管理层意识到他们不知道他们的IT部门或软件产品是多么依赖开源软件。明码实价，明确的政策可以帮助确保公司每个人都在船上与你的开源战略和员工感受到像他们有权在适当情况下使用开源软件。
- 最大化开源软件的好处。通过创建策略，您将把使员工能够有效地使用开源软件以及在团队之间共享知识和工作负载的过程放置到位。例如，三个不同的团队不会独立地找出如何为同一个项目获得支持，不同的员工也不会独立地评估同一个升级。采用开放源码软件策略并在整个企业中共享信息，将使您的公司能够最大限度地利用它所使用的开放源码软件。
- 最小化使用开源软件的法律、技术和业务风险。行政管理和律师往往很关心被诉使用开源软件，被抓到没有足够的技术支持，或接受有关如何开源软件使用的负面宣传。一个开放源码软件的政策，不仅可以最大限度地减少这些风险，但也表明有关雇员的公司是如何应对这些需求。
编写开放源码策略的过程
编写一个开放源码软件政策的关键是刚刚开始！公司通常是写，批准，并在一个月内采取开放源码软件的政策，否则他们花几个月的政策工作，但未能获得对成品全公司的批准。通过以下步骤可以确保你的公司已经批准的，并在几周内采取的政策：
- 识别关键的利益相关者
- 让涉众接受策略的概念
- 找出你的公司战略
- 创建策略的第一稿
- 获得广泛的审查和验收，开始你的利益相关者
- 如有必要，重复最后两个步骤
利益相关者
第一步，重要的要确保您的策略是一个采用，是确定你的政策的利益相关者。有几种类型，从那些谁照顾拼命，因为你可能会改变他们做他们的工作（如开发商）对那些谁照顾拼命的能力，因为他们认为一个糟糕的政策可能会向他们射击（如CIO和那些谁向他们汇报。）一定要包括你认为谁将会不同意你的人的政策，更好地解决他们的分歧比前期有他们对抗政策，因为他们不喜欢它的一个组成部分。
当你将不得不使用什么策略最在您的组织，让所有参与尽快利益相关方会帮助你得到的政策更广泛迅速采用。越多，你的利益相关者觉得这是他们的政策，效果更佳。最理想的情况是，如果他们可以说他们审视，而感觉舒适与您（或不管是谁写策略）采取的细节。
当你整理你的利益相关者列表时，你应该考虑:
- 开发商——将不得不遵循政策的人
- IT人员，因为他们可能下载和使用开源软件
- 球队经理使用开源软件
- 律师
- CIO和员工
- 技术架构师;许多公司都有建筑委员会，他们应该参与其中
你可能有两个组的利益相关者：谁需要批准该策略的关键利益相关者，谁还会受到政策影响的人。
战略
开放源码软件策略旨在帮助您的公司的战略——包括它的一般战略和它的开放源码战略。
例如，您可能将开源软件视为降低IT成本的一种方式。在这种情况下，您的策略不应该是“尽可能多地使用开源软件”，而是“通过使用开源软件来降低IT成本”。This will enable all of your employees to make the right decision when it comes to choosing between open source and proprietary solutions. The policy will then help your company reduce IT costs—not just by encouraging the use of open source software that has no licensing fees associated with it, but by also leveraging the preexisting open source knowledge of your IT staff.
在另一方面，你可能想建立自己公司的产品围绕一个在线社区。在这种情况下，您的策略可能是为了鼓励外部开发者，帮助建立了功能，使您的社区增长到使用开源软件。你的兴趣是在社区，而不是通过销售软件赚钱，所以你甚至可能要开源自己的软件，并长出了它的社区。
确定你的开源战略的前期不仅会帮助你找出自己的政策，但它也将帮助你给别人解释为什么它是你的公司正确的政策。
下面是一个开源战略声明的例子:
背景陈述
许多开源软件策略从讨论他们试图解决的问题开始。你是否需要这个部分可能取决于你的公司。以下情况可能需要使用此部分:
- 管理不知道有多少开源软件公司使用或依赖。
- 对于使用多少开源软件，存在着广泛的不同意见。
- 这里有一个开源软件规则或政策与现实发生冲突（例如，“允许不开源的，”但你的IT基础设施时开源软件构建的）。
- 有对公司应该如何使用开源软件的大分歧。
如果你决定你需要一个背景介绍，尽量简短。一些关键的东西在后台声明包括（如果您知道）有：
- 公司目前使用多少开源软件。
- 多少开源软件已经或将要拯救你，不只是节省资金，还要考虑开发时间减少，咨询时间，学习曲线，等等。
- 需要注意的风险——例如，您的24x7网站依赖于一个目前没有定义支持流程的开源软件包。
开源策略中的背景声明可能像这样:
范围
您的公司可能有很多的政策，这可能是他们盖谁明显。然而，随着开源软件的政策，通常需要界定，不仅给谁保险，但保险内容。
谁在覆盖
大多数采用开放源码软件策略的公司在公司范围内采用该策略。然而，对于许多组织来说，有一个非常简短的公司策略更有意义，它只是简单地陈述了策略并提供了一些关于如何使用开放源码软件的一般指导方针。然后，允许每个部门详细阐述和扩展政策，以满足其需要。在其他情况下，一个特定的部门制定一项政策，然后试图让整个公司采用它。
不要忘记在这个定义中指定子公司和代理。您可能需要咨询律师，将开源软件提供给公司的代理或子公司是否被认为是分发，因为分发会触发某些开源软件许可证中的条款。
另外，您可能希望指定开放源码软件策略是否适用于每个人，还是仅适用于从事某些工作或角色的员工。例如，您可能并不关心您的IT人员如何在内部IT环境中使用开放源码软件，但是您希望确保所有使用分发给其他人的应用程序的软件开发人员都知道开放源码软件策略。
无论您做什么决定，都要确保声明清楚，并确保有合适的人员审查和批准该策略。下面的示例说明了一种定义策略所涵盖的人员的方法:
什么是覆盖
有很多的误解和分歧约究竟有资格作为“开源软件”。一个常见的误解是，免费软件，免费使用,仅适用于个人使用许可证的开源软件许可证。
公司通常决定了下一个许可证下发布的任何软件批准开放源码计划(OSI)被认为是开源软件。
您需要定义您的公司的开放源码软件政策所涵盖的内容和未涵盖的内容。许多公司对IT、开发和生产环境中使用的开放源码软件有不同的标准。
您还需要考虑什么是开源软件，以及需要涵盖哪些使用案例。
- 该政策适用于使用公司内部的软件？
- 它是否适用于运输软件？
- 免费软件吗?人们经常假设任何不花钱的东西都是开源软件——这不是真的，您需要明确地包括或排除这种类型的软件。
一个开源策略可以解决这样的问题:什么样的语言才是开源的:
所有权
您的开源软件策略将成为一个活文档。随着业务条件的变化，您的公司更加适应使用开放源码软件，并且新的开放源码软件包和许可证已经可用，您将希望调整策略以适应新的情况。此外，个人或团队需要回答问题、提供培训和批准任何异常。
尽管开源软件政策通常是由个人撰写的，但应该由一个委员会或开源评审委员会拥有该政策。审查委员会在代表公司主要部门时最有效。如果每个团队都觉得自己得到了充分的代表，你就会在以后得到更好的支持和服从。
什么时候可以例外，谁可以例外
只有少数人可以对开放源码软件策略做出例外:策略的所有者，以及允许决定业务收益大于破坏策略的风险的业务组或经理。
审批流程
虽然在建立审批流程之前创建开放源码软件策略更容易，但实际上通常会发生相反的情况。有人负责做出开源决策，他或她最终将一组人聚在一起创建一个非正式的审批流程。一旦建立，即使是非正式的批准程序也可以变得相当复杂和有效。
如果你没有一个审批过程中，你要发送一个。如果你有一个，你需要充分考虑您的开源政策审查。
谁是开源评审过程的一部分?
你可能想要建立一个跨部门的开源审查委员会。这通常是拥有开源软件策略的同一团队。它绝对应该包括一名律师或与之密切合作。
您还希望审查委员会包括任何使用经过批准的开源软件的团队，因为他们同意政策和过程是很重要的。他们可以向您提供反馈，以确保流程顺利地与他们的工作流程集成，以便快速进行检查，并顺利地解决问题。
哪些信息应该被审查?
决定评审过程中应该包含哪些信息。至少你会希望每个开源使用请求包括:
- 员工提交请求的名称。
- 所请求的开放源码软件包的名称和版本号。
- 软件的来源(下载它的网站)。
- 与软件及任何捆绑组件相关的许可证的列表。
- 请求的业务原因。
- 将在其上安装软件的平台。
- 计划开源软件到其它软件目前正在使用或生产整合。
- 是否有计划修改源代码(Y/N)。如果是，说明修改原因。
- 是否有计划发布开源软件，修改与否(Y/N)。如果是，说明发行的原因。
- 计划支持软件、监控安全更新和执行升级。
接下来，决定审查请求的流程。在请求升级到公司开源审查委员会之前，让当地管理层和律师对请求进行审查，可能会节省大量不必要的审查。
开放源码审批流程的最佳实践包括: