Why The US Government Open Sources Its Code (opensource.com)
He's been the White House technology advisor since 2015, and this month Alvand Salehi delivered a keynote address at OSCON about the U.S. government's commitment to open source software. An anonymous reader quotes OpenSource.com:
The Federal Source Code Policy, released in August 2016, was the first U.S. government policy to support open source across the government... All new custom source code developed by or for the federal government must be available to all other federal agencies for sharing and reuse; and at least 20% of new government custom-developed code must be released to the public as open source. It also established Code.gov as a platform for access to government-developed open source code and a way for other developers to participate.
Before this policy was released, agencies were spending a lot of money to redevelop software already in use by other government agencies. This initiative is expected to save the government millions of dollars in wasteful and duplicative spending on software development. Because of this, Salehi said, open source is not a partisan issue, and "Code.gov is here to stay." Another benefit: Releasing open source code allows the government to benefit from the brainpower of developers across the country to improve their code.
Code.gov points potential contributors to their code repository on GitHub.
Before this policy was released, agencies were spending a lot of money to redevelop software already in use by other government agencies. This initiative is expected to save the government millions of dollars in wasteful and duplicative spending on software development. Because of this, Salehi said, open source is not a partisan issue, and "Code.gov is here to stay." Another benefit: Releasing open source code allows the government to benefit from the brainpower of developers across the country to improve their code.
Code.gov points potential contributors to their code repository on GitHub.
The US mil tried to save money and advance with Ada.
I worked for several years for DoD contractors in the late 1980s, and we did several projects with Ada before it faded away. The only way we got anything done was to first write the project in C which was way faster for development, get it working, get client sign-off on interface and functionality, and then rewrite it into Ada. The Ada version was always three times the size and half the speed. The number of bugs was about the same. Ada doesn't have the pointer and memory allocation bugs, but with proper coding standards, those aren't much problem in C either. Most bugs are in logic or misunderstood specs, not anything language specific.
When the client asked why they were paying extra for delay, bloat, and slowness, we explained that Ada was their requirement, not ours.