Make Government Code Publicly Available

Much of the software the public pays for never sees daylight. The reasons are rarely explained in procurement documents, but the opacity has costs.

• Bugs linger longer. When the source is visible, independent auditors, academics, civic technologists, and rival vendors can reproduce builds, file issues, and submit fixes. Many eyes do not guarantee quality, but they shorten the time between defect and patch and reduce the chance that a single vendor’s blind spot becomes a system’s failure.
• Prices stay high. In a federal system, dozens of agencies commission near-identical tools—eligibility calculators, queueing systems, staffing schedulers, case-management portals. Publishing the code reduces barriers to entry for new bidders, shrinks bespoke effort, and lets jurisdictions adapt proven modules instead of paying to rebuild them.
• Spillovers remain uncaptured. Permissively licensed building blocks—say, queue management or optimal staffing libraries—become public infrastructure. Firms can redirect engineering time from reinventing plumbing to solving domain problems, raising productivity beyond government projects themselves.
• Trust is lower. When software translates law into outcomes—benefits, scores, eligibility—inspectable logic lets watchdogs and the public verify that the statute and the code align.

There are potential costs to publishing code: releases may ship secrets and regulated data; third-party licenses can constrain redistribution; and publishing can create a maintenance burden. These are implementation problems, not arguments for opacity.

Why, then, is so much code still closed? Several hypotheses fit the facts. Procurement is path-dependent: standard templates were written for deliverables, not for public releases, so “source under a permissive license” is absent unless someone fights to add it. Intellectual-property clauses are vague about who owns the derivative work; when counsel can’t tell, caution wins. Security teams are rewarded for avoiding rare catastrophes, not for enabling reuse, so the easiest posture is "no." Vendors have rational motives to keep implementations proprietary: opacity preserves negotiating leverage, blunts price comparisons across jurisdictions, and protects the option to resell similar work.

The remedy is to flip the default and make openness the norm, with narrow, well-justified exceptions. Contracts should specify “open by default”: code developed with public funds is delivered under a standard permissive license (e.g., MIT or Apache-2.0), along with build scripts, tests, minimal documentation, and a software bill of materials, and released only after secrets are scrubbed and reproducible builds are verified. Exceptions—for security, privacy, or export controls—must be explicit and scoped to specific modules. Ownership should be clearly defined upfront: pre-existing vendor IP remains the vendor’s and is clearly delineated; work-for-hire code belongs to the public domain. Where law allows, transparency statutes (such as FOIA or state public-records laws) can serve as a backstop to obtain source code or, if redactions are required under trade-secret or security exemptions, at least interface specifications, tests, and configuration schemas.

p.s. Firms like OpenGov that produce open-source software for the government are already helping bring some of the code online.