Slashdot Mirror
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.
When the nsa had their code open sourced, everone got upset...
If an experiment works, something has gone wrong.
I did some stuff back in the early 90s with ADA. I didn't have any problems with performance since I took the time to optimize my code and ADA was really just doing a lot of checks I already would have done otherwise, as a control freak, I would regularly read the generated assembler to learn what checks were occurring and would add more if needed. ADA was nice in the sense that I didn't have to write all those checks myself but was bad because it meant there were occasions I would forget to check the generated code and then assume that the compiler was checking something it wasn't.
The main problems with ADA often were that the tool chains were absolutely shitty. There was also the issue that even with practice, there were times where you would find yourself wondering why your code wouldn't compile... and when you were working mostly from make files and vi as your development environment and you were logged into a shell account to do it... from a DOS terminal like telix or telemate, it was just hopeless. If there were modern tools like Visual Studio, Eclipse, etc... there would be no real problems.
That said, ADA was just another functional programming language and while it did have much prettier support for things like structures, most ADA code was just plain ugly. Again, this was because of tools. I've always programmed heavily in an object oriented style. So, where today I would make a class and the class would be the only thing within a file, back then, if I were programming C, I would make a structure in a header file and then write the code to operate on the structure in a C file. I almost never wrote functions which didn't require "the object" as the first parameter. ADA was not a good language for this style of coding. The few times I tried this method of programming, I would sometimes end up making object stores and passing object indices instead of structures to functions because the cost of passing a structure was insane.
So that being said, ADA wasn't usable for anything other than a few hundred lines of quick and dirty stuff. I couldn't imagine being forced to implement a full system in ADA. And I did learn the language well enough to use it. I could honestly see writing better code in COBOL than in ADA. The "safety" came at too much of a cost in functionality.
That leaves... Javascript used for different website apps. I would be surprised if anything much of anything else was published through this program.
Instead of spouting off your ignorant (and incorrect) opinion about what is on code.gov, why didn't you just take 30 seconds to go there and have look before posting?
I did go look through the repository to see if anything interesting caught by eye and he is not far off the mark. It appeared to be mostly web APIs and web apps.