Burton, a former Defense Intelligence Agency analyst and software developer, speaks today at the Military Open Source Software Working Group in Virginia. It’s a gathering of 80 or so national security tech-types who’ve heard a thousand stories about good ideas and good code getting sunk, because of squabbles over who owns the software.
Burton, for example, spent years on what should’ve been a straightforward project. Some CIA analysts work with a tool, “Analysis of Competing Hypotheses,” to tease out what evidence supports (or, mostly, disproves) their theories. But the Java-based software is single-user — so there’s no ability to share theories, or add in dissenting views. Burton, working on behalf of a Washington-area consulting firm with deep ties to the CIA, helped build on spec a collaborative version of ACH. He tried it out, using the JonBenet Ramsey murder case as a test. Burton tested 51 clues — the lack of a scream, evidence of bed-wetting — against five possible culprits. “I went in, totally convinced it all pointed to the mom,” Burton says. “Turns out, that wasn’t right at all.”
The program was supposed to work with Analytic Space, an online workspace for spooks. No one could come up with A-Space’s proprietary development specifications. Then came the problem of figuring out ACH’s licensing rights. Progress on the project ground to a halt.
“The Department of Defense spends tens of billions of dollars annually creating software that is rarely reused and difficult to adapt to new threats. Instead, much of this software is allowed to become the property of defense companies, resulting in DoD repeatedly funding the same solutions or, worse, repaying to use previously created software,” writes John M. Scott, a freelance defense consultant and a chief evangelist in the military open source movement. “Imagine if only the manufacturer of a rifle were allowed to clean, fix, modify or upgrade that rifle. This is where the military finds itself: one contractor with a monopoly on the knowledge of a military software system.”
Take Future Combat Systems, the Army’s behemoth program to make itself faster, smarter, and better-networked. One of the many reasons it collapsed: the code at the heart of the system was controlled by a single company, and not even the sub-contractors building gear that was supposed to rely on that code could have access to it.
“For years,” Scott adds, “the U.S. military has been losing an asymmetric battle that involves not improvised explosive devices, bullets or al-Qaida, but instead swarms of defense industry contractors seizing control of taxpayer-funded ideas because government policy and regulations were engineered to buy iron and steel, not to deploy a software-based military.”
Burton is under no illusions that open sourcing the ACH software suddenly means it’s going to embraced by a thousands analysts. “Most people in the community don’t know what open source is or they don’t care,” he says.
But for the government’s alpha geeks, it’s yet another example of why Washington’s bizarro-world rules surrounding software need to change. And there are signs — small, tentative signs — that some movement is under way. Even the big defense contractors are toying with some open source projects. Lockheed Martin recently released the source code for Eureka Streams, a social media platform for government agencies. Veteran tech writer Dana Blankenhorn instantly pooh-poohed the project. But Gunnar Hellekson, a leading technologist for the open source Linux distributor Red Hat, practically moon-walked with glee. “Open source advocates have, for years, been trying to encourage more code to come out from behind corporate skirts,” he wrote. “If more code is open, that makes everyone smarter. And that, my friends, is exactly what Lockheed Martin did today.”
Versión en español