DevSummit07:Open-Source To Transform The Way Government Does Business: The Case of NASA
Facilitated by Andrew Hoppin, NASA Ames Research Center
NASA has its own open-source software license and several prominent open-source software projects such as Worldwind. However, even NASA's license is onorous to use and results in vast amounts of code that could benefit the public remaining behind closed doors. Similarly, NASA software engineers typically do not make great use of existing open-source software and build redundant code from scratch.
Andrew Hoppin will share the story of NASA CoLab and Cosmoscode.org, new NASA projects that aim to transform this status quo by building a "sourceforge for space" and a space open-source software development community.
Early surprising results include the fact that the biggest impact of Cosmoscode may not have anything to do with the code itself- it may, in fact, be cultural.
How then can open-source standards, licenses, community, and culture be used as positive change agents for the largest non-profit organization in the world-- the US Government?
Andrew runs the session. A couple of friends of his were brought in to work at NASA in Mountain View. They are progressive and reform-minded, but were butting up against some political issues with instituting change at NASA. Andrew's goal is to make NASA more open and transparent, and then government in general.
How to get progressives to care about NASA -- be progressive (in a non-political sense). He started an organization to try to get NASA to open up their gates. NASA has a lot of career people who are not likely to be fired. They have a lot of data on a wide variety of issue. They also have a lot of facilities and other resources. The Bay Area entrepreneurial community has a lot of passion and a lot of knowledge about technology, as well as a progressive mentality. CoLab tries to bring together people from both worlds to work together, to increase the flow of ideas back and forth between NASA and the community.
Try to get open source software to be used -- NASA projects to do their code in open source, and then release the code to help the community, as well as using the outside community to help with what is out there to help NASA accomplish their goal.
Some poeple at NASA are scared -- of looking bad. There is a risk-adverse culture. They have to be risk-adverse for their projects, since there are lives at stake. Hwoever, this mindset can pervade their entire way of life. How to cause change? Do concrete work to prove that the risk-level is low, or not any greater than it currently is.
One tangible way to do this -- help get OSS to get support with their projects. NASA doens't like to use software in which you can't pay for support, so this is low-hanging fruit. Also, it helps to work with Google. Google brings credibility.
Another issue: security and export control. Its a big headache, so getting the code released is often not done for this reason, even though a large majority of the code is not relevant to security-related issues. The best way to help this is to build the community. The larger the community, the less scary this becomes, and the more existing support is available.
Is top-down or bottom-up the best way to go. Having the support of the head guy is certainly important, and a big step, but building up from the grassroots is also important, and perhaps more important. The rank-and-file typically realize that initiatives such as this can come and go, so the best way is to go along with it, but as minimally as possible so that they can continue to do what they've always been doing, until the winds change again. You have to convince them that it will make their lives easier in order to affect real change.