Thanks for comments from: Dan Katz, Suresh Marru, Abby Cabunoc Mayes, Micaela S. Parker, Danielle Robinson, and Nic Weber. Research software is software created by scholarly researchers. Often researchers produce source code that is ‘open’, in alignment with scientific norms. But this code and the research it supports is not always “sustainable”, because it does not have a viable community of developers and users working with it in an ongoing way.
We are witnessing the early stages of a revolution in the computational molecular sciences. Numerous community codes in quantum chemistry, biomolecular simulation, and computational materials science are beginning to adopt modern, collaborative software engineering practices and tools, to the benefit of the broader field. Over their long history, the computational molecular sciences have emerged as an essential partner with experiment in elucidating the structures and mechanisms that control chemical processes, and, in fact, often precede experiment in the knowledge-based design of new systems.
(reposted from Titus’s blog) We are slowly working towards a v2.0 release of sourmash, our software for MinHash and modulo hash analysis of genomic data, and the question of proper authorship is once again on my mind! The question du jour: how should authorship on software papers be decided? Some background - our previous take on authorship Those of you with long memories may recall a hullabaloo in 2015 over this occasioned by the khmer v2.
Containers, such as Singularity and Docker, are an amazing advance in software sustainability. By allowing software developers to package not only application software but also other components of the software stack, including software dependencies, that the application needs, and with which the application is well tested, containers make the porting of applications to new platforms much more straightforward, convenient and efficient. In the large scale research computing world, containers are a miracle in the near-term, but a looming challenge in the medium- to long-term.
This is a time of great growth at the intersection of software engineering and research software. There is a need to bring together members of these communities to identify common goals and lay out research agenda to move both communities in a positive direction. To address this, the SE4Science’19 workshop will be held May 28, 2019 in conjunction with the International Conference on Software Engineering (ICSE) in Montreal, Canada. The goal of this workshop is to provide a unique venue for interaction between software engineers and scientists.
(reposted from SSI blog) By Mateusz Kuzak, Maria Cruz, Carsten Thiel, Shoaib Sufi, and Nasir Eisty. This post is part of the WSSSPE6.1 speed blog posts series. Photo courtesy of Lee Cannon We argue that research software should be treated as a first-class research output, in equal footing to research data. Research software and research data are both fundamental to contemporary research. However, the recognition of the importance of research software as a valuable research output in its own right is lagging behind that of research data.
Credit and recognition for research software: Current state of practice and outlook
Stephan Druskat, Daniel S. Katz, David Klein, Mark Santcroos, Tobias Schlauch, Liz Sexton-Kennedy, and Anthony Truskinger • December 3, 2018
(reposted from SSI blog) By Stephan Druskat, Daniel S. Katz, David Klein, Mark Santcroos, Tobias Schlauch, Liz Sexton-Kennedy, and Anthony Truskinger. This post is part of the WSSSPE6.1 speed blog posts series. The cruise ship "Columbus" leaving the harbor at Amsterdam during WSSSPE 6.1. Photo by Mark Santcroos. Like the behemoth cruise ship leaving the harbor of Amsterdam that overshadowed our discussion table at WSSSPE 6.1, credit for software is a slowly moving target, and it’s a non-trivial task to ensure that the right people get due credit.
(reposted from GSI blog) Numerous fields are increasingly dependent on geospatial software that is defined to transform geospatial data (i.e. data with geo and/or spatial references) into geospatial information, knowledge, and intelligence. The growing benefits and importance of geospatial software to science and engineering is driven by tremendous needs in these fields such as agriculture, ecology, emergency management, environmental engineering and sciences, geography and spatial sciences, geosciences, national security, public health, and social sciences, to name just a few, and is reflected by a massive digital geospatial industry.
A major part of our year long effort to plan a US research software institute is to understand the diverse challenges and barriers that researchers face when using or developing research software. To better understand these challenges, we are currently in the midst of running a large scale survey aimed at researchers who develop or use software in academia, government, and other research focused institutes. If you’re involved in any aspect of research software or know colleagues who are, please take and share the survey:
(reposted from Daniel S. Katz’s blog This blog post is intended as companion text for a talk I gave at the September 2018 NumFOCUS Project Forum in in New York, though I also hope it stands on its own. To address software sustainability, it is important first to understand how the term sustainability is used more generally. It’s most often used in the context of ecology, often specifically in the relationship between humans and the planet.
CiteAs.org links between pieces of software and their requested citations. It enables moving from the name of a piece of software, its webpage URL, or a DOI, directly to the machine-readable metadata (e.g., BibTex, Zotero auto-import) for the citation the author of the software package wants you to use. CiteAs.org is funded by the Digital Science program at the Sloan Foundation (Grant Number 8028), and conceived and developed by Heather Piwowar and Jason Priem at ImpactStory, together with James Howison from the Information School at the University of Texas at Austin.
What do sociologists, ecologists, economists, engineers, anthropologists, geographers, hydrologists, evolutionary biologists, and environmental scientists all have in common? Software! Science at the intersection of humans and the environment increasingly requires collaborative, interdisciplinary work among researchers with varied computing backgrounds to gather insights from highly diverse data at multiple scales. Reliable software is necessary to achieving this synthesis. At the National Socio-Environmental Synthesis Center (SESYNC), we provide cyberinfrastructure support oriented toward helping researchers choose, apply, and develop software to meet the research needs of the 40+ interdisciplinary projects we support at any given time.
When I first started thinking about how we could create a career path for Research Software Engineers (RSEs) in academia, I assumed it would involve persuading university managers to implement a new career path. Quite frankly, I wasn’t looking forward to the interminable bureaucracy that such a change would require me to navigate. Fortunately, a completely different solution quickly gained traction in the UK: the rise of RSE Groups. An RSE Group is a centralized group, based at a university or other research organization, that employs a number of RSEs and then hires them out to researchers across the organization.
It is a truth universally acknowledged that a biologist in possession of a data must be in want of a computer to analyze it on. Or, perhaps not. In 2016 as part of our efforts to better understand the needs of users and potential users of CyVerse (NSF-funded cyberinfrastructure for life sciences), we conducted a survey of NSF-funded investigators to determine what was important for them when it comes to analyzing large datasets.
Software has been both ubiquitous and largely neglected in computational science and engineering (CSE) since before the field became a recognized entity. The interest in CSE software for both practitioners and sponsors has primarily been on the scientific insights and advances it enables rather than on its value as a long-lived tool or product. As a result, the culture of CSE, broadly speaking, has a structure and reward system that focuses on the algorithms and the results, but where good quality research software, as well as the time and effort required to produce it, often tend to be marginalized.
Among the many efforts that are underway as part of NSF’s SI2 program, one of the most cross-cutting efforts is the planning for a US Research Software Institute (URSSI), which was funded in December 2017. This effort aims to plan an institute that would address challenges around making research software sustainable and robust, and more importantly, improve the sustainability of the researchers who develop such software. Some of our initial discussions, described in detail below, have surfaced problems encountered by specific researchers working on specific software applications, but the solutions conceived of and planned for by URSSI are not aimed at any one domain or discipline of research.
Note: This is reposted from the CANARIE Blog My previous blog posts have focused on the research software landscape in Canada, but the challenges and opportunities we face are not different from those in other parts of the world. In this post, I provide a brief overview of three international organizations that CANARIE works with as part of our Research Software program. These organizations are very different in their structure and approach to excellence in research software, but as you’ll see, they are all trying to solve common problems.
In 2016, the UK Software Sustainability Institute (SSI) ran a first survey of Research Software Engineers (RSEs): the people who write code in academia. This produced the first insight into the demographics, job satisfaction, and practices of RSEs. To support and broaden this work, the Institute planned to run the survey every year in the UK and an ever-expanding number of countries so that insight and comparison can be made across the globe.