"War upon the Map" User Innovation in American Military Software Jon R. Lindsay Technology and Culture, Volume 51, Number 3, July 2010, pp. 619-651 (Article) Published by The Johns Hopkins University Press
For additional information about this article http://muse.jhu.edu/journals/tech/summary/v051/51.3.lindsay.html
Access Provided by MIT Libraries at 08/16/10 4:40PM GMT
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 619
“War upon the Map” User Innovation in American Military Software
J O N R . L I N D S AY
The art of war therefore became, in a sense that it had not been before, an art to be pursued upon the map, and with an immensely greater number of permutations and combinations possible than ever before. Obviously, the conduct of war upon this level required a far different order of intelligence, knowledge, preparation, and skill than the command of a visible mass of men upon a visible terrain. — Dallas D. Irvine1
The iconography of U.S. defense publications regarding computers at war usually features lightning bolts arcing around networks of ships, aircraft, satellites, and ground vehicles. While such cartoons evoke an image of global networked power, they also tend to obscure all the low-level effort that enables this technology to function. One journalist covering the 2003 invasion of Iraq noted “an unsung corps of geeks improvising as they went, cobbling together a remarkable system from a hodgepodge of military-built networking technology, off-the-shelf gear, miles of Ethernet cable, and commercial software.”2 This is hardly a wartime anomaly, for military perJon Lindsay is a Ph.D. candidate in the Massachusetts Institute of Technology Department of Political Science, where he is completing a dissertation on information-technology usage in military organizations. He holds a B.S. in symbolic systems and an M.S. in computer science from Stanford University and has served as an intelligence officer in the U.S. Navy, recently completing a tour in Iraq. Many people offered constructive comments on previous versions of this article, including Barry Posen, Harvey Sapolsky, Kenneth Oye, Merritt Roe Smith, Eric von Hippel, Kieran Downes, Brendan Green, Austin Long, Joshua Rovner, Colin Jackson, John Staudenmaier, and the anonymous T&C reviewers. This research has been supported by the MIT Program on Emerging Technologies (PoET), a National Science Foundation Integrative Graduate Education and Research Traineeship. ©2010 by the Society for the History of Technology. All rights reserved. 0040-165X/10/5103-0004/619–51 1. Dallas D. Irvine, “The Origin of Capital Staffs,” Journal of Modern History 10 (1938): 173. 2. Joshua Davis, “If We Run Out of Batteries, This War Is Screwed,” Wired, June 2003, http://www.wired.com/wired/archive/11.06/battlefield_pr.html (accessed 10 March 2010).
619
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 620
C U LT U R E
sonnel often find themselves modifying or working around officially procured technologies in order to meet emergent operational needs. As a result, military computer networks host a motley tangle of user-developed databases, scripts, websites, and sophisticated applications, all running alongside commercial and government programs. This article explores the phenomenon of bottom-up military innovation through the history of a popular software application called FalconView. As a general-purpose geospatial toolkit, FalconView can display a variety of map and imagery formats, create custom map overlays, perform planning calculations, interface with Global Positioning System (GPS) receivers, and display real-time data from tactical radio feeds. In the early 1990s, U.S. Air National Guard fighter pilots created the PC/Windowsbased program to aid preflight mission planning for the F-16 fighter. A decade later, all four services and other government agencies were using FalconView to support an astonishing variety of intelligence, planning, and operational tasks. Networks of enthusiastic users drove its functional evolution and diffusion into a de facto standard for geospatial information processing in the U.S. military, all for a total cost of about $20 million. By contrast, official acquisition programs inspired by and designed to replace FalconView went millions of dollars over budget, lagged years behind schedule, and—with an official focus on aviation alone—lacked FalconView’s general-purpose, military-wide appeal. FalconView is a striking example of sustained and successful bottom-up innovation in a military environment.3 The role of users as agents of technological change has been well established for commercial and consumer realms.4 According to Eric von Hippel’s economic model of the phenomenon, people innovate when the costs of inventing something they will personally benefit from using are less than the transaction costs of finding a manufacturer and communicating situated and changeable design requirements. As an alternative to contracting, 3. Strictly speaking, “FalconView” is the geospatial interface application for a diverse suite of mission-planning software tools called the Portable Flight-Planning System (PFPS) or, more recently, Execution Planner (XPlan). Many users often refer to the entire bundle as FalconView, as, for simplicity’s sake, does this article. 4. Nelly Oudshoorn and Trevor Pinch, How Users Matter: The Co-Construction of Users and Technology (Cambridge, Mass., 2003); Ronald Kline and Trevor Pinch, “Users as Agents of Technological Change: The Social Construction of the Automobile in the Rural United States,” Technology and Culture 37 (1996): 763–95; Lucy Suchman, “Working Relations of Technology Production and Use,” in The Social Shaping of Technology, 2nd ed., ed. Donald A. MacKenzie and Judy Wajcman (Philadelphia, 1999), 258–68; Wanda J. Orlikowski, “Improvising Organizational Transformation Over Time: A Situated Change Perspective,” Information Systems Research 7 (1996): 63–93; Ruth Schwartz Cowan, “The Consumption Junction: A Proposal for Research Strategies in the Sociology of Technology,” in The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology, ed. Wiebe Bijker, Thomas P. Hughes, and Trevor Pinch (Cambridge, Mass., 1987), 261–80.
620
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 621
LINDSAYK|KAmerican Military Software
“lead users” in low-cost niches can use local knowledge and materials to improvise their own solutions. Lead users tend to enthusiastically share their inventions with others who have similar interests and who can further improve and share the designs, thereby generating increasing returns in a self-reinforcing user community. User innovation has been found to improve product quality and social welfare in a variety of industries.5 However, extreme sports aficionados and open-source software developers are generally not members of all-encompassing bureaucracies like the military, nor are their inventions designed to kill. It is, of course, natural for soldiers to modify their weapons or improvise field expedients to deal with the exigencies of combat.6 The ancient Greeks built the Trojan Horse, American servicemen in World War II turned German beach obstacles into hedgerow cutters for Sherman tanks, and the prevalence of improvised explosive devices (IEDs) in contemporary conflicts attests to the enduring lethal efficacy and cross-cultural appeal of wartime improvisation. Likewise, computer-savvy personnel often adapt their information-processing tools to particular situations, using ubiquitous PC software technology that offers them multiple avenues for low-cost intervention (e.g., through configuring applications, designing databases and spreadsheets, writing documents, macros, or actual programs). Yet while war encourages expedient adaptation, military organizations present some serious obstacles to any significant and sustained level of user innovation. Would-be user-innovators live in a controlled world of classified information and austere configuration policy intended to limit lethal mistakes and enemy exploitation. Short tours-of-duty and war-fighting responsibilities limit users’ ability to support their inventions, and they lack the legitimacy of official acquisition and certification regimes. The defense procurement bureaucracy is notoriously complicated and inefficient: it is plagued by strategic uncertainty, congressional log-rolling, industrial rent-seeking, inter-service competition, and a raft of lawyers, program managers, and engineers.7 While offi5. Eric von Hippel, Democratizing Innovation (Cambridge, Mass., 2005) and The Sources of Innovation (New York, 1988); Yochai Benkler, “Coase’s Penguin or, Linux and ‘The Nature of the Firm,’” Yale Law Journal 112 (2002): 369–446; Volker Wulf and Matthias Jarke, “The Economics of End-User Development,” Communications of the ACM 47 (2004): 41–42; Josh Lerner and Jean Tirole, “Some Simple Economics of Open Source,” Journal of Industrial Economics 50 (2002): 197–234. 6. Field expedients and tactical innovations appear regularly in most combat histories. Thematic treatments include James Jay Carafano, GI Ingenuity: Improvisation, Technology, and Winning World War II (Mechanicsburg, Penn., 2006); Michael D. Doubler, Closing with the Enemy: How GIs Fought the War in Europe, 1944–1945 (Lawrence, Kans., 1995); John H. Hay, Tactical and Materiel Innovations (Vietnam Studies) (Washington, D.C., 1974); Center of Military History, Improvisations during the Russian Campaign (Washington, D.C., 1986); and Timothy T. Lupfer, The Dynamics of Doctrine: The Change in German Tactical Doctrine during the First World War (Leavenworth, Kans., 1981). 7. Harvey M. Sapolsky, Eugene Gholz, and Caitlin Talmadge, US Defense Politics: The Origins of Security Policy (New York, 2008); Peter Dombrowski and Eugene Gholz,
621
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 622
C U LT U R E
cial channels may be inefficient, nevertheless the worries of procurement and network managers about the quality, scalability, and reliability of amateur user code are often well-founded.8 Military bureaucracy thus poses something of a hard test for user innovation in both theory and practice. While FalconView demonstrates that lead users and innovation communities can and do emerge within military organizations, the case also suggests some conditions for its possibility. Enthusiasts have to work hard to construct organizational support and protection for their projects. Interactions among various actors are often contentious, but rather than a simple rivalry between heroic users and hidebound bureaucracy, we also find mutual accommodation as personnel engage in heterogeneous engineering with technical and political resources.9 Ironically enough, the emergence of user-centered alternatives to traditional bureaucratic procurement actually requires enthusiasts to adopt bureaucratic characteristics in order to support the process. FalconView was also enabled by several important historical developments that opened opportunities for software innovation. From the early 1980s into the 2000s, the U.S. strategic landscape underwent significant change, and the commercial information-technology (IT) sector took off. The Reagan administration’s buildup during the 1980s sought to offset the Soviet Union’s quantitative advantages in nuclear and conventional forces by developing complex sensor networks and precision munitions, and these advanced weapons in turn increased the information-processing load on operational units. Further information demands emerged after the Cold War, when a series of American expeditionary adventures during the 1990s and 2000s altered organizational objectives from high-intensity warfare to counterterrorism and counterinsurgency. At the same time that military means and missions were radically changing during the 1980s and 1990s, the commercial IT industry exploded with the rapid growth of PC-based software and widespread public embrace of the internet. Low-cost, powerful computing tools became available to public and private sectors, along with an increasingly computer-literate workforce. Taken together, the considerable changes in the strategic demand for information processing and in the comBuying Military Transformation: Technological Innovation and the Defense Industry (New York, 2006); Eugene Gholz and Harvey M. Sapolsky, “Restructuring the U.S. Defense Industry,” International Security 24 (2000): 5–51; Alex Roland, The Military-Industrial Complex (Washington, D.C., 2001); Daniel Wirls, Buildup: The Politics of Defense in the Reagan Era (Ithaca, N.Y., 1992); Thomas L. McNaugher, “Weapons Procurement: The Futility of Reform,” in America’s Defense, ed. Michael Mandelbaum (New York, 1989), 68–112. 8. While this article describes a case of successful bottom-up military innovation, the author’s dissertation dwells at length on the nasty coordination problems that amateur modifications of information technology can inflict on military organizations. 9. John Law, “Technology and Heterogeneous Engineering: The Case of Portuguese Expansion,” in The Social Construction of Technological Systems, 111–34.
622
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 623
LINDSAYK|KAmerican Military Software
mercial supply of IT provided some unique opportunities for pilots to develop their own mission-planning software.10 This history of FalconView not only demonstrates that user innovation can work in the military and suggests conditions for its sustained success, but it also contributes to broader themes in scholarship. The literature on military innovation tends to focus on the doctrinal and industrial challenges associated with large-scale, capital-intensive projects such as tanks, aircraft carriers, and nuclear missiles;11 however, bottom-up technical innovation within the user organization can also create a pathway to lasting change. Debate on the role of computers in war—the supposed “revolution in military affairs” (RMA)—has been dominated by enthusiastic reformers and skeptics regarding the impact of IT on military effectiveness, yet this discussion has cast little light on the everyday use of computers in military organizations.12 Computing historiography, as Paul Edwards points out, has for its part focused more on infrastructure and machinery than on the dynamic web of software applications they enable.13 This article spans the intersection of these literatures by focusing on the efforts of military personnel to redesign the very software they are using to deal with emerging operational needs. 10. Wirls; Thomas G. Mahnken, Technology and the American Way of War since 1945 (New York, 2008); Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (Cambridge, Mass., 2004); James W. Cortada, The Digital Hand, 3 vols. (New York, 2004–08). 11. Thematic treatments of military innovation include Adam Grissom, “The Future of Military Innovation Studies,” Journal of Strategic Studies 29 (2006): 905–34; Williamson Murray and Allan R. Millett, Military Innovation in the Interwar Period (New York, 1996); Alex Roland, “Science, Technology, and War,” Technology and Culture 36 (1995): S83–S100; Stephen Peter Rosen, Winning the Next War: Innovation and the Modern Military (Ithaca, N.Y., 1991); and Merritt Roe Smith, ed., Military Enterprise and Technological Change: Perspectives on the American Experience (Cambridge, Mass., 1985). 12. Mahnken; Tim Benbow, The Magic Bullet? Understanding the Revolution in Military Affairs (London, 2004); Andrew F. Krepinevich Jr., The Military-Technical Revolution: A Preliminary Assessment (Washington, D.C., 2002); William A. Owens and Edward Offley, Lifting the Fog of War (New York, 2000); Michael E. O’Hanlon, Technological Change and the Future of Warfare (Washington, D.C., 2000); Jeremy Shapiro, “Information and War: Is It a Revolution?” in Strategic Appraisal: The Changing Role of Information in Warfare, ed. Zalmay Khalilzad (Santa Monica, Calif., 1999), 113–53; Stephen Biddle, “The Past as Prologue: Assessing Theories of Future Warfare,” Security Studies 8 (1998): 1–74. 13. Paul N. Edwards, “Virtual Machines, Virtual Infrastructures: The New Historiography of Information Technology,” Isis 89 (1998): 93–99; Kent C. Redmond and Thomas M. Smith, From Whirlwind to MITRE: The R&D Story of the SAGE Air Defense Computer (Cambridge, Mass., 2000); Alex Roland and Philip Shiman, Strategic Computing: DARPA and the Quest for Machine Intelligence, 1983–1993 (Cambridge, Mass., 2002); Arthur L. Norberg and Judy E. O’Neill, Transforming Computer Technology: Information Processing for the Pentagon, 1962–1986 (Baltimore, 1996); Paul N. Edwards, The Closed World: Computers and the Politics of Discourse in Cold War America (Cambridge, Mass., 1996).
623
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 624
C U LT U R E
This article furthermore combines historical and ethnographic methods. My first exposure to FalconView was as an active-duty U.S. naval officer. From 1998 to 2003, I used it regularly in intelligence work and also developed complementary software tools to extend its functionality. I dealt with discombobulated military networks on a daily basis and observed the challenges of official procurement firsthand. This experience would later provide me access to and credibility with the individuals I interviewed for this account, as well as a feel for the dynamics of military user innovation. My informants were key participants in mission-planning systems, whom I identified through interviewee referrals. I supplemented these interviews with primary documents in the public domain or that were provided to me by participants. These methods provide ethnographic insight and cast light on phenomena that might otherwise be missed by outsiders. While some readers, unable to access the same data, might be concerned about potential pro-FalconView bias, this possibility is mitigated by the fact that several officers I interviewed were actively involved with both informal and official mission-planning systems, putting them in a good position to report on both sides. A broader study of the entire mission-planning world, including greater attention to the internal processes of program managers and defense contractors, would be valuable indeed, but that is beyond the scope of this article, which seeks instead to highlight the experience of computer users themselves. I believe the insights emerging from the case are nevertheless generalizable, an issue to which I return at the end of the article.14 Pilots Begin Automating Mission Planning
Aviation mission planning includes all the information gathering and processing that aircrew must do before takeoff. A simple cross-country flight requires aviators to find proper charts, plot a flight route, gather weather data, update airfield and navigational-aid information, calculate fuel consumption, and file a flight and communication plan with airspace managers. In addition, an attack mission requires parsing the air tasking order from higher headquarters, studying intelligence about threats and targets, calculating weapons settings, “de-conflicting” operations with friendly air and ground forces, and developing search-and-rescue contingency plans. Different missions have different requirements, such as slowdown and air-release points for cargo airdrops. Aircrew typically print this information on kneeboard cards for easy reference inside the cockpit. 14. On ethnographic validity, see Michael H. Agar, The Professional Stranger: An Informal Introduction to Ethnography, 2nd ed. (New York, 1996); John Van Maanen, “The Fact of Fiction in Organizational Ethnography,” Administrative Science Quarterly 24 (1979): 539–50; and Susan Leigh Star, “The Ethnography of Infrastructure,” American Behavioral Scientist 43 (1999): 377–91.
624
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 625
LINDSAYK|KAmerican Military Software
FIG. 1 Planning materials used prior to the automation of mission planning:
paper charts, navigation updates, flight manuals, and “whiz wheel” calculators. (Photo: Jake Thorn, 1981. Reproduced with permission.)
“Mission planning is not rocket science,” one aviator explained, “but it’s complicated with lots of moving parts.”15 Prior to automated mission-planning systems, these calculations were time-consuming activities involving paper charts, protractors, dividers, “whiz wheel” calculators, grease pencils, flight manuals, and paper orders and updates. Aircrew pulled strings across charts to measure distances, traced turns around coins, and cut strip charts with scissors and glued them together. In some squadrons, manual planning was not uncommon well into the 1990s (fig. 1). By the late 1970s, aviators were experimenting with automating some of these tasks by using microcomputers and engineering calculators. The nascent software market was experiencing something of a gold rush with the appearance of mass-produced microcomputers like the Apple II and Tandy Radio Shack TRS-80 in 1977, and the IBM PC running Microsoft DOS in 1981. Most successful software programs for such microcomputers—the VisiCalc spreadsheet, WordStar word processor, and dBase II database—were written on microcomputers by groups of just one or two pro15. Colonel Jake Thorn (U.S. Air Force Reserve), personal interview with author, 13 October 2005.
625
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 626
C U LT U R E
grammers.16 This situation created similar opportunities for military aviators to buy computers and program the stereotyped calculations needed for flight planning; already responsible for their own planning and navigation, officers “could fly with beta software because if they screwed up it was their wings anyway.”17 In 1981, two young A-10 fighter pilots, Captains Jake Thorn and Jerry Fleming, both avid electronics hobbyists, began using a TRS-80 Model 1. The commander of Air Force Tactical Air Command (TAC), General Wilbur Creech, met the pair during a routine visit and asked: “Can you flight plan on that thing?” They were invited to give a demonstration at a meeting of air force leadership, and their squadron commander agreed to take them off the flight schedule so that they could get to work. “Jake and Jerry’s Two Week Flight Planner” impressed the crowd enough that Creech created the Small Computer Program to provide every squadron with a microcomputer and begin “squadron automation.” Aircrew started writing and running software on Cromemco System 2 (CS-2) machines.18 Various aviator-written programs percolated through the community, passed around on floppy disks from one aviator to another as they circulated via fighter jet around air bases. One program that became widely used was FPLAN (“Flight Planner”), first written in 1983 by Thorn, Fleming, and another pilot at Eglin Air Force Base in Florida. FPLAN performed basic route and fuel calculations, but its real novelty was an updatable database of navigation coordinates and frequencies from the monthly printed update to instrument flight rules. Like a garage-startup software company, the officers’ wives manually typed in the data from each update so that they could make copies on floppy disks and mail them out to other aviators. Over the next several years, they released several new versions of FPLAN updates on the side while working their primary jobs, and their distribution list grew considerably. FPLAN found its way onto computers of squadrons across the Air Force and Air National Guard (fig. 2).19 As happened in the commercial world, when software production costs declined with the advent of low-cost personal computers, technically savvy lead-users like Thorn and Fleming innovated for their own benefit. They freely revealed their programs to other pilots, giving rise to a user community. They also planted the seeds for bureaucratic support—and competition.
16. Campbell-Kelly (n. 10 above), 202–21. 17. Major Mike Bartgis (U.S. Air National Guard), personal interview with author, 28 October 2005. 18. Jake Thorn, “Mission Planning Historical Perspective,” slide presentation prepared for SAIC (Science Applications International Corporation), provided to author in October 2005; Thorn interviews, 13 October and 15 November 2005. 19. Thorn interview, 13 October 2005.
626
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 627
LINDSAYK|KAmerican Military Software
FIG. 2 A-10 pilot Captain Jerry Fleming with oscilloscope, 1981. Fleming and
Captain Jake Thorn co-authored FPLAN, the first user-developed application to diffuse widely throughout the military aviation community. Most automated mission-planning tools were developed by pilots like them who were electronics hobbyists and held engineering degrees. (Photo: Jake Thorn. Reproduced with permission.)
Two Paths Diverge
In 1983, TAC established a center for testing and evaluating automated mission-planning systems at Eglin, which became something of a hub for official and unofficial activity. The first contractor-produced systems like the Mission Support System (MSS) also used the CS-2 platform but ran a Unix operating system, while the squadron machines ran DOS. These twin paths—official, expensive, something-for-everyone, difficult-to-manage Unix solutions versus informal, run-on-a-shoestring, mission-focused DOS solutions—would characterize mission-planning software throughout the 1990s. Another pattern to emerge was that the same aviators involved with official systems at Eglin were also developing unofficial systems on the side, having strong interests in improving mission planning and insiders’ knowledge of problems plaguing official programs. Thorn, for example, was the operations officer of the Eglin test squadron conducting the operational test of MSS at the same time he was working on FPLAN.20 20. Major Mark A. Gillott, “Breaking the Mission Planning Bottleneck: A New Paradigm,” Air University Air Command and Staff College Research Report AU/ACSC/
627
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 628
C U LT U R E
Aircrew found MSS difficult to use as delivered, leading to a complete software overhaul in 1983. An even larger version followed in 1986, enclosed in a refrigerator-sized ruggedized container. Jake Thorn once again became a key link between formal Unix and informal PC-DOS efforts in 1989 as chief of the MSS Projects Office at Eglin. He was painfully aware of the problems plaguing official development and the importance of ensuring that pilots had something that worked well in the meantime, so he still facilitated informal development and distribution efforts even while working to improve MSS. Furthermore, the popularity of PC-DOS solutions among aircrew led to decisions that MSS should mimic the FPLAN interface for better usability, and that Eglin should start funding onsite contractors to write small-scale PC-DOS utilities as stopgaps for the Unix MSS. Collectively known as “Portable Flight-Planning Software” (PFPS), this smorgasbord of software would make it easy for users to mix and match or even add functionality, rather than to wait for upgrades of a monolithic system. Thus official systems inspired by early user efforts were further shaped by them through the agency of hybrid user/managers like Thorn, and they also provided resources for further informal supplements.21 MSS did have some novel features the PC programs lacked. In addition to the first digital map displays, it was the only way to load the recently created cartridges (or “bricks”) that transferred data from computers in office spaces to the avionics of advanced fighters like the F-16C. As more aircraft were fitted with data cartridges, costs to support them expanded—an example of weapons improvements leading to greater data-processing loads, as well as expanding requirements on the official systems (fig. 3).22 Unfortunately, not all squadrons with F-16s had an MSS, and those that did found them difficult to use and maintain. Air National Guard squadrons were particularly hard-pressed, being well below active-duty squadrons in priority for new equipment but still needing to be as portable as possible for deployments. This led two officers in the Guard, Majors Robert Sandford and Walter Sobczyk, to build a device that would connect directly to a PC and load a cartridge. Their first prototype was literally carved out of wood at Hill Air Force Base in Ogden, Utah, and dubbed the “Ogden Developed Device” (ODD). Soon PCs running FPLAN and refined ODDs 099/1998-04, 4–6; Thorn interview, 13 October 2005; Thorn, “Mission Planning Historical Perspective”; Mike Bartgis, “AFMSS MPS and PFPS News,” ANG/DOOM Newsletter, May 2000, 6. “AFMSS MPS and PFPS News” was a monthly compilation of programmanagement news and technical advice for the mission-planning user community; the May 2000 issue contained a section titled “History from Fading Memory” (pp. 5–9) in which Bartgis, then an officer with the Air National Guard Bureau, described a pattern of rising expectations and frustrations with various systems. 21. John Pyles (FalconView project manager at GTRI from 1993 to 2000), personal interview with author, 28 October 2005; Gillott, 7; Colonel Jake Thorn, official military biography page, provided to author in October 2005. 22. Pyles interview; Gillott, 4, 15.
628
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 629
LINDSAYK|KAmerican Military Software
FIG. 3 Major Jake Thorn demonstrating General Dynamics Mission Support
System II (MSS-II), 1987. MSS-II, the first planning system to field digital maps, is an example of official programs providing a cost- and computation-intensive feature beyond the range of early user-developed applications. FalconView would later leverage the map data developed for such systems. (Photo: Jake Thorn. Reproduced with permission.)
were available to air national guard aircrew, eliminating the need for MSS. ODDs found their way into active-duty squadrons, despite headquarters’ protests that they were unsafe. Reflecting a tradition of aircrew responsibility for planning, squadron commanders sided with aircrew, who found the ODD/FPLAN solution more reliable and hassle-free than MSS.23 The 1991 Gulf War provided a major stimulus to automated mission planning. Many aircrew were exposed to digital mapping on the MSS for the first time and were impressed with its possibilities. However, there were never enough to go around, the machines were frequently down, and manual planning with paper charts and grease pencils was still common. Mission planning took at least six to eight hours and sometimes days for complex strikes; target imagery and intelligence was often unavailable; and coordination with widely dispersed members of strike packages was very 23. John Pyles, personal communication (e-mail) with author, 26 October 2005.
629
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
A N D
7/15/10
10:37 AM
Page 630
C U LT U R E
JULY 2010 VOL. 51
FIG. 4 The Air Force Mission Support System (AFMSS) fielded after the first
Gulf War, 1992. The AFMSS mission-planning system was physically larger than its predecessor, more expensive, classified, and expanded to serve aviation platforms across the air force. Frustration with the program led Air National Guardsmen to spearhead development of FalconView, an alternative program that would run on laptop PCs. (Photo: Jake Thorn. Reproduced with permission.)
difficult, and with friendly ground forces, sometimes impossible. In response, the Air Force established a program office at the Electronic Systems Center in Massachusetts to create a new Air Force Mission Support System (AFMSS). Its scope expanded beyond fighters to also encompass bomber, airlift, tanker, and special-operations aircraft, as well as headquarters command and control. This effort to make something for everyone at one go would prove frustrating for users and managers alike, as the expense and coordination challenges tended to separate engineers from users with layers of red tape. The resultant hardware suite ended up even bigger than the already large MSS. Also, the entire system, including its generic navigation functionality, was classified; by contrast, programs like FPLAN had always been unclassified and easy to disseminate (fig. 4).24
24. Thomas A. Keaney and Eliot A. Cohen, Gulf War Air Power Survey Summary Report (Washington, D.C., 1993), 177–78; Jane Glaser, “When Reflex Is a Matter of Life and Death,” expanded draft, provided to author, of chapter 21 in Bill Gates, Business @ the Speed of Thought: Succeeding in the Digital Economy (New York, 1999); Gillott, 8–12.
630
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 631
LINDSAYK|KAmerican Military Software
“The Killer App”
Unfortunately, the ODD/FPLAN stopgap was limited by architectural legacies dating back to the earliest microcomputers (like single-character variables) and idiosyncrasies of several ports across different operating systems. Sandford remained pessimistic that the new cumbersome program would ever be viable, especially for the Guard. He started to consider instead a complete PC alternative that would run on a single laptop, display digital maps, support graphical mission planning, and load cartridges via an ODD. Prevailing upon National Guard Bureau staffers, he obtained unallocated year-end money.25 In the late 1980s, most engineers viewed PCs as too underpowered to support graphics-intensive mapping. Sandford presciently believed that this problem would go away as PCs running Microsoft software became more capable, while Unix machines would remain scarce for squadrons. With the release of Microsoft Windows 3.0 in 1991, graphics-heavy programs were finally feasible on the PC. Another challenge was that mapping software required detailed, regularly updated, efficiently compressed map data covering wide areas. Commercial customers who could afford this expensive data could also afford a more powerful Unix machine to work with it. Sandford, however, would be able to freely leverage all the map data developed for Unix systems like AFMSS, which resolved this problem as well.26 In the spring of 1993, Sandford found a sympathetic ally in research scientist John Pyles at the Georgia Tech Research Institute (GTRI). Pyles had previously worked on Army software that displayed photographs of maps on PCs, which showed him how portable and useful laptops were in the field; he had also worked on an MSS contract that familiarized him with military-map data formats. Sandford and Pyles signed a contract for a “flight plan simulation mapping system,” with the word “simulation” added so that the Guard could piggyback on an existing Army contract with Georgia Tech for simulation software. Pyles’s managers also required him to phrase the contract wording so that deliverables would be “beta”—working prototypes rather than finished products—because they felt that the six-month deadline was too ambitious. “We were just too naïve to realize this ourselves and just went ahead and finished the initial release anyway,” Pyles recalls. “Being fresh out of college, $475K sure sounded like a lot of money to us and as a result we were under a good deal of self-induced pressure to deliver.” The beta version was completed in January 1994, and Sandford discreetely provided a tested version 1.01 to F-16 aircrew in June.27 25. John Pyles, personal communication (e-mail) with author, 7 December 2005; Lieutenant Colonel Robert Sandford (U.S. Air National Guard), personal interview with author, 12 October 2005. 26. Sandford interview; Campbell-Kelly (n. 10 above), 250–51. 27. Pyles interview (n. 21 above); Pyles personal communication, 7 December 2005.
631
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 632
C U LT U R E
Like other engineers, Pyles wanted to do Sandford’s project in Unix, even a PC running Unix, but Sandford was adamant. The constraint of designing for the Intel 8086 processor (rather than a more powerful Unix minicomputer) challenged the engineers to come up with fast and efficient rendering techniques. Although this constraint evaporated as PC hardware performance improved, it paid dividends later on in fast, smooth performance. “I knew technology was on our side and we could ride the hardware wave of hard disks, screen resolution, and PC performance improvement,” Pyles said. As Sandford pointed out, “PCs are disposable.”28 Sandford and Pyles consciously based FalconView management on Frederick Brooks’s classic The Mythical Man-Month.29 Brooks argues that conceptual integrity is the most important and elusive part of software design, which is inherently complex, hard to visualize, changeable, and somewhat arbitrary; he recommends a small “surgical team” of talented programmers, a chief programmer controlling the concepts, and frequent end-user interaction to ensure that the task and solution are coordinated. Pyles played the role of chief programmer, while Sandford—the chief user—was closely involved in architecture and interface discussions, sometimes even coding working prototypes to convey a concept. Although he was a staff officer at the Pentagon, Sandford was still flying F-16s regularly, thus keeping his understanding of planning requirements fresh.30 The team made two key decisions. First, they bet on Microsoft: “It will be whatever Bill Gates decides.” This meant designing for DOS (and, later, Windows), writing in the C++ language rather than ADA (the Department of Defense standard at the time), and adopting the Microsoft Office interface style.31 They paid a lot of attention to the user interface, because they wanted a novice to be productive with daily tasks right away. In stark contrast to the official programs that required users to memorize cryptic combinations of keyboard commands, FalconView became an application that people liked to play with the first time they were exposed to it. As one aviator said: “I’ve learned more in ten minutes on my own with this software than I did during two weeks of training on [AFMSS].”32 Second, version 1.0 would be designed only for the F-16 (hence the The fresh-out-of-college naïveté expressed itself in other ways also. Someone on the FalconView team included a copy of the video game Doom on the CD with version 1.0. The game remained on the CD for three years until a squadron intelligence officer told GTRI he was having trouble getting FalconView on his machines because security managers told him Doom wasn’t accredited. 28. Pyles interview. 29. Sandford interview; Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, 20th anniversary ed. (Reading, Mass., 1995). 30. Bartgis interview (n. 17 above). 31. Lieutenant Colonel Joe Webster (U.S. Air Force Reserve), personal interview with author, 25 October 2005. 32. Cited in Gillott (n. 20 above), 15.
632
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 633
LINDSAYK|KAmerican Military Software
name FalconView, after the F-16 “Fighting Falcon”). Even though there was interest in Sandford’s project elsewhere, especially in the C-130 airlift community, he wanted to avoid the kind of “requirements creep” that plagued official programs. Sandford and Pyles supposed from the start that a general-purpose, PC-based geospatial package could be broadly useful for other aircraft, simulator instructors, and even nonaviation communities. “We knew it would be a really cool app if anyone would let us build it,” said Pyles. Yet they decided to hold these possibilities at bay in order to first achieve success with the basics: “Do only 80%, but do it perfect.” This set a precedent for small incremental changes in FalconView, always making sure that basic functionality was solid before trying to add more.33 By focusing on the human interface rather than just technical functionality and by limiting their initial scope, Sandford and Pyles laid the foundation for an application that others—and not only pilots—found intuitively attractive. The application would be free to any government employee, sidestepping the proprietary licensing associated with contractor-developed code. It would also be unclassified, since any overlays would be separate data files rather than part of the application code (i.e., the program could be disseminated on unclassified CD-ROMs and later loaded onto classified networks). All of this would hasten FalconView’s diffusion through user networks. Competing Complements
Military users and program managers are not homogenous groups. Sandford and Thorn, like many officers who rotated between operational and staff jobs, could play either at different times, and each developed different opinions about the relationship between user-led software efforts and the big programs. Sandford was exasperated with the latter’s inefficiency and sought to bypass them altogether with an independently funded Air National Guard system, FalconView; Thorn, by contrast, was involved in AFMSS program management and saw user software efforts as temporary supplements that would eventually help improve it. Thorn hoped to reform the acquisition programs, but the more revolutionary-minded Sandford wanted to avoid them altogether. The two officers could at least agree that the venerable FPLAN needed to be overhauled: Sandford needed its flight-planning capabilities for FalconView, and Thorn needed a stopgap until the official AFMSS system was ready. Sandford transferred Guard funding to Eglin (where Jerry Fleming, one of the original FPLAN developers, now worked as a civilian contractor), and Thorn achieved reluctant program-office acquiescence by promising to 33. Webster interview; Pyles interview (n. 21 above); Sandford interview (n. 25 above).
633
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 634
C U LT U R E
keep it separate from FalconView, which was perceived as a wasteful distraction from the main Unix effort. Thorn ensured that the new program, Combat Flight-Planning Software (CFPS), shared the look and feel of the AFMSS interface in order to help train aircrew, thereby achieving programoffice buy-in and eventual further funding. This enabled CFPS to leverage aircraft-specific software modules, also developed at Eglin, to facilitate datacartridge loading. Sandford, in turn, ensured that FalconView—under a separate guard contract with Georgia Tech—would be able to interface with CFPS, thus giving him not only flight planning, but data-loading capabilities as well. Ironically, CFPS was separated from FalconView so that the Air Force program office would not be funding a PC-based map display, but in doing so, it ended up subsidizing more potent capabilities for its PC competitor.34 Thorn and the program office recognized the threat and tried to slow development. They demanded that route coordinates entered through CFPS remain fixed in FalconView, but Sandford’s next version allowed users to graphically construct and modify a route; they also demanded that FalconView not duplicate an expensive and classified AFMSS capability to display threat data, but Sandford’s next version allowed users to graphically build threat overlays, while keeping the application unclassified. The FalconView team could routinely ignore angry AFMSS protests as they added new features, because their funding came from the Guard and the Air Force Reserve rather than the active-duty Air Force. Furthermore, AFMSS development was having a lot of problems and receiving extremely negative user feedback, so program managers grudgingly recognized that a functional stopgap solution really was needed.35 In early 1996, FalconView version 2.0 was percolating throughout the Air Force when a tragedy in Croatia further raised its visibility. On 3 April, a CT-43 carrying U.S. Commerce Secretary Ron Brown and thirty-four others crashed on instrument approach to Dubrovnik, killing all aboard. Investigators concluded that had the pilots used FalconView’s GPS-enabled moving map in the cockpit, the crash might have been avoided. Later that year, the Air Force made FalconView use mandatory on all aircraft carrying distinguished passengers.36 34. Bartgis, “AFMSS MPS and PFPS News” (n. 20 above), 6–7; Sandford interview. 35. Bartgis, “AFMSS MPS and PFPS News,” 7; Sandford interview. Lieutenant Colonel Webster took over FalconView management from Sandford when Sandford transferred from the Air National Guard Bureau to the F-16 test team at Nellis Air Force Base in 1995. Sandford still spoke frequently with and made monthly visits to the development team at GTRI, thus ensuring that FalconView continued to benefit from immediate user feedback (see Webster interview). 36. Linda D. Kozaryn, “Air Force Releases Brown Crash Investigation Report,” American Forces Information Services, 13 June 1996, http://www.defense.gov/news/news article.aspx?id=40796 (accessed 10 March 2010); Chris Bailey, “FalconView: Mission Planning Tools at GTRI,” GTRI slide presentation on FalconView capabilities in the 2001 timeframe, provided to author in October 2005.
634
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 635
LINDSAYK|KAmerican Military Software
Frustration with AFMSS mounted and the popularity of FalconView grew, spreading informally to an estimated 13,000 users by 1997. The issue came to a head at a meeting of Air Force general officers at the Pentagon. The AFMSS program office director was fired, and AFMSS was directed to officially incorporate FalconView and related PC applications, although GTRI and Eglin would continue actual development. AFMSS continued funding the Unix systems, however, because some specialized missions or aircraft (such as the F-117 stealth fighter) depended on it, yet FalconView finally won official endorsement, as well as $4.4 million of AFMSS money over the next two years.37 By October, GTRI released FalconView 3.0, updated for the 32-bit Windows 95 operating system and including 100-meter digital terrain elevation data. That same year, FalconView was recognized as one of five finalists in the “core business” category of Microsoft’s annual Windows World Open competition. Microsoft CEO Bill Gates later featured a chapter on FalconView in his book Business @ the Speed of Thought, pointing out that reservists had created an avenue for ideas about civilian technology development to influence the military.38 Building Institutional Support
Despite these successes, FalconView’s future was often uncertain. The AFMSS program office still viewed it as an unsustainable, unmanageable hobby-shop project. The majority of mission-planning funding went to the various Unix systems, as well as to a new official program intended to replace both Unix and FalconView systems with a PC alternative. Before describing this new initiative, it is important to understand how FalconView managed to survive on a fraction of the funds allocated to AFMSS, yet still appeal to a far broader user community. Ironically, a small program designed for the F-16 alone became popular with a diverse user group beyond aviation, while large programs designed from the outset to support multiple aircraft communities failed even to satisfy their target users. FalconView requirements were informally coordinated with GTRI and Eglin, whose engineers either were former aviators or had developed and maintained close relationships with aircrew. A standing contract with the Ogden Air Logistics Center allowed other organizations to transfer small amounts of money. FalconView supporters—usually pilots doing a staff 37. This was still only a small portion of the overall $32.6 million AFMSS budget during the same period, FY1999–2000, which covered legacy MPS development and JMPS development (Department of Defense RDT&E Budget FY2001–2002, PE #0208006F). 38. Chris Bailey (FalconView project manager at GTRI from 2000 to present), personal interview with author, 14 October 2005; Thorn interview, 13 October 2005 (n. 15 above); Glaser (n. 24 above); U.S. Department of Defense, “Air Reserve Software Program Wins Worldwide Recognition,” press release, 3 June 1997, http://www.defense.gov/ releases/release.aspx?releaseid=1283 (accessed 10 March 2010).
635
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 636
C U LT U R E
tour with Air Force, Navy, or Special Operations program offices—were often “shaking trees” to keep Pyles’s team in business. Each modest contribution funded a specific feature for a specific customer, creating pressure for continuous improvement and aggressive quality control. Every few months Pyles would call his patrons to warn: “We’re about to turn into pumpkins! Do you have more work?” Lacking a guaranteed budget, FalconView had to be responsive to “the guy flying the airplane right now” to keep the money flowing. Furthermore, the existing Air Force contract and small lumps of money allowed officers to avoid an official sourceselection process, enabling quicker turnaround. By contrast, budgets for the official mission-planning systems were congressional budget lineitems, executed in a more lugubrious, legalistic, and carefully managed style that was insulated from the operators.39 Different organizations that wanted new features contributed money or prototypes, and these improvements then became available for free to all users; one aviator described FalconView’s management as “stone soup,” after the fable of the villagers who added ingredients to a magic recipe to create something from nothing.40 Air Force special operations funded terrain-elevation and threat-masking algorithms to calculate the effect of ground features on radar coverage so that aviators could predict which surface-to-air threats could see them; this feature could then be used by ground forces in reverse to predict what they would be able to see from observation points. The Navy funded digital nautical charts, a three-dimensional flight simulator, and image georectification, which appealed to operators at sea, in the air, and on land. Frequent, incremental, modular improvements on the solid FalconView foundation, together with the basic contracting vehicle, enabled different service components to achieve a degree of interoperability that much larger “joint” programs aspired to.41 FalconView’s diffusion to other services featured the same sort of creative bureaucratic maneuvering that enabled the application’s initial emergence in the Air Force. For example, a Marine Corps F/A-18 aviator working at the Naval Mission Planning Systems office, Major John Bennett, viewed FalconView as a viable alternative to the Navy’s own troubled Unix program (TAMPS).42 Bennett proactively visited with aircrew and mailed 39. Pyles interview (n. 21 above); Webster interview (n. 31 above). Most FalconView contributions were less than $200,000, the outlier being a U.S. Special Operations Command (SOCOM) contribution of $2 million in 2003. 40. Lieutenant Colonel Paul Hastert (U.S. Air Force Reserve), personal interview with author, 8 October 2005. 41. Chris Bailey, “Department of Defense Usage of FalconView,” GTRI White Paper, 2005. 42. The Tactical Air Mission Planning System (TAMPS) evolved from a Tomahawk cruise missile planning system, passing through three different contractors and routinely failing operational testing and evaluations because of both interface and basic functionality issues. The physical system was so large that it had to be hoisted from the aircraft-
636
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 637
LINDSAYK|KAmerican Military Software
out hundreds of CDs to “beta users” before FalconView was ever certified for Navy use. Bennett decided that he needed fleet “disciples” to overcome the criticism of engineers at Navy labs who, as in the Air Force story, focused on Unix and were hostile to maverick PC efforts. To build official support, he would ghostwrite messages for units to send to the Chief of Naval Operations staff with glowing evaluations and endorsements of the software. Network managers complained that they would find it on one squadron machine and remove it, only to come back later and find it on several more. On the deckplates, it “was somewhere between a cult and a virus.” The groundswell of enthusiasm led to the approval in 1998 of a Navy channel for distributing and funding small improvements for FalconView. Bennett leveraged this to accommodate requests from Marine Corps units for new features to support ground forces, expanding FalconView’s scope beyond aviation for the first time.43 To build and maintain FalconView, its supporters exploited organizational opportunities—by helping to balance budgets, cutting deals, letting out contracts, and so on—to expeditiously deliver software functionality to users. They also sought ways to lay in more institutionalized support for a growing user community. A dozen aviators held the first Mission-Planning User Conference (MPUC) at the Eglin Officers Club in 1993. This became an annual forum to discuss developments in both FalconView and the official programs, with attendance growing to over 1,100 people in 2000. Program representatives attended the meetings, downplaying the significance of FalconView 3.0’s distribution in 1998; in 2001, the same speakers apologized to the crowd that they had not been able to divest themselves of the big Unix systems fast enough. The Air National Guard staff commenced distributing a monthly newsletter to a growing mailing list with detailed technical, operational, and programmatic advice on both Unix and PC systems. Software traveled with aircrew around the world for exercises and carrier hangar deck and through the floor into the intelligence center above. Navy regulations classified damage to the cartridge as a class C mishap—technically grounding the aircraft—so maintenance officers were reticent to let aircrew take the cartridge, since aircrew could still plan without it. The introduction of the AGM-84E Stand-Off Land Attack Missile (SLAM) prior to the Gulf War finally made TAMPS use unavoidable, but even for SLAM, planning aircrew preferred to use paper charts and informal planning techniques, only then transferring the results to TAMPS to use it merely as an expensive ($200,000 per workstation) data-cartridge loader. Hank Davison, a former A-7 pilot working as a civilian TAMPS instructor at Naval Air Station Lemoore in the 1990s, lamented: “When just planning, I was having a hard time coming up with a use for TAMPS. It took more time than with a pile of charts and scissors, which was faster and more accurate for adept planners.” Commander Hank Davison (U.S. Navy, subsequently a contractor with NAVAIR PMA-281), personal interview with author, 18 October 2005; Davison, personal communications (e-mails) with author, 3–5 April 2006; Major John “Festus” Bennett (U.S. Marine Corps, subsequently with Tybrin Corporation at Eglin Air Force Base), personal interview with author, 19 October 2005. 43. Bennett interview; Davison interview.
637
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 638
C U LT U R E
operations, and as officers transferred assignments frequently, they took FalconView with them to different commands, sometimes assuming positions within acquisition organizations to influence mission-planning funding. This turnover of user/managers might have been destabilizing but for the complementary cultivation of small groups of engineers at GTRI and Eglin, with low turnover and close user interaction, cooperative relationships with program managers, and, most importantly, the longevity and perseverance of a handful of officers in key staff positions. The missionplanning community grew into a dynamic hybrid of formal and informal projects and of aviators, managers, and engineers, all constrained by but also shaping their institutional environment.44 Second-Order Innovation
The first wave of user innovation during the 1980s and 1990s launched automated mission planning and culminated in official recognition and support for FalconView. In the process, FalconView became a contract-mediated, civilian-managed engineering project, although not quite as bureaucratically encumbered as the larger programs such as AFMSS. The proverbial closing of the black box did not, however, mean an end to the technology’s “interpretive flexibility,” as Kline and Pinch describe in the case of the early automobile.45 Software architectures are layered and modular, so that any particular application is often actually a collection of programs and files, all built on top of other software components and protocols.46 The same PC that runs software can be used to make more software (often challenging distinctions between “real” code and scripts, macros, and documents). Information technology is combinatorially generative, offering many opportunities for users to intervene or create novel behavior from existing functionality.47 The stabilization of FalconView as a freely available, general-purpose geospatial tool enabled users to leverage it as a toolbox for new applications, thereby catalyzing a new wave of innovation. Thus closing the black box at one level actually fostered an increase in interpretive flexibility at another. User extensions might simply combine existing features for a new purpose, as when bomber crews duct-taped commercial GPS antennas and data-loggers into their cockpits to record their flying routes. Many pro44. Bartgis, “AFMSS MPS and PFPS News” (n. 20 above), 1, 7; Hastert interview; Major Mike Bartgis, personal communication (e-mail) with author, 28 October 2005. 45. Kline and Pinch (n. 4 above); cf. David N. Lucsko, The Business of Speed: The Hot Rod Industry in America, 1915–1990 (Baltimore, 2008). 46. For an accessible overview of the different layers in hardware and software architectures, see Elihu Zimet and Edward Skoudis, “A Graphical Introduction to the Structural Elements of Cyberspace,” in Cyberpower and National Security, ed. Franklin D. Kramer, Stuart H. Starr, and Larry K. Wentz (Washington, D.C., 2009), 91–112. 47. Jonathan L. Zittrain, “The Generative Internet,” Harvard Law Review 119 (2006): 1975–2040.
638
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 639
LINDSAYK|KAmerican Military Software
grams generated output files that FalconView could read and display, such as the actual ground footprint of an aircraft’s forward-looking sensor or the expected bomb-dispersal pattern. Some low-level utilities made FalconView more versatile, such as automating data-sharing between machines. Contractors also designed FalconView complements when users found funds, such as the bird-avoidance model (BAM) that drew from a database of migratory routes to create overlays depicting the probability of bird strikes at any given time, and TaskView, which parsed air tasking orders into interactive FalconView overlays.48 Many user applications helped bridge data from noninteroperable “stovepipe” systems, or work around them altogether. Software-savvy personnel often wrote Visual Basic scripts within Microsoft Office documents to get around network policy that banned uncertified executables; sophisticated code and operating-system calls could then masquerade as “just an Excel spreadsheet.” A Navy junior officer aboard an aircraft carrier developed an Access database, Quiver, which automatically generated target and threat overlays for FalconView and target imagery and data on PowerPoint slides. A similar database, Vulture, managed intelligence and operational data for an Air Operations Center, thereby sidestepping the unwieldy Theater Battle-Management Core System (TBMCS). A versatile tool called Excel2FV written inside a Word document simplified the import of other data formats into FalconView; an officer managing combat intelligence during Operation Anaconda in Afghanistan in 2002 said that this tool “literally saved lives countless times and was the ONLY way we could’ve managed the battle situation” (figs. 5 and 6).49 Recognizing the extent of this activity in 2000 and trying to encourage it, Georgia Tech exposed FalconView application-program interfaces (APIs) and provided a software-development kit (SDK) in 2002. End users/developers gained the ability to add buttons, control the FalconView display from other applications, and respond to user actions in FalconView within their own code. When software designers expose interfaces, provide code libraries and web services, or include scripting/macro languages, they create opportunities for third parties to become experts in customization, which has the benefit of expanding the market for the original application without the original developer having to pay for the work.50 Intensive third-party pro48. Shawn Fleming, “Using FalconView for Situational Awareness and Post-Mission Reconstruction,” presentation at Mission-Planning Users Group, Moving Map Working Group, 1999; Davison interview (n. 42 above); Hastert interview (n. 40 above); Bartgis interview (n. 17 above); Pamela Bowers, “CrossTalk Honors the 2002 Top 5 Quality Software Projects Finalists,” CrossTalk: The Journal of Defense Software Engineering, July 2003, http://www.stsc.hill.af.mil/crosstalk/2003/07/top5finalists.html (accessed 10 March 2010). 49. Major William A. Hastings (U.S. Air Force), personal communication (e-mail) with author, 28 October 2005. 50. Stefan Thomke and Eric von Hippel, “Customers as Innovators: A New Way to Create Value,” Harvard Business Review 80 (2002): 74–81.
639
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
A N D
7/15/10
10:37 AM
Page 640
C U LT U R E
JULY 2010 VOL. 51
FIG. 5 The Predator sensor field-of-view (FOV). Many users extended Falcon-
View’s functionality with customized add-ins. This FalconView screenshot shows satellite imagery of an air force bombing range, over which is superimposed a user-produced overlay of the sensor FOV from a Predator unmanned aerial vehicle, 2002. This overlay was automatically updated in real time through a tactical radio feed from the Predator, thus providing greater situational awareness for the Predator sensor operator, who would otherwise only be able to see through the “soda straw” of the video sensor itself. (Screencap: Paul Hastert. Reproduced with permission.)
grammer support of FalconView led to an explosion of new applications, many of them created by users on a very modest scale to address local-unit activities. Many of these were amateurish from a software-design perspective, and some would even introduce data-coordination problems when local expedients frustrated efforts to standardize data protocols across units. The FalconView team remained small, never amounting to more than twenty people, including administrative support; it accepted the fact that it would often have no idea how FalconView was being employed, whether for good or ill.51 By facilitating extensibility, the team deliberately reinforced the general-purpose nature of FalconView as a reliable, user-friendly, geospatial tool—supporting a critical representational form in military practice— rather than just a specialized aviation mission planner.52 This also insulated 51. Bailey, “Department of Defense Usage” (n. 41 above); Bailey interview (n. 38 above). 52. The FalconView team deliberately sought to design interface abstractions that
640
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 641
LINDSAYK|KAmerican Military Software
the core application from the risks of user innovation (quality, sustainability, coordination, and so on), much as the kernel of the open-source Linux operating system is carefully managed amid the more rambunctious decentralized development of supporting modules.53 This separation caused some friction, however, as successive releases of FalconView sometimes broke third-party applications that depended on specific file-format or programinterface definitions; while this imposed coordination costs on users, the benefits of extensibility tended to outweigh the hassle of the alternative, which was complete dependence on a program office for functionality. Because FalconView was free, unclassified, general purpose, and generative, it diffused out to a very diverse user group. Georgia Tech estimated that there were more than 20,000 FalconView users in 2004, with much of the growth outside of aviation.54 Military interrogators used it with detainees who were unable to read maps, but could point out locations on satellite imagery.55 Special Forces operators strapped FalconView laptops onto their all-terrain vehicles (ATVs) to navigate in Afghanistan.56 Soldiers in Iraq shared FalconView unclassified satellite imagery with coalition partners to improve coordination.57 Using FalconView, a marine corps artillery battery constructed a counterfire coordination system during the Battle of Fallujah.58 Air Force officers developed the ability to broadcast Predator unmanned-aerial-vehicle data over internet protocol (IP), displaying multiple Predator tracks in real time on FalconView imavoided reference to specific local applications in order to enable the software to be applicable for multiple localities. This general strategy is described by Neil Pollock, Robin Williams, and Luciana D’Adderio, “Global Software and Its Provenance: Generification Work in the Production of Organizational Software Packages,” Social Studies of Science 37 (2007): 254–80. 53. The definition and integration of modules is one of the hardest and most important conditions for successful decentralized user innovation, which can be facilitated by community norms, hierarchical management, and technical constraints; see Benkler (n. 5 above). 54. T. J. Becker, “Not for Pilots Only: Flight-mapping Software Attracts Broad Audience with Its Diverse Capabilities,” Georgia Tech Research News, 20 July 2004, http:// gtresearchnews.gatech.edu/newsrelease/falconview.htm (accessed 10 March 2010). The estimate of 20,000 users is surely far too low given the ubiquity of FalconView on intelligence- and mission-planning workstations observed by the author on active duty as recently as 2008; the estimate likely counts the number of names on a distribution list rather than the gross number of users, which, given the constant rotation of active and reserve service members supporting the wars in Iraq and Afghanistan, is probably higher by an order of magnitude. 55. Author’s observation in Iraq, 2007–08. 56. Sean Naylor, Not a Good Day to Die: The Untold Story of Operation Anaconda (New York, 2005), 162–63. 57. Eric Lipton, “3-D Maps from Commercial Satellites Guide G.I.s in Iraq’s Deadliest Urban Mazes,” New York Times, 26 November 2004. 58. Keil R. Gentry, “RCT-1 Fires in the Battle of Fallujah,” Field Artillery, November–December 2005, 26–29.
641
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
A N D
7/15/10
10:37 AM
Page 642
C U LT U R E
JULY 2010 VOL. 51
FIG. 6 Lieutenant Colonel Paul Hastert writing code for FalconView application
“Excel2FV” while aboard a C-130 cargo aircraft, 2002. (Photo: Paul Hastert. Reproduced with permission.)
agery.59 Other applications aided aircraft-crash forensics, tracked whale migrations, and analyzed directed-energy blinding threats. Outside of the Department of Defense, the U.S. Forest Service used FalconView to plan airdrops and track the spread of forest fires, customs agents tracked drug-running aircraft, and dozens of other countries legally acquired FalconView.60 Colombia, for example, used it for intelligence coordination in counterinsurgency operations.61 China also obtained a copy from hackers who broke into computers at the Redstone Arsenal in Alabama (fig. 7).62
59. Lieutenant Colonel Paul Hastert, “Spiral Development in Wartime,” slide presentation to NDIA, provided to author in October 2005; Hastert interview (n. 40 above). 60. Becker (n. 54 above); Abby Vogel, “Mapping and Imagery Display: FalconView Goes Open Source for Corporate, Environmental, Government and Other Users,” Georgia Tech Research News, 12 August 2009, http://gtresearchnews.gatech.edu/falconview-open-source (accessed 10 March 2010). 61. Author’s observation in Colombia, 2002. 62. Nathan Thornburgh, “The Invasion of the Chinese Cyberspies (and the Man Who Tried to Stop Them): An Exclusive Look at How the Hackers Called TITAN RAIN Are Stealing U.S. Secrets,” Time, 5 September 2005, http://www.time.com/time/magazine/article/0,9171,1098961,00.html (accessed 10 March 2010).
642
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 643
LINDSAYK|KAmerican Military Software
FIG. 7 FalconView laptop mounted on the passenger side of a Humvee (Iraq,
2003). A commercial GPS receiver connected to the laptop provides real-time navigation support. This is an example of how FalconView diffused beyond the aviation communities for which it was developed. (Photo: Paul Hastert. Reproduced with permission.)
JMPS, Up and Down
Even while FalconView catalyzed enthusiastic second-order innovation well beyond military aviation, it continued to be criticized within the acquisitions community. After 1998, FalconView was the de facto aviation mission-planning application for the Air Force, Navy, and Special Operations Command. AFMSS had been humbled in 1997, when the Air Force fired its program director and endorsed FalconView. The acquisitions organizations’ response was to launch yet another formal program, the Joint Mission-Planning System (JMPS, or “Jumps”), intended to replicate and replace it. Ironically, the arguments that FalconView proponents employed early on to secure bureaucratic support (or at least toleration) for its emergence would be turned against them. To secure Air National Guard funding, Major Sandford had articulated a vision of Microsoft-based mission-planning software running on cheap, commercial PCs. Accordingly, throughout the 1990s, the mission-planning debate was framed in narrowly technical terms as a contest between popular PCs and unwieldy Unix systems. This resonated with Air Force and Navy aviators, who were frustrated with their dysfunctional Unix boxes. As long as the program offices were committed to the Unix-installed base, this debate played out well for FalconView—the only viable PC mission planner available. By the end of the decade, however, acquisitions managers drew an obvious lesson: a single PC/Windowsbased system would be better than struggling with service-specific Unix 643
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 644
C U LT U R E
“stovepipes”; that is, they took the problem to be simply a matter of computer architecture, rather than the bureaucratic nature of acquisitions processes. This narrow framing of the issue marginalized FalconView’s innovative processes, which closely involved users in development and thereby reduced the costs of linking emerging operational needs to technical expertise. Moreover, the mission-planning program offices were actively critical of FalconView’s process, which they characterized as maverick coding unsupported by adequate testing, review, and configuration management and thus not scalable, reliable, or interoperable (even though FalconView’s wide demand-driven diffusion suggested the contrary). In 1998, the Air Force Electronic Systems Center commissioned an independent Carnegie Mellon study, which found—with some reason—that FalconView was too personality-dependent and therefore unsustainable. The program offices used the report and austere Defense Department configuration-management directives to undermine the renegade FalconView. On top of this, the Navy program office did not want to depend on FalconView, because, since its 1997 coup, it was officially an AFMSS program; that is, the Navy did not want to replace its erstwhile Unix program with Air Force software. Interservice deadlock was resolved by launching a joint program in 1998 to create a new PC-based mission planner for all the services (including special operations). JMPS would thus have an even more ambitious scope than that which confounded AFMSS.63 Initial hopes for JMPS ran high, even among some officers who had been active proponents of FalconView over AFMSS.64 Colonel Jake Thorn returned to full-time active duty to take charge of the JMPS project (some took to calling it “Jake’s Mission-Planning System”), hoping to use the fresh start to reconstruct FalconView with the sustainability, longevity, and accountability that a managed program might provide. FalconView’s champions worried instead that previous experiences of mounting expense and inefficiency were about to be repeated, but they were an unfunded minority amid many interested parties. Once again, FalconView officially became a temporary stopgap awaiting the development of a larger program of record. Thorn felt confident that Northrop Grumman, with a $50 million budget and eighteen months, could meet its modest goal of replicating Fal63. Thorn interview, 13 October 2005 (n. 15 above); “Joint Mission-Planning Segment (JMPS) Statement of Objectives (SOO) Version 2.0,” Naval Air Systems Command (PMA-233) and Air Force Electronics Systems Center (ESC/AC) planning document, 12 February 1998; Jake Thorn, “JMPS: Industry Day, a Roadmap to Success,” slide presentation during an initial meeting with JMPS subcontractors and collaborators on 4 May 1998, provided to author. 64. “This project holds great promise to break with the problems of the past” (Gillott [n. 20 above], 24); “[s]ince JMPS is based on PFPS [FalconView], there is no excuse for not meeting the user needs . . . the user should be completely happy since the user will be on familiar ground” (Bartgis, “AFMSS MPS and PFPS News” [n. 20 above], 8).
644
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 645
LINDSAYK|KAmerican Military Software
conView’s functionality, so he resisted allocating any additional funding for FalconView, which was in need of a major overhaul because of 1990s development legacies and new opportunities in emerging Windows platforms.65 By 2001, however, JMPS was suffocating with cost and schedule overruns. Northrop Grumman started cutting corners to keep the program afloat. With all of its subcontractors, development problems, and policycompliance concerns, most of the effort was expended on coordination within the program, rather than between users and developers. Things that were easy in FalconView became hard in JMPS. Exasperated with the situation, the original three FalconView developers left GTRI in 2000 and Thorn retired from JMPS in 2002. A certified, initial operational first version of JMPS had still not been completed by 2006, six years after the program had planned simply to field a replacement for the 1999 version of FalconView.66 Operational needs did not wait. Throughout the 1990s, the United States conducted aerial patrols and strikes in Iraq; in 1999, the country fought its largest air war since Desert Storm, in Serbia. The bulk of mission planning was digital, with greater emphasis than ever before on time-critical precision strikes. Major combat operations in Afghanistan and Iraq furthermore stressed mission planners to support special operations, ground forces, and an unprecedented profusion of unmanned vehicles. FalconView’s decentralized mode of development and ease of distribution proved responsive to emerging war-fighting challenges, as well as to users outside of JMPS’s aviation-only jurisdiction. Accordingly, customers such as Special Operations Command and the Army made up for FalconView’s funding deficit. While JMPS was still struggling to complete its first version, four new, operationally certified versions of FalconView were fielded (although with increasing amounts of time between each release, as the increasingly formalized FalconView-development process had to contend with increasing complexity and a larger pool of users). Like the programs before it, JMPS struggled simply to meet its original requirements, even while those requirements changed significantly in the meantime.67 Some $20 million has been spent on the various versions of FalconView since 1993; JMPS cost nearly $1 billion in its first decade. In retrospect, 65. Bartgis, “AFMSS MPS and PFPS News,” 8; Webster interview (n. 31 above); Thorn interview, 13 October 2005. 66. Thorn interview, 13 October 2005; Bennett interview (n. 42 above); Pyles interview (n. 21 above). The JMPS project traced the typical software-management pattern that Brooks identified in The Mythical Man-Month (n. 29 above) (and that FalconView champion and Brooks disciple Robert Sandford also predicted); its development woes were thus not a military-specific problem, although the red tape associated with defense contracting surely exacerbated the basic dynamic. 67. Robert Sandford and Paul Hastert, “PFPS Sustainment and Improvement: Giving the Warfighters What They Want Now,” slide presentation to the 2006 Mission Planning Users Group, provided to author.
645
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 646
C U LT U R E
Thorn estimated that it should have been possible to deliver everything JMPS was supposed to do for $200 million by using the FalconView model. As of this writing, advanced aircraft like the F-22, F-35, and F/A-18E/F/G still need JMPS to fly, since JMPS took on many tasks (e.g., weather modeling) that FalconView was able to ignore. JMPS suffered from cost overruns piling on top of already-high sunk costs. Without a viable alternative, the program came to be viewed as extraordinarily high-risk. As a result, Northrop Grumman lost the JMPS contract in 2008 to BAE Systems, and services other than the Air Force pulled out of the program, leaving it “joint” in name only. Once again, FalconView came to the rescue, as JMPS incorporated its mapping engine, and FalconView implemented more and more planned JMPS functionality. In a fairly radical step for government software development, most of the FalconView code-base was moved into a public open-source forum to improve coordination among far-flung developers (fig. 8).68 Given the prominence of user innovation in mission-planning software history, it is likely that some new mission-planning solution will emerge to displace both JMPS and its perennial stopgap solution FalconView, or at least many of their functions. Advances in commercial geospatial software—exemplified by Google Earth and mobile-phone mapping software—continue to lower technical barriers to user innovation, while two ongoing wars continue to generate unexpected demand. As FalconView development became more bureaucratized in order to survive (although never to the same degree as larger programs like JMPS), some users began to bypass it with newer commercial components. At the same time, mission-planning software—as with command, control, and intelligence technology generally—has become a multibillion-dollar defense industry, with all the congressional, corporate, and bureaucratic politicking that entails. This tends to raise organizational barriers to user innovation, since the field is far more crowded and regulated than ever before. In any case, the military information-processing environment will continue to become an even more complex menagerie of officially managed and maverick projects competing and collaborating in unexpected ways. Conducting War upon the Map
In the last few decades, the information-processing load associated with U.S. military operations has continued to grow as a result of data-hungry weapons systems, the planning challenges of precision targeting and counterterrorism operations, and a fluid strategic environment of traditional 68. Thorn interview, 13 October 2005; Bailey interview (n. 38 above); Toni Dineen, PFPS Technical Interchange Meeting minutes, 26 August 2009; Vogel (n. 60 above). Georgia Tech engineers did not expect that FalconView users per se would participate in opensource development, but rather that it would ease coordination with other contractors.
646
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 647
LINDSAYK|KAmerican Military Software
FIG. 8 FalconView’s development team at the Georgia Tech Research Institute
(GTRI) promoting release of an open-source version of the FalconView codebase, 2009. (Photo: Gary Meek. Reproduced courtesy of GTRI.)
and emerging actors interacting in unpredictable ways. The defense-acquisition bureaucracy, already inefficient in procuring massive hardware projects, appears especially challenged by software.69 Meanwhile, the commercial market has made powerful, flexible, low-cost software tools available, while service members are more computer literate than previous generations. Because contemporary U.S. military operations generate a high demand for information-processing power, which traditional acquisitions processes are ill-suited to efficiently supply, personnel are thus empowered to attempt to supply it for themselves. These developments blur the distinction between software design and use. Enthusiastic personnel leverage powerful toolkits to extend information-processing functionality into new domains and improve operational adaptability. Moreover, for FalconView users flying with moving maps, for pilots of unmanned vehicles that are thousands of miles away, and for intelligence officers with considerable leverage over tactical events, these developments also blur Jomini’s classic distinction between “fighting upon the 69. Report of the Defense Science Board Task Force on Defense Software (Washington, D.C., 2000); U.S. Government Accountability Office, “Stronger Management Practices Are Needed to Improve DOD’s Software-Intensive Weapon Acquisitions,” Report GAO04-393, 1 March 2004; David C. Gompert, Charles L. Barry, and Alf A. Andreassen, “Extending the User’s Reach: Responsive Networking for Integrated Military Operations,” National Defense University, Center for Technology and National Security Policy, Defense and Technology Paper no. 24, 2006.
647
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 648
C U LT U R E
ground” and “planning upon a map.”70 While popular conceptions of war emphasize harrowing combat, many contemporary personnel engage in information work exclusively, and even those who operate “outside the wire” spend more and more of their effort busied with it. Whatever the pros and cons of the RMA for overall military effectiveness, the everyday experiences of U.S. service members involve greater interaction with a tangled web of software authored by commercial firms, government contractors, and military users themselves. This heterogeneous bricolage of functionality provides both the impetus and the means for users to adapt tools to their emergent information needs. The development of FalconView exhibits many of the classic features of user innovation. Individuals on the leading edge of emerging trends improvised mission-planning software solutions using inexpensive PCs and shared them freely with their comrades. These expedients anticipated and often suggested features that were later incorporated into official systems, much as automobile manufacturers incorporated hot-rodders’ after-market adaptations or as bicycle companies developed mountain bikes.71 Personnel explored areas of functionality that the official programs said would be too difficult or expensive, notably with planning tools that interoperated across service communities. Again and again, the official programs ran into extraordinary difficulty and expense as formal requirements, federal budget cycles, sharply defined jurisdictions, classification, and acquisitions red tape separated users from engineers, while FalconView outsourced the definition of requirements and the prototyping of novel functionality to the users themselves. When provided with toolkits like FalconView’s program interfaces and Microsoft’s Visual Basic, personnel produced working applications and used them to wage war.72 Although there are idiosyncrasies in the FalconView case, such as the engineering bias for Unix, the PC/Windows opportunity, a chance accident in Croatia, and so on, it is not a unique case of military-user innovation. Just as pilots introduced automated aviation mission planning, the first digital aid for naval air defense was a product of a savvy user/developer group and senior officer support.73 Even after the Navy established formal 70. Antoine-Henri Jomini, The Art of War, trans. G. H. Mendell and W. P. Craighill (1862), Project Gutenberg, EText no. 13549, released 28 September 2004, 69. 71. Lucsko (n. 45 above); Christian Lüthje, Cornelius Herstatt, and Eric von Hippel, “User-Innovators and ‘Local’ Information: The Case of Mountain Biking,” Research Policy 34 (2005): 951–65. 72. It is ironic that Microsoft products enabled so much user innovation in the military given that the firm is so vilified in open-source discourse, as in, for example, Eric S. Raymond, The Cathedral and the Bazaar, 2nd ed. (Cambridge, Mass., 2001). While few civilian engineers would choose to write an application in Visual Basic, normal softwaredevelopment packages (to enable users to code C++ or Java projects) are prohibited on most working military networks. 73. David L. Boslaugh, When Computers Went to Sea: The Digitization of the United States Navy (Los Alamitos, Calif., 2003).
648
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 649
LINDSAYK|KAmerican Military Software
electronic-system procurement offices, user innovation continued, as when members of the USS Eisenhower carrier battle group cobbled together a tactical decision-aid system during a large exercise in 1981, with some of the actual software written by sailors. JOTS (originally the Jerry O. Tuttle System after the battle-group commander, and later changed to Joint Operational Tactical System) replaced a costly Navy system that had been under development for a decade; Admiral Tuttle later commanded the Naval Space and Electronic Warfare Command (SPAWAR), completing JOTS’s transition from informal experiment to program of record.74 During the 1980s, Army geospatial software procurement suffered recurring delays and cost increases, while informal prototypes emerged through the West Point computer science department and became popular with users.75 User innovation continues in contemporary conflicts, as with an Access database that translates between NATO and Soviet artillery doctrine for U.S. personnel training Afghans on old Soviet equipment.76 During the 2003 invasion of Iraq, “the digital interface between the land and air components required tremendous human intervention to work. . . . Despite the multitude of systems, most headquarters defaulted to MS Office software to create decision products or to communicate ideas most effectively.”77 Countless operational, intelligence, logistics, and administrative tools trace a similar pattern. Not all bottom-up adaptation is positive, as the powerful flexibility of modern software packages enables personnel to construct a digital Tower of Babel on their networks, causing severe collective-action problems in knowledge management.78 User innovation with IT (for both good and ill) is, in fact, so common in military organizations that one wonders why we should be surprised when it happens. The popular image of military organizations as rigid command-and-control hierarchies obscures a great deal of creative ferment taking place within a diverse organizational milieu. While FalconView demonstrates that significant user innovation is possible in the military, it also shows how a dense bureaucratic environment 74. Norman Friedman, Seapower and Space: From the Dawn of the Missile Age to NetCentric Warfare (Annapolis, Md., 2000), 217–22, 354n. 75. Donna J. Peuquet and Todd Bacastow, “Organizational Issues in the Development of Geographical Information Systems: A Case Study of U.S. Army Topographic Information Automation,” International Journal of Geographical Information Science 5 (1991): 303–19. 76. Daryl L. Fullerton, “Back to the Basics: Training Army Artillerymen to Grow Afghan National Army Artillerymen,” Air Land Sea Bulletin, no. 3 (2008): 4–7. 77. Thomas L. Kelly and John P. Andreasen, “Joint Fires: A BCD Perspective in Operation Iraqi Freedom,” Field Artillery, November–December 2003, 20–25. 78. The author’s dissertation argues that the experience of war for most contemporary U.S. military personnel increasingly involves coping with this sort of information friction. Formal management seeks to mitigate decentralized coordination failures, even as users seek to work around centralized management failures. This recursive dynamic tends to ratchet up the complexity and friction of information systems.
649
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
T E C H N O L O G Y
JULY 2010 VOL. 51
A N D
7/15/10
10:37 AM
Page 650
C U LT U R E
shapes the process. Traditional acquisitions- and network-management regimes viewed military-user-development activity as unsustainable and illegitimate. FalconView supporters thus had to turn organizational barriers into opportunities in order to obtain funding and build institutional support. They leveraged organizational schisms between the Air Force and National Guard and between aviation- and ground-oriented communities and exploited policy loopholes. User enthusiasm for FalconView and antipathy for official systems sometimes seemed out of proportion with its mission-planning utility, yet behind the rhetorically useful morality tale there was a more complicated interdependence between official and unofficial software systems. In a series of mutual accommodations, the same officers managed both types of programs, both types shared common software components and map data, the formal programs looked to the renegades for requirements and assistance in covering shortfalls, FalconView could enjoy the luxury of ignoring some high-end computational or mission-sensitive functions, and FalconView’s management eventually took on a more bureaucratic character in order to comply with certification and testing policy. Increasing accommodation of official processes also tended to lock in FalconView’s 1990s-vintage architecture by foreclosing redesign opportunities as the mission-planning community looked to embrace JMPS. The literature on user innovation often represents it as a spontaneous, self-organizing process, but, in fact, it requires institutional management to provide recombinable tools and to solve integration problems.79 The requirement for an institutional platform for decentralized innovation is even more critical with the personnel rotation and lethal outcomes associated with military organizations. A further software-specific kind of institutional support helped foster user innovation. Software architectures feature many layers of protocols and programs that are developed, popularized, and stabilized by a sprawling ecosystem of organizations, mostly outside of the military.80 Defense contractors and military users alike purchase and recombine these rich resources in creating military-specific applications. Contemporary militaries depend on the commercial software industry to define powerful and extensible protocols, and this appears (tentatively) to empower user/innovators to a greater degree than is the case with hardware technologies. Declining costs and increasing power and flexibility, with service recruits who are more savvy in exploiting these, may help explain why military users have 79. On the conditions for efficient open-source production, see Benkler (n. 5 above); Carliss Baldwin and Eric von Hippel, “Modeling a Paradigm Shift: From Producer Innovation to User and Open Collaborative Innovation,” Harvard Business School Working Paper no. 10-038, November 2009. 80. David G. Messerschmitt and Clemens Szyperski, Software Ecosystem: Understanding an Indispensable Technology and Industry (Cambridge, Mass., 2003).
650
04_51.3lindsay 619–51:03_49.3dobraszczyk 568–
7/15/10
10:37 AM
Page 651
LINDSAYK|KAmerican Military Software
been able to consistently stay ahead of electronic-systems program offices, even as the latter have grown considerably. For every story of users developing innovative solutions and building institutional support, however, there are countless others of inventions that either withered away when their champions transferred or else crashed when they crossed into some adverse regulatory jurisdiction. I personally experienced this on active duty in 2000, when I teamed up with the officer who wrote Quiver, the carrier-based targeting application mentioned above. In a familiar pattern, Quiver became popular with and responsive to intelligence personnel and aircrew, but it was opposed by a Navy program office, SPAWAR, because it competed with a cumbersome Unix system. Despite thousands of lines of Visual Basic code and operating-system calls, Quiver was still nominally “just an Access database,” so SPAWAR legally could not prevent its use. Ultimately, SPAWAR decided to incorporate Quiver’s features into a future version of its own system, but it never really followed through on this. Unlike FalconView, Quiver never secured advocates with staying power who were willing to work both formal and informal channels to protect it. An underground version of Quiver lived on under a different name in the Naval Special Warfare community, evolving on a daily basis to support SEAL commando operations during the 2003 invasion of Iraq, yet this also moved into programmatic channels, this time in U.S. Special Operations Command, and withered away. Informal user innovation occurs almost spontaneously in military units, but the development of staying power and a robust user community requires the consent and support of formal organizational authority. FalconView and Quiver are, respectively, stories of success and failure in heterogeneous engineering. In military organizations, the distinction between user innovation and formal acquisition has been wielded rhetorically in procurement battles, but it is something of a false dichotomy. Both modes of production have strengths and weaknesses. Many user projects are indeed amateurish, unstable, nonscalable, and unsupportable; program offices can usefully channel resources and provide continuity across personnel rotations. Effective software development involves a balancing act between them, even though there is certainly room for institutional reform to better encourage and support open user innovation.81 Automated mission planning has been from its inception a chaotic hybrid of operator initiative and formal bureaucracy, and it is likely to change only by increasing in complexity.
81. Gompert, Barry, and Andreassen (n. 69 above) discuss policy reforms, including greater reliance on open architectures and the cultivation of technical skills in the workforce, but overemphasize centralized “joint” management of what is an inherently decentralized process.
651
