Open-Source Software and Its Role in Space Exploration

A software developer from JPL explains the reasons that NASA has embraced free and open source software in its application development process. Because, in a Mars launch, the term "mission critical" has a literal meaning.

1 2 Page 2
Page 2 of 2

We're hit hard by International Traffic in Arms Regulations (ITAR), Export Administration Regulations (EAR) and intellectual property concerns. Even innocuous software has to be screened for release, and is slow to share with an industrial or foreign partner who needs the same tool (possibly ported to their platform).

"Free as in free speech" can help; here's an example. The thing about a Deep Space Network is, the Earth rotates. The big antennas are spaced out (if you'll forgive the pun) around the globe in California, Spain and Australia. Once, it was time to upgrade some encryption software (ssh), and we discovered that it couldn't be exported as binaries from the United States—which is funny, because the source code came from Finland. That gave us the solution: While sitting in California, we logged in to Australia and Spain, downloaded the Finnish code and built it there. "Finnishing" in a few minutes what would have taken weeks of paperwork.

Recently, we've experimented with auto-generation of Electra source code from UML state diagrams. It may or may not work out well enough to fly the code; we'll see. It's only because of the openness of the architecture and tools that we could even contemplate this radical modification to development.

7) Collaborative Software

With specialized instruments and parts coming from all over the globe, teleconferences and videoconferences are essential. There are a lot of really bad services out there, and the consistent failing theme is when the server expects your desktop to have some single-vendor thing that you've never heard of and shouldn't need to know about.

Why is it college kids can talk to their friends using every platform made, and we can't? Because they require interoperability from the beginning.

8) Confidence in the Future

At the risk of harping on the portability and openness points above, software projects have very long lives, and the selection process weighs in our confidence that it has a future. Developers like me are comforted by having the source code in hand as a risk mitigator.

Managers, however, prefer support contracts for the same reason: to get a commitment that someone is maintaining expertise in the product. We've had good success with companies whose core business is supporting FOSS projects. Large companies are seeing the same advantage, and have opened their formerly proprietary source code and funded organizations and universities that maintain them. This relatively new phenomenon is working well.

9) Security

It's not like any launch codes are on my laptop, but I still don't want some cracker breaking into my machine. I want to know the software I'm running is solid, to be told at once an issue was discovered and to have a patch immediately. I do not want a smiling happy representative telling me everything is fine, ignore that funny sound, and I can upgrade to the new version when it comes out next year. 'Nuff said?

I read the weekly security announcements from the SANS Institute (SysAdmin, Audit, Network, Security) and pay attention to whether announced vulnerabilities have a fix available or whether it's "being investigated by the vendor."

10) The Cost Question

"Free as in free beer" can matter for small tasks or where labor is cheap (graduate students work for ramen noodles), but mostly the price isn't a big factor for using FOSS. As CIOs know well, Total Cost of Ownership is dominated by learning curves, testing cycles, reviews, writing procedures, etc. So the cost savings is less in procurement than in labor, and in the way that openness saves time performing other activities.

Freedom Isn't Free

Free speech doesn't mean anyone has to listen. No one is entitled to a forum for their opinions, and freedom of the press belongs to them as owns the presses. Or in this case, the website. If you want to be heard, you have to convince your audience to invest their attention.

Perhaps you're a member of an open-source community that hopes we'll adopt your software. I can get my hands on all kinds of FOSS; what I download, build and fly is another matter. I'm always drawn to the products that include automated regression test suites. If the documentation includes a reference guide, user guide and maybe a QuickStart, it reflects an empathy for solving my problems.

We must meet very strict software quality-assurance and dissemination requirements. Here are some of the guidelines in NASA's Software Policy (NPD 2820.1C):

  • Require software providers (includes internal NASA providers) to have proven organizational capabilities and experience to deliver quality software on time, within budget and within technical acceptability.
  • Require software providers to develop a plan to manage software throughout the program/project lifecycle. This plan shall include the collection and reporting of actual software related expenditures at the project level by lifecycle phases.
  • Release software in accordance with NPR 2210.1, External Release of NASA Software, consistent with law and applicable agreements, for commercial, industrial, educational and governmental purposes.

You can find lots of other good stuff in that document by searching for "software."

The point is that "assurance" means "do more than write solid code." I need a story to go with it. Working demos go far, but not the last mile. These are the infamous paper trails that slow commercial projects. At one extreme is to incorporate your "development organization" and pay for an external audit of your processes. My personal jury is still out on this; I see lots of projects where the extra effort doesn't actually raise quality (like most FISMA reporting) and it's a waste. On the other hand, my current project is being appraised for Capability Maturity Model Integration (CMMI) level 3, and we're actually changing how we do things, in a good way. The difference is made, naturally, by the quality of management attention.

Challenges Enough for Everybody

I hope this conveyed the impression that FOSS plays a significant role in space exploration. The more FOSS code we send to Mars, the more time I can spend working on different hard things.

FOSS's strength is in the people, the community. Events like the International Conference on Open Source Systems build that strength. I'm honored to work with these folks, and I greatly appreciate what they do to help us all.

This article was adapted from an invited talk at the USENIX LISA 2006 conference in Washington, D.C.

This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.

Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer or otherwise, does not constitute or imply its endorsement by the United States Government or the Jet Propulsion Laboratory, California Institute of Technology.

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Download CIO's Winter 2021 digital issue: Supercharging IT innovation