Software increasingly underpins science. It connects the data, hardware, networks, and people to enable the analysis leading to new knowledge and discovery. Open source software (OSS) can be a major facilitator of this process by helping create an environment for collaboration and transparency. This can provide efficiencies, aid in scientific reproducibility, and help NASA advance its mission. Movement toward more OSS development will foster a norm of openness, collaboration, and sharing, but it is not a straightforward process. NASA will need to balance the different goals in Chapter 1 of enabling innovation and discovery, facilitating scientific reproducibility, encouraging collaboration, ensuring security, and benefiting society when developing policies that are as open as possible and only as closed as necessary.
The basic act of releasing software as open source is not difficult (see Figure 4.2), but it can evoke some complex considerations, including complying with institutional and contractual intellectual property guidance, determining the appropriate license to apply, and ensuring that export-controlled information is not included in the software. Furthermore, making software open is insufficient by itself in ensuring scientific reproducibility or realizing any of NASA’s goals. Poorly documented software and associated data files, even if shared publicly, will likely result in an inability to replicate research. Historically, software funding and support has not been well coordinated across NASA’s Science Mission Directorate (SMD). Understandably, the focus is often on creating new software to solve a scientific problem rather than evolution, maintenance, and sharing of existing software. Yet, to make open software truly useful requires a coordinated, end-to-end development approach supported by adequate infrastructure, community practices, and education over the long term. Any open source policy will need to address these issues. Open source can provide great benefits, but there will be transition and maintenance costs requiring a careful balance of trade-offs and active engagement by program managers. The committee’s nine recommendations regarding an OSS policy are restated below.
Recommendation: NASA Science Mission Directorate should explicitly recognize the scientific value of open source software and incentivize its development and support, with the goal that open source science software becomes routine scientific practice.
Recommendation: NASA Science Mission Directorate should initiate and sponsor programs to educate and train researchers in open source best practices. Topics could include, but are not limited to export controls, licensing and intellectual property, workflows, and software development. These resources
could be made available to the community via in-person trainings as well as webpages, screencasts, and webinars.
Recommendation: Any open source software policy that NASA Science Mission Directorate develops should not impose an undue burden on researchers; therefore, any policy should be as simple as possible, and any mandates should be fully funded.
Recommendation: NASA Science Mission Directorate should support the infrastructure, governance, and maintenance of a healthy open source community, taking advantage of existing community resources to the greatest extent possible.
Recommendation: NASA Science Mission Directorate should support open source community-developed libraries that advance NASA science.
Recommendation: NASA Science Mission Directorate should foster career credit for scientific software development by encouraging publications, citations, and other recognition of software created as part of NASA-funded research.
Recommendation: NASA Science Mission Directorate should consider a variety of policy options depending on discipline and software type and transition to greater openness over time.
Recommendation: NASA Science Mission Directorate should encourage the use of standard open source licenses, but not mandate a particular license. Nonstandard licenses should be justified in the software management plan.
Recommendation: NASA Science Mission Directorate should develop internal policies and external legal language conducive to the swift release of open source scientific software and the full participation of NASA employees in internal and external open source projects, without jeopardizing national security or incurring legal liability.
It is important to note that most of these recommendations apply regardless of whether NASA SMD explicitly requires OSS. The cultural shift toward greater openness is much more challenging than the actual policy development. Implementation of any new policy can result in community resistance, where scientists apply to other agencies for funding, attempt to circumvent the spirit of the policy, or ask for special exemptions. This can result in decreased productivity and costly missteps. There are numerous studies in behavioral science on how organizations can best implement change and companies that specialize in consulting on these issues. There are several key elements for reducing the cost and risk associated with implementing new policies, which the committee’s recommendations address, as follows:
- Communicate goals to the community and emphasize the benefits.
- Identify and empower influential individuals as groundbreakers.
- Anticipate and try to mitigate obstacles.
- Provide education, tools, and training to ease adoption.
- Highlight successes.
- Implement change incrementally and respond and adapt to feedback.
There are two communities that need to be considered in this process: the program managers who will implement the policy and the research community the policies will impact. Engaging and educating program managers on OSS development best practices will allow them to better anticipate possible obstacles and provide immediate feedback to NASA on how best to affect the culture within their research community. A SMD-level coordination
of program managers’ experiences as policy is implemented may significantly decrease the length of any transition period. Many of the lessons learned from the implementation of open data policies are discussed in Chapter 3 and can be applied to the implementation of an OSS policy. A theme of this report, however is that OSS policy is more complex than open data policy and will require a multidimensional approach as outlined in the options discussed in Chapter 5. The committee believes in the benefit of an OSS policy, but its implementation must be carefully planned, gradually implemented, appropriately funded, and well coordinated across SMD.