Skip to main content

Currently Skimming:

5 Policy Options and Recommendations
Pages 60-72

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 60...
... and Technology Transfer Office may differ on matters of OSS release. SMD may choose an overall level of openness for new software produced by and for the directorate in the long term, but individual programs and software types will advance toward greater openness at their own rate and through different means.
From page 61...
... Section 5.4 describes how incentives and mandates can be combined for different types of software. 5.1 POLICY OPTION A: CONTINUE STATUS QUO As stated earlier, SMD does not currently have division-wide policy regarding software publishing, distribution, or licensing.
From page 62...
... Table 5.1 summarizes how these may apply to the different software types presented in Chapter 2. 5.2.1 Option B1 -- Funding for Full Open Source Software Proposals With Option B1, SMD or its divisions allocate funding, either in existing or new grant programs, to open existing software with community reuse potential or replace it with functionally equivalent OSS, to develop new OSS, to maintain existing OSS, or to extend community open source libraries and frameworks.
From page 63...
... NOTE: General approach of moving toward a full SMD-wide OSS policy based on software types described in Chapter 2 (see Table 2.1)
From page 64...
... 1 See https://swehb.nasa.gov/display/7150/SWE-102+-+SW+Development-Management+Plan. 5.2.3 Option B3 -- Pilot Software Management Plans With Option B3, specific programs within SMD begin to require SMPs for scientific proposals containing substantial new software development.
From page 65...
... Pros: An OSS mandate would be the surest and quickest way to increase the transparency of NASA science and to satisfy the recent Office of Management and Budget (OMB) memorandum "Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software"3 and NASA CIO response to "encourage vendors to use open source technology wherever possible."4 It could potentially enhance NASA's national and international reputation as a leader in open science.
From page 66...
... The transition schedule may need to be modified based on the response to incentives as they are developed. Program managers will play an important role by tailoring their policy execution to their understanding of communities and culture across SMD, to incremental needs depending on software types, and to community experience with open science practices.
From page 67...
... C Box 5.2 describes the general path to take, but different software types will have different priorities and requirements in moving toward openness. Table 5.1 lays out how the various policy options described above could be applied and when and if mandates would be applied.
From page 68...
... Single-Use Software Software written for use in unique instances is inherently lower priority for OSS policy. SMD may want to consider some proposal add-ons or pilots to transition single-use software to more broadly useful OSS, but mandates for opening single-use software would be challenging to implement.
From page 69...
... 5.5 ASSESSMENT AND FUTURE CONSIDERATIONS As just discussed, there will be a variety of implementation strategies for the different options, disciplines, and software types. An assessment of community software users before, during, and after implementation of policies could help advance policy goals more efficiently.
From page 70...
... Conclusion: SMD will need to assess and adapt policy to new computing technology developments to main tain its intent. 5.6 POLICY IMPLEMENTATION With policy options for specific software types, NASA SMD also will need to consider implementation details.
From page 71...
... Investigators can usually release their software more easily if the open source arrangements were made prior to award of a grant or contract. 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.
From page 72...
... Reproducibility of the science may be impacted by SaaS systems, especially generic ones that may change without notice to the user, or that may disappear entirely during an investigation. Software management plans will need to include discussion of use of SaaS in new software development.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.