Bill requiring US agencies to share source code with each other becomes law
A new U.S. law requires federal agencies to share custom-developed software source code with one another and publish metadata about those projects, aiming to reduce duplication, increase transparency, and curb vendor lock‑in. Commenters welcome the move as a rare step toward “public money, public code,” but point out that the law stops short of mandating open source, includes broad exemptions for classified and national-security systems, and may be undermined by contractors’ incentives and bureaucratic resistance. Security implications, cultural hostility to open source in government IT, and the risk of added compliance overhead without meaningful reuse are recurring concerns.
Overall sentiment
- Many view the law as rare positive progress: reducing duplication, increasing transparency, and potentially improving quality and competition.
- Others are skeptical it will change much in practice, expecting bureaucratic avoidance, carveouts, or new layers of process with little real sharing.
Scope of the law & exemptions
- Law requires federal agencies to share “custom-developed” source code internally and to publish metadata (e.g., contract number, repository link) publicly.
- It does not require code to be open source for the public, only inter-agency sharing.
- Broad exemptions: classified code, national security systems, intelligence community elements, and code whose sharing would pose privacy risks.
- Several commenters expect agencies to expand classification or invoke privacy/national security to avoid sharing.
Public money, public code debate
- Strong contingent argues: anything built with taxpayer funds should default to public/open, with narrow exceptions (e.g., classified material, personal data).
- Opposing view worries about adversaries (e.g., “because China”) and about government giving away expensive code.
- Some point out current loopholes where contractors retain copyright, so government-funded code is not truly public.
Contractors, competition, and incentives
- Some predict contractors will lose their ability to resell the same code repeatedly, potentially saving money.
- Others worry vendors will copy competitors’ code, underbid without understanding context, and then push costly rewrites.
- A few see upside: more competition, peer review of code quality, and potential central stewardship (e.g., by standards bodies) of shared libraries.
Security implications
- Concerns: shared code could let a single exploit propagate across agencies or be a target for spies.
- Counterpoint: hiding code is just “security through obscurity”; broader review can improve security, similar to open source arguments.
- Some note agencies already rely on secrecy to mask poor code and have used “privacy” or “security” to deny technical transparency.
Cultural and implementation challenges
- Commenters with government experience emphasize: culture is resistant to reuse and open source, with status, turf, and job protection at play.
- Government IT is described as highly constrained, risk-averse, and procurement-driven; simply mandating sharing will require significant policy work, governance, and behavior change.