powdermonkey

Joint Light Tactical Vehicle award this week: it won't be open I bet

I saw this story:
BMW seeking partners for open-source car software platform and then insidedefense.com had the story: "The Defense Department this week will announce technology development contract awards in the Joint Light Tactical Vehicle [JLTV] competition, according to the Pentagon acquisition chief.

And then talking with Jim Stogdill and reading his excellent post, I was left feeling its too bad that for all the millions that will go into JLTV, its too bad DoD didn't levy some requirement for the operating system to be more open, as in made open source. (Note I am less worried about vehicles, more so about software intesive systems that go inside them)

DoD is now going pretty explicitly to a winner take all model of acquisitons (2 pilot projects and then they pick a winner that goes into full production). Now this makes sense for big iron, physical goods (need to build factories, etc.), but for software its the the wrong, very wrong model.

When DoD picks a winner for a system that is heavily software reliant the Government is placing a bet that the Contractor Team will stay at the leading edge of technology. This never happens, Contractor Teams that win slowly build a Fortress to keep ideas out, while locking the Government into their platform. Then you end where we are now, with weird data standards, legacy systems, etc. Further, 1 team will win, but the loosing Team will have some better ideas or capabilities that the warfighter would love to have on their platform, but won't get because it would mean the Winner would ultimatley get less of the pie.

So, the industrial base shrinks, a division at a company goes out business, etc. OR as an alternative the loosing team could make open source their platform: kind of a 'loose the battle, but win the war" strategy.

Practical guidence for the Gov would be: 1. open the platform up (put an RFP out to make/deliver/build an open source platform or make OSS an existing one). 2. build a community around a capability. 3. let small contracts out for incremental improvements in platforms. 4. simplify the intellectual property rights lanscape for contracting with the government so that a developer can understand them

OSS COnf: 4th DoD Open Technology Conference in DC, Oct. 29

conference to attend:

OPEN ARCHITECTURE OPEN SOURCE SOFTWARE OPEN STANDARDS

The 4th DoD Open Technology Conference expands the dialogue between government and industry on the business case, security and real-world military applications for open technology methods and paradigms.  This conference will address many of these critical issues from the perspective of both warfighter benefits and challenges for DoD implementation.  Topics include: Emerging open source software policy in DoD How open technologies will support DoD 2.0 Impacts to business models as primes and agencies move to open technologies Improving DoD access to innovation Federated - collaborative development environments and their impact of DoD software development processes Impacts on acquisition processes Intellectual property issues in open environments Attendees will hear from government leaders and industry experts on the use of open source software, open standards and open architectures across the military services, and potential for impact on defense industry business models.

GOSCON08: NASA-Cracking the Code on Government Procurement Requirements; Open Source BI Fuels Jet Propulsion

notes from GOSCON 2008 session:
Cracking the Code on Government Procurement Requirements; Open Source BI Fuels Jet Propulsion

using JasperSoft for business intelligence on the ground stations, as well as an enourmous amount of open source throughout the enterprise. OSS is on the mars landers as well

Pentagon: Open source good to go

Not good to go yet, but soon hopefully...
Pentagon: Open source good to go

Military IT folks wondering if their use of Apache, Perl, Linux and other open source software is copacetic with the brass will soon get some answers from the Defense Department's Office of the Chief Information Officer.

The office is preparing a memorandum that further clarifies how open source may be procured and used within the services.

The memo should answer many lingering questions still surrounding the open source, said Daniel Risacher, the data strategy leader for the Office of Secretary of Defense who is drafting the memo. The draft may point out some potential benefits as well.

"Those factors that are in favor of open source have not been appreciated to date," said Risacher, speaking at the Red Hat Government Users and Developers conference, being held today. The DOD CIO office is aiming to release the memo by early November.

From Risacher's description of the draft, the memo may reinforce the acceptability of using open source software within the Defense Department, as well as for other federal agencies. It may even broaden procedures for procuring commercial software.

"Those mandates [in which] we have to consider commercial off-the-shelf software, we have to apply that to open source software as well," Risacher said. "And that is not well appreciated within government."

Risacher said that he first started working on the memo last summer at the behest of the Defense Deputy CIO, David Wennergren. Although widely used in federal government, open source software, due to its unusual form of distribution, has raised questions among regulation-minded program managers.

Forward leaner of the week: NSA & Open Source Software

its interesting that the most secretive government agency is more concerned with software quality than keeping everything complete locked down. via slashdot...

NSA shows the way to develop secure systems

Posted on 06 October 2008.

The development of highly secure, low defect software will be dramatically helped by the release of the Tokeneer research project to the open source community by the US National Security Agency (NSA).

The Tokeneer project was commissioned by the NSA from Praxis High Integrity Systems as a demonstrator of high-assurance software engineering. Developed using Praxis’ Correctness by Construction (CbyC) methodology it uses the SPARK Ada language and AdaCore’s GNAT Pro environment. The project has demonstrated how to meet or exceed Evaluation Assurance Level (EAL) 5 in the Common Criteria thus demonstrating a path towards the highest levels of security assurance.