NASA needs open source framework

Despite some well-known open source projects undertaken by NASA, the space agency lacks a framework for understanding the use and production of open source software at the agency level, say a clutch of computer programmers and technologists.

In an article published earlier this spring by IT Professional, information technology professionals led by Chris Mattmann, a senior computer scientist at the NASA Jet Propulsion Laboratory, say that when they tried to open source a JPL project, they "entered uncharted territory."

Among the issues they encountered was which license to use and where to distribute the code. Article authors wanted to use an Apache license and put the code on the Apache Software Foundation's hosting site, but they had to resolve issues such as the existence of a NASA-specific license and another license created by the JPL jointly with the California Institute of Technology, plus the fact that JPL also had its own code hosting site.

Navigating through such complicating factors requires three considerations: licensing, redistribution and contributions back into the code, authors say.

The type of license chosen has an impact on whether the code can be commercially developed, for example. The GNU Public License, authors note, requires commercially-developed modifications to open source code to remain open source, whereas the Apache license is "more commercially friendly, giving private companies quite a bit of leeway."

Redistribution once was as simple as setting up a FTP or HTTP server, authors also say, but these days distribution requires features such as discussion forums, issue tracking, and even build, testing and integration tools. NASA can elect to run such infrastructure itself, or it can avail itself of public site such as GitHub. If choosing an outside site to redistribute code, however, it must decide between two major models of redistribution–the "help desk model" implicitly endorsed by Google Code and Sourceforge, or the "community building model" of Apache, GitHub and Eclipse.

Under the former model, "software originators release it as open source yet remain the final arbiters of what comprises the source code." The community model requires software originators to "engage the collective in an in-depth way, forming a virtual organization," authors state.

The type of redistribution model chosen will in turn affect the contribution model, they add. "For the help-desk model, code contributions might not occur at all, or only as a result of bug reports. Patches, if they're accepted, are often given intense scrutiny before they're committed to the code corpus."

Here again, they identify two overarching models, that of "review-then-commit" and "commit-then-review."  

The first relies heavily on an issue tracking system and "helps reduce the ego tied to individual contributor." The second requires a less central role for an issue tracker--because there are fewer patches to manage--"but automated testing is far more vital to ensure a complete, stable, runnable system."

For more:
- go to the article page

Related Articles:
NASA looks to lower open source licensing barriers 
SASC Accumulo language pro-open source, say proponents 
Ozone Widget Framework to be on GitHub by Sept. 30
Many obstacles to open source in government