Notes

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?”

Open Source developers should not be considered free labor

You need to have a mutual benefit in order for people to have motivation to contribute

Project/mission needs must be balanced with community needs.

License compatibility issues are a barrier to open contribution and distribution of code

If NASA has the NOSA, but project contributors take patches from the community without requiring copyright assignment paperwork, it short-circuits the intention of the NOSA. People are going to route around the problem of overly restrictive licenses in practice.

People need to learn about the code base before they can contribute.

Opening things up early and accepting contributions would be better than trying to open things up later.

NASA as an agency has to come to terms with “letting go” of a project and turning it over to the community in order for the community to thrive.

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”

Need to incentivize (or at least explicitly encourage) involvement with open source communities

NASA employees are already contributing patches; for example::

RSA token auth for Django and Trac

Section 508 fixes for Django templates

Submitting patches is the first step, but the next logical is to have direct commit access -- contributor access -- to these projects. And these are usually granted by the project owner after successful demonstration of clue and contribution. It’s how open source grows community.

But are we allowedto do this? OMG, a nasa.gov address on a code commit message!? Won’t that be seen as tacit endorsement of a certain technology or product? Isn’t that against policy, almost as bad as a Hatch Act violation? Policy is unclear on this.

Next step would be to host a project we own on a public repo, like Github, BitBucket, LaunchPad, SourceForge, or other repo. We have done two public-facing websites based on CMSes (Plone, Django+FeinCMS); why not host these in the public sphere? why not share our tech, improvements, and reap the benefits of others’ contributions?

Barriers are lower than they were 15 years ago

Apache WebServers and MySQL/PostgreSQL databases are easy now.

Incorporating newer software requires proving license clarity

Starting new projects we can begin libraries or modules.

I (shentonfreude) consult for other clients, outside the goverment, and we contribute heavily to the code of the projects we use. At conferences, we will stay after the formal sessions and “sprint” for several days, writing tests or code or docs with the other developers working on the project, in the same physical space. This is incredibly productive. And it has to be done in an open way, open source, public repositories and bug trackers and such.

Use social approaches, with the element of discoverability, for non-sensitive efforts

How? This is easier said then done.

Try getting agreement amongst NASA administrators

It wouldn’t be hard to do, specially if good tools and standards are in use

Cross-platform, thin client emphasis would help

Distributive repository use is a good mechanism to accomplish shared development

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.

Barriers are lower than they were 15 years ago

Apache WebServers and MySQL databases are easy now.

Incorporating newer software requires proving license clarity

Starting new projects

Software tools need to encourage open source participation. For example, using Subversion to manage source control is a barrier to entry because an open source developer cannot commit to a Subversion repository without having commit access. Using a distributed version control system (DVCS) such as Git, Bazaar, or Mercurial allows developers to freely commit to his or her own copy of an open source project.

Using tools that are familiar to open source developers can lower the learning curve

Maven for Java projects

Ant + Ivy can perform similar dependency management as Maven with less complexity

Autotools, GNU make, … for C/C++ projects

Also provide Visual Studio solutions (SLNs) for Windows users.

CMake solves the multiplatform build issue for C/C++ based projects to a great extent, it can generate both visual studio solutions and makefiles. A lot of OSS C/C++ projects use it.

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.

Use separate, public mailing lists for each open source project at NASA

GNU Mailman or similar mailing list managers are widely used in the open source community

Allow anyone to subscribe and post a message

Set up Wikis and document repositories to host design documents, requirement analyses, etc.

Don’t let documentation and public communication “stagnate” if a project is active.