DoD Study Urges OSS Adoption

Krishna Dagli writes to mention an Ars Technica article about the Open Technology Development road map, a report for the U.S. government advising the DoD on ways to integrate OSS into DoD policies. From the article: "The report argues that the standard practices associated with purchasing of physical goods are not adequate or fully applicable to software. According to the report, the DoD is 'limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities' by 'treating DoD-developed software code as a physical good.' The report also points out that utilizing open source technology will force the commercial software industry to respond with greater agility and competitiveness."

Comments

Well...

[fitten]

What if other projects adopt "no military" clauses like we've seen lately? This certainly has to be in the list of risks that the DoD will face.

Anyway, other than toolkits and general systems (a Linux based workstation to compile code on, use OpenOffice to write documents, and such) there's not going to be a lot of OSS that will be reusable for the developers since they will be writing software for missile guidance systems and interfacing to hardware not generally available to the public. Some GUI toolkits, maybe, and GCC, of course.

Plus, how will GPL's clauses about not having to release code for things you do on-site relate to the contractor/subcontractor relationships that are present in DoD projects and if parts are sold to other countries (like selling an F-16 to Israel, for example)?

I'm obviously not talking much about office productivity and listening to mp3s and stuff because I'm pretty sure that's not what the DoD is talking about here.

Re:Well...

[Chris Burke]

What if other projects adopt "no military" clauses like we've seen lately? This certainly has to be in the list of risks that the DoD will face.

I doubt it, as that's not a clause of the standard GPL, and a pretty stupid clause to boot. If people want to complain that their screwdriver was eventually used to attach two pieces of a bomb, they should be protesting the decisions that require bombs to be made and used, not refusing to allow their screwdriver to be used in military applications since it's simply untennable. If war is to be waged, war machines will be made, using your code or no. Eliminate the root cause, not innefectually stymie the effect just to have a slightly clearer conscience.

Frankly I think it's dumb. Look at what the NSA has done for open source; the DoD could theoretically provide similar benefits. The DoD will continue to exist. Having the OSS community benefit from DoD development would be a good way for us to directly benefit from their continued existence.

Anyway, other than toolkits and general systems (a Linux based workstation to compile code on, use OpenOffice to write documents, and such) there's not going to be a lot of OSS that will be reusable for the developers since they will be writing software for missile guidance systems and interfacing to hardware not generally available to the public. Some GUI toolkits, maybe, and GCC, of course.

The DoD does a lot more than write code for missles. They crunch masses of data on commercially available parts, and OSS will be very useful for them in that regard. Also, I doubt that the embedded systems for missles are really that exotic -- they may be using hardened versions of microcontrollers, but I doubt they'll be using some completely esoteric ISA that would be difficult to port an OSS real-time OS to.

Plus, how will GPL's clauses about not having to release code for things you do on-site relate to the contractor/subcontractor relationships that are present in DoD projects and if parts are sold to other countries (like selling an F-16 to Israel, for example)?

If they sell it to other countries or give it to contractors, then it's no longer on-site as you've distributed it. In which case, distributing the source would be appropriate. By the same logic that you chose OSS in the first place, your customers, e.g. Israel, would want to be able to view the source code for validation and maintenence purposes.

The DoD culture is very anti-OSS

[bingbong]

I worked as a defense contractor for the Office of the Secretary of Defense (OSD) at the Pentagon for a few years. I put together a proposal for a global kiosk system of 2000+ systems that would have had hardened linux distro (which one isn't the point) as the underlying OS for the kiosk. This system would have booted into the application (a Java app) and the users would never see the OS. It was particulary tricky as the kiosks were to be deployed at DoD facilities world-wide (OCONUS in govvie-speak), and needed to be managed from a few key sites in the US (CONUS).

The Gov't agreed that the solution was more secure, easier to manage and would save a few million $USD (in additional management, security and helpdesk costs) but they instead chose to go with Windows Server 2003 because of "look and feel." Remember, the users never saw the underlying OS!

To me this said that they weren't really open to any other options, their minds were already made up and that OSS is still largely untrusted by the neck-tie community. I still have the minutes from the meeting as a souvenir.

Costs of vendor lock in beginning to sink in!

[140Mandak262Jamuna]

Back in late 80s and early 90s, all the businesses were demanding Compatibility with IBM-PC. Remember the old joke about Cray supercomputer with the punch line "Is it IBM-PC compatible?". The older generation of IT managers knew compatibility and interoperability was important. But they did not fully understand the concept of vendor lock in. They confused IBM-PC compatibility with interoperability. Accepting a closed proprietary standard owned by a profit making corporation was a very bad idea. But those guys did not know it then.

Now slowly the next generation of IT managers with more experience are coming up. Now a days software costs lot more than hardware. Hardware prices have been dropping like a stone for decades and the software costs have stopped dropping after Microsoft consolidated its market lead and vendor lock in. In 1994 I paid 2700$ for a 90 MHz Pentium with 570 KB disk and 2X CD-ROM. MS Word was already above a 100$ then. In 1990 MS-Word was selling for 50$.

I keep returning to my favourite examples of light bulbs and car tires. Would anyone buy a car that can accept only Goodyear tires or build a home that can only accept GE bulbs? Car tire standards are set by SAE not GM or Toyota. It is just a matter of time before we have full interoperability to standards defined by a body like IEEE. Heck, if the Fortune 500 companies chip in a million bucks each to set up an "Institute for Sofware Ineroperability Standards" to work with IEEE and ACM to make experts define interoperability they will recoup the investments in no time.