Defense Department Releases Open Source Memo

by Jim Stogdill | @jstogdill | comments: 11

I've been holding my breath for so long waiting for this memo that I may not remember how to start breathing again, but here it is. The Department of Defense Deputy CIO Dave Wennergren has signed and released "Clarifying Guidance on Open Source Software."

2009OSS

Written primarily by my friend Dan Risacher at the Office of Secretary of Defense the memo is intended to clear up common misconceptions and make it easier for DoD program managers to include OSS in their programs. Its goals are to improve agility, eliminate lock in, and reduce cost.

One of the memo's key points comes from Dave Wheeler at IDA - OSS is considered "Commercial Off the Shelf" software as far as DoD acquisition rules are concerned and therefore OSS must be considered on an equal footing by law whenever a program is doing market research prior to technology selection.

Some will argue that it doesn't go far enough by only encouraging and not demanding the use of OSS on government programs (I certainly have some sympathy for that point of view) but my hope is that this will at least provide some counter to the FUD machine - you know who you are - and keep moving OSS in defense toward a tipping point of acceptance.

By the way, if you are interested in open source in government and are in or near DC, make sure you check out GOSCON next Thursday, Nov 5. Dave Wennergren will be giving the breakfast keynote and you can ask him all about this memo.

Three Quick Open Source in Defense Links (and then one other)

by Jim Stogdill | @jstogdill | comments: 0

Next week I'll be participating in the inaugural Military Open Source Software Working Group Conference in Atlanta Georgia. Open source conferences that focus on the defense market are often salesy, have a dearth of actual developers, and tend toward sartorial blandness - a sea of dark blue suits worn by open source vendor sales people so they can convince hesitant buyers that their wares are just like the other guys. Look, we even license it by the seat!

This grass roots event, which will be held at the Georgia Tech Research Institute Conference Center, is designed to answer the question raised by those other conferences; "where the geeks at?" It will even have a dress code to match, no suits allowed. There is still space available, so if you are having the kind of ridiculously cool summer that makes August in Atlanta sound appealing, pack your shorts and sandals and head down.

If you aren't familiar with the defense software space, it buys and builds an immense amount of software. Quite a lot of it is actually pretty cool too because it is designed to solve interesting problems. We're still waiting for the defense market to have its IBM/Apache moment, but when this market inevitably tips hard into open source the impact is going to be tremendous. Open source methods and licensing will be a conduit for technology transfer from the DoD into commercial use on a vast scale. However, what I think is really cool, is the opportunity it will offer for important participation in the other direction.

A couple of projects at the vanguard of this trend that just opened up are FalconView and Open CPI.

FalconView started life as a moving map for USAF mission planning and was already a great example of user innovation in the military. Recently the team at Georgia Tech took the next logical step and open sourced the bulk of the project.

My colleague John Scott (@johnmscott) and his team at Mercury Computer Systems just opened up the distinctly different Open CPI project. Sort of a middleware for FPGA's, it grew out of the signals processing field and, if it picks up community support, should make it simpler to develop and build hybridized hardware platforms for special purpose applications. I've written before at Radar about the trend in some areas away from pure commodity hardware in areas where performance and energy consumption are a priority. I think projects like Open CPI will contribute to this trend by making the development of specialized platforms more approachable.

This last link isn't related to open source software except for the fact that Gunnar Hellekson @ghelleks of Redhat pointed me to it. We were chatting over lunch about the epidemiology of virus and vulnerability propagation and the fact the removal term is too low to keep populations small. All too often, once a system on the network (whether in the enterprise or at the home) is infected, it stays infected until it is removed from the network and (hopefully responsibly recycled) sometime after it has been fully depreciated.

Furthermore, in a large enterprise with as many as millions of machines to deal with, it is simply impossible to manage the process of consistently hardening machines to prevent infection in the first place. If Population = (rate of infection - rate of removal)*t you can see that these two issues conspire to help the bot herders and other nefarious characters keep populations large.

To deal with the second problem (and perhaps someday enable a solution to the first) NIST has been developing the Security Content Automation Protocol (SCAP). Basically it is an extensible XML schema for defining the hundreds of security configuration parameters and their values that need to be managed. Once defined and rolled into profiles, agents running on various platforms can implement the profiles automagically. In DoD parlance, this means that Security Technical Implementation Guides (STIGs) can be implemented broadly, efficiently, and, perhaps most importantly, in an ongoing manner.

The Army, the Web, and the Case for Intentional Emergence

by Jim Stogdill | @jstogdill | comments: 19

Lt. Gen. Sorenson, Army CIO, at Web 2.0 Summit

I didn't make it to the Web 2.0 Summit in San Francisco in November last year so I didn't get to see Army CIO Gen Sorenson present this Higher Order Bit talk in person. However, I thought it was cool that the Army made the agenda and luckily someone posted the video. I finally got a chance to go through it. If you didn't see the talk, or don't have the 20'ish minutes to watch it now, here's a rough summary:

- Because of security and related concerns, it takes a very long time for the Army to take advantage of new generations of technology. We tend to deploy it widely about the time it's becoming obsolete.

- However, we are now beginning to take some advantage of Web 2.0 technologies in, for example, Stryker Brigade collaboration, battle command information sharing, and command and control.

I don't think that slow technology adoption is caused by fundamental first principles, so I don't think it has to remain true. But that's a long discussion for another time. In this post I'd like to focus on Army Battle Command, Web 2.0 and Gen Sorenson's connecting the two. Specifically I'd like to talk about lost opportunity and how the same technologies can constitute a generative platform in one setting and window dressing on a temple to determinism in another.

The lost opportunity I'm thinking of isn't whether Army Battle Command is Web 2.0 enough or not. It's that enterprises tend to see web technologies as an add on to whatever they already have. Plus, they tend to focus on specific technologies rather than the combination of technology, process and policy that make a collection of technologies viable as a generative platform. "Let's add some Web 2.0 to this system; we'll use REST instead of SOAP." But the fundamental question that the web answers isn't whether REST is better than SOAP, but whether emergence is more likely to create innovation than enterprise planning, and the answer to that question is yes.

General Sorenson says in the video that "CPOF brings in Web 2.0 capability, chat, video, etc..." and then comments on "graphics, chat, use of tools..." and stuff like that to reinforce the idea that Command Post of the Future (CPOF) and the Battle Command suite it is part of has Web 2.0 attributes. Like many enterprise technologists, General Sorenson appears to be focusing on rich user experience and collaboration as the attributes that give CPOF a Web 2.0 imprimatur. While that's not unexpected, I think it leaves most of the benefits on the table and untapped.

Putting aside for the moment that CPOF isn't primarily delivered through a browser, a first step toward webness, the reality is that CPOF and other systems like it neither leverage accessible platforms nor contribute to them. It is a standalone (though distributed) computing system with gee whiz collaboration and VoIP. And while it offers some enterprise-style data services, it has none of the features of a generative platform. If I'm in the field I can't readily extend it or build on it to solve different problems, modify its proprietary underpinnings to suit my local needs, or quickly incorporate its information into other applications. If an important aspect of Web 2.0 is enabling the long tail, then this isn't Web 2.0.

I should say, this isn't a post about web 2.0 semantics. However, it's important to understand that the web's power derives from its evolution as a platform. Otherwise it's hard to see what is being missed by the military's IT enterprise (and many other large enterprises).

From the beginning the web has been generative. It wasn't CompuServe. With some basic skills you could add to it, change it, extend it, etc. Jonathan Zittrain, in his excellent book The Future of the Internet - and How to Stop It, reflects on why the Internet has experienced such explosive innovation. He argues that it's the powerful combination of user-programmable personal computers, ubiquitous networking with the IP protocol, and open platforms. Today, the emergence of open source infrastructure, ubiquitous and cheap hosting for LAMP-based sites, open API's, and the intentional harnessing of crowd wisdom has ushered in the web 2.0 era. It's an era of high-velocity low-cost idea trying that leverages the web itself as the platform for building world changing ideas and businesses.

The Internet hosts innovation like it does because it is an unconstrained complex system where complex patterns can grow out of easy to assemble simple things. Simple things are not only permitted, but they are encouraged, facilitated, and often can be funded with a credit card.

I've subscribed to the notion of Gall's Law for longer than I knew it was a law:

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

(continue reading)

Open Source in Defense

by Jim Stogdill | @jstogdill | comments: 5

I’ve been meaning to write a post about open-source software in defense for a while and today my inbox achieved critical mass with the arrival of yesterday’s GCN article on the subject. The article previews a memo being prepared by the Defense Department’s CIO that should be released in early November. It will provide additional guidance on the use of open source software in defense and is meant to make it easier for the government to obtain the benefits that come with open source.

In particular, the memo will make it clear that government defense programs should evaluate open source as legally equivalent to commercial off the shelf. It also will clarify policy about participation and contribution back to the community. I’m particularly interested in that latter part as I’d really like to see the DoD improve its karmic positioning vis-a-vis open source consumption vs. contribution.

The GCN article was spurred by comments Dan Risacher gave this week at the Red Hat Government Users and Developers Conference. Dan is the principal author of the memo and previously gave an overview of the policy intent at our inaugural Barcamp.mil in August. Dan and I will be discussing the policy and its hoped-for impact (among other things) further on a panel at the 4th DoD Open Technology Conference in DC on October 29 if you would like to hear more about it.

(continue reading)

How Technology Almost Lost the War, but Should Do Better

by Jim Stogdill | @jstogdill | comments: 12

It was cool that ETech ventured into unexpected territory this year with Noah Shachtman's presentation on technology’s failure in Iraq. The talk was derived from his provocatively titled Wired article "How Technology Almost Lost the War: In Iraq, the Critical Networks are Social - not Electronic". In it he takes shots at the military’s infatuation with the bright shiny objects that support the big fight while missing the day-to-day realities of counter insurgency operations; a reality that revolves around people.

Leaving aside for the moment the fact that using technology to win the big fight gives one the luxury of discussing failures in the subsequent counter insurgency phase, Shachtman argues that the military's “Network-Centric” technology is the wrong tool for the counter insurgency job. Systems like Command Post of the Future (CPOF) are cool, but in this phase of conflict, they are like bringing an iPhone to a knife fight.

I can’t disagree, but I think the reasons are as much about a monoculture focused too long on the Fulda Gap as they are about technology's bells and whistles. But that’s a conversation for another day (and venue). An interesting question might be the one he doesn’t ask, what kinds of technology might help now in the midst of a counterinsurgency and how can we get them faster?

Released just before Shachtman’s talk, MIT’s Technology Review magazine covered DARPA’s Tactical Ground Reporting System (sorry, registration required), or TIGRnet. Where CPOF was designed for commanders fighting conventional battles, TIGRnet is for the patrolling sergeant and lieutenant fighting in a counter insurgency. While CPOF supports conventional ideas of command and control, TIGRnet gives troops on the ground new tools to share information horizontally (which might make it an accidentally subversive culture virus).

TIGRnet is interesting because it was built from scratch for the counter insurgency environment. This is no small thing in a one-size-fits all Army. However, it’s disappointing because it has been so long in the making.

(continue reading)