Skip to main content

Currently Skimming:

Summary
Pages 1-9

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 1...
... to complement its existing policy on open data. In particular, the report reviews existing data and software policies and the lessons learned from the implementation of those policies, summarizes community perspectives, and presents policy options and recommendations for implementing an OSS policy for NASA SMD.2 The purposes of any open code policies that SMD may develop are to serve the goals of SMD and NASA.
From page 2...
... In some cases, software policy will need to take into account funding sources, the parties involved, the development history, and the size and complexity of the software and computational requirements. For example, a large community-source software project may involve contributions from different institutions, agencies, and countries, each of which may have its own software policies and legal constraints that impede software sharing, export, and licensing practices.
From page 3...
... Concerns included legal ramifications, institutional barriers, costs, the level of effort required to implement OSS policies, the need for training and education, and other impacts on individual scientists and their careers. Some suggested that an open source policy may not always benefit science, because for researchers, time spent publishing software comes at the expense of time spent doing science.
From page 4...
... (Chapter 4) 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.
From page 5...
... Each element has its pros and cons, and they are likely to be applied differently for different software types. Option B1 -- Funding for Full Open Source Software Proposals Under Option B1, SMD or its divisions would allocate funding for new proposals addressing an OSS need, such as to open existing software with community reuse potential or replace it with functionally equivalent OSS, to develop new or maintain existing OSS, or to extend community open source libraries and frameworks.
From page 6...
... This option is otherwise similar to B1, with the difference that there may be situations where the scientific merit of a proposal is not rated high enough for support, but the open source add-on is seen to have significant value. Option B3 -- Pilot Software Management Plans Under Option B3, specific programs within SMD would begin to require SMPs for scientific proposals containing substantial new software development as part of the proposed research.
From page 7...
... , the committee describes in detail which policy options may be appropriate for each of seven defined software types and a suggested time frame for moving to mandated openness. The committee considers 3 years to be the minimum transition time, which is applicable to only some software types or communities.
From page 8...
... 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. (Chapter 5)
From page 9...
... Many of the lessons learned from the implementation of open data policies can be applied to the implementation of an OSS policy; however, OSS is more complex than open data. The recommendations allow for an implementation of open source that is carefully planned, gradually implemented, and well-coordinated across NASA SMD.


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.