Table Of Contents
This is the sixth and final essay in a series on the digital humanities. Part 1 asked what the digital humanities are. Part 2 surveyed tools for dissertations. Part 3 brought the conversation home to theology and religious studies. Part 4 made the case for why we need this work at all. Part 5 faced the uncomfortable truth that most digital projects die, and argued that preserving them is itself a form of knowledge-making. This essay is the constructive answer to Part 5's diagnosis. If digital projects die because we build them too big, too fragile, and too dependent on money and machines that will not last, then the cure is to build small, plain, and durable from the start. Two communities have spent the last decade working out what that looks like in practice: Global Outlook::Digital Humanities and the minimal computing working group that grew out of it.
I want to make the argument plainly before I make it at length. Preservation is not a chore you perform at the end of a project. It is a set of decisions you make at the beginning, and the communities best positioned to teach us those decisions are not the best-funded labs in North America and Europe. They are the scholars who never had the luxury of assuming fast networks, new hardware, stable power, and permanent staff. Constraint taught them what is necessary. The rest of us, flush or not, should listen.
Where Part 5 Left Us #
Part 5 ended with a list of failure modes, and it is worth restating them because everything in this essay answers one or more of them. Digital projects die when their databases rot and no one is left who knows the schema. They die when the content management system needs a security patch that never comes, and the hosting institution quietly takes the site down rather than risk a breach. They die when the grant ends and the server bill comes due. They die when the one graduate student who understood the custom code graduates. They die when a platform company pivots, gets acquired, or shuts off an API. And they die in a quieter way when web archives try to capture them and cannot, because the content lives behind JavaScript queries and login walls that a crawler cannot follow.
Notice what all of these have in common. None of them is a failure of scholarship. The research was sound. The editions were careful. The maps were accurate. What failed was the stack, the pile of software and services and salaries that the scholarship was balanced on top of. Every layer in that pile is a promise someone has to keep, and promises lapse. A database is a promise that someone will keep migrating it. A CMS is a promise that someone will keep patching it. A server is a promise that someone will keep paying for it. Part 5 argued that we should treat preservation as knowledge-making, as real intellectual work rather than janitorial afterthought. This essay argues something more specific. The most reliable way to keep a promise is to need fewer of them. Choose the smallest adequate toolchain, and the pile gets short enough that one scholar, or one small department, can actually hold it up for decades.
That phrase, the smallest adequate toolchain, is doing real work. Small alone is not the goal. A project that cannot do what the scholarship requires has failed differently but just as surely. The discipline is in the word adequate. You figure out what the work actually needs, you meet that need, and you stop. It sounds obvious. Almost no one does it. And the people who have thought hardest about how to do it came to the problem not from preservation anxiety but from a question about global equity.
Global Outlook::Digital Humanities #
In January 2013, the Alliance of Digital Humanities Organizations announced the creation of its first Special Interest Group, Global Outlook::Digital Humanities, usually shortened to GO::DH.[1] ADHO describes it as "a Community of Interest whose purpose is to help break down barriers that hinder communication and collaboration among researchers and students of the Digital Arts, Humanities, and Cultural Heritage sectors in High, Mid, and Low Income Economies."[2] Read that sentence again and notice what it does not say. It does not say GO::DH exists to help poor countries do digital humanities. The founding announcement made the point explicitly: "It is not an aid programme. Instead it recognises that work is being done in many countries and regions and that we all have much to learn from each other."[1:1]
That sentence is the ethos of the whole enterprise. Every member has something to offer and something to learn, whatever the GDP of the country they work in. Daniel Paul O'Donnell, the founding chair, told an interviewer in 2013 how the group came together out of three experiences: conversations at the DH2012 conference in Hamburg about collaboration with scholars in China and Taiwan, his encounter with Alex Gil's project mapping digital humanities work around the world, and a December 2012 meeting with researchers in Havana. What struck him in Cuba was not deficit but kinship. The experiences were symbiotic, he recalled: "we shared many problems and approaches, and, where our experiences and opportunities differed, we were richer for the discovery."[3] The group ran on volunteer labor and a few thousand dollars from the University of Lethbridge, which is itself a small lesson in adequacy.
O'Donnell and his collaborators, including Gil, Katherine Walter, and Neil Fraistat, laid out the intellectual case in a chapter called "Only Connect: The Globalization of the Digital Humanities."[4] The argument, compressed, is that digital humanities as institutionalized in North America and Europe had mistaken itself for the whole field, when in fact digital scholarship was happening everywhere, under different names, in different languages, and under different constraints. The field's centers of gravity had mistaken their local conditions for universal ones, treating fast networks, grant economies, and English as givens.
GO::DH set out to correct that by doing things rather than issuing statements. Gil's project Around DH in 80 Days, launched in 2014, published a new digital humanities project from somewhere in the world every day for eighty days, a simple, cheerful, and quietly devastating demonstration that the field was already global.[5] The group ran an essay prize in its first year and received 53 entries in seven languages, with first prizes going to scholars in France, Australia, the United States, and India.[6] At the DH2014 conference in Lausanne, volunteers wearing badges offered live whispered translation for attendees, an experiment the community called DH Whisperers, and the enthusiasm it revealed grew into the GO::DH Translation Toolkit, a catalog of tools and practices for multilingual conferences, journals, and projects.[7] The toolkit's authors insist that "the labor of translation in DH cannot be delegated to a group," meaning it is everyone's job, not a service performed by the margins for the center.[7:1]
You might reasonably ask what any of this has to do with preservation. Here is the connection, and it is the hinge of this essay. When GO::DH members compared notes across high, mid, and low income economies, the differences that mattered most were infrastructural. Bandwidth. Hardware. Power. Server money. Institutional support. A scholar in Lethbridge and a scholar in Havana could share methods and questions, but they could not share assumptions about what a computer could be counted on to do. So GO::DH chartered a working group to think about exactly that problem, computing under constraint. They called it minimal computing. And it turned out that designing for scholars with little produced exactly the durability that scholars with much had been failing to achieve.
Minimal Computing: What Do We Need? #
The minimal computing working group maintains a wiki, originally published under GO::DH's own domain and now at minicomp.github.io/wiki, that serves as the community's commonplace book.[8] Its self-description is careful. "We use 'minimal computing' to refer to computing done under some set of significant constraints of hardware, software, education, network capacity, power, or other factors."[8:1] The definition is deliberately broad because the group noticed early that minimalism means different things depending on who is being minimal and why. The wiki notes that minimal computing covers both "the maintenance, refurbishing, and use of machines to do DH work out of necessity along with the use of new streamlined computing hardware like the Raspberry Pi or the Arduino micro controller to do DH work by choice."[8:2] Necessity and choice, the Havana case and the Lethbridge case, gathered under one tent.
The founding provocation came from Alex Gil, then at Columbia University Libraries and a co-chair of GO::DH, in a short 2015 essay called "The User, the Learner and the Machines We Make."[9] Gil's move was to shift the conversation away from features and toward sufficiency. "I prefer to approach minimal computing around the question 'What do we need?'" he wrote, and he was explicit about who the we is: "When I ask 'what do we need?' I'm asking scholars around the world—librarians, professors, students, cultural workers, independent: What is enough?"[9:1] He refused to let the question harden into doctrine. Minimal computing, he wrote, "does not stand in as a universal call, but rather as a space for new questions and practices, an injunction to constantly repeat the question, 'what do we need?'"[9:2]
The question sounds humble. It is actually radical, because almost nothing in academic technology is built by asking it. Projects get built by asking what would be impressive, what the grant reviewers will reward, what the vendor is selling, what the lab down the hall just launched. "What do we need?" cuts through all of that. Ask it plainly about a digital scholarly edition and the answers are short. Readable text. Stable addresses. Notes and apparatus. A way for readers to find it. Nothing in that list requires a database, an application server, or a subscription.
Jentery Sayers, who co-chaired the working group with John Simpson, complicated the picture productively in a 2016 essay called "Minimal Definitions."[10] Sayers showed that "minimal" fans out into many distinct commitments that do not always agree with each other. "To me, minimal computing immediately suggests minimal design, especially as it pertains to workflow and communication," he begins, and then keeps going: minimal use, minimal consumption, minimal maintenance, minimal internet, minimal externals, minimal automation, minimal technical language, and more.[10:1] On maintenance, the concern closest to this series, he observes that "we might say that minimal computing simply decreases the maintenance of machines and related configurations/formats."[10:2] The essay's real lesson is that you cannot minimize everything at once. Minimizing your own labor might mean maximizing a dependency on someone else's platform. Minimizing bandwidth might mean minimizing images your argument needs. Minimal computing is not a checklist. It is a habit of asking which constraints matter for this project, in this place, for these readers.
The most mature statement of the field came in 2022, when Digital Humanities Quarterly published a special issue, volume 16 number 2, called "The Questions of Minimal Computing," edited by Roopika Risam and Alex Gil.[11] Their introduction distills a decade of practice into a compact framework. "Minimal computing connotes digital humanities work undertaken in the context of some set of constraints," they write, and they name the stakes without flinching: "In environments in which we are contending with limitations, whether of infrastructure, finances, labor, and/or technical knowledge, among other factors, we simply cannot have it all."[11:1] Gil's founding question anchors the whole issue. "'What do we need?' is a question that echoes throughout essays and case studies in this special issue," the editors note, and they sharpen it against its opposite. The minimal in minimal computing "stands in stark contrast to an implied 'maximal,' where 'maximal' connotes design choices that are made without putting the question of what is necessary and sufficient at the heart of decision-making."[11:2]
Maximal computing, in other words, is not a strawman. It is the default. It is what happens when nobody asks the question. And the special issue is honest about minimal computing's own tradeoffs. Quinn Dombrowski's essay in the issue, pointedly titled "Minimizing Computing Maximizes Labor," argues that stripping away infrastructure does not make work disappear, it moves the work onto people, often the same overextended people the movement means to liberate.[12] A static site with no CMS has no login screen, but it also has no edit button for the colleague who never learned Git. That critique is worth keeping in view. Minimal computing done thoughtlessly just relocates fragility from machines to humans. Done well, it puts the labor where labor can actually be sustained, in skills that are common, documented, and transferable rather than in systems that are rare, opaque, and rented.
What This Looks Like in Practice #
So far this could sound like theory. It is not. Minimal computing has a mature, working toolkit, and most of it is free in both senses.
Start with the writing itself. Minimal computing projects almost universally begin with plain text, usually in Markdown, a lightweight markup you can learn in an afternoon and read without any software at all. Plain text is the most durable digital format we have. Files written forty years ago open today on any machine, which is a claim no database export or word processor format can make. Markdown adds just enough structure, headings, links, emphasis, footnotes, to carry scholarly prose, and because the source is human-readable, the format cannot hold your work hostage. If every Markdown renderer on earth vanished tomorrow, your files would still say what they say.
Then comes the static site generator, the workhorse of the whole movement. A static site generator takes your folder of plain text files, runs once on your own machine, and produces ordinary HTML pages. Jekyll is the elder of the family and the one GitHub Pages runs natively, which means GitHub will rebuild and host a Jekyll site for free every time you push a change.[13] Eleventy is a newer, lighter option in JavaScript, and Hugo is famously fast and ships as a single executable.[14] The differences matter less than what they share. The output is plain HTML, CSS, and a little JavaScript. There is no application running on the server, because there does not need to be a server in any meaningful sense at all, just a place that hands files to browsers.
On top of the generators, the minimal computing community has built scholarly tools with real disciplinary intelligence. Wax, a project led by Marii Nyröp at New York University with Alex Gil, is "an extensible workflow for producing scholarly exhibitions with minimal computing principles."[15] It gives you what a digital collections platform gives you, image collections at archival quality served through the IIIF standard, item metadata, search, without the platform. The output is a static site you can host anywhere. Ed., a Jekyll theme Gil built for textual editions, makes the preservation argument right in its documentation. It is "designed for textual editors based on minimal computing principles, and focused on legibility, durability, ease and flexibility," and it produces "static pages whose rate of decay is substantially lower than database-driven systems."[16] Rate of decay is exactly the right metric, and it is telling that a tool for editing poetry is the software that names it honestly.
It helps to see the whole workflow in miniature, so picture a project many readers of this series might actually build, a digital edition of a nineteenth-century preacher's sermon collection. You transcribe the sermons into Markdown files, one per sermon, with a few lines of metadata at the top of each, date, place, scripture text, source archive. The folder of transcriptions goes into a Git repository, which from that moment is the project's permanent record. You drop the Ed. theme into the folder, run Jekyll once, and you have a readable, searchable, citable edition with a table of contents and stable URLs for every sermon. You push it to GitHub Pages and it is published, at no cost, over an encrypted connection, on infrastructure as fast and reliable as anything your library could rent. Total software learned: Markdown, which takes an afternoon, and enough Git to commit and push, which takes another. Total recurring cost: nothing. Total running services you are now responsible for: none. When you add sermon twenty-three next spring, you write it, commit it, and push. That is the entire maintenance story, and it will still be the entire maintenance story in fifteen years.
Now line this toolkit up against Part 5's failure modes, one by one, because this is the payoff of the whole series.
The database rots. There is no database. Your content is a folder of text files, and the published site is a folder of HTML files. Both can be copied, moved, and opened anywhere, by anyone, indefinitely.
The CMS needs patching. Nothing here needs patching, because nothing is running. A static site has almost no attack surface, because there is no login to breach, no plugin to exploit, no admin panel to probe. Nobody takes your site down as a security risk, because it is not one.
The grant ends and the server bill comes due. Static hosting is free or nearly free, on GitHub Pages and its peers, precisely because serving flat files costs providers almost nothing. A project that costs nothing to keep alive does not need a budget line to survive, which means it does not die when the budget does.
The one person who understood the system leaves. The system is plain text, a folder structure, and one well-documented generator with an enormous public user base. Any successor who can use a text editor can maintain it, and the version history, if you keep the source in Git, is the documentation of every decision ever made.
The platform shuts down. There is no platform. If your host disappears, you move the folder. Every internal link still works, every page is still there, and the migration takes an afternoon instead of a funded year.
The web archive cannot capture it. This one matters more than people realize. Crawlers like the Internet Archive's struggle with content assembled by JavaScript queries against a live backend, which is why so many elaborate digital projects survive in the Wayback Machine only as broken shells. A static site is the easiest possible thing to crawl, because what the crawler sees is the whole site. Build minimally and the world's archives preserve you for free, without being asked.
None of this is hypothetical. It is how a growing share of careful digital scholarship already works, and it is why the Endings Project at the University of Victoria, which has done the most systematic thinking anywhere about how digital projects should conclude, arrives at the same architecture from the preservation side. The Endings principles are blunt in a way academic guidelines rarely are: "No dependence on server-side software: build a static website with no databases, no PHP, no Python." And again: "No boutique or fashionable technologies: use only standards with support across all platforms."[17] Two communities, one asking what scholars with little can build and the other asking what scholars' work needs to survive, converged on the same answer. That convergence is the strongest evidence I know that the answer is right.
Justice, Not Austerity #
Here I want to guard against a misreading. It would be easy to hear all of this as an aesthetic, a sort of digital Shaker furniture, or worse, as austerity dressed up as virtue, telling underfunded scholars to be grateful for less. That gets the movement exactly backwards, and the people who built it have said so from the start.
Minimal computing came out of GO::DH, which means it came out of the concrete experience of scholars working with low bandwidth, aging hardware, intermittent power, and institutions that could not promise a server would exist next year. For a scholar on a slow connection, a lean static page is not a style choice. It is the difference between a site that loads and a site that does not. For a department whose electricity fails in the afternoon, software that runs on a modest laptop and publishes to free hosting is not minimalism. It is access. Risam and Gil's introduction keeps the ledger honest, naming "infrastructure, finances, labor, and/or technical knowledge" as the constraints in play and refusing the fantasy that any project escapes all of them.[11:3]
The justice argument runs in both directions, and this is the part the well-funded should sit with. When scholars in wealthy institutions build maximally, they do not only endanger their own work. They set the field's default expectations, and those expectations become gatekeeping. If a real digital project is assumed to need a development team, a server budget, and a grant, then most of the world's scholars are defined out of doing real digital projects, and their institutions are defined out of hosting them. Building small is a way of keeping the field's front door wide. A methodology that a graduate student in Colombo can practice on a secondhand laptop, publish for free, and maintain alone is a methodology the whole discipline can share. One that requires a lab is not.
Language sits inside this argument too. GO::DH's translation work and the multilingual entries in Around DH in 80 Days both insist that a global field must be multilingual in its infrastructure, not just in its sentiments.[5:1][7:2] Plain text helps here in an unglamorous way. Unicode text files handle the world's scripts without a plugin or a locale pack, and a static site serves Tamil or Yoruba or Arabic exactly as cheaply as it serves English. This is also where the critical DH literature this series leaned on in Part 4 connects. The scholars gathered in Global Debates in the Digital Humanities, edited by Domenico Fiormonte, Sukanta Chaudhuri, and Paola Ricaurte, have documented how deeply the field's infrastructure encodes the asymmetries of access, language, and power between its centers and its supposed peripheries.[18] Minimal computing is one of the few practical programs that answers that critique with a build instruction rather than a lament.
So the point is not that constraint is good for the soul. The point is that infrastructure choices are ethical choices, and the practices developed by scholars who had no choice about their constraints turn out to be better practices for nearly everyone, including the preservation of the work itself. Necessity was the teacher. Durability is the lesson.
Minimal Computing for Theology and Religious Studies #
Part 3 argued that theology and religious studies are natural homes for digital scholarship. I want to close that loop, because our fields have particular reasons to take this essay's argument personally.
Start with our materials. Religious studies is multilingual by constitution. The texts we study move among Hebrew, Greek, Arabic, Sanskrit, Pali, Ge'ez, Classical Chinese, and dozens of living vernaculars, often within a single project. Every layer of software you add to a project is another layer that can mishandle a script, mangle a right-to-left passage, or silently normalize a diacritic that carried meaning. Plain Unicode text handles all of it, and a static page serves a Syriac hymn as faithfully and cheaply as an English abstract. The less machinery between your sources and your readers, the fewer places for the languages to break.
Then consider our colleagues. The study of religion is one of the most globally distributed conversations in the academy, and much of the most important work on lived religion happens exactly where GO::DH's mid and low income members work, in institutions without server budgets or digital humanities centers. A seminary in Nairobi, a Buddhist studies program in Colombo, a scholar of Candomblé in Salvador documenting a terreiro's archive, these are not edge cases for our field. They are the field. Methods that require a funded lab exclude them structurally. Methods built from plain text and free hosting do not. If Part 4's argument was that the digital humanities need critical attention to global asymmetry, this is what acting on that argument looks like for us in particular.
And consider our time horizons. Scholars of religion think in centuries by professional habit. We work on texts that survived because communities copied them onto durable media and kept the copies moving. It should unsettle us that the scholarly editions we make of those texts are often the most fragile link in their transmission history, dependent on a database license and a hosting contract. A two-thousand-year-old psalm deserves better than a five-year platform. The manuscript cultures we study already teach the minimal computing lesson: simple formats, many copies, low dependence on any single institution, and a bias toward media that degrade slowly. A folder of Markdown files in version control, published statically and deposited in a repository, is the nearest thing our moment has to that tradition of transmission.
The practical openings are everywhere once you look. A minimal edition of a sermon collection in Ed. A Wax exhibit of devotional objects photographed during fieldwork, with IIIF images that other scholars can cite and reuse. A congregation's records, digitized and published as a static archive a volunteer can maintain after the grant student graduates. A multilingual glossary of liturgical terms that loads instantly on a phone in a place where phones are the internet. None of these needs permission, a committee, or a line item. All of them can outlive their makers, which is, after all, the kind of survival our sources themselves have modeled for millennia.
People and Places Doing It Right #
Arguments are easier to trust when you can point to people living them, so let me praise three by name.
Lincoln Mullen, a historian of American religion at George Mason University and executive director of the Roy Rosenzweig Center for History and New Media, has spent his career demonstrating what plain-text computational scholarship in public looks like.[19] His project America's Public Bible tracks the presence of biblical quotations in millions of pages of historical American newspapers, and it is exemplary twice over. Once as scholarship, an early prototype won the National Endowment for the Humanities' Chronicling America Data Challenge in 2016, and the finished work appeared as a born-digital monograph with Stanford University Press. And once as practice, because the code and data behind it sit in the open on GitHub, where anyone can inspect the methods, rerun the analysis, or learn from the workflow.[20] For a religious studies scholar wondering what this series' methods look like at full maturity in our own field, Mullen is the standing answer. His GitHub account is a public lab notebook. That transparency is minimal computing's social side, scholarship whose workings are legible because its materials are plain.
Mullen's institutional home deserves its own praise. The Roy Rosenzweig Center for History and New Media, founded by Roy Rosenzweig at George Mason in 1994, has probably done more than any single institution to give humanists open infrastructure.[21] Zotero, the citation manager this series recommended back in Part 2, came out of RRCHNM. So did Omeka, the collections publishing platform that powers thousands of library and museum exhibits, and Tropy, which brings order to the photographs every archival researcher hauls home. These tools are free, open source, and built by people who understand scholarly work because they do scholarly work. RRCHNM's whole history is a proof that academic infrastructure can be a public good rather than a leased service.
And credit where it is due to Northwestern University's Knight Lab, whose TimelineJS, StoryMapJS, and JuxtaposeJS have carried more humanities storytelling onto the web than almost anything else, precisely because they ask so little of their users.[22] A scholar with a spreadsheet can have a polished interactive timeline in an hour, no code, no budget. That generosity is real and I do not want to undersell it. But Knight Lab's tools are also a good place to practice Part 5's discipline, because the standard embeds depend on Knight Lab's servers continuing to exist and to serve them. The projects are open source, so the escape hatch exists. If your timeline matters to your scholarship, plan its minimal-computing exit, self-host the library or export the underlying data so that the day the service sunsets, your work does not sunset with it. Generous tooling still deserves an exit plan. Nothing in this series is a criticism of these builders. It is a reminder that even the best-run service is a promise, and archives should not run on promises.
A Playbook for Ending Well #
Everything above condenses into practice you can adopt this week. Consider this the closing playbook of the series, six habits, in roughly the order they enter a project's life.
First, write in plain text. Markdown for prose, CSV for tabular data, TEI XML if your editing tradition calls for it. The test is always the same. Could a stranger in thirty years open this file with whatever they have and understand it? If the answer requires naming a company, choose differently. Your dissertation notes, your transcriptions, your metadata, all of it can live in formats that no vendor can orphan.
Second, keep your sources in version control. Git costs nothing and a public or private GitHub repository gives you, for free, the three things projects die without: an off-site copy, a complete history of every change, and a path for collaborators or successors to take over cleanly. Version control is often sold to humanists as a collaboration tool. Think of it instead as continuity insurance. The repository is the project. Everything else is a rendering.
Third, publish static. Run your Markdown through Jekyll, Eleventy, or Hugo, and put the result on GitHub Pages or any host that serves flat files.[13:1] Resist every feature that requires something to be running on a server, and when a feature seems to demand it, ask Gil's question first. What do we need? Search can be a pre-built index. Comments can be an email address. Maps can be static images with a link to the interactive version. You will be surprised how often the need dissolves under the question.
Fourth, use persistent identifiers. Link rot is preservation failure at retail scale, and the antidote is boring discipline. Keep your URLs stable and human-readable, never break an address you have published, and when you cite the work of others, prefer DOIs and archived links so your footnotes outlive other people's hosting decisions. The Endings Project's rule that every entity should have "a unique page with a simple URL" is as much about citability as durability.[17:1]
Fifth, deposit your work. A website, even a durable one, should not be the only copy. Knowledge Commons, the scholarly network at hcommons.org that grew out of Humanities Commons, runs CORE, "a library-quality repository for sharing, discovering, retrieving, and archiving digital work."[23] Deposit the finished article, the dataset, the site's source, and your work gains a stable, citable home in institutional-grade infrastructure that is not a commercial platform and does not depend on your personal hosting arrangements. For scholars in theology and religious studies, whose societies increasingly maintain a presence there, it is the natural first shelf.
Sixth, plan the ending from day one. This is the Endings Project's great reframing, and the deepest single idea I know in digital preservation.[17:2] A digital project is not a garden that grows forever. It is a book that takes longer to finish. Write into your project charter, on the first page, what done will look like: a final static release, validated and archived, hosted cheaply, deposited in a repository, citable forever. Projects with defined endings can end well. Projects without them can only be abandoned. The difference between an ending and an abandonment is the difference between a monument and a ruin, and it is decided at the beginning, not the end.
A seventh habit runs underneath the other six, and Dombrowski's labor critique is the reason to name it. Document as you go, in the same plain text as everything else. A README at the top of the repository that says what the project is, how to build it, and what each folder contains costs an hour and repays it a hundredfold, because minimal computing's real dependency is not software but memory. The system is simple enough for a successor to maintain only if the successor can find out how it works without you in the room. Write the README for a stranger. Eventually, one way or another, a stranger is who will read it, even if that stranger is you in a decade.
None of these habits requires a grant. None requires a developer. None requires permission. That is the point. Preservation through minimal computing is the rare methodological reform that is more available to the underfunded than its alternative.
Practicing What This Essay Preaches #
There is a small recursive pleasure in how you are reading this. This essay was written in Markdown, one plain text file, portable to anywhere, and it is rendered on a static site by markdown-it, with the footnotes you have been clicking generated by markdown-it-footnote. There is no database behind this page and no CMS in front of it. The scholarly apparatus, every citation below, travels inside the text file itself as plain footnote syntax, which means the argument and its evidence cannot be separated by a platform migration. If this site's host vanished tomorrow, this essay would move intact, footnotes and all, in seconds. The form of the essay is the argument of the essay. What do we need? For six essays on the digital humanities, we needed text files and a folder. That was enough, and enough is the whole idea.
Closing the Series #
Six essays ago, this series began with a definitional question, and it seems right to end by watching how the answers stack. Part 1 argued that the digital humanities are not a gadget collection but a scholarly practice, humanistic questions pursued with computational means. Part 2 got practical, showing how that practice serves the longest project most scholars ever undertake, the dissertation. Part 3 claimed the work for theology and religious studies in particular, fields whose texts, communities, and material cultures reward digital attention as richly as any. Part 4 stepped back to make the case for why the humanities need these methods, and took seriously the critical scholars who warn that the field's infrastructure carries the world's inequities inside it. Part 5 faced the mortality of digital projects and insisted that preserving them is knowledge-making, not maintenance. And this essay has argued that the practices most likely to make our work last, plain text, small tools, static publication, planned endings, are the same practices that make the field most open to the world's scholars, because they were forged by communities, GO::DH and minimal computing, who asked what we need instead of what we can get.
If you have read all six parts, you have watched an argument assemble itself. If you are arriving here first, the practical upshot fits in a sentence. Start your next project by asking what you need, write the answer in plain text, keep it in version control, publish it statically, deposit a copy, and decide on day one what finished will look like. You can begin this afternoon. The tools are free, the skills are learnable in a weekend, and the communities named in this essay have already written the documentation, which is one more thing to admire about them.
That convergence is where I want to leave you. Durability and justice turn out to be the same discipline. Build small enough to keep, and you have built open enough to share. Ask what you need, and mean the question, at the start of every project, and the answer will usually be less than you feared and enough for more than you hoped. The digital humanities do not need to be big to matter. They need to last, and they need to belong to everyone. Those two goals, it turns out, have the same architecture.
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
Alliance of Digital Humanities Organizations, "Global Outlook::Digital Humanities (GO::DH) Special Interest Group Created," ADHO, January 13, 2013, https://adho.org/2013/01/13/global-outlookdigital-humanities-godh-special-interest-group-created/. ↩︎ ↩︎
Alliance of Digital Humanities Organizations, "Global Outlook::Digital Humanities," ADHO, https://adho.org/go-dh/. ↩︎
"Bringing Diversity of Experience Together: An Interview with Daniel O'Donnell," 4Humanities, May 2013, https://4humanities.org/2013/05/interview-daniel-o-donnell/. ↩︎
Daniel Paul O'Donnell, Katherine L. Walter, Alex Gil, and Neil Fraistat, "Only Connect: The Globalization of the Digital Humanities," in A New Companion to Digital Humanities, ed. Susan Schreibman, Ray Siemens, and John Unsworth (Wiley-Blackwell, 2016), https://onlinelibrary.wiley.com/doi/10.1002/9781118680605.ch34. ↩︎
Alex Gil et al., "About," Around DH in 80 Days, 2014, https://arounddh.org/about/. ↩︎ ↩︎
Alliance of Digital Humanities Organizations, "Global Outlook::Digital Humanities Announces Essay Prize Winners," ADHO, December 2013, https://adho.org/announcements/2013/global-outlookdigital-humanities-announces-essay-prize-winners. ↩︎
Global Outlook::Digital Humanities, "About," The Translation Toolkit, https://go-dh.github.io/translation-toolkit/about/. ↩︎ ↩︎ ↩︎
Global Outlook::Digital Humanities Minimal Computing Working Group, "About," Minimal Computing, https://go-dh.github.io/mincomp/about/. ↩︎ ↩︎ ↩︎
Alex Gil, "The User, the Learner and the Machines We Make," Minimal Computing, May 21, 2015, https://go-dh.github.io/mincomp/thoughts/2015/05/21/user-vs-learner/. ↩︎ ↩︎ ↩︎
Jentery Sayers, "Minimal Definitions," Minimal Computing, October 2, 2016, https://go-dh.github.io/mincomp/thoughts/2016/10/02/minimal-definitions/. ↩︎ ↩︎ ↩︎
Roopika Risam and Alex Gil, "Introduction: The Questions of Minimal Computing," Digital Humanities Quarterly 16, no. 2 (2022), https://digitalhumanities.org/dhq/vol/16/2/000646/000646.html. ↩︎ ↩︎ ↩︎ ↩︎
Quinn Dombrowski, "Minimizing Computing Maximizes Labor," Digital Humanities Quarterly 16, no. 2 (2022), https://digitalhumanities.org/dhq/vol/16/2/000594/000594.html. ↩︎
GitHub, "About GitHub Pages and Jekyll," GitHub Docs, https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/about-github-pages-and-jekyll. ↩︎ ↩︎
Jekyll, https://jekyllrb.com/. Eleventy, https://www.11ty.dev/. Hugo, https://gohugo.io/. ↩︎
Minimal Computing Working Group, "Wax," Minimal Computing Wiki, https://minicomp.github.io/wiki/wax/. See also Wax's credits, which name Marii Nyröp as lead and Alex Gil as maintainer, https://github.com/minicomp/wax. ↩︎
Minimal Computing Working Group, "Ed," Minimal Computing Wiki, https://minicomp.github.io/wiki/ed/. ↩︎
The Endings Project, "Endings Principles for Digital Longevity," version 2.2.1, University of Victoria, March 3, 2023, https://endings.uvic.ca/principles.html. ↩︎ ↩︎ ↩︎
Domenico Fiormonte, Sukanta Chaudhuri, and Paola Ricaurte, eds., Global Debates in the Digital Humanities (University of Minnesota Press, 2022), https://www.upress.umn.edu/9781517913267/global-debates-in-the-digital-humanities/. ↩︎
Roy Rosenzweig Center for History and New Media, "Our People," RRCHNM, https://rrchnm.org/our-people/. See also Lincoln Mullen's site, https://lincolnmullen.com/, and code at https://github.com/lmullen. ↩︎
Lincoln Mullen, America's Public Bible: A Commentary (Stanford University Press, 2023), https://americaspublicbible.org/. Code and data at https://github.com/public-bible. ↩︎
Roy Rosenzweig Center for History and New Media, https://rrchnm.org/. ↩︎
Knight Lab, Northwestern University, https://knightlab.northwestern.edu/. ↩︎
Modern Language Association, "CORE," Knowledge Commons support documentation, https://support.mla.hcommons.org/getting-started/core/. Knowledge Commons, formerly Humanities Commons, is at https://hcommons.org/. ↩︎
Tags : digital-humanities minimal-computing go-dh digital-preservation religious-studies
Webmentions
No webmentions yet.