Outside the Box

With some hesitation, the Defense Department is starting to give open source products a whirl.

One day a few years ago in the bowels of U.S. Central Command's central headquarters in Tampa, Fla., something new awaited the techies who support the Global Command and Control System. The military relies on GCCS-Joint to present a unified global picture of itself-how ready its troops are to fight, where they're located, intelligence reports and more. Its primary residence is CENTCOM.

The new thing was a situational awareness piece of hardware and software called the Joint Range Extension, which tracks airborne assets. Andrew Seely, a GCCS lead system administrator contractor, recalls that it "just showed up one day, bang, it's in the rack.

"It was literally a black box . . . no documentation, no experience, no knowledge and big, fat serial cables coming out the back," Seely says. It could interface with the GCCS system, but it soon stopped working, and no one in Tampa knew why. Turns out the internal structure was proprietary, and CENTCOM hadn't paid for access to the technical documentation. So, the malfunction was a mystery. To fix it, system administrators had to hack their way in to find the bug causing the system crash.

That's what can happen (and happens often enough) when the government pays the private sector to develop an information technology system but doesn't pay for access to the source code or the technical documentation. Often when it does pay for the code, it can afford only a limited-distribution license. Companies charge extra to write documentation or hand over what they consider their intellectual property.

Situations like this have some Defense Department folks advocating open technology development. This approach means building applications with open source software such as the freely distributed programming language Linux. It allows more eyeballs to scan code, so problems are found and solved quickly. (The Joint Range Extension failed due to a bug that Seely says could easily have been avoided.)

The approach is about open standards for data exchange among systems. It's about not having to build everything from scratch because similar hardware and software is locked away in proprietary restrictions. It's also about agility: Integrating pre-existing open systems is faster and more responsive than building systems from the ground up.

Basically, it's about transparent systems, the opposite of enigmatic, proprietary black boxes. "The traditional approach of software development doesn't necessarily allow you to have the source code," says John J. Lussier, the Navy's acting chief information officer. Lussier is close to signing a memo encouraging Navy and Marine Corps staff to consider open source technology. The department wants to make sure they know open source is a viable option "because apparently there was some misunderstanding there."

Terry Mitchell, deputy undersecretary of Defense for advanced systems and concepts, knows why many in Defense have shied away from open source technology, despite its apparent benefits.

"The name brings a baggage of uncertainty," he says. "There's a perception that open technology doesn't have that structure behind it that maintains the sustainability and keeps it going." When Defense considers adopting something, it evaluates whether the manufacturer will last.

Another hurdle is how to get open source through information security certification and accreditation requirements. Developers of proprietary systems have whole teams dedicated to pushing an application through the security requirement process, notes John Scott, defense consultant and director of open integration for RadiantBlue Technologies Inc. of Reston, Va. "With open source, who does that?"

Mitchell's hypothesis is that open technology can surmount the doubts around it. The advanced systems and concepts office is finishing up the first of a three-year experiment (officially called a Joint Capability Technology Demonstration) using open source tools to help U.S. Strategic Command and intelligence agencies store and retrieve large volumes of data from the Defense network, the Global Information Grid.

Mitchell and Scott already have some thoughts on how to clear those hurdles. One is, pay defense contractors to support the ongoing maintenance of open source systems-most of the revenue from software is in support anyway, Mitchell says. Security issues need to be addressed early on within a project.

Defense has used open source tools before. The Army even deployed an open source server operating system called JBoss for logistics support. But the odds of a private sector developer successfully proposing an open source solution in response to a Defense solicitation still are remote, given the unknowns. So far, it's mostly been smart or thrifty managers and developers who have managed to introduce open source piecemeal.

As is usual with new technology, the main challenge associated with open source isn't the technology itself, but the governance issues around it. Mitchell stresses that he's not out to challenge the existing Defense acquisition system, with its multiple reviews and many requirements. Open technology would have to work inside that environment.

Open source advocates aren't against the notion of proprietary systems. Indeed, para-doxically, open source probably will make proprietary systems better by keeping developers on their toes. Mitchell points out, "Why should I pay for technology you developed 10 years ago, when I can go out and get it basically for free, pay for service and some integration, and it's done?" Mitchell is trying to change a mentality surrounding technology development, however. "If I didn't use the phrase 'open technology,' and I said we're going to take Northrop Grumman software, would it bother [anybody]?" he asks rhetorically. "Maybe we could create a culture that says, 'Oh, I've got to build X' . . . and companies would say, 'OK, maybe I can solve that with open technology.' "