JPL Engineer: Open Source Helps Fix Govt. Procurement

In a published version of his 2006 presentation to a US government system administrators' conference, Jet Propulsion Laboratory software engineer D. J. Byrne writes for CIO Magazine that the cultural synergies between open source software developers and space technology engineers have made it possible for JPL to execute complex software projects that would have consumed considerable engineering time and taxpayer expense if it had to be procured from a manufacturer.

"Planets move; launch windows don't," Byrne writes. "The Spirit and Opportunity Mars Rovers had to go in the summer of 2003 or never. They are simply too massive to throw that far, for that budget, unless the planets aligned just so. (Mars and Earth line up every 26 months or so, but in 2003 they were unusually close together.) Procurement cycles for spending lots of government money can be months long, and they can dominate critical paths...Quickly obtainable FOSS relieves that pressure and gives us some elbow room. Bug fix turnaround times can be critical. If we can fix the source code ourselves, we can keep a whole team moving forward."

The procurement problem, Byrne goes on, has led to a situation in which the entire space program, with its worldwide resources, must purchase processing power a la carte. As a result, JPL ends up with a multifarious variety of processing systems upon which software must not only be made functional, but standardized as well.

Assuming procuring their services were not a problem, not only would individual vendors be incapable of achieving this goal, Byrne implies, they may be unwilling, especially in situations where one vendor ends up essentially providing support for the products or platforms of another.

Byrne was involved in a 1994 JPL project to move legacy code written in PL/1 from VMS-based servers to a Sun workstation environment. There, he may have seen the first practical implications of designing destination platforms in a platform-agnostic fashion, especially with the selection of an implementation of the Informix RDBMS that, at that time, was relatively standards compliant. Informix is now part of the IBM product line.

In researching Byrne's reasons for open source's adoption by JPL, the reasons have less to do with Linux than you might think. Although Linux is expected to be adopted by more than 15% of US government enterprise servers by 2009, by IDC's projection, JPL servers are reportedly split among Red Hat Enterprise Linux for e-mail and messaging, Mandriva Linux for desktop applications, and Solaris for science and engineering applications.

In 2006, JPL admin Gary Brack stated that while users there would prefer to run Linux, "We don't run our main servers on Linux, because there are too many flaws in main Linux kernel."

So it's not the need for Linux which drives open source adoption at JPL so much as the need for a reliable, capable programmer community.

"The best way to shake out software bugs is to have lots of testers independent of development try it out in unfamiliar environments and in ways unforeseen," Byrne writes for CIO, "which pretty much describes the FOSS user community. By the time something's on its 2.1 release, it's usually been beaten up pretty thoroughly. And the beauty is, you have full disclosure about what broke in the 1.0 release, under what conditions, how it was fixed and what tests prove it's gone."