1. Open Source at NASA
A practitioner’s perspective …
Terry Fong
Intelligent Robotics Group
NASA Ames Research Center
terry.fong@nasa.gov
irg.arc.nasa.gov
Open Source at NASA – A practitioner’s perspective 1

2. Why is Open Source good for NASA?
More transparent
• Enables the public to better understand what software NASA needs to
fulfill its mission & activities
• Enables the public to better understand how taxpayer dollars are
being used
More participatory
• Enables the public to assist in NASA software development
• Enables students, scientists, the general public, etc. to contribute their
expertise and skills
More collaborative
• Enables NASA to transfer technology efficiently and rapidly
• Enables NASA to more easily partner and work with others
Open Source at NASA – A practitioner’s perspective 2

3. IRG Open Source Software
Vision
GeoCam
Workbench
Vehicle
RoverSW
Detection
Neo Geography
RAPID
Toolkit
Open Source at NASA – A practitioner’s perspective 3

4. Vision Workbench (2006)
Overview
• Modular, extensible, C++ computer vision framework
• Rapid development and flexible, multi-platform (Linux, OS-X, Win32)
• Supports science analysis, robot perception, image stitching, etc.
Open Source at NASA – A practitioner’s perspective 4

5. Vision Workbench (2006)
Developers
• Government: NASA Ames Intelligent Systems Division
• Prime Contractor: QSS Group, Inc.
• University: Carnegie Mellon / Silicon Valley
• Non-Profit: Research Institute for Advanced Computer Science
Key points
• Software library
(continuous release / hosted on GitHub)
• Rapid, on-going development
• Supports numerous collaborations (funded & informal), interns, etc.
• Requires several external, open source libraries
(OS licenses: Boost, MIT, BSD-like)
• Enhanced functionality with additional open source libraries
(OS licenses: zlib/png, SGI, GPL2, etc.)
Open Source at NASA – A practitioner’s perspective 5

6. GeoCam (2007)
Open Source at NASA – A practitioner’s perspective 6

7. GeoCam (2007)
Developers
• Government: NASA Ames Intelligent Systems Division
• University: Carnegie Mellon / Silicon Valley
• Internship program: Education Associates
Key points
• Software suite: smartphone apps, Web UI’s, server software, tools
(continuous release / hosted on GitHub)
• Rapid, on-going development
• Supports developers, first responders, citizen groups, etc.
• Requires several external, open source libraries
(OS licenses: BSD, BSD-like, MIT, NOSA)
• Enhanced functionality with additional open source libraries
(OS licenses: Apache 2, BSD-like, LGPL3, MIT)
Open Source at NASA – A practitioner’s perspective 7

8. Neo-Geography Toolkit (2009)
Overview
• Tools for geospatial data processing, automated map making, etc.
• Supports large-scale data (10-100 TB), cloud & super computing
• Import / export to geo-browsers & OGC standards (Web services)
Open Source at NASA – A practitioner’s perspective 8

9. NGT for “Moon / Mars in Google Earth”
Open Source at NASA – A practitioner’s perspective 9

10. Neo-Geography Toolkit (2009)
Developers
• Government: NASA Ames Intelligent Systems Division
• Prime Contractor: SGT, Inc.
• University: Carnegie Mellon / Silicon Valley
• Internship program: Education Associates
Key points
• Software suite: libraries, processing pipelines & tools
(continuous release / hosted on GitHub)
• Rapid, on-going development
• Supports numerous collaborations (funded & informal), interns, etc.
• Requires several external, open source libraries
(OS licenses: Apache 2, BSD, GPL 3, ISIS 3, LGPL 2.1, MIT, NOSA)
Open Source at NASA – A practitioner’s perspective 10

11. RAPID (2009)
Overview
• “Robot Application Programming Interface Delegate”
• Standardized programming interface (API) for robot software
• Messaging & data distribution for NASA robots & user interfaces
RAPID RAPID RAPID
API
API
Robot
Workbench Middleware Bridge
Open Source at NASA – A practitioner’s perspective 11

12. RAPID (2009)
Developers
• Government: NASA Ames (Code TI) & Johnson (Code ER)
• Prime Contractor: SGT, Inc.
• Subcontractor: TRACLabs, Inc.
• Non-Profit: Research Institute for Advanced Computer Science
Key points
• Software suite: libraries, user interface, reference implementation
(hosted on SourceForge)
• Facilitates basic research & collaboration worldwide (does not require
SUA / other agreement that would be extremely difficult to execute)
• De-facto NASA robotics open standard
Open Source at NASA – A practitioner’s perspective 12

13. RoverSW (2010)
Overview
• Service-oriented robotics software architecture
• Designed for NASA-relevant research robots
• Software framework + composable modules
Open Source at NASA – A practitioner’s perspective 13

14. RoverSW on the K10 Planetary Rover
VIDEO
Open Source at NASA – A practitioner’s perspective 14

15. RoverSW (2010)
Developers
• Government: NASA Ames Intelligent Systems Division
• Prime Contractor: SGT, Inc.
• University: Carnegie Mellon / Silicon Valley
• Non-Profit: Research Institute for Advanced Computer Science
Key points
• Software library
• Facilitates collaboration with others worldwide & interns
• Enables third-parties (e.g., small businesses) to test without SUA
• Requires several external, open source libraries
(OS licenses: BSD, BSD-like, LGPL 2.1 & 3, MIT, NOSA)
• Enhanced functionality with additional open source libraries
(OS licenses: BSD-like, NOSA)
Open Source at NASA – A practitioner’s perspective 15

16. NTL “Vehicle Detection” (2011)
NASA Tournament Labs (NTL)
• Collaboration between NASA, Harvard Business School & TopCoder
• Crowd-source NASA software through programming contests
• Winning solutions will be released as NASA open source
Vehicle Detection Challenge
• First contest: three-weeks (Jan 28-Feb 18, 2011)
• Automatically classify aerial images that contain a vehicle
• 139 competitors from around the world
http://community.topcoder.com/ntl
Open Source at NASA – A practitioner’s perspective 16

17. IRG Open Source Software
Common characteristics
• Developed by multi-org workforce, not just civil servants
➯ Have to consider contract clauses & other concerns (Bahy-Dole rights)
• On-going, rapid development
➯ Intermittent point releases are not appropriate
• Intended to support & facilitate collaboration
➯ Must be easy to adopt (e.g., licensing should not get in the way !)
➯ Must be easy to access (e.g., hosted on popular sites, not NASA site !)
• Wide range of users (individuals, companies, non-profits, etc.)
➯ Barrier to entry must be as low as possible (licensing, access, paperwork)
• Built upon other open source libraries
➯ May restrict how software is released or what license is used
Open Source at NASA – A practitioner’s perspective 17

18. Open Source Release Process*
* From a developer’s perspective
Fill-out release forms Submit Release meeting Release approved
 NF1679 (invention disclosure) release  SW briefing
DEVELOPER
 Software release request forms  Q&A
 List of external libraries
(and their licenses)
 NPR 7150.2 matrix
Month 1 2 3 4 5 •••
AUTHORITY
SOFTWARE
Initial reviews Final reviews
RELEASE
 Export review
 External library licenses
 Collect copyright assignments
 etc.
Open Source at NASA – A practitioner’s perspective 18

19. Lessons Learned: Potential Bottlenecks
Copyright assignment
• Multi-org workforce: civil servants, contractors, interns, universities
• Can take long if non-NASA organizations unfamiliar with process
Export control
• Can take long if software is difficult to categorize
• Can take long if software has possible ITAR characteristics
External licenses
• Must carefully distinguish between "required" and "optional”
• Review can take long (no central database of reviewed licenses)
508 compliance
• NASA workforce (especially researchers) not trained for ensuring this
SE compliance
• Open source software is not (usually) designed with this in mind
(can be at odds with agile development methods …)
Open Source at NASA – A practitioner’s perspective 19

20. Towards Open Source Development
What makes NASA different ?
• Taxpayer-funded federal institution
• Culture (engineering driven, minimize risk, etc.)
• Mixed workforce (civil servants, contractors, etc.)
• Unique, highly-specialized software
• Non-competition with commercial sector
Open Source at NASA – A practitioner’s perspective 20

21. Development Use Cases
Point release
• Infrequent release of completed software (traditional model)
• Internal development by NASA workforce
Continuous release
• On-going, frequent release of software under development
• Done only within well-defined bounds and with periodic review
• Internal development by NASA workforce
Community development
• On-going, joint development to common code base
• NASA workforce (official duties) & volunteers
Crowd-sourcing
• Rapid development at hackathons
• Result of programming contests (e.g., NASA Tournament Labs)
• May / may not have NASA workforce involved (official duties)
Open Source at NASA – A practitioner’s perspective 21

22. (Some) Issues
How can we improve the NASA OS release process?
• How to make it faster & more efficient?
• How to make it more consistent across the agency?
• How to make it easier for practitioners?
How can we improve licensing?
• Under what circumstances is NOSA (still) useful?
• What is needed for NASA to be able to use a suite of licenses
(Apache 2, GPL 3, etc.) for release?
How can NASA engage in community development?
• What is needed for third-party contributions?
• What is needed for crowd-sourcing?
• What can we do in the near-term?
Open Source at NASA – A practitioner’s perspective 22

23. Questions?
Intelligent Robotics Group
Intelligent Systems Division
NASA Ames Research Center
irg.arc.nasa.gov
Open Source at NASA – A practitioner’s perspective 23