大多数使用开源软件的公司都知道他们需要一个开源策略。然而，当涉及到创建策略时，公司通常不知道从哪里开始，并且花费数月时间讨论策略细节和研究选项。本指南旨在帮助您编写开放源码软件策略。但也许更重要的是，它还将帮助您确定在策略创建过程中应该包括谁，以便您的公司在编写开放源码软件策略之后可能会同意并使用它。
为什么你需要一个开源软件的政策？
一开始，许多公司质疑开源软件政策的必要性，主要是因为他们认为开源软件政策很难创建。策略创建确实需要大量的工作和协作，但是通过遵循本文的指导，您应该能够在不到一个月的时间内创建并推出一个开源软件策略。
拥有开源软件政策的一些主要好处包括:
- 确保公司就如何使用开源软件达成一致。企业往往开始起草一个开源的政策，当有人在管理层意识到他们不知道他们的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环境中如何使用开源软件，但是您希望确保所有处理分发给其他人的应用程序的软件开发人员都了解开源软件策略。
无论你做什么决定，都要确保声明清楚，并有合适的人审核和批准该政策。下面的例子说明了一种方法来定义政策覆盖的人群:
什么是覆盖
关于什么是“开源软件”有很多误解和分歧。One common misconception is that免费软件，免费使用,仅适用于个人使用许可证是开源软件许可证。
公司通常决定了下一个许可证下发布的任何软件批准开放源码计划(OSI)被认为是开源软件。
您需要定义公司的开源软件策略所涵盖的内容和未涵盖的内容。许多公司对IT、开发和生产环境中使用的开源软件有不同的标准。
您还需要考虑什么是开源软件，以及需要讨论哪些使用案例。
- 该政策适用于使用公司内部的软件？
- 它是否适用于运输软件？
- 免费软件吗?人们通常认为任何不需要花钱的东西都是开源软件——这是不正确的，您需要明确地包括或排除这类软件。
一个开源策略可能会用这样的语言来解决什么才算是开源的问题:
所有权
您的开源软件策略将是一个活文档。随着业务条件的变化，您的公司使用开源软件会变得更加自如，新的开源软件包和许可也会变得可用，您需要根据新的情况调整策略。此外，个人或团队需要能够回答问题、提供培训并批准任何例外情况。
虽然个人通常编写开源软件策略，但是一个委员会或开源审查委员会应该拥有该策略。当审查委员会代表公司的主要部门时，它是最有效的。如果每个团队都觉得自己得到了充分的代表，你以后就会得到更好的认同和服从。
什么时候可以例外，谁可以例外
应该只允许少数人对开放源码软件策略做出例外:策略的所有者，以及允许决定业务利益大于违反策略的风险的业务组或管理人员。
审批流程
虽然在建立审批流程之前创建开源软件策略更容易，但实际上通常会发生相反的情况。某人负责做出开源决策，他或她最终召集一组人来创建一个非正式的审批流程。一旦建立起来，即使是非正式的审批流程也会变得非常复杂和高效。
如果你没有一个审批过程中，你要发送一个。如果你有一个，你需要充分考虑您的开源政策审查。
谁是开源审查过程的一部分?
你可能想要建立一个跨部门的开源审查委员会。这通常是拥有开源软件策略的同一个团队。它肯定应该包括一个律师或与一个密切合作。
您还希望审查委员会包括将使用已批准的开源软件的任何团队，因为他们同意策略和流程非常重要。他们可以给你反馈，以确保流程与他们的工作流程顺利地集成，从而快速地进行评审并顺利地解决问题。
应该审查哪些信息?
决定在审查过程中应该包括哪些信息。至少你会希望每个开源使用请求包括:
- 员工提交请求的名称。
- 请求的开放源码软件包的名称和版本号。
- 软件的来源(下载该软件的网站)。
- 与软件及任何捆绑组件相关的许可证的列表。
- 请求的业务原因。
- 安装软件的平台。
- 计划开源软件到其它软件目前正在使用或生产整合。
- 是否有修改源代码的计划(Y/N)。如果是，解释修改的原因。
- 是否有发布开源软件的计划，修改与否(Y/N)。如果是，解释分配的原因。
- 计划支持软件、监控安全更新和执行升级。
接下来，决定审查请求的流程。在请求升级到企业开源审查委员会之前，让本地管理人员和律师审查请求，您可能会节省大量不必要的审查。
开源审批流程的最佳实践包括: