1 Open Source at NASA – A practitioner’s perspective irg.arc.nasa.gov
Terry Fong Intelligent Robotics Group
NASA Ames Research Center [email protected]
Open Source at NASA A practitioner’s perspective …
2 Open Source at NASA – A practitioner’s perspective
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
3 Open Source at NASA – A practitioner’s perspective
IRG Open Source Software
Vision Workbench
RoverSW
Neo Geography Toolkit
GeoCam
Vehicle Detection
RAPID
4 Open Source at NASA – A practitioner’s perspective
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.
5 Open Source at NASA – A practitioner’s perspective
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.)
6 Open Source at NASA – A practitioner’s perspective
GeoCam (2007)
7 Open Source at NASA – A practitioner’s perspective
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)
8 Open Source at NASA – A practitioner’s perspective
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)
9 Open Source at NASA – A practitioner’s perspective
NGT for “Moon / Mars in Google Earth”
10 Open Source at NASA – A practitioner’s perspective
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)
11 Open Source at NASA – A practitioner’s perspective
RAPID (2009)
Overview • “Robot Application Programming Interface Delegate” • Standardized programming interface (API) for robot software • Messaging & data distribution for NASA robots & user interfaces
RAPID Workbench Robot RAPID
Bridge RAPID
Middleware
API A
PI
12 Open Source at NASA – A practitioner’s perspective
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
13 Open Source at NASA – A practitioner’s perspective
RoverSW (2010)
Overview • Service-oriented robotics software architecture • Designed for NASA-relevant research robots • Software framework + composable modules
14 Open Source at NASA – A practitioner’s perspective
RoverSW on the K10 Planetary Rover
VIDEO
15 Open Source at NASA – A practitioner’s perspective
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)
16 Open Source at NASA – A practitioner’s perspective
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
17 Open Source at NASA – A practitioner’s perspective
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
18 Open Source at NASA – A practitioner’s perspective
Open Source Release Process*
Month 1 2 3 4 5 • • •
Fill-out release forms NF1679 (invention disclosure) Software release request List of external libraries
(and their licenses) NPR 7150.2 matrix
Submit release forms
Initial reviews Export review External library licenses Collect copyright assignments etc.
Final reviews
Release approved Release meeting SW briefing Q&A
DEV
ELO
PER
SOFT
WA
RE
REL
EASE
A
UTH
OR
ITY
* From a developer’s perspective
19 Open Source at NASA – A practitioner’s perspective
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 …)
20 Open Source at NASA – A practitioner’s perspective
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
21 Open Source at NASA – A practitioner’s perspective
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)
22 Open Source at NASA – A practitioner’s perspective
(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?
23 Open Source at NASA – A practitioner’s perspective
Questions?
Intelligent Robotics Group Intelligent Systems Division
NASA Ames Research Center
irg.arc.nasa.gov