That word "open"

For most people, the word "open" might seem rather benign, conjuring only images of open fields or perhaps a late-night eatery still catering to hungry travelers. For military personnel, however, "open" has a negative connotation. Any good soldier should bristle at the word. Things that are open need to be secured, for they are vulnerabilities where an enemy force could encamp.

This latent fear of the word "open" is as good an explanation as any we've heard on why the military has thus far been reluctant to adopt open-source software. The word certainly does not inspire the same degree of trust as other words, such as "Raytheon" for instance.

We're not being merely snarky; this observation about the comparatively superior trustworthiness of the integrator's name came from one attendee at yesterday's DOD Open Source Conference, held by the Association for Enterprise Integration. The purpose of this conference was to help acclimatize Defense workers to the open-source concept. John Weathersby, executive director of the Open Source Software Institute of Hattiesburg, Miss.--one of the sponsors of the conference--was confident that the meeting helped in this regard. But the day also showed how much more work advocates still need to do.

A few months back, the Office of the Deputy Undersecretary of Defense for Advanced Systems and Concepts issued a report about potential open-source use that generated quite a bit of enthusiasm within Defense circles. Now we see why. At the meeting we saw how skeptical Defense IT personnel--and contractors--remain towards open source, and even open standards.

And maybe with good reason. It would be glib to characterize the Defense Department's reluctance to embrace open source as irrational. Some of the more interesting exchanges between the audience and open-source emissaries were over the basic assumptions of the open-source methodology, and the limits of that approach.

For instance, after a talk given by Brian Behlendorf, co-founder of the Apache Software Foundation, the audience's questions indicated less interest in the Apache Web server software and its offshoots, and more in the process that brought Apache together in the first place.

This is not surprising. Open-source software is developed in a way that runs counter to notions of how big projects--including big military projects--should be executed.

"Software devlopment is a very communal act, but it doesn't come in on schedule," Behlendorf explained. Most successful open-source applications didn't arrive after a specific manager-imposed deadline. This approach of software production, one that can be likened to an assembly line job, was popularized by IBM in the 1960s and 1970s, he noted. But he charged that the idea of treating the complex activity of software development like a factory operation is one that just leads to mediocre software at best.

In contrast, open-source software comes together organically, as resources allow. Team leaders have to rely on volunteers who have erratic schedules and varying levels of commitments. And yet rock-solid applications, such as the Linux kernel, have sprung from these limitations.

The lesson from Behlendorf? Organizers should be more agreeable to projects where there is no shipping date, and instead rely on developers who ruthlessly exploit every chance for advancement that comes along.

Behlendorf likened the open-source approach to that of a garden, where "promising exact outcomes isn't as important as successful managing the process that maximizes the output," he said. "You don't know how many tomatoes you will produce, but you know you if you tend to the plants and weed them, you will get a whole lot."

Brian Stevens, the chief technology officer for Linux distributor Red Hat Inc. of Raleigh, N.C., also echoed Behlendorf's thoughts that day. "I think about [improving efficiency] far more than I think about schedules," he said.

Those who have suffered through using half-finished commercial software that was released merely to hit a ship schedule might appreciate this approach. An open-source application may take years to get to a full-fledged 1.0 release, but when it does, you can be sure that it has been thoroughly tested, Behlendorf boasted. An open-source version of 1.0 would be equal to "what most companies would call a 3.1," he quipped. Without pressure from investors to hit some arbitrary timeframe, coders can, in theory, actually finish the software to the degree it needs completion.

Of course, it could also lead programmers to meander. Perhaps the Perl scripting language is the best example of what is good and bad about this approach. We have been awaiting for years version 6 of Perl. On the other hand, the 5.x version of Perl works so well that relatively few users are begging for an update.

Still, this approach has some shortcomings, and they are just the kind of shortcomings that the Defense Department can't abide. In the military, leaving tasks unfinished until some indeterminate time in the future is simply not acceptable, especially in cases where life--and accountability--is at stake.

Behlendorf admitted that at least half of all the 129,000 open-source projects on Sourceforge are dead--no one is working on them. Nor does the communal approach guarantee continued support, or even that the origin of the code comes from a trusted source (essential not only for warding off litigation, but also foreign espionage).

Open-source advocates pointed out that, in many cases, proprietary software vendors fail with these goals just as often as open-source software projects do. All that commercial vendors can offer is a heartier guarantee that such failings will not happen. But that very guarantee is all-important within a military chain-of-command, which can't trail off to some open-ended point.

And there's that "open" word again. So while Defense personnel may have learned a thing or two from the open-source people, let's hope the open-source folks picked up a few lessons as well.

--Posted by Joab Jackson