(1) and (4) are the emphasis of our paper so far, but check against the dataset.

Make the implicit explicit.

Yes - also part of the low-friction transition equation.

Kansa - should bring up the 'loose coupling' argument.

Yes, this is part of the low-friction transitions / data portability. Mention funcationality modularisation.

Again, perhaps we can test the 'simplicity' argument using the dataset we're building.

Not a bad idea, haven't seen any in the wild

Perhaps we can find some metric here that could be expressed in / derived from the dataset to show (a) maximum use of the tool, (b) when the tool died.

This is key

REinventing the whell is a problem, in our dataset we should look for evidence of use, at least at an order-of-magnitude scale.

Avoid at all costs.

Anyway - highlight this lack in the 'future directions' section of the paper, and mention it in the section arguing for low-friction transitions.

This sort of research would be useful, until then, focusing on reducing the friction of change from one tool to the next is the best we can do.

Perhaps we could suggest something here based on what our dataset of softare looks like.

Perhaps use the 'fading away' article as a model.

Yay, this is our paper!

Maybe some truncated version of this, where there are built-in archiving / export tools.

Yes, actual use is key

Yeah, this is what university IT departments want...

Ok, this was going to be the main point of the paper, need to talk to Peter Sefton about how to go past the results of the Ending Project.

Require standard data formats, ensure data portability, if a project's custom softare dies, another tool can potentially read the data.

Perhaps can extend by focusing on low-frinction transition to other tools, such as the use of bog standard formats and data bundled with metadata (like ROCrate).

This seems like a good idea given practical constraints

Perhaps getting better...

See also 'crapple' license...generally poor RSE practice in DH

Small scale, poorly resourced, no standards...

Voyant, QGIS - large open-source tools the only ones that are really succeeding in archaeology / DH - Pareto distribution, I'm sure...

Good RSE practices more common in STEM

In big data / big science fields, sustainability is approached at the infrastructure and community level.

Small data / small science problems, scale of DH software development rarely exceeds the individual project.

More longitudinal studies needed. Only strong hints and isolated metrics plus analogies to data in the literature at present. No comprehensive empirical model for software longevity.

Methods include surveys, repository mining, case studies and post-mortems, studies of dependency networks. Unsurprisingly, software with more users and uses survives longer (strengthening argument for FAIR software, see above). Broad user base, as with Voyant, is crucial.

Static site, source doce with DOI (Zenodo + GitHub), descriptive metadata. Again, however, most of the examples are from collections not tools.

Another GitHub study: Duckles et al (2020). Poorly documented. Allen et al 2019 looks at Zenodo and shows increase it its use after 2016. Internet Archive can be used to retrospectively study project websites.

Projec tBamboo taken as a case study in unsustainability of DH.

Relative few: Vines et all 2014 looks at data (half-life of 6-7 years). Nielsen et al (2017) looked at biology papers and found that many could not be obtained a few years later. Endings Project has some data. Katz and Niemeryer (2019) look at Github repos and found that most have a short, bursty commit history (see also Howison and Herbsleb). Few are active beyond five yeras or attract multiple external contributors. Overall, short lifespan.

Failed due to lack of governance, iterative development, and community buy-in - the last is probably the most common problem...

Importance of shared infrastructure

KDL, tiered archiving framework, classifies each project based on importance and feasibility, some kept running, others are archived

Applied Endings Principles, all research data in standard formats and website archived to statis HTML

Need to get DR to summarise the ARIADNE project

Methodologies and tools * Endings Principles for Digital Longevity: data, documentation, processing, publication, and release management * 'Data' under Endings Principles is the closest to what we are arguing, recommending that all project data should be stored in open, non-proprietary formats, so no closed or obsolecent formats (follow up, isn't clear exactly what 'data' they are talking about - I assume it's data produced by the software, as we are discussing, but need to confirm). * Producing a static website end product not really relevant, shows how much of the literature is about collections rather than tools. * Goddard (2023) dark archving, web harvesting, emulation, continuous migration.

National and international initiatives - lots of good advice here: * Early planning for preseravation * Choosing appropriate OS licenses * engaging users to encourage co-development * better software practices (e.g., FAIR4RS) * software rachiving * support for reproducibility (what does this mean?) * Capacity and expertise building * Larger infrastructure orgs like data centers, libraries, eresearch institutes, etc) should be more active rather than individual project teams (IMPORTANT: comes from NL report, essentially trying to apply big data / big science solutions to small-science domain). * NL report explains how FAIR makes software more sustainable: easier to find and reuse, less likely to be lost or reinvented - I would add more likely to build a larger user base and get more people involved to provide or find resourcing)

Potential additional research querries: (1) national (and other) reports on software sustainability like the one from NL (2) Relationship of FAIR for RS and sustainability (3) Projects on deliberate end-of-life planning, like the Endings Project (4) Frameworks for assessing sustainability, like RSMM (5) Methods and tools for sustainability like the Endings Principles

Note the existence of national reports on research software sustainability. Are there others?

'Intended for adoption by a wider community' might be part of our definition of a software tool, to eliminate one-offs by researchers. The criteria we are using to select software (e.g., publicaton about it or citing it) seem to select for this criteria.

Endings project is crucial, as it's the only one I've found so far that actually promotes end-of-life planning.

RSMM is important, but too new to assess whether it's had any impact.

FAIR has, I think, limited applicability to longevity / sustainability. It helps make software more discoverable and reusable, which in turn migh tincrease uptake and make it more likely that the original creators or someone else will do the work to maintain the software. Otherwise, the key here is improved interoperability, which allows the software to be substituted with something else with as little friction as possible.

Small data / small science problem again

Keyword: abandonment

Cross-domain differences in funding models

Again, big vs. small, particularly challenging for small disciplines since work necessary for maintanence is concentrated, there are fewer standards / less standardisation, less shared infrastructure (more bespoke work / reinventing the wheel) and funding is less

'big science' vs 'small science' / big data vs small data

culture change necessary around organisational and social context of research tools

Brittle nature of the staffing around digital tools

Grant funding is brief, but upkeep costs continue

Keyword: persistence

tools need continual upkeep

Institutional / socio-technical challenges. I'd probably separate 'techological challenges' and 'socio-technical challenges' in the lit review.

This is key: 'inevitable obsolescence of software dependencies and environments'

I wouldn't quite word it this way, but the idea that research software tools need to endure longer than the technologies they are built from is an imporant one, and summarises why tools need continual investment and resourcing.

Keywords: preservation, life-cycle

Keywords for conventional lit search: sustainability, longevity