作为一名硬核开发者，我非常关心软件，并且在当地政府工作了八年，我经常思考这个问题。一方面，一个贯穿始终的哲学主题是，编程是新的读写能力，并且由于软件渗透到我们生活的方方面面，编程就像写作一样，相当于表达知识。
另一方面，编程仍然需要相当多的技术专业知识和工程技能，因此，与组织的核心竞争力一起培养这些技能既困难又成本高昂。对于较小的政府而言，成为一个具备软件能力的组织并非长远之计。更糟糕的是，软件被认为是负担，一种必要的罪恶，不仅是那些不擅长计算机的人员，而且 IT 部门本身也这么认为。为这种态度付出的代价远比人们想象的要高。
支持系统与重要系统
任何类型的组织都面临着内部软件与外包的两难境地，分析通常区分“基础设施软件”和“业务软件”，后者封装了业务知识。Philip Armour 在《ACM 通讯》上发表的一篇文章对权衡进行了高质量的深入分析。他没有像通常那样区分基础设施与业务，而是谈论支持系统与重要系统。支持系统协助业务，但不是业务本身的构成部分。重要系统是组织所做工作的可操作知识，这证明了组织存在的合理性。
Armour 认为，公司明智的做法是避免构建内部支持系统，但也要避免外包重要系统。后者是反传统的——我们应该外包以削减成本，而不管系统的性质如何，对吗？这就是软件作为成本的传统观点：一种您可以利用的资产，就像您租用实体空间来运营一样。这种观点的问题在于，软件已成为组织拥有的业务知识的最佳、最准确（有时也是唯一）的表达方式。这里的关键点在于对内部开发态度的彻底转变：内部开发不应作为最后的手段，而应成为首要考虑的选择。
政府外包的意外后果
外包软件意味着外包知识。这可能并不明显，因为提供服务的人力部分的人员仍然受雇于该机构，但这只是一种肤浅的保证。当政府 IT 采购部门没有真正的软件专家时，容易受骗的职业官僚会选择最迷人的供应商。太多影响重大的技术决策是由具有肤浅知识的管理者做出的。即使人们不采取政府雇员在宽松的财务约束下运作的愤世嫉俗的立场，又怎能期望他们准确评估一件软件的潜力或货币价值呢？
当一家大公司向一位真正的软件专业人士提出 20 万美元的估价，而这笔工作保守估计只需两周时间时，他们会受到质疑。当他们对一位因其奉献精神而晋升为决策者的光荣 Excel 文员这样做时，就不能指望他们做出批判性评估。由于所有技术专业知识和大部分业务知识基本上都推迟到了外包实体，因此他们充当了该主题的最终权威。这并不是要妖魔化私营的、以盈利为导向的企业。供应商的行为并没有内在的恶意。然而，这种公私关系中的动态是倾斜的。
政府作为其自身的开源社区
另一种选择是每个政府机构都承担编写自己的软件的成本和精力吗？显然，这也没有多大意义。正如经济安排随着时间的推移而受损时经常发生的那样，切断中间人可以解决问题——这里的中间人是管理重要软件系统的生产和成本的营利性企业。
在许多开源计划中，政府不是被动的消费者，而是贡献者。其中包括白宫的美国数字服务 18F 特遣部队，该特遣部队是为了应对 healthcare.gov 的惨败而成立的。对于属于支持类别的系统，这是一个很好的趋势。另一方面，由于政府“不从事软件业务”的错误观念，因此没有重大努力来解决遵循开源模型的“重要”系统。
机构聘请精通现代技术的合格程序员以开放的方式编写代码来驱动政府业务，共享专业知识和努力，如何？这才是真正的成本削减，也是最佳的长期战略投资——一个政府对政府的开源社区，拥有自己的一套政策和自己的项目治理模式。此外，拥有一支优秀的程序员团队是解放和赋能。错误修复和升级可以快速完成，并且由于知识保留在组织内部，因此可以确保项目连续性，这对于长期成本控制至关重要。
启动这种文化变革需要相当多的主动性和理想主义，但这值得考虑。在迈阿密-戴德县，我们多年前组织了一个小型会议（2010 年 ShareGov 研讨会），由当地机构组成。这个想法很简单：我们编写了一些内部代码，效果很好，让我们将其提供给其他人，并让我们在改进和维护方面进行协作，以便每个人都受益。诚然，从一段内部代码创建一个蓬勃发展的开源项目需要时间，但这很值得。当员工看到他们的工作为机构外部的人们服务时，这种努力也可以成为激励员工的好方法。
迈阿密-戴德努力的一个显著成果是最大和最成功的内部项目之一，即驱动 311 应答中心的 CRM 系统。该系统已上线并运行，并且在 GitHub 上等待关注。政府过去可能不擅长软件开发和创新，但开源正在改变这种局面。
4 条评论