1. 明确你的最终目标
“选择[自由和开放源码]的项目最重要的准则是选择符合你业务目标的项目“，一位州政府的律师，并长期从事系统架构师工作的 Marc Jones 说到，“你不会希望选择一个这样的项目 —— 需要你现在投入大量的精力来进行修改以满足你的需求。从这方面来说，它与购买专有软件非常相似。“
Acquia 公共部门首席数字战略家兼副总裁 Tom Cochran
对此深表同意。“有些政府部门会目光短浅地说，‘对于所有项目，我们都采取开源的’”，Cochran
在美国国务院和白宫工作时曾这样说过，“应该将开源视为可选解决方案的一部分....不过这需要在就事论事的基础上完成。”
然而，CivicActions CEO Henry Poole 则认为，对于政府来说，开源可以且应该是其最终目标。“公共基金正在用于支付公共事业”，他说到，“在我看来，将代码公开可访问，只从纳税人的角度来看的话是正确的。你们希望将采购策略转移到支付新技术上，而不是支付一些已存在的技术。”
“在白宫，实际上已树立了一面旗帜，表明‘项目必须是开源的’”，Cochran 说到，“其中一些是对那些糟糕的闭源代码的回应，我们不希望被采购到另外一些糟糕的项目。”
“避免被开发方捆绑是值得认真考虑开源的好理由”，他补充说到，“有大量的中小型公司可以做到这一点。如果你不满意所获得的服务或支持，也不需要重新更换平台。”
不过，接受本文采访的人都同意：每个开源解决方案都应该被视为一个潜在的工具，但政府部门任务必须推动决定哪种工具可供选择。
2. 知道看起来健康的开源项目是怎样的
“首先要确定的问题就是‘你实际所使用的自由和开源的项目它的所有功能也都是自由和开源的’”，在 CivicActions 工作的 Jone 这样说道，“特别是在利基市场，公司会提供所谓的‘开放核心’，其基本特征是 FOSS（自由及开源软件），不过它在市场上却将有价值的东西独立出来并使其专有。”
“更糟糕的是，有些声称是开源的项目却带有限制性的专有许可证”，他说到，“这意味着你只可以查看源代码。”
ProudCity 首席执行官 Luke Fretwell 说，一旦确定了潜在的开源解决方案，他的公司会提供一个简短的清单来衡量其可行性。
“首先，社区有是真正领导者的项目维护人员吗？”，他说到，“例如，Brian Behlendorf 和 Matt Mullenweg，分别与 Apache Web 服务器和 WordPress 有高度协作的一面。这是一个有效的试金石，因为他们把自己的职业生涯投入到了这些项目中。”
“第二，是否存在某个可持续的业务，其主要业务模型基于这个产品？这是另一个判断点。”Fetwell 说。
第三点与使用有关。“使用方”很重要 —— 拥有广泛的应用群体就意味着存在持续发展的需求 —— 不过他更看重的是是否有大量的贡献者，包括个人和来自企业的开发人员。
Fretwell 还说到他会检查开源项目是否具备行业中任何形式的标准，是否有年度活动或吸引人的本地社区？这些是否都还活跃？
Poole 回应了这些观点并强调需要“分析代码所在环境的生态系统”。
对于在前总统奥巴马管理下的白宫在 Web 方面的努力，Cochran 表示，选择 Drupal 很大程度是是因为该项目的社区。社区的支持力度越大，就越能提升和增强你自己的工程团队。
3. 明智地选择您的供应方
“第一件也是最重要的一件事情是让员工知道他们在做什么以及在谈论什么”，Cochran 说到，“让一部分人认识到‘自己不知道的’更为重要。”
“老实说，事情仅仅在于人际关系以及找到能指引你进入合适的社区群体的朋友”，他补充到。
Fretwell 说过，供应方的资质归结为两点：代码能力的高低，以及对社区投入精力的多少。
他补充说，任何认真对待其开源贡献的组织，都会有一个活跃的 GitHub 仓库，因为这可以用于检查工作。如果一家公司的员工正在维护一个开源项目的组件、在会议中发言并与其他贡献者进行交流，这将能为政府部门交付专业的知识和沟通。
“开源没有门槛”，Fretwell 说，“它靠的全是热情和努力，所以如果你正在评估一家公司，这就是试金石：这些公司的领导和员工与他们的开源社区合作关系如何？”
Jones 重申了对积极贡献者的重视，而且他建议寻找那些将定制这股潮流引导回到开源项目的供应方 —— 无论是在主要的代码库中，还是通过插件或 FOSS 分支。这些公司会为实现你的具体需求而编写新的代码，而不是一味地试图通过销售已有的代码进行获利。
4. 拥抱协作
政府机构当然可以既是生产者也是消费者。在联邦政府，行政管理和预算局(OMB)去年启动了一个试点计划，要求各政府部门至少发布 20% 的定制开发软件代码以作为开源软件，一些政府部门有数百名开发者参与其中。然而，成功的共享毕竟还是需要政策和基础设施的支持。
例如，NASA 已经开发了一套系统来为已创建的代码编制目录，并鼓励各政府部门之间的诸多组件可进行协作（参见“NASA 的共享代码系统”，第 xx 页）。美国国防部（DoD，Department of Defense）长期以来一直依赖于 Forge.mil，而在 3 月份，国防部国防数字服务公布了一项名为 Code.mil 的计划，旨在解决许可证导致 DoD 开发变得复杂的问题。
“这样，即使没有内部开发人员的政府部门也可以为开源项目作出贡献，并且从中获益”，Jones 说道。
“最简单的办法是聘请承包商修改你正在使用的[自由和开源软件]，并通过合同要求他们将修改的内容作为 FOSS 发布，并尝试将其提交到上游”，他说。
“将这些改动纳入核心代码库将帮助您避免被占据的风险，也可以免费获得第三方的工作质量评估”，Jones 说，“如果承包商的改动被上游采纳，那么你会知道至少一位该项目的专家喜欢他们做了什么。”
具有内部开发人才的政府部门应该鼓励他们积极参与开源，Poole 说，不仅仅是因为这提高了代码的质量，而且还可以帮助员工发展和留住人才。
“如果你有一款自由和开源的软件，并且可以为其贡献，我认为没有理由不这样做”，他说，“认识到这里面存在学习曲线很重要。你可以对难以维护和不了解的地方做出改变。对于特定的技术社区，都有其自己的编码标准和做法，对于这些内容，可能需要反复学习。”
尽管如此，政府部门还是应该这么做，Jones 说，必须以我们对待专业开发和分享其他领域最佳做法的相同方式来对待自由软件。
“例如，当你的工作是找出农村发展机遇的时候，你不知道如何做，然后把这个消息对其他正在做农村发展调研的政府部门保密”，他说，“不过，当你的同事询问你有关清单和最佳做法时，你会分享给他们。在 IT 界也是如此。”
5. 时刻准备打破神话
Greg Elin 是 GovReady 的首席执行官，GovReady 是一家正在努力使网络安全兼容性变得更好的创业公司。然而，作为联邦通信委员会的首席数据官，他是一个希望使用开源工具的政府人员，他发现自己处于艰难的战斗之中。
“我于 2010 年进入政府机构”，他说，“在最初的的几年里，对于这个观点有许多抵制的声音。”
“大部分抵制的声音是围绕着安全方面的”，他说，“其实维护通过开源构建的项目的安全兼容性并不比使用专有软件组件更难。但是在使用商业软件时，使用者觉得会有人明确的对他负责。但在接触开源后，他们不确定到底谁该负责。
事实上，Elin 表示，专利软件许可证上明确表示，供应方“不负责任，并且不用对他们的软件出现问题负任何责任”。他强调，该机构有责任确保有人正在监控安全公告，并制定必要的更新。
“这真的不是专有 vs 开源，”他说，“这是关于组织是否会在如何管理风险方面做出领导决策，沟通这些决定，并拥有足够的资源来追求这些目标。”
“同样地，采购人员也会使工作复杂化，因为不了解开源的人很难认真地考虑如何采购一些不用付出任何代价的东西”，Cochran 说。
Jones 对此表示同意，“这太常见了，尤其是政府部门的……他们把采购和购买混淆。”，他说，“采购的过程在你决定掏钱并说‘嘿，这怎么会是我们想要的？除此之外就没有别的什么我们可以开发的吗？’之前就已经开始。”在这种情况下，我们应该跳出来想，在服务软件定制方面应如何努力。要么干脆什么也不做，因为我们需要的已经实现了。
更广泛地讲，Jones 说，关于开源最大的谣言之一是“它是个只会消耗你的付出的纯慈善活动。”
“人们提到的大多数付出其实是他们已经在承受的”，他说，“即使政府部门的领导们并不承认。”“IT平民们正把自由软件带到你的商店。你的 IT 员工已开始编写软件 —— 尽管他们并不是真正的开发人员 —— 但开源软件不仅对他们有用，对其他人也有用。”
此外，Jones 说，“如果他们打算将其分享出去并希望得到其他 IT 同行的反馈，这会使他们在自己的工作上干得更好。”
