NASA Open Source Summit

Solutions to Issue #3: What are the barriers to involvement from the open source community?

Instructions

  • 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

Notes

  • 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

As a government agency bound by large amounts of regulation and bureaucracy, what are the boundaries of community contribution? For example, could a NASA-originated codebase ever be handed over to a non-NASA community member for long-term support and maintenance? Is this legal? If it is legal, would it be practical?”

Factors influencing Open Source developer involvement with NASA

        PRO:         NASA works on exciting projects

                Offering people the chance to collaborate can generate a wider community

                Potential to find dynamic leadership outside the NASA agency

                While NASA can’t endorse products, an author can say “I built this for NASA”

                        

        CON:         Bureaucratic processes and delays

                Administrative burden of reviewing contributions, long-term stewardship

                NASA is typically a consumer, not a producer of OSS

                No cohesive resource for NASA OSS, “finished” or under-development, etc.

Proposed Solution #0: Have NASA engage openly with the OSS community

Using and finding engagement in OSS communities is a great way of driving expertise inward:

Proposed Solution #1:  Hire external OSS developers to modify their existing code to suit NASA’s needs

Proposed Solution #2: Build a cohesive resource for all NASA software, OSS or otherwise

Public co-development efforts.

Proposed Solution #3: Use Existing Open-Source Tools

Using proprietary or internal tools in the development of open source software can limit the number of developers who can participate.

Proposed Solution #4: Make mailing lists and internal communication public

A big part of the development of open source software is having access to communication related to its development.

Proposed Solution #5: Describe how developers can contribute (and follow through)

Each project should create a document (public facing webpage) that describes the process of contributing changes to open source projects.

Proposed Solution #6: Have a single Contributor License agreement the way that Fedora, Google, FSF, and other organizations do. That would simplify collaboration and leave NASA in control.