Over the past decade, digital humanists have come a long way in recognizing when a project is “done” [Kirschenbaum 2009]. But DH still has a problem when it comes to project resiliency. As Constance Crompton points out in her contribution to this issue, DH grant funding is disproportionately awarded to new and shiny digital technologies and tools rather than to disciplinary scholarship implemented and published with standard digital tools. Almost no funding is available for maintenance, remediation, upgrading, and remaking, even though technological frameworks will have changed considerably in a five-year funding cycle. The result is a huge maintenance burden for project leads and developers (Holmes & Takeda in this issue) and/or a hosting and storage problem for institutions (Cummings in this issue).

Most of the papers in this DHQ special issue are the product of a virtual symposium held in April 2021 by The Endings Project at the University of Victoria. The Endings Project, a five-year collaboration funded by the Social Sciences and Humanities Research Council (SSHRC), is creating tools, principles, policies, code, and recommendations to help digital scholarship practitioners create accessible, stable, long-lasting resources in the humanities. Unusually for DH, the Endings Project was initiated by developers (see Holmes and Takeda in this issue). It brings together digital humanists and librarians because, as Matthew Kirschenbaum has argued, “Digital humanists need the long-term perspective on data that archivists have”  [Kirschenbaum 2013]. The Endings team’s developers (all of them humanists by their first training) are the bridge between Humanities researchers and Librarians/archivists. The Endings Project facilitates a long-term conversation between the three constituencies responsible for the intellectual generation, building, and long-term preservation of digital research products.

The impetus for The Endings Project was the substantial maintenance burden accrued by UVic’s Humanities Computing and Media Centre (HCMC), which has been involved in over 200 digital humanities projects since the 1990s. Its history, as described in Holmes & Takeda, clearly shows the problems inherent in current approaches to digital edition projects, particularly projects with short-term or sporadic grant funding. The growing maintenance burden facing the HCMC was ultimately unsustainable. Project Endings was conceived and convened to address this problem.

The mission of The Endings Project was:

• to discover what human and institutional factors prevent completion of projects;
• to learn how to make web-based digital editions that will last indefinitely without maintenance; and
• to learn how to archive finished projects without placing undue burdens on the repository.

Ultimately, we wanted to know how projects end, why and when they fail to achieve their final milestone, what constitutes a good ending, and where best to store the finished product so that its research outputs continue to be available long-term.

The Earl of Essex was said to have put his arguments to Queen Elizabeth in the highly constrained form of the sonnet [Wotton 1672, 165]. While sonnets did not save the earl’s neck, we do believe that the answer to the question of how to create long-term, accessible resources is found in cultivating cultures of constraint. We have phrases like “scope creep” and “feature creep” to describe the near-irresistible temptations to act on every good idea a project member may have. We introduce the term “platform creep” to describe easy-to-deploy platforms that facilitate rapid deployment of a new project, but incur technical debt leading to inevitable obsolescence. At the end of these types of projects, project leads are often surprised when their institutional library or archive is unable to preserve the bespoke software stack they’ve cobbled together. Instead of trying to preserve what we accidentally made, we should be trying to make what can be preserved.

The fewer flourishes in software, the longer the project seems to last. The recent work of the HCMC has been to be innovative within a limited set of technologies, in order to minimize the maintenance burden of over 200 projects, so that developer time can be invested in newer projects coming in. We learned quickly that a “simple” security update could render sites unreadable, thus necessitating constant tending and time. The need for action within very strict constraints (time and funding) forced us to be creative to serve our users.

There are unspoken constraints in the library, as well. Space and human resources force librarians and archivists to make hard decisions about what stays and what goes – weeding the stacks of unused material to make room for new books is one of the less understood aspects of librarians’ jobs. Recently, a member of the Humanist Discussion List asked why librarians can’t preserve digital projects as they do books. It seems like a reasonable request at first glance, but the vast number of bespoke DH projects that would require continual software updates and rewrites in order to keep running quickly would quickly made library preservation an unmanageable task — even with strong documentation created by the projects (and good documentation also tends to be something we run out of time to do). Although libraries and archives can’t fire up hundreds or thousands of Wordpress and Drupal sites, they certainly can run a server on which flat sites can be stored, accessed, and preserved. Asking for such a server is a reasonable request. In this way, limitations need to be the drivers of innovation and the DH community should see “constraint” as an admirable feature of a project since it will give the project the best chance of survival. As a community, we need to adopt constraint as an aesthetic, and make it a part of “the stories we tell,” a phrase Claire Battershill explores in this issue, about our work.

The work of Endings began with a day seminar in which the UVic Endings researchers, developers, and librarians[1] met to describe their work, share their institutional vantage point, and learn from each other. We made many surprising discoveries about each other and deconstructed erroneous assumptions about the roles of our institutional colleagues. For example, the Library’s position on archiving was effectively invisible to researchers and developers; the web subdomain of a project (mapoflondon.uvic.ca, for example) seemed self-evidently crucial to researchers as an extension of the project’s title and “brand,” while to the Library it seemed obvious that the subdomain didn’t matter at all and that an archived project should be delivered through a library-specific domain.

This day seminar led to our conducting a survey of DH practitioners, in order to learn about the experiences and realities faced by those working in other contexts and institutions. What we learned from the survey (see [Carlin 2018]; [Endings Team 2022]) was not surprising: most projects faced exactly the same sorts of problems and limitations, although the scale of technical support and resources provided by host institutions varied widely. From the 125 survey respondents, we identified 25 project leads with whom we conducted more in-depth interviews during 2019 and 2020.

These interviews were then transcribed and encoded (see Comeau in this issue for a detailed description of the interview and analysis process) to provide us with a searchable resource from which we could easily draw examples and examine general tendencies and issues across the DH landscape. Papers are forthcoming that describe the results of those interviews. Finally, we invited a selection of our interviewees from a range of different disciplines to continue the co-created conversation by participating in the 2021 symposium that gave rise to this special issue.

We begin with a pair of papers that address two of the key problems in foreseeing an ending to a digital project. In “The Stories We Tell,” Claire Battershill addresses our very human reluctance to imagine our own projects coming to an end. She proposes that if we think about DH projects “in a literary sense, we can analyze and read digital projects as the creative and multifaceted texts that they are and become. We can perhaps approach them with intention and care not only as technical artifacts but also as works that we’ve made, often along with a number of collaborators.” Projects begin in “promise, potential, and excitement”; despite challenges along the way, we keep projects going because the project becomes intrinsic to our purpose and definition, especially for the many digital humanists in precarious employment. Resolving disciplinary and other inequities would go a long way towards helping projects reach their end, she argues, because a team in stable institutional positions may keep collaborating on other projects, large or small. Constance Crompton points out the ways in which funding structures that reward innovation have discouraged sustainable, replicable practices until the “recent turn to sustainability, signalled by the rise of data management plans and data deposit requirements.” Given the self-replicating nature of DH practices through the apprenticeship model whereby students work on large projects, mentorship will be a crucial factor in breaking the cycle of unsustainable, boutique project building.

James Cummings discusses two well-known digital edition projects, the CURSUS project and William Godwin’s Diary. Both projects were severely endangered by the lack of legacy planning. When key personnel are lost, and a project has no champion at its host institution, the consequences can be disastrous, especially when the project depends on a technical framework that is not part of the institution’s core infrastructure. Both of these projects would have been completely lost without Cummings’s persistent intervention.

In telling two digital disaster stories, Sara Diamond reminds us that even the most important and socially significant projects are subject to institutional changes, career moves, and shifting priorities. The Banff New Media Institute was deaccessioned after a leadership change, resulting in the overnight disappearance of a vast archive of Indigenous art and history. The Daniel Langlois Foundation archive survived only because of the determined efforts of Jean Gagnon, on whose good will the project is still worryingly dependent. Diamond’s own fonds and sub-collections have been built with the lessons of these two experiences in mind. Ultimately, Diamond suggests that “institutions, creators of archives and their users all bear responsibility for the protection and continuity” of those archives.

Nick Thieberger’s paper, on the monumental PARADISEC project, describes an attempt to thwart the forces of entropy on a massive scale. PARADISEC has rescued over 14,000 hours of field audio tape recordings representing over 1300 languages from the Pacific Region, and is hosting them in a public archive, as well as attempting to return them in accessible format to the originating Indigenous communities. This enormous project is itself facing resiliency issues, since it has no stable funding and depends on a small team of dedicated researchers, reminding us that the process of data rescue and retrieval may be cyclical and repetitive without reliable commitments to long-term archiving.

Like Battershill, Jessica Otis is concerned with deconstructing narratives — in this case the funding narratives that suggest, erroneously, that DH projects are either “cash cows” bringing money into the institution via grants or “free” because of donated scholarly labor. Having shown the hidden costs of project maintenance, Otis discusses the prospects of obtaining long-term funding to sustain a project beyond its initial grant-funding, the availability of hard-funded resources from the institution, and the practical realism required to retool projects to fit into sustainable long-term funding models.

There is a traditional assumption that what matters about a digital project is its “data” (however we might define that), rather than its web interface, which is considered ephemeral. However, every session at the symposium touched on the issue of interface, arguably the most recognizable and least preservable part of a digital project. Preserving the look and feel of web-based digital projects continues to be a challenge. Symposium attendees discussed the possibility of doing video captures of website tours and archiving video along with a digital project’s data. Diamond points to emulation as a preservation strategy, and we can undoubtedly learn much from the work of electronic literature scholars as well. Emulation is expensive in terms of hardware, software, and maintenance, and perhaps only works like those described by Diamond will merit such preservation.

Our final two papers were not presented at the symposium. However, Holmes and Takeda, as Endings team members and co-hosts of the symposium, shared their ideas in the discussion. They approach the practical issues of project resiliency from a technical point of view. Their role on the Endings team was to develop the detailed guidelines and recommended practices that would govern the rewriting of many HCMC projects as pure static websites, and then to put the guidelines into practice, rebuilding a dozen or so existing HCMC projects in Endings-compliant form. Along the way, they developed diagnostic tools and an entirely static search engine that can be deployed for any static digital edition.

Coble and Karlin’s paper is a serendipitous addition to our collection; the authors were not presenters at our symposium, but their paper is an apt counterpoint to the other work on project resiliency. They examine not the reliability of individual project data and outputs, but the larger web of scholarly referencing within which they live. Their research looks at citations of digital resources from articles in DHQ itself, to see not just whether links still function, but also whether the resources to which they point are the same resources the author intended to cite.

Sometimes things are meant to be ephemeral: there is ephemeral employment and there are ephemeral products of scholarship, which is fine as long as ephemerality is intentional. Yet the majority of DH projects find themselves in the unfortunate position of being unintentionally ephemeral. One of the anonymous reviewers of this issue made the point that we shouldn’t have to keep making the point that digital projects need to be more robust and preservable. The reviewer wondered why we are still having to advocate for what they characterized as common knowledge and common sense. Taken together, the essays in this collection show the difficulty of realizing common sense in practice. The roots of this persistent problem are both social and technological.

DH has a strong tradition of “collaboration,” which frequently includes students, colleagues from across campus, and programmers, as well as librarians and archivists. However, each group brings to the table its own cultural norms and presuppositions, and each group works within existing structures of power, funding, and promotion that are frequently at odds with one another.

A faculty member who may want to launch a project quickly may be seduced by the siren song of “easy to deploy,” which is nearly always at odds with long-term survivability. A hastily-concocted Wordpress or Drupal site, although ready for a promotion file — or replaced with the next big project — will be at the mercy of how much time the scholar actually has to commit to regular updates (usual answer: little to none). The programmer may resist the upfront work of setting up a sustainable long-term platform because they are accustomed to working with specific platform stacks and are tempted to fall back on what they already know, or to pick up whatever library or platform is momentarily newest and most interesting; projects built out of such a mindset will be at the mercy of security vulnerabilities, software obsolescence, and personnel changes. Librarians and archivists are constrained by a scarcity economy of space and funding — it is easy to eschew preserving digital projects when you know it will be impossible to maintain them. Although the dream of a “universal library” is a beautiful ideal, it will nonetheless remain a fiction until we choose universal technologies.

The first stage in building an Endings-compliant project is having an honest conversation among faculty, programmers, and librarians/archivists about expectations, abilities, and sustainability that is agreed upon and documented. This step should happen before the first byte is saved to disk. Normally trained to work in solitude, faculty may need to rely on experts beyond their discipline who work at a different pace. Programmers may have to be open to different ways of programming and take the extra time to design for the eventual flattening of sites even if a dynamic site is preferred for the length of the project (which is perfectly fine, assuming there is funding and time for a complete rewrite at the end). Librarians and archivists need to invest in people, services, and technologies to sustain flat websites — which could simply be a server that is part of the libraries’ long-term preservation plan. As this issue was being created, the Diary of Robert Graves project became the first archived DH project at UVic Libraries, a process which was possible only because the site is Endings compliant. UVic Libraries is committing to preserving flattened, Endings-compliant sites as part of its preservation activities. It has taken some time to reach this point and the process has involved stakeholders from across the institution (Systems, Metadata, Digital Scholarship, and the University Librarian's Office), but we’re here. Hosting a server for static sites is eminently achievable for most university libraries. With collaboration comes compromise in the name of long-term access and discoverability. Everyone on the team needs to understand the needs and limitations of the others, while also mutually agreeing to Endings Principles.

Finally, if there’s one constant in DH, and computing in general, it is that technologies will change. Our toolkit is not a technological solution that will be out of date next year. Rather, it is a series of practices for you to consider when starting your project. Moreover, each DH project exists within a unique environment with unique challenges. We’ve thus made our recommendations adaptable to any project, at any scale, with the hope of creating something sustainable. Who knows what tomorrow will bring? What we do know is that the fewer dependencies a digital edition has, the longer it is likely to last. The first HTML page marked up by Tim Berners-Lee in 1991 is still renderable by modern browsers.[2] Simplicity for the win.