Carver, Jeffrey

Gesing, Sandra

Haines, Robert

Heroux, Michael

Huff, Kathryn

Katz, Daniel S.

Löffler, Frank

Niemeyer, Kyle

Pierce, Marlon

Wilson, Greg

English

Research across all fields is increasingly digital, and increasingly dependent on software. However, software must be continually maintained for it to continue to function. This is part of the meaning of sustainability: software is sustainable if it will continue to be available in the future, on new platforms, and meet new needs. But sustainability doesn’t happen automatically; it must be encouraged, enabled, planned, and enacted. And for both individual projects and the overall software environment, NSF can and should help make this happen

The University of Manchester - Institutional Repository

The University of Manchester ResearchSustaining Software as a Key Element ofCyberinfrastructureDocument VersionOther versionLink to publication record in Manchester Research ExplorerCitation for published version (APA):Katz, D. S., Haines, R., Huff, K., Löffler, F., Pierce, M., Heroux, M., Niemeyer, K., Gesing, S., Carver, J., & Wilson,G. (2017, Apr 5). Sustaining Software as a Key Element of Cyberinfrastructure: Submission in Response to NSFCI 2030 Request for Information.Citing this paperPlease note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscriptor Proof version this may differ from the final Published version. If citing, it is advised that you check and use thepublisher's definitive version.General rightsCopyright and moral rights for the publications made accessible in the Research Explorer are retained by theauthors and/or other copyright owners and it is a condition of accessing publications that users recognise andabide by the legal requirements associated with these rights.Takedown policyIf you believe that this document breaches copyright please refer to the University of Manchester’s TakedownProcedures [http://man.ac.uk/04Y6Bo] or contact uml.scholarlycommunications@manchester.ac.uk providingrelevant details, so we can investigate your claim.Download date:08. Jun. 2022Submission in Response to NSF CI 2030 Request for InformationDATE AND TIME: 2017-04-03 20:36:51REFERENCE NO: 209PAGE 1This contribution was submitted to the National Science Foundation as part of the NSF CI 2030 planning activity through an NSF Requestfor Information, https://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf17031. Consideration of this contribution in NSF'splanning process and any NSF-provided public accessibility of this document does not constitute approval of the content by NSF or the USGovernment. The opinions and views expressed herein are those of the author(s) and do not necessarily reflect those of the NSF or the USGovernment. The content of this submission is protected by the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0International License (https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode).Author Names & AffiliationsDaniel S. Katz - University of Illinois at Urbana-ChampaignRobert Haines - University of Manchester, UKKathryn Huff - University of Illinois at Urbana-ChampaignFrank Löffler - Louisiana State UniversityMarlon Pierce - Indiana UniversityMichael Heroux - St. John’s UniversityKyle Niemeyer - Oregon State UniversitySandra Gesing - University of Notre DameJeffrey Carver - University of AlabamaGreg Wilson - Rangle.ioContact Email Address (for NSF use only)(Hidden)Research Domain, discipline, and sub-disciplineComputational and Data Science, as applied to all science and engineering fieldsTitle of SubmissionSustaining Software as a Key Element of CyberinfrastructureAbstract (maximum ~200 words).Research across all fields is increasingly digital, and increasingly dependent on software. However, software must be continuallymaintained for it to continue to function. This is part of the meaning of sustainability: software is sustainable if it will continue to be availablein the future, on new platforms, and meet new needs. But sustainability doesn’t happen automatically; it must be encouraged, enabled,planned, and enacted. And for both individual projects and the overall software environment, NSF can and should help make this happen.Question 1 Research Challenge(s) (maximum ~1200 words): Describe current or emerging science or engineering research challenge(s),providing context in terms of recent research activities and standing questions in the field.Modern research is inescapably digital, with data and publications most often created, analyzed, and stored electronically. The processesby which this happens rely on software of ever-increasing complexity. While some of this software is general-purpose office software (e.g.,for email, text, presentations, spreadsheet), a great deal of it is developed specifically for research, often by researchers themselves. ThisSubmission in Response to NSF CI 2030 Request for InformationDATE AND TIME: 2017-04-03 20:36:51REFERENCE NO: 209PAGE 2type of research software is essential to progress in science, engineering, humanities, and all other fields. It has led to Nobel prizes (e.g.Karplus, Levitt and Warshel in Chemistry in 2013, Englert and Higgs in Physics in 2013, Perlmutter, Schmidt and Riess in Physics in 2011)and likely will again, such as for the LIGO discovery of gravitational waves, which relied on both data analysis and forward models to matcha particular model to an observed set of data. Software also enables tens to hundreds of thousands of individual researchers to work ondistinct aspects of grand challenges, and to have their work build into a set of knowledge, for example in bioinformatics, where computerscientists develop workflow tools, and bioinformaticians develop components, which then are combined together to solve problems. Despitethis ubiquity of research software, few research environments offer researchers the necessary training, experience, or institutional supportto robustly maintain the software they author. In particular, researchers who support sustainability of software rarely have externalincentives in the existing academic landscape, and tenure and promotion committees seldom recognize the importance of software inresearch. All those involved in the research environment, from the researcher to the archivist to the university administrator to the funder tothe publisher, must strive to make choices that contribute to improving that environment where research software is created and sustained.Question 2 Cyberinfrastructure Needed to Address the Research Challenge(s) (maximum ~1200 words): Describe any limitations orabsence of existing cyberinfrastructure, and/or specific technical advancements in cyberinfrastructure (e.g. advanced computing, datainfrastructure, software infrastructure, applications, networking, cybersecurity), that must be addressed to accomplish the identifiedresearch challenge(s).Research software is a key element of the cyberinfrastructure in many fields. Most research software is produced within academia, byacademics, ranging in experience and status from students to postdocs to staff members to faculty. The academic environment in whichthis software is developed, maintained, and used, varies widely with regards to the software processes. While the environment and cultureof science have developed over hundreds of years, software has become important only more recently, in some fields over the last 60+years, but in many others, just in the last 20 or fewer years. Furthermore, much of the software is produced by academics who are notpermanent employees of their institutions, and thus, many of these contributions have a transient nature: the developers may not continueto maintain the software after they graduate or change jobs. Even when software is produced by permanent employees (faculty and staff onuniversity funding lines), these employees are often not hired, rewarded, or promoted based on their software work.Given this, the key need is not the software element of the cyberinfrastructure, but rather, the environment that allows it to be mosteffectively created, maintained, used, and sustained over time. The existing environment has been organically created by a variety ofstakeholders, including funders, university administrators, research leaders, publishers, librarians, etc. For this environment to be improvedso that better software is created and continues to exist, those stakeholders must make conscious decisions to improve the environment,not just to attempt to create specific software tools.Improvements that may make a research environment more suitable for sustaining software will vary according to many parameters (e.g.software purpose, scientific domain, institution type). Training programs and curriculum may improve the software skills of scientists at alllevels, and these are being discussed in another response to this RFI, titled “Research Software Training Initiative: Identifying andaddressing challenges in scientific software development” and led by Frank Löffler. In many cases, such training may only be feasible whencoupled with institutional incentives so that permanent staff have the opportunity to be rewarded for their software products. In addition totraining and incentives, expert support in the form of permanent scientific software staff may be appropriate for sustaining an institution’sresearch software investments. Beyond this, improved symbiosis between institutions and open source communities will be beneficial inmany cases. When research software products have the potential to engage a sufficiently large open source user/developer community tosustain the research software, researchers may need support and training to nurture, nourish, maintain, and lead that community.The NSF has invested in campus cyberinfrastructure through the CC-* program and its predecessors. These investments have been in theform of science DMZs, computing resources, innovative storage, and “cyber teams” of applied scientific computing experts. We suggest asimilar need to seed university-centered teams of cyberinfrastructure software architects and developers, with university-level commitmentsto sustainability. These university-centered software cyberinfrastructure centers of expertise can be networked into regional and domain-specific federated teams, with an ultimate goal of a national level federation. The key element is to provide incentives at the university level,such as within the Office of the Vice Presidents/Provosts for Research, to make long term commitments to supporting cyberinfrastructuresoftware and the architects and designers who produce it.Submission in Response to NSF CI 2030 Request for InformationDATE AND TIME: 2017-04-03 20:36:51REFERENCE NO: 209PAGE 3Question 3 Other considerations (maximum ~1200 words, optional): Any other relevant aspects, such as organization, process, learningand workforce development, access, and sustainability, that need to be addressed; or any other issues that NSF should consider.Cyberinfrastructure includes software, and the software must be strengthened as it is a key but currently under-supported element.Because of software collapse (dependencies on underlying software which itself changes over time, seehttp://blog.khinsen.net/posts/2017/01/13/sustainable-software-and-reproducible-research-dealing-with-software-collapse/), software stopsworking relatively quickly if not continuously maintained. But NSF funding for software only lasts a short period, equivalent to theconstruction phase of an MREFC. In some cases, this maintenance after construction can be handled by an open source community, ifthere is a community of sufficient size, if funding is available, and if the community has the skills to do this maintenance. However, thiscombination is rare: either the community isn't large enough, or doesn't have the right skills, or doesn't have the funding needed. Membersof the community might be cyberinfrastructure software professionals, supported by their universities. In other cases, if there is not acontinuing investment, the software will stop working, and the initial construction effort will have been wasted. NSF first needs to recognizethat this is a problem, and second needs to recognize that for some software, sustainability requires NSF to continue to invest inmaintaining the software over time (equivalent to the operating period on an MREFC). If NSF is not willing to provide this longer termfunding, and the developers don’t have a good alternative method to acquire the needed resources, NSF should carefully consider itschoice to fund the initial development against the short term payoff during the life of the award.Funding to sustain software can be provided at multiple levels, which might range from continued funding of the project itself, to keep thedevelopment team together, to centralized funding of teams of research software developers at institutions, to take on projects as theymove out of the build phase. Different projects will need different approaches. (Projects across NSF can also be incentivized to developsustainable software from the start by providing funding in the initial award to cover the extra costs associated with performing these tasksduring the life of the award, as the SI2 program tries to do.)To call attention to this need, and to make the best award decisions, NSF should also require a Software Management Plan for allproposals. Software Management Plans should provide a justification for the development of new software, having considered theexistence of similar software already available, and should detail how (and for how long) any such new software is to be sustained. Thismight include plans to build a community around it, or a request for further support from NSF. Both Data and Software Management Plansmust be public and should be machine-readable for two reasons:1. The science community (reviewers and program officers) needs to thoughtfully consider, at all stages of proposal review and projectmanagement, the public interest and NSF's requirement that investigators and organizations have the responsibility as members of thescientific and engineering community to make results, data, and collections available to other researchers.2. Software and data management plans should be public documents, stored as archival documents, similar to how papers, software, anddatasets are stored, so the record of what a project planned can be later verified by other scientists, including peer-reviewers of futureprojects by the same investigators. As shown by Van Tuyl and Whitmire (http://dx.doi.org/10.1371/journal.pone.0147942), proposerscompliance with their own data management plans have been somewhat problematic.The Software Management Plan might be combined with the Data Management Plan, but if so, it should be a true combination with a newname, not a slightly expanded Data Management Plan.Consent Statement“I hereby agree to give the National Science Foundation (NSF) the right to use this information for the purposes stated above and todisplay it on a publically available website, consistent with the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0International License (https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode).”

Sustaining Software as a Key Element of Cyberinfrastructure:Submission in Response to NSF CI 2030 Request for Information

https://pure.manchester.ac.uk/ws/files/53888268/RFI_Katz_209.pdf

Sustaining Software as a Key Element of Cyberinfrastructure:Submission in Response to NSF CI 2030 Request for Information

Abstract

Similar works

Full text

Available Versions

The University of Manchester - Institutional Repository