Table Of Contents
Somewhere right now, a digital humanities project is dying. Nobody decided to kill it. The grant ended three years ago. The postdoc who maintained the server took a job in industry. The library migrated its hosting environment over the summer, and nobody remembered to test the old sites afterward. The project still loads, mostly. The map tiles no longer render, and the search box returns an error that nobody has reported because nobody is checking. Next year the domain registration will lapse. After that, the project will exist only as a line on someone's CV and a scatter of citations pointing at a URL that no longer answers.
If you have worked in or near the digital humanities for more than a few years, you have watched this happen to something you admired. Maybe it was a database you leaned on in coursework, or an interactive edition a mentor built, or the companion site to a book you still assign. The field has produced brilliant work for three decades, and it has lost a discouraging amount of it. This essay is about why that happens and what you can do about it.
I want to make one claim up front, because everything else follows from it. What happens to a project when the site is no longer maintained is not an IT question. It is a scholarly question. Preservation is not janitorial work you do after the real thinking is finished. Deciding what deserves to survive, in what form, with what documentation, under whose care — these are acts of scholarly judgment, the same kind you exercise when you choose an edition, weigh a source, or build a bibliography. A field that treats preservation as somebody else's problem is a field that has quietly decided its own work is disposable.
A note on where we are. This is the fifth essay in a six-part series on the digital humanities. Part 1 asked what the digital humanities are. Part 2 surveyed tools for dissertation writers. Part 3 turned to theology and religious studies in particular. Part 4 made the case for why we need the digital humanities at all. This essay takes up the problem the first four kept circling without landing on: digital scholarship is fragile, and keeping it alive takes deliberate work. Part 6 will look at the most promising response I know, minimal computing.
The Web Forgets: Link Rot #
Start with the plainest failure, the link that dies. Librarians call it link rot. You click a citation and get a 404 page, a domain squatter, or a server that never answers. Every scholar has met it. Few realize how bad it actually is.
In 2013, Jonathan Zittrain, Kendra Albert, and Lawrence Lessig measured link rot in the places you would most expect durability, law journals and Supreme Court opinions. Legal citation is famously obsessive about precision, and legal writing is preserved with more institutional care than almost any other kind. It did not matter. They found that more than 70 percent of the URLs cited in the Harvard Law Review and two other Harvard law journals, and 50 percent of the URLs cited in United States Supreme Court opinions, no longer led to the material the authors had originally cited.[1] Sit with that for a moment. The evidentiary record of the most heavily scrutinized court on earth rests partly on citations that have already failed.
The rot is not a legal peculiarity. In 2024 the Pew Research Center examined a decade of webpages and found that 38 percent of pages that existed in 2013 were no longer accessible ten years later. A quarter of all webpages that existed at any point between 2013 and 2023 were gone by the time of the study. Fifty-four percent of Wikipedia articles contained at least one link in their references pointing to a page that no longer exists, and roughly a fifth of the government and news pages Pew sampled carried at least one broken link.[2] The numbers from industry are worse. Ahrefs, a company that crawls the web commercially and has no scholarly axe to grind, sampled links pointing to more than two million websites and found that 66.5 percent of the links created since 2013 had rotted.[3]
The digital humanities cannot claim immunity. Zach Coble and Jojo Karlin studied citations in Digital Humanities Quarterly, one of the field's flagship open-access journals, across articles published from its 2007 launch through 2019. Thirty-one percent of the citations containing links no longer worked correctly.[4] In a journal where digital humanists talk to each other about digital scholarship, nearly a third of the linked evidence has already slipped away. We are not even preserving our own conversation about preservation.
If you are writing a dissertation right now, this is not an abstract worry. The URLs in your bibliography have already started to rot, and some of them will be dead before your defense. Doctoral timelines run three to seven years, which is plenty of time for a fifth of your web citations to fail at the rates measured above. Your committee may never check, but the scholar in 2040 who wants to build on your third chapter will, and what she finds when she clicks will shape whether your work remains usable evidence or becomes an artifact that must be taken on faith. Later in this essay I will describe the tools that solve this problem at the moment of citation, because it is solvable, cheaply and today.
For a scholar, link rot is not an inconvenience. It is a hole in the argument. A citation is a promise to your reader: here is my evidence, go and check it. When the link dies, the promise dies with it. Your reader is left to take your word for what the source said, which is exactly the situation scholarly citation was invented to prevent.
Content Drift: The Page That Lies #
Link rot at least has the decency to announce itself. A 404 page tells you something is wrong. The subtler failure is content drift, and it deserves a precise definition because people constantly blur it into link rot. Content drift is what happens when the URL still resolves — the server answers, a page loads, everything looks fine — but the content at that address is no longer what the author cited. The link works. The evidence is gone.
The definitive study here is by Shawn M. Jones, Herbert Van de Sompel, and their colleagues, published in PLOS ONE in 2016 under a title that gives away the ending: "Scholarly Context Adrift: Three out of Four URI References Lead to Changed Content." Examining links in scholarly articles, they found that for more than 75 percent of references, the content had drifted away from what it was when the author cited it. As they put it, a reader who follows a link in an article some time after publication "is led to believe that the resource's content is representative of what the author originally referenced," when very often it is not.[5]
Drift is more corrosive than rot because it is invisible. Imagine you cite a denomination's statement on marriage from its official website, and three years later the denomination revises the statement after a contentious synod vote. Your citation now points to a text that says something different from the one you analyzed, with no notice to your reader and none to you. Anyone checking your work will conclude that you misread the source, or worse, misrepresented it. The page did not die. It changed underneath your footnote, which is a quieter kind of loss and a more dangerous one.
Religious studies scholars should feel this problem acutely, because so much of our source material now lives on exactly the kinds of pages that drift: congregational websites, diocesan announcements, statements from religious organizations, online devotional publications. These are working documents for the communities that publish them. They get revised, reorganized, and pruned without any obligation to the scholars who cited them. The web is a living archive maintained by people who never agreed to be an archive at all.
When the Stack Dies #
Links and pages are only the surface. Underneath every digital project sits a stack of technologies, and stacks die too. Sometimes they die suddenly and publicly, and sometimes they die the slow death of neglect, but either way they take scholarship with them.
The sudden deaths make the best cautionary tales. On December 31, 2020, Adobe ended support for Flash Player, and starting January 12, 2021, Adobe actively blocked Flash content from running in the player at all.[6] Flash was not a niche technology. For roughly two decades it was the default medium for interactive work on the web: animated timelines, clickable maps, games, digital art, museum kiosks, language-learning modules, and a whole generation of interactive scholarly projects. When Adobe pulled the plug, all of it stopped working at once. Not gradually. At once. A project built in Flash in 2008 did not degrade gracefully in 2021. It simply would not run.
The rescue efforts are instructive. In November 2020 the Internet Archive announced it would emulate Flash animations and games in the browser using an emulator called Ruffle, so that "Flash animations, games and toys" could live on without any plugin installed.[7] Rhizome, the born-digital art organization, did similar work with its web archiving tools, and its preservation director Dragan Espenschied was honest about the limits: Ruffle handles self-contained Flash files "quite splendidly," but emulation "always introduces an extra step to access," and none of the available emulators "will be able to reproduce the immediacy of Flash in its heyday."[8] That honesty matters. Emulation is a rescue operation, not a preservation strategy. If your plan for your project's afterlife is that someone will heroically emulate it later, you do not have a plan. You have a hope.
Java applets tell the same story with less drama. If you used the web in the early 2000s, you sat through the gray loading box of an applet embedding some interactive visualization into a page. Browser vendors dropped support for the underlying plugin architecture one by one, the applet API was deprecated in Java 9 in 2017, and by 2021 the OpenJDK project moved to strip it out entirely, noting that the API had become "essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so."[9] Every scholarly project built on applets — every interactive text tool, every early mapping experiment — went down with the plugin. The technology did not fail. It was withdrawn, by companies making reasonable business decisions that had nothing to do with scholarship.
Then there are the slow deaths, which are more common and less discussed. Most digital humanities projects of the 2005 to 2020 era were built on database-backed content management systems, usually Drupal, WordPress, or Omeka. These platforms are wonderful for building and terrible for lasting. They require constant security patching, and when the patches stop, the site becomes a liability. Drupal 7, which powered an enormous number of library and humanities sites, reached its official end of life on January 5, 2025, fourteen years after its release.[10] Every unmigrated Drupal 7 site on a university server is now unpatchable, which means every one of them is a security incident waiting to happen. When a campus IT department takes such a site down, it is not being philistine. It is doing its job. The scholarship just happens to be collateral.
Omeka deserves a special word here, because it is the platform closest to home for humanists, built by digital historians for exactly the exhibit-and-archive work our fields do. Omeka is good software, and an Omeka site is still a PHP application with a MySQL database that someone must patch, upgrade, and eventually migrate. In practice, that someone is usually one dependable person, a librarian or a technically inclined faculty member, and the site's real lifespan is the length of that person's job. The field runs to a remarkable degree on the unbudgeted goodwill of individuals. Goodwill is a lovely thing and a terrible infrastructure.
Database-backed sites also fail at migration time, and migration time always comes. A dynamic site is a running program, not a document. It needs a specific version of PHP, a specific database, specific server modules, and a specific configuration, and when the library moves to new infrastructure, some of those assumptions break. A plain HTML page written in 1996 still renders perfectly in any modern browser. A dynamic site built in 2016 may already be unservable. That asymmetry tells you most of what you need to know about designing for longevity.
The librarians who clean up afterward have started publishing their case notes. Kirsta Stapelfeldt and her colleagues at the University of Toronto Scarborough described rescuing a series of stranded projects: a Flash-based educational game, a Drupal mapping project on the history of a local Chinatown, a story map built on a hosted commercial platform. Their blunt assessment is that "the gradual disappearance of digital scholarship projects forms a gap in the scholarly record."[11] A gap in the scholarly record. That is the correct frame. When a monograph goes out of print, libraries still hold copies. When a digital project dies, there is often no copy anywhere, because nobody ever decided what a copy of it would even be.
Behind almost every one of these deaths is the same economic structure. Grants fund launches. Nothing funds maintenance. A project gets three years of money, a triumphant release, a conference paper, and then a cliff. The team disperses, the money is gone, and the site enters what preservationists politely call benign neglect. The problem is not that anyone behaved badly. The problem is that the entire funding system is arranged around beginnings, and preservation is a discipline of endings.
What Stability Looks Like #
So what actually lasts? The pattern in the wreckage is consistent, and you can state it in three preferences. Static over dynamic. Plain text over binary. Documented data over black-box platforms.
Static over dynamic means the site your project leaves behind should be a set of files, not a running program. A static site — plain HTML, CSS, and JavaScript, with no database and no server-side code — can be served by any web server ever written, copied with a single command, archived by the Wayback Machine in its entirety, and handed to a library as a folder. It has almost nothing that can break. A dynamic site is a performance that must be re-staged correctly every single day. A static site is a book on a shelf.
Plain text over binary means your data and your writing should live in open, human-readable formats: TEI or other XML, Markdown, CSV, JSON, plain UTF-8 text. Files like these can be opened by any editor on any machine, inspected without special software, tracked line by line in version control, and read by scholars fifty years from now with no archaeology required. Proprietary binary formats promise convenience today and demand emulation tomorrow. If you have ever tried to open a word-processor file from the early 1990s, you know which side of this bargain you want to be on.
Documented data over black-box platforms means the intellectual core of your project — the dataset, the transcriptions, the encoding decisions, the categories you built — should exist independently of whatever software currently displays it, and it should be documented well enough that a stranger could pick it up. I argued in Part 4 of this series that metadata is a knowledge-making practice rather than a clerical afterthought, and preservation is where that argument pays off. An undocumented dataset is a ruin without an inscription. The stones are there, but nobody knows what the building was for.
None of this is my invention. The clearest articulation of these principles comes from the Endings Project at the University of Victoria, a team of digital humanists, programmers, and librarians led by scholars including Martin Holmes and Janelle Jenstad, funded by the Social Sciences and Humanities Research Council to answer one question: how do you actually finish a digital project? Their published principles are bracingly concrete. Data should be "stored only in formats that conform to open standards." Products should have "no dependence on server-side software: build a static website with no databases, no PHP, no Python." Every release should be versioned and clearly identified, and pages should keep working even without JavaScript or CSS.[12] They call this designing for the ending, and they treat the ending not as failure but as a normal part of a project's life, the way a monograph has a final chapter.
The Endings team also gathered data on how bad the situation is. In a global survey of digital humanities practitioners conducted in 2017 and 2018, covering 127 projects, only about 24 percent of projects were considered complete, and fewer than half had any long-term preservation plan from the outset.[13] In the special issue of Digital Humanities Quarterly on project resiliency that grew out of this work, the editors offer an observation that ought to be printed on a poster in every DH lab: "The fewer flourishes in software, the longer the project seems to last."[14] Simplicity is the preservation strategy, not a compromise you settle for when the budget is small.
A Citation You Can Keep: Permalinks and Persistent Identifiers #
Stability of projects is half the problem. The other half is stability of reference, how you cite digital things so the citations still work in twenty years. Here the infrastructure already exists, and the failure is one of habit rather than technology.
The general solution is called a persistent identifier, and the idea is simple indirection. Instead of citing a location, which changes, you cite a name, which does not, and a resolver service maintains the mapping from name to current location. The most familiar persistent identifier is the DOI, the Digital Object Identifier, administered by the DOI Foundation and resolvable through doi.org.[15] When a journal moves to a new platform, every DOI pointing at its articles keeps working, because the publisher updates one registry instead of hoping every citation in the world updates itself. A DOI is only as durable as the institution behind it, but that is precisely the point. It converts a technical problem, where did the file go, into an institutional commitment, someone is responsible for this name.
DOIs have siblings worth knowing. The ARK, or Archival Resource Key, was created in 2001 by John Kunze and R. P. Channing Rodgers and stewarded by the California Digital Library, and it is widely used by libraries, archives, and museums, partly because assigning ARKs is free. The ARK specification states its founding principle in a line every digital humanist should memorize: persistence "is purely a matter of service," neither inherent in an object nor conferred by a naming syntax.[16] Nothing about a URL, a DOI, or an ARK is magically permanent. Permanence is a promise made by an organization, and identifiers are how organizations sign their promises. PURLs, persistent URLs, have offered similar redirection since 1995, first at OCLC and, since 2016, under the care of the Internet Archive.[17]
For the ordinary web pages you cite, the news story, the blog post, the denominational statement, there are two tools you should be using today. Perma.cc, built by the Harvard Library Innovation Lab in direct response to the link rot studies discussed above, lets you create an archived snapshot of a page at the moment you cite it, preserved by a network of libraries, with a permanent link you can put in your footnote.[18] And the Internet Archive's Wayback Machine remains the great safety net under the entire web. Its scale is hard to absorb. In mid-2025 the Internet Archive announced that the Wayback Machine was about to cross one trillion archived web pages, a milestone it marked that October.[19] You should not only rely on it passively. The Wayback Machine has a save-page feature, and archiving a page at citation time takes seconds. Make it a reflex, the way checking a quotation against the original is a reflex.
Here is the practice I want to argue for, stated as an obligation rather than a tip. If a DOI or other persistent identifier exists for a source, citing the bare URL instead is a scholarly failure, the same category of failure as citing a book without a page number. If no persistent identifier exists, creating an archived snapshot and citing it alongside the live URL is the minimum standard of care. We hold ourselves to exacting standards about editions and translations because we know texts are unstable and transmission is treacherous. The web is the most unstable textual medium humans have ever built. It deserves at least the rigor we give a medieval manuscript tradition, and for the same reason. The reader who comes after you has to be able to find what you found.
Where Projects Go to Live: Preservation Infrastructure #
Suppose you are persuaded. Your project's data is in open formats, your site can be flattened to static files, your documentation exists. Where does it all go? The good news is that the humanities do not have to build this infrastructure from scratch. Most of it already exists, much of it is free, and using it is easier than maintaining a server.
Zenodo is the general-purpose workhorse. It describes itself as "a free and open digital archive built by CERN and OpenAIRE, enabling researchers to share and preserve research output in any size, format and from all fields of research."[20] The physics laboratory that runs the Large Hadron Collider also runs a repository where a religious studies scholar can deposit a dataset, a codebase, a PDF, or a zipped snapshot of an entire website, and every deposit receives a DOI. Zenodo also handles versioning, so your dataset can grow while old citations keep pointing at the exact version a scholar used. If your code lives on GitHub, Zenodo can archive each release automatically. Ten minutes of setup buys your project a form of citability and durability that no departmental server will ever provide.
Dataverse serves a similar role with deeper roots in research data management. It is "an open source web application to share, preserve, cite, explore, and analyze research data," developed at Harvard's Institute for Quantitative Social Science, and it powers institutional data repositories at universities around the world.[21] Your own institution's repository, whatever software it runs, belongs in this list too. Institutional repositories are unglamorous, and they are also staffed by professionals whose actual job description includes keeping your deposit alive after you retire. Librarians have been preserving scholarship for centuries. Handing them a well-documented deposit is not outsourcing your responsibility. It is fulfilling it.
Underneath the repositories sits a deeper layer most scholars never see. LOCKSS, a system developed at Stanford, operates on the principle in its name, Lots Of Copies Keep Stuff Safe: libraries around the world hold synchronized, mutually auditing copies of published content, so no single failure can destroy the record.[22] Its sibling CLOCKSS runs a shared dark archive on the same technology, holding publisher content that is unlocked and made freely available if the publisher disappears.[23] The insight here is old. Redundant copying by distributed communities of custodians is how the classics survived antiquity and how scripture survived everything. Anyone whose work touches the history of religious texts already understands LOCKSS in their bones. Monasteries were a distributed preservation network with a strict replication protocol. We are relearning what scriptoria knew.
For humanists specifically, there is Knowledge Commons, the scholarly network formerly known as Humanities Commons, founded in 2016 under the Modern Language Association and now hosted at Michigan State University.[24] Its repository, CORE, gives every deposit a DOI and puts your work in an open, library-grade archive run by and for scholars rather than by a commercial publisher. For the many people in theology and religious studies who work outside big research universities, at seminaries and small colleges without institutional repositories of their own, CORE fills a real gap. Deposit the article preprint, the syllabus, the dataset, the conference paper. It costs nothing, and it means your work has an address that does not depend on your employment status.
And for the project as a whole, the Endings Project again offers the model: finish the project deliberately. Produce a final, versioned, static release. Archive it in a repository with an identifier. Document what it was, what it did, and what a future scholar can do with the data. A project that ends this way is not dead. It is complete, the way a published book is complete, and completeness is a far better afterlife than the long slow rot of an unmaintained server.
Projects Die of People Problems #
Everything so far sounds like a technical story, and I have told it that way deliberately, because the technical failures are visible and datable. But if you talk to the people who actually run long-lived projects, they will tell you that technology is the easy part. Projects die of people problems. They die of funding cliffs, staff turnover, and graduated students. The server outlives the community around it, and then, unattended, the server dies too.
The evidence here is more than anecdote. In 2014, Ithaka S+R published a study by Nancy L. Maron and Sarah Pickle with a title that names the wound: "Sustaining the Digital Humanities: Host Institution Support Beyond the Start-up Phase." Drawing on interviews with well over a hundred faculty, librarians, and administrators across four campuses, they found that institutions had built elaborate support for launching digital projects and almost nothing for sustaining them.[25] Everyone owns the beginning. Nobody owns year six. A university will happily issue a press release about a new digital archive and has no office whose job is to keep that archive alive when its creator takes a job elsewhere.
The University of Pittsburgh's Visual Media Workshop, led by Alison Langmead, turned this insight into a practical instrument called the Socio-Technical Sustainability Roadmap, built through an NEH-funded project between 2016 and 2018.[26] The roadmap's central move is in its name. Sustainability is socio-technical. It asks project teams the questions that feel rude at a launch party. How long do you intend this project to live? Who will do the work in year five, and what are they being paid? Which features will you let die first? If those questions have no answers, the project's lifespan is not unknown. It is short.
The librarian Lisa Goddard, writing in the Endings-adjacent literature, distills the whole argument into one line she borrows from the DOI Foundation: "persistence is a function of organizations, not a function of technology."[27] Files do not keep themselves. Institutions keep files, and institutions are made of budgets and job descriptions. Graduate students are the sharpest case of this. An enormous amount of digital humanities labor is performed by doctoral students, who are structurally guaranteed to leave. If a project's continuity plan is a person who will graduate, the plan has a built-in expiration date, and everyone involved knows the date. Building on graduate labor without a succession plan writes the departure into the project's architecture from day one.
And then there are the cliffs nobody can plan around. In April 2025, the Roy Rosenzweig Center for History and New Media reported that six of its NEH grants, totaling $789,000 in unspent funds, had been terminated in the federal government's mass cancellation of humanities funding. Among the terminated projects was American Religious Ecologies, which was digitizing the 1926 Census of Religious Bodies, a project close to the heart of anyone who works on American religion.[28] The center's director wrote about it publicly and without self-pity, describing how the center would carry on through donor support. The lesson is grim but clarifying. Even excellent stewardship at a well-run center cannot make a project safe from politics. Which is one more reason the work itself, the data and the code and the documentation, needs to live in places designed to outlast any single funder's mood.
What Doing It Well Looks Like #
It would be easy to end in gloom, so let me spend some time on the people who show what good stewardship looks like in practice. The digital humanities have exemplars, and they deserve to be named and praised.
Take the Roy Rosenzweig Center for History and New Media at George Mason University, mentioned above in sadder circumstances. Founded in 1994 by the historian Roy Rosenzweig with a mission to use digital media "to democratize history," RRCHNM is one of the oldest digital history centers in the world, and it has done something almost no one else has managed. It has kept its projects alive for decades.[29] Its September 11 Digital Archive, launched in January 2002 with the American Social History Project at CUNY, collected first-hand stories, emails, and images of the attacks, more than 150,000 digital items in all. In September 2003 the Library of Congress accessioned the archive, its first major digital acquisition, and the archive is still online and still serving researchers today, more than two decades after the towers fell.[30] Along the way RRCHNM built and released tools the whole field depends on, including Zotero, Omeka, and Tropy. What makes the center a model is not that it never struggles. It struggles constantly, and it writes about the struggles in public, including the unglamorous work of sustaining old projects on new infrastructure and the scramble that follows lost funding.[28:1] Honesty about maintenance is itself a contribution to the field. Most project websites perform success. RRCHNM documents survival, which is more useful.
Consider also Lincoln Mullen, professor of history at George Mason and RRCHNM's director, whose everyday practice is a model of preservation-friendly scholarship. His work lives in plain text and version control. His code is open source under permissive licenses on GitHub, his datasets are published openly, and his personal site is a static site generated from files anyone can inspect.[31] His project America's Public Bible, which tracks biblical quotations across millions of pages of nineteenth-century American newspapers, won first prize in the NEH's Chronicling America Data Challenge in 2016 and grew into a digital monograph published by Stanford University Press in 2023.[32] Look at how the project is put together. The website's prose is under copyright, the code is MIT licensed, and the underlying data is released into the public domain under CC0, all documented in a public repository with a suggested citation.[33] Every layer of the project can be inspected, downloaded, forked, and cited independently. If the website vanished tomorrow, the scholarship would survive, because the scholarship was never only the website. For religious studies readers this example is doubly instructive, since it shows that computational work on religion at the highest level and durable open practice are the same project, not competing priorities.
Then there is Knight Lab at Northwestern University, which I want to discuss with affection precisely because it complicates the story. Knight Lab makes some of the most beloved free tools in the digital humanities: TimelineJS, StoryMapJS, JuxtaposeJS, SoundciteJS. TimelineJS alone has been used by more than 250,000 people, in over sixty languages, to tell stories seen hundreds of millions of times.[34] If you have taught a DH-inflected course, you have probably assigned one of these tools, and your students probably loved it. The tools are open source, and the lab has been a generous citizen of the field.
Here is the complication, and it is not a criticism of Knight Lab. It is a lesson about dependency. These tools are hosted services. A TimelineJS timeline is typically driven by a published Google Sheet, which means your elegant class project depends on Google's continued support for that publishing feature and on Knight Lab's continued hosting of the rendering code. StoryMapJS projects are authored through and stored on Knight Lab's servers. Knight Lab is a university lab, staffed substantially by students, and university labs reorganize, lose funding, and change direction. None of this makes the tools bad. It makes them dependencies, and dependencies demand an exit strategy. If you build scholarship on a hosted tool, keep your own copy of the source data, export or snapshot the rendered result, and document what the tool did well enough that the work could be reconstructed. Enjoy the free infrastructure. Just do not confuse it with an archive, because its makers never promised you one.
Start With the Ending #
What should you actually do, especially if you are a graduate student or early-career scholar with a project in hand and no budget line for preservation? The advice compresses well, and none of it requires permission or money.
Plan the ending at the beginning. Before you build anything, write down how long the project should live, what its final form will be, and where that final form will be deposited. The Endings Project's principles are free, short, and battle-tested, and they are the assigned reading I would give any dissertation writer with a digital component.[12:1] Choose boring, open, plain-text formats for anything you cannot afford to lose, and let the flashy presentation layer be the disposable part. Keep the project under version control from the first day, because a Git repository is a complete, portable, self-documenting history of the work that can be archived anywhere. Write the README you would want to inherit, explaining what the data is, where it came from, what the fields mean, and what a stranger may do with it.
Cite digital things the way you would want your own work cited. When you cite a dataset, a code repository, a digital edition, or a website in your dissertation, cite it as scholarship, with a creator, a title, a version, a date, and a persistent identifier wherever one exists. I made this argument in Part 2 of this series in the context of dissertation tools, and it bears repeating here because citation is where preservation becomes contagious. Proper citation is how digital work gets counted in tenure files and grant reports, and work that counts is work someone will eventually pay to maintain. Every time you cite a dataset by its DOI instead of waving at a homepage, you make the scholarly record slightly more durable, and you cast a small vote for a field in which digital work is real work.
Then use the infrastructure that already wants to help you. Deposit versions of your data and code in Zenodo or your institutional repository and put the resulting DOIs in your dissertation, so that what you cite is what your readers can still find. Put your papers and preprints in Knowledge Commons CORE. Archive every important web page you cite with the Wayback Machine or Perma.cc at the moment of citation. When the project is done, flatten it. Produce a static final release, deposit it, give it an identifier, and write the short note that tells the future what it was. And in every grant application and project charter you ever write, include the afterlife as a line item, because a budget that funds only the launch is a plan for a beautiful ruin.
I said at the start that preservation is a scholarly question, and I will end with the reason I believe that so firmly, which is that religious studies taught it to me. Every tradition we study survived because someone treated transmission as sacred work. Texts endured through copying, glossing, cataloging, and care by communities who understood that keeping a thing alive is a form of honoring it, and that the copyist's labor was never lesser than the author's. The humanities' digital record deserves custodians with the same conviction. Preservation is not what happens after scholarship. It is scholarship, extended to the reader who has not been born yet.
That conviction raises an obvious question. If projects last longest when they are simple, static, and plain, why not design them that way from the very first line of code? That is exactly the wager of minimal computing, a movement within the digital humanities that treats constraint as a scholarly virtue, and it is where this series goes next. Part 6 will look at minimal computing and the work of Global Outlook::Digital Humanities, and at what it would mean to build projects that are born preservable.
In this series #
- Digital Humanities Part 1: What Are the Digital Humanities?
- Digital Humanities Part 2: Digital Humanities Tools for Dissertations
- Digital Humanities Part 3: Digital Humanities for Theology and Religious Studies
- Digital Humanities Part 4: Why We Need the Digital Humanities
- Digital Humanities Part 5: Preserving Digital Humanities Projects
- Digital Humanities Part 6: Preservation through Minimal Computing and GO::DH
Jonathan Zittrain, Kendra Albert, and Lawrence Lessig, "Perma: Scoping and Addressing the Problem of Link and Reference Rot in Legal Citations," Harvard Law Review Forum 127, no. 4 (February 2014), https://harvardlawreview.org/forum/vol-127/perma-scoping-and-addressing-the-problem-of-link-and-reference-rot-in-legal-citations/ ↩︎
Athena Chapekis, Samuel Bestvater, Emma Remy, and Gonzalo Rivero, "When Online Content Disappears," Pew Research Center, May 17, 2024, https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/ ↩︎
Patrick Stox, "At Least 66.5% of Links to Sites in the Last 9 Years Are Dead (Ahrefs Study on Link Rot)," Ahrefs Blog, April 29, 2022, https://ahrefs.com/blog/link-rot-study/ ↩︎
Zach Coble and Jojo Karlin, "Reference Rot in the Digital Humanities Literature: An Analysis of Citations Containing Website Links in DHQ," Digital Humanities Quarterly 17, no. 1 (2023), https://dhq.digitalhumanities.org/vol/17/1/000662/000662.html ↩︎
Shawn M. Jones, Herbert Van de Sompel, Harihar Shankar, Martin Klein, Richard Tobin, and Claire Grover, "Scholarly Context Adrift: Three out of Four URI References Lead to Changed Content," PLOS ONE 11, no. 12 (December 2, 2016), https://doi.org/10.1371/journal.pone.0167475 ↩︎
Adobe Inc., "Adobe Flash Player End of Life," January 13, 2021, https://www.adobe.com/products/flashplayer/end-of-life-alternative.html ↩︎
Jason Scott, "Flash Animations Live Forever at the Internet Archive," Internet Archive Blogs, November 19, 2020, https://blog.archive.org/2020/11/19/flash-animations-live-forever-at-the-internet-archive/ ↩︎
Dragan Espenschied, "Emulation or it Didn't Happen," Rhizome, December 21, 2020, https://rhizome.org/editorial/2020/dec/21/flash-preservation/ ↩︎
"JEP 398: Deprecate the Applet API for Removal," OpenJDK, 2021, https://openjdk.org/jeps/398 ↩︎
Drupal Association, "Drupal 7 End of Life Officially Announced for 5 January 2025," Drupal.org, August 14, 2023, https://www.drupal.org/association/blog/drupal-7-end-of-life-officially-announced-for-5-january-2025 ↩︎
Kirsta Stapelfeldt, Sukhvir Khera, Natkeeran Ledchumykanthan, Lara Gomez, Erin Liu, and Sonia Dhaliwal, "Strategies for Preserving Digital Scholarship / Humanities Projects," Code4Lib Journal, no. 53 (May 2022), https://journal.code4lib.org/articles/16370 ↩︎
The Endings Project, "Endings Principles for Digital Longevity," University of Victoria, https://endings.uvic.ca/principles.html ↩︎ ↩︎
The Endings Project, "Endings Project Survey Results," University of Victoria, https://endings.uvic.ca/survey.html ↩︎
Martin Holmes, Janelle Jenstad, and J. Matthew Huculak, "Introduction to Special Issue: Project Resiliency in the Digital Humanities," Digital Humanities Quarterly 17, no. 1 (2023), https://dhq.digitalhumanities.org/vol/17/1/000671/000671.html ↩︎
DOI Foundation, "The DOI System," https://www.doi.org/ ↩︎
John A. Kunze and R. P. C. Rodgers, "The ARK Identifier Scheme," IETF Internet-Draft, https://www.ietf.org/archive/id/draft-kunze-ark-34.html and ARK Alliance, "The ARK Origin Story," https://arks.cdlib.org/about/the-ark-origin-story/ ↩︎
Mark Graham, "Persistent URL Service, purl.org, Now Run by the Internet Archive," Internet Archive Blogs, September 27, 2016, https://blog.archive.org/2016/09/27/persistent-url-service-purl-org-now-run-by-the-internet-archive/ ↩︎
Harvard Library Innovation Lab, "Perma.cc," https://lil.law.harvard.edu/our-work/perma-cc/ ↩︎
Chris Freeland, "Wayback Machine to Hit 'Once-in-a-Generation Milestone' this October: One Trillion Web Pages Archived," Internet Archive Blogs, July 1, 2025, https://blog.archive.org/2025/07/01/wayback-machine-to-hit-once-in-a-generation-milestone-this-october-one-trillion-web-pages-archived/ ↩︎
Zenodo, "About Zenodo," CERN, https://about.zenodo.org/ ↩︎
The Dataverse Project, "About the Project," Institute for Quantitative Social Science, Harvard University, https://dataverse.org/about ↩︎
LOCKSS Program, "About LOCKSS," Stanford University Libraries, https://www.lockss.org/about ↩︎
CLOCKSS, "Frequently Asked Questions," https://clockss.org/faq/ ↩︎
Knowledge Commons, https://hcommons.org/ ↩︎
Nancy L. Maron and Sarah Pickle, "Sustaining the Digital Humanities: Host Institution Support Beyond the Start-up Phase," Ithaka S+R, June 18, 2014, https://sr.ithaka.org/publications/sustaining-the-digital-humanities/ ↩︎
Visual Media Workshop, "The Socio-Technical Sustainability Roadmap," University of Pittsburgh, https://sites.haa.pitt.edu/sustainabilityroadmap/about/ ↩︎
Lisa Goddard, "What's Left When It's Over: Libraries and Digital Humanities Project Preservation," IDEAH 3, no. 5, July 18, 2023, https://ideah.pubpub.org/pub/mfid9ero/release/1 ↩︎
Lincoln Mullen, "Carrying On When the Grants Go Away," Roy Rosenzweig Center for History and New Media, April 11, 2025, https://rrchnm.org/blog/carrying-on-when-the-grants-go-away/ ↩︎ ↩︎
Roy Rosenzweig Center for History and New Media, "Our Story," George Mason University, https://rrchnm.org/our-story/ ↩︎
"September 11 as History," Library of Congress Information Bulletin, October 2003, https://www.loc.gov/loc/lcib/0310/911.html and The September 11 Digital Archive, https://911digitalarchive.org/ ↩︎
Lincoln Mullen, personal website and code repositories, https://lincolnmullen.com/ and https://github.com/lmullen ↩︎
National Endowment for the Humanities, "NEH Announces Winners of Chronicling America Data Challenge," July 25, 2016, https://www.neh.gov/news/press-release/2016-07-25 ↩︎
Lincoln A. Mullen, America's Public Bible: A Commentary (Stanford, CA: Stanford University Press, 2023), code and data repository at https://github.com/lmullen/americas-public-bible ↩︎
Knight Lab, Northwestern University, https://knightlab.northwestern.edu/ ↩︎
Tags : digital-humanities digital-preservation scholarly-communication minimal-computing religious-studies
Webmentions
No webmentions yet.