From Military Information Technology, Volume 10, Write as We Fight. Written by Sue C. Payton
During a combat operation, a new coalition sensor becomes available that could help exploit an enemy’s vulnerability if it can be quickly integrated into the common operating environment. Within hours, engineers access the source code, coordinating with a community of programmers who review and bug-test modifications.
Days later, the command interface has been modified to import data from the new sensor. Missions are more successful, and there is unprecedented coordination with coalition forces, because the commander can implement the same software, minus a few classified modules, on the coalition network.
An open technology acquisitions strategy, including accessible source code, makes this scenario possible. Unfortunately, this kind of technological responsiveness and agility is all but impossible today, because much of the Department of Defense’s software, which is central to its operations, is bound up in proprietary systems. These “black boxes” cannot be accessed or modified by anyone but the original vendor, even though DoD nominally has rights to millions of lines of code that have cost billions of dollars to develop.
To wage information-age warfare, we need business processes that allow us to evolve faster than our adversaries. The problem is that DoD software is acquired with the same industrial-age business processes used to acquire ships, tanks and other physical machinery. Unlike planes or tanks, which require factories to make multiple copies, software can be copied perfectly and modified on the fly to change its characteristics. Software created today can be deployed in weeks versus years for physical systems. So why are we buying lines of code the way we buy ordnance?
As budgets tighten, the department must do more with resources and avoid “reinventing the wheel” as existing code is constantly recreated. Given sobering trends in American science and engineering education, we must make more efficient use of human resources in our industrial base.
By 2015, the projected number of lines of code required for avionics, compared to the number of clearable software coders, will be overwhelming. There are not enough cleared American programmers to sustain the U.S. military’s information technology infrastructure if we cannot leverage software across the defense enterprise. The current model of closed software development is broken; a new model is required.
WHAT’S THE ALTERNATIVE?
Any new acquisition model for software must account for a more rapid cycling of ideas and requirements, and allow commanders and program managers to leverage IT investments across services and agencies. We can learn from the open source software development model in the private sector.
In this model, software is collaboratively developed by a distributed community of programmers that may number in the tens of thousands for operating systems like Linux, or small groups working on highly specialized applications. The resulting software can be modified as needed. The software can be distributed without paying royalties or licensing fees to developers, as long as the accompanying copyright agreement is followed.
Open source software may be freely available, but like proprietary software, integration into an existing system requires funding for custom implementations.
For some, open source software development seems to go against common sense. “Intuition tells us that thousands of volunteers are unlikely to come together to collaborate on a complex economic project, sustain that collaboration over time and build something that they give away,” writes Steven Weber, a professor at the University of California, Berkeley. Weber acknowledges, however, “open source software is a real, not marginal phenomenon.”
Moreover, the phenomenon is growing. In 2001, SourceForge.net, an open source software development site, reported 23,000 projects and 208,141 registered users. By 2003, it had 67,400 projects and more than 600,000 registered users. Participation is also widespread. The best-known open source software, Linux, reported contributors from 31 countries.
Despite the myth that open source is a “gift economy” or alternative cultural preserve, the reasons that programmers participate are rational and self-interested. Most are trying to solve a technology problem or achieve a capability that they personally need, and it makes more sense to leverage others’ progress versus solving problems in isolation by trial and error. If someone has already solved the problem, why waste time solving it again? For a rising generation of programmers, this is common sense, and a default behavior, just as it was for the technical pioneers who built the Internet in an open, collaborative fashion.
Beyond the efficiency of writing software quickly, open source methodologies also allow programmers to hone their skills. For many, playing a small supporting role on an open source project is a professional development that their employer does not provide, but which is crucial to keeping skills current and sharp.
In addition to efficiency and skills benefits, open source methods and the communities they foster make the technical talent base larger and more transparent. In proprietary development, a qualified, even desperate customer may be unaware of available talent because coders are cloistered away, working on some black box application that they can neither share nor discuss. In an open source community, such talent would be easily discoverable online.
No longer a “bleeding edge” phenomenon, open source development has moved into the mainstream of large corporate enterprise because it makes sense. “The open movement will transform e-business,” IBM Executive Vice President William Zeitler has stated.
Hewlett-Packard has more than 200 products that utilize open source software, and hosts more than 50 open source projects on SourceForge. Organizations such as Merrill Lynch, the Chicago Mercantile Exchange, Pfizer and Continental Airlines have dramatically lowered technological overhead and realized millions in savings by switching from proprietary to open source platforms.
Similar benefits are being acknowledged in the public sector. As the President’s Information Technology Advisory Committee said in 2000, “The open source development model represents a viable strategy for producing high quality software.”
Recently, the FAA saved $15 million by migrating to an open-source platform for traffic flow management. In contrast to a proprietary solution being considered, which would have cost $25 million with an 18-month wait for full deployment, the open source platform was implemented in one-third the projected time for less than $10 million. Likewise, the Army Future Combat Systems program has adopted Linux as a key platform for deploying future capabilities.
In the Army’s Land Warrior program, open source has mitigated the pain of software integration for the Stryker Brigades’ 300-plus hardware and software interfaces. After software malfunctions, the Army replaced the commercial operating system with an open source operating system in its Land Warrior interoperability program for Stryker Brigades.
Open source also alleviates the overhead of upgrading network architecture. Each time a developer releases upgrades, users must modify the new software and hardware so it will work in the architecture. A simple upgrade can mean seven to 28 changes in an architecture.
Defense already has at least 115 open source software applications operating for more than 250 purposes. The Naval Oceanographic Office, which analyzes data on the world’s oceans for Navy, DoD and commercial customers, found that a 900 percent savings had been realized by transferring from proprietary to open source systems.
A project sponsored by the National Geospatial-Intelligence Agency found it was able to successfully develop open source software for geospatial processing with nightly releases of software generating 4,000 Web pages of documentation from more than 600 developers. It also created 270,000 new lines of state-of-the-art C++ code. Such development can speed systems to warfighters, providing technological agility in a world where it counts.
GOVERNANCE AND SECURITY
While open source code is available for viewing, commenting and modifying, the number of people who have “write” access for the public release version is typically less than a dozen on any open source project. For example, the open source Web server project Apache is controlled by a 20-person team, although suggestions, comments and fixes come from thousands of people around the globe. Only that group has access to modify the public source code for the next release.
Open source software also undergoes intense scrutiny. Linux, for example, has attracted 120,000 programmers, who not only contribute to development, but who also review it for flaws. “Given enough eyeballs, all bugs are shallow,” states Linus’s law.
All these eyes on code make it more likely that bugs and glitches in the code will be found, leading to more secure software. Many unfamiliar with software development believe that releasing the source code makes it less secure. But an ad hoc working group from DARPA, GSA, NIST and NSA found that a source code’s wide availability is more likely to uncover changes that can have negative consequences. It also allows static analysis tools to detect malicious code or undocumented features.
Additionally, the group reported that security features could be more easily incorporated for approved versions. NSA has developed a more secure version of Linux because it is heavily used by some defense agencies. Additionally, open source software is critical to network security. Open source software applications, like “Snort,” have been developed to detect hostile network intrusions. Moreover, knowing the source code allows rapid modifications in response to cyberattacks, as noted in a recent MITRE study.
These lessons are important for DoD, where similar governance and security issues apply. While proponents of proprietary software are quick to plant fear, uncertainty and doubt in the minds of others about the security and provenance of open source software, the fact is that commercial software, like its open source counterparts, is a global production.
Microsoft is investing $3.7 billion in China during the next five years, and IBM will invest $6 billion in India during the next three years. Cisco announced a billion dollar investment in India last year. Going forward, DoD would be short-sighted to presume that the software it procures from commercial vendors will not contain lines of code written in far-flung research centers.
All software needs to be tested and reviewed for reliability and security. The advantage of open source software is that we can see the code, as opposed to taking it on faith that a closed, proprietary software system is secure because the vendor’s corporate headquarters is in the United States.
Supporters of black box solutions often argue that with proprietary solutions, “There is someone to call if things go wrong.” Who actually said that? But under U.S. law, software developers are not liable for damages caused by flaws in their software. So while having a designated target might seem comforting, it does not make the developer accountable, nor enhance a developer’s ability to actually fix a problem. The opacity of software ensures that there will be a smaller available pool of people who can address the flaw.
This is not to say that military software source code should necessarily be public or that commercial software does not provide value to DoD. But in cases where the military pays to develop software for its own use, as opposed to licensing pre-existing software developed commercially, DoD needs to assert its legally established government rights to view, access and modify code, and leverage it across the department.
Defense-specific software may never be released outside of DoD. Indeed, classified applications may not be accessible outside particular compartments. But within the community of defense programs and end-users benefiting from collective software development, we should be able to treat our own IT base as a leveragable asset, and foster a distributed and diverse community of programmers who can service and supplement that software on demand.
A WAY FORWARD
The challenge for DoD is “getting from here to there.” Making open source software development a default behavior will require changes in requirements, policies, procedures and reviews. Getting there may be possible with a document, entitled “Open Technology Development: A Roadmap Plan,” released in April 2006. It lays out actions and phases for introducing open source software development in the department during the next two years and its expansion.
The journey begins with focusing on projects within the Office of Acquisition, Technology and Logistics, specifically the Office of Advanced Systems and Concepts. These organizations have played a central role in changing how technology is developed and deployed in DoD.
Pilot projects such as the Large Data Joint Capabilities Technology Demonstration program will implement such practices. Once such projects have established open source software processes, their success can be translated to larger programs using the metrics and information gathered along the way.
Ultimately, success will be measured in terms of added agility, reliability and security of our information technology systems. If the boots-on-the-ground community is urged to “train as you fight,” the technology community that supports warfighters must similarly be urged to code as we fight—not as a set of scattered assembly lines, but as a robust, responsive network.