NASA Open Source Summit
Solutions to Issue #6: Limitations on Contributing to External Open Source Projects
- This is the place for all summit participants to propose and discuss solutions to the one issue listed above.
- Feel free to build on rather than delete what others are saying.
- Format for Breakout Sessions:
- Introduce each other with quick, 1-sentence bios
- Describe the issue to get everyone on the same page
- Brainstorm solutions
- Go in-depth with one solution at a time
- Record notes or your discussions will not impact policy
- The full list of issues is here.
- If you opened this in Edit mode and it’s now Read Only, there are probably too many editors right now (max is 50). In that case, use this supplemental page to capture your solutions to this issue. Notes from all supplemental pages will be moved to the main page for that issue after the summit.
Description of the issue
"Open Source is a tool by which to accomplish NASA's mission"
- How can we increase awareness of what NASA developers (civil servants, contractors, grantees, etc) can/cannot already do to contribute to external (non-NASA) development projects?
- What are the differences between contributing minimal / incremental changes / bug fixes vs. new features (as per NPR 2210.01)? And, who makes this decision?
- What lessons learned / best practices can be drawn from current NASA open source development “pathfinder” projects (and can these be applied “generally”)?
- What is (should be) the policy of NASA workforce (civil servants, contractors, etc.) contributing in their off-hours? How do you handle / treat situations where people work off-hours on things that derive directly, or are inspired, by what they worked on during the day (during official hours)?
- Any new policy needs to be written as simple as possible, so that it is understandable!
- This sort of thing needs to take into account things like Fair Labor Standards Act (non-exempt people have to be compensated for “work”) and “shop-rights” to inventions, etc. Someone may be perfectly happy toiling at home on their own time, but their employer may think otherwise (esp for NASA contractors).
Proposed Solution #1: Clarify existing policy and/or restrictions on contributing to open source projects
Given the issues stated in the description and a general sense of confusion, and a prevailing attitude of “asking forgiveness is easier than asking permission”, NASA needs to clarify what the existing policy means for software developers who are--or wish to be--contributing to open source software currently. Publish this information prominently online and make it widely available. Simple, unambiguous language without a lot of caveats is critical.
Proposed Solution #2: Agency-wide blanket authorization covering contributions to external Open Source Software
Moving forward from solution #1, the Agency could create a blanket agreement permitting contributions to open source projects. This would be greatly preferable to having one-off contributor agreements for individual projects/contributions.
- This may require an incremental implementation given current contract language, contractor agreements, etc.