When I finished writing Drupal for Humanists on July 15, 2015, my Magic-the-Gathering-playing, arithmetic-doing kindergartener was a barely-verbal toddler. The night I finished the manuscript was memorable in more ways than one: I was four months pregnant with my second kid, and it was the first time I felt him kick. When I sent in that manuscript, Donald Trump had announced his presidential campaign just a month earlier, but I paid it no mind as anything but a sideshow, because we all knew there was no way he’d win.
I had no way of knowing that the resulting book would be given a release date of November 8, 2016. By that point, my vague source of nausea while writing Drupal for Humanists had turned into a roly-poly nearly-1-year-old, dressed in a Hillary onesie sent by his great-aunt in Texas. (We waited until late in the election for him to wear it; Berkeley never really got over Bernie.) We believed things were going to be all right with the election, but I joke when I’m nervous. For the months leading up to November 4th, the Day When This Would All Be Over, I’d roll my eyes when I told people the release day of my book, and would quip, “At least one good thing will happen that day!”, fully expecting it wouldn’t come to that.
You know the rest of the story: my book coming out was, indeed, the only good thing that happened on November 8, 2016. And no one, myself included, cared.
It was an inauspicious start for “Drupal for Humanists". All the things I’d imagined doing to promote the book vanished from my to-do list, replaced by an urgent need to try to wrap my head around what it all meant for us, for our friends and neighbors. I took my oldest kid, in his froggy jacket and rain boots, to an Inauguration Day protest in San Francisco. He rocked a fire truck skirt as he carried a “Refuse Fascism” sign as tall as he was to a rally against the Muslim Ban. On every level, from the climate to the direct threats to one of our favorite preschool teachers, a Dreamer, it felt like the world was starting to unravel.
Drupal wasn’t exempt from the zeitgeist. Drupal 8 was released on November 19, 2015 — a year before Drupal for Humanists came out, but after I’d submitted the full manuscript. Chapter 2 includes an extended analogy involving Catalan and Latin, to explain the fracture it caused within the Drupal developer community. I wasn’t concerned; it had taken a year for module support to catch up (for existing, widely-used modules — let alone new developments) when Drupal 7 originally came out, and I expected it would take longer for Drupal 8. That same section included a reference to Backdrop, a fork of Drupal 7 that had been announced in January 2015. At the time, I wasn’t impressed: Drupal modules had to be rewritten to remove the database abstraction layer in order to work in Backdrop, and I couldn’t see the payoff compared to sticking with Drupal 7 and seeing how things played out. By the time everything else in the world felt like it was going to pieces, it was clear to me that — for digital humanities projects — Drupal 8 had taken a wrong turn. Drupal 8 made it harder, not easier, for the kinds of users I’d written the book for. I wanted website-Legos that anyone with an idea for a DH project could assemble into something very functional and reasonably nice-looking, without writing a line of code. Instead, Drupal 8 was built for Enterprise, where IT teams of developers and sysops folks are paid lots of money to deal with technical processes. As an organization, Drupal was courting developers who were familiar with the enterprise PHP web application framework Symfony, not historians who learned a little PHP while hacking WordPress on the side.
So that was awkward.
I co-taught Drupal at DHSI the summer after the book came out, and my co-instructor, Erica Cavanaugh, taught it the following summer, after my job at UC Berkeley imploded and I was no longer funded to do DH. The Drupal website grew increasingly pushy about Drupal 8, selling a narrative that we knew wouldn’t line up with any of our students’ experience with using it. But I can’t help but wonder about what we sounded like to the students, assuring them that everything was fine, Drupal 7 was still perfectly usable, and in fact the better option, don’t worry about starting a project in Drupal 7, all things will be clear by the time Drupal 9 rolls around and all the existing D7 projects have to commit to a direction for the inevitable migration. It was a statement of faith, hope, and incredulity that something as useful as Drupal 7 would just cease to exist.
Time passed, and it became increasingly evident that Drupal, as presented in the book, was a tool for a time and place that I had imagined in 2015, but had not come to pass. Maybe somewhere there’s a parallel universe where large-scale communities in the US and beyond have prioritized investment in pragmatic forms of infrastructure that provide technical scaffolding to support digital scholarship, without the building and maintenance burden falling to the scholar. In this one, though, we face more pressing, immediate problems.
Historically, I have not been a fan of the minimal computing approach to web development. A tool like Drupal allows scholars with a much lower level of comfort with technology to build much more complex projects. It is true that the technical skills that go into the workflow for a GitHub pages Jekyll site (Command-line installs! Markdown! Github! YAML!) are applicable in other contexts. But it is also true that the majority of the scholars I’ve worked with over the course of 15 years of doing DH would see learning all that as a very, very lsteep hill — particularly in light of what you actually get at the end. (In 2016, let alone 2019, where there’s a big search box in every application and website, explaining that search with Lunr.js is a non-trivial thing to set up isn’t going to win you any friends.) Let’s be real: it can be a stretch to ask faculty (especially older faculty) to rethink their materials in a Google Doc to facilitate bulk data import, but it’s easier to draw a straight line to how that benefits their project. Getting them to debug the syntax of a YAML file, or learn Markdown for text formatting (instead of just using a familiar WYSIWYG editor) is often too much. Either they’d conclude that the digital humanities was too hard and not worth it, or if they persevered, it would be me — not them — having to handle absolutely every technical thing along the way: the exact opposite of the DIY vision I had for Drupal. (We really wanted to present [Wax](https://minicomp.github.io/wax/) as an option for image-centric DH projects at this fall’s [Slavic DH](https://slavic-dh.princeton.edu/) workshop at Princeton, but when we looked at the amount of workshop time we had, and how far that would get students vs. what we could do with Omeka, Omeka won hands-down.)
I continue to struggle with making Jekyll work — even as a person who’s generally succeeded in doing “technical” things for some 25 years. I’m still skeptical of how widely it can be adopted, particularly by people who don’t have ongoing access to technical support. But I think the biggest change in my thinking over the last seven years (when I first had the idea of writing Drupal for Humanists) has been how much value I place on sustainability, and the inevitability of endings.
When I started Drupal for Humanists, I envisioned a future where things kept getting easier. I imagined a Drupal 8 that included self-updates of the core and module code. Low-cost access to high-quality, responsive hosting services. When researchers felt their project was “finished”, it would be trivial to indefinitely maintain what they had built. And when the underlying technical components were all outdated, emulation would save the day! Those were some very wrong prognostications. (Except for the web hosting part — thanks, [Reclaim Hosting](https://reclaimhosting.com/), for continuing to be wonderful in the face of a general slide towards dystopia!)
The minimal computing advocates were right: database-driven websites with dynamic code are inherently fragile, vulnerable things. They’re easy to hack. While high-profile sites with controversial content actively draw the attention of hackers, sometimes sites get hacked for no reason beyond free access to server resources. In Drupal for Humanists, I talked about all the highly configurable, dynamic features that were so easy to implement with Drupal, but never talked about what you lose. It’s nice that Drupal has a very granular set of permissions that can be associated with any arbitrary number of “roles” that can be assigned to accounts — but what vulnerabilities do you open yourself up to by allowing people to log into the site to begin with? Making it easy for people to add content to the site is appealing (particularly for directories and the like, where “crowdsourcing” once seemed like a promising model for minimizing labor on the part of the project itself), but so many hacks start with malicious code embedded in such “contributions”. If you’re fastidious about updates, and are careful about limiting unvetted users’ access to the site, and are using the site regularly to keep an eye on things, you can run a Drupal site for some time without problems. But that’s not reality. In reality, things come up: you don’t get around to dealing with a critical security update right away, you get sick, you have a family crisis, the grad student you’re paying to handle updates gets distracted with comps or struggling with their dissertation, or maybe there’s turnover in your local technical support staff and maintenance falls through the cracks for a few weeks or months. And then you may find yourself facing a monstrous clean-up job.
When you’re building a Drupal site, it can feel like Legos. But in the medium term and beyond, it’s a misleading analogy. Barring the interference of careless pets or children with their hearts set on destruction, the Legos you assemble stay assembled until you choose to take them apart. Instead, building a Drupal site is like buying a pony. It seems like a fun and exciting undertaking, but you quickly discover that ponies require constant feeding and cleaning-up-after. You don’t ever get a break — you can’t shrug and figure the pony will sort out its own food-and-feces situation while you turn your attention to a new project. If you don’t take care of it, and don’t find (and probably pay) someone else to take care of it, you can try to give it away — but wise technical staff will balk at the offer of having to take on someone else’s Drupal site, particularly if it’s been neglected for some time. Once your project is done, if you’re not realistically going to devote the ongoing resources required for maintaining it indefinitely, it’s time to consider what it will take to “archive” it, shut it down in some orderly manner. In essence, the responsible decision is to euthanize the pony.
Almost all the Drupal sites I’ve helped build over the years are now dead. A few of them I archived responsibly. I’ve let more starve to death — sometimes finding someone who’ll make the good-intentioned mistake to promise to take care of the site without really understanding what that entails. And then there was the DiRT tool directory, where I tried to do the responsible thing by feeding it to TAPoR (mmmm, delicious, nutritious pony!). But I couldn’t bring myself to part with DiRT's bones, and they lingered, giving the impression of a functional site even as it had largely decayed, until the organizational owners of the domain name recently let its renewal slip away. It was a mercy.
Getting the metaphorical barnyard in order has been a major priority since I started a position doing DH support in the Division of Literatures, Cultures, and Languages at Stanford University, a year ago. Things were in a sorry state when I arrived: my predecessor had built lots of complex Drupal sites, many incorporating custom modules, and he did so in such a way that the scholars were wholly dependent on him for changes and maintenance. Some of the sites were on servers managed by the digital systems group at the library, who provided system-level updates, but left it to my predecessor to do Drupal updates. Others were on externally-hosted servers, racking up bills of the hundreds or thousands of dollars per year, with account-level credentials that the faculty didn’t know. Still others were on free-for-all Stanford-provided webspace, where anyone could run a content management system, provided they dealt with all updates themselves. Two of these sites had been hacked; the one on a library server had been shut down, the one on the commercial hosting persisted in serving malware.
One by one, I’ve tried to find an approach that will work for these Drupal sites. I was able to do a web archiving capture and data export for one of the hacked sites. Another, I got working again — but we’ve taken steps towards a more sustainable approach where we’ll use library infrastructure to distribute the project’s materials in a way that will make them more findable and less siloed. The current CMS will evolve into a static-HTML textbook. I rebuilt a third site more simply, stripping out “features” students were obviously confused by, using a Drupal-based platform operated and maintained by Stanford’s Web Services group. Another will probably be migrated to a centrally-maintained university WordPress instance as soon as it launches early next year. See the trend? If I’m going to be in this role for some time, it would take very little time for all my working hours to fill up with managing custom websites, given the faculty expectation that all sites will just continue to work indefinitely. The only way I can ever work on new projects, to support faculty and students’ evolving interests, is by getting websites onto infrastructure where someone else will handle the maintenance. This comes with managing expectations about the trade-offs involved (e.g. especially in terms of limiting highly custom functionality), and making the case for why this is the right approach nonetheless.
I’m happy to say that in my first year at Stanford, I have created zero new websites that were not either static, or maintained by Stanford Web Services. (Much love and gratitude to my colleagues in Stanford Web Services. I couldn’t do this job without you all.) I’ve been building community; I’ve been working with scholars to create, clean, and analyze data sets; I taught a course and [published all the materials (including a data set of dresses!)](https://github.com/quinnanya/dlcl204) to GitHub. Every project needs a different balance of nimbleness (e.g. adaptability for the next iteration of a course), persistence (e.g. for graduate student collaborators who will be going on the job market in a few years), and publication in forms that can be unambiguously be called done. There aren’t enough of me (and, honestly, I’m not by nature organized enough) to adopt the [formalized charters](https://cdh.princeton.edu/research/project-management/charters/) and project management workflows used by Princeton’s Center for Digital Humanities, which include a “living will” for the project from the start, defined points where developers can accommodate technical changes, and defined periods for data entry — rather than having to accommodate changes to structure and/or data at any point, indefinitely. But now I try to go into projects advocating that same mentality: it’s risky to start a project where you can’t articulate what it would look like for the project to be done.
I’ve realized that Drupal, as depicted in _Drupal for Humanists_, was the kind of DH recommendation that you might get from the Bad Idea Bears in “Avenue Q”. Look at all the things you can _just do_! Don’t you want to _go do them_? You can structure your data _however you want_! You _don’t even need to decide_ on what questions you’re asking, and _why_ — just _put your digital research collection in_ and then build some queries and _insights will leap out_! Don’t worry about updates, they’re not that hard to do! _Yaaayyyy!!_ There’s been lots of discussion about using digital humanities methods for supporting an argument, vs. exploring a problem space, and I take no issue with the latter. But in most cases, explorers want to find a way home, share their findings, and seek new horizons. When exploration has no exit strategy, it becomes something else.
Sometimes, what people are setting out to do is, in fact, something else — at least for a time. The [Modernist Archives Publishing Project](https://modernistarchives.com/) does actually want to run a virtual archive that reunites letters, order books, and other digitized ephemera related to the Hogarth Press. These materials are distributed across numerous physical archives (not all of which support IIIF), and having them in one place is useful for this group of scholars and their colleagues. As they have taken ownership for the site (originally built by my predecessor, who had sole access to admin privileges), they’ve come to understand what it means to be running infrastructure — and they still want to do it, at least for now. They do actually want a pony. But they’re also planning for a future after the pony, accessioning (with permission) the materials they’ve collected and the metadata they’ve generated into the Stanford Digital Repository, where it can persist as a unified “collection” in an infrastructure with the goal of long-term preservation, and funding/staffing to match. Other groups, like the [Center for Digital Editing](http://centerfordigitalediting.org/) at the University of Virginia, have developed and run Drupal-based infrastructure for their own projects like the [George Washington Financial Papers](http://financial.gwpapers.org/), and work with projects with similar needs to adopt and adapt the same approach. They’re something like a horse fancier society, breeding and caring for ponies, and helping others do the same. That’s also a reasonable approach!
So what is a project like MAPP or a group like the Center for Digital Editing to do when faced with the upcoming cliff of Drupal 7 end-of-life in 2021? In cases where Drupal 7 aligns well with the project’s goals — even when factoring in maintenance costs — [Backdrop](https://backdropcms.org/) has evolved into what I hoped for from Drupal 8. They stepped back from their earlier, more complicated requirements for porting a Drupal 7 module to Backdrop. They’ve developed auto-updates for Backdrop core, to decrease the maintenance burden — and what’s more, they’ve incorporated a majority of the most widely-used modules into Backdrop core, so that code can benefit from ongoing automatic updates, too. There’s still a few kinks to be worked out; the developer community for Backdrop is smaller than Drupal, and fewer sites are using it, meaning it can take longer for bugs to be identified and fixed. Backdrop’s primary audience is non-profits and small companies (i.e. groups with technical skills and staffing levels more comparable to digital humanities projects than large corporations), and uptake has been gradual to date. But I have reason to hope that Backdrop will continue to develop into a viable next step from Drupal 7. By taking the plunge and migrating early, MAPP is doing a service to the broader DH community by funding the port of a DH-oriented Drupal 7 module that they need (Partial Date), which will then be available for anyone else to use. With a few exceptions (blocks / panels / page layout being the major one), Backdrop feels like Drupal 7, overhauled to smooth over many of the annoying quirks inherent to Drupal. On and off over the last year, I’ve been going through the text of Drupal for Humanists and updating it to reflect the changes in Backdrop; I’ve posted everything I’ve written so far on the [Drupal for Humanists](http://drupal.forhumanists.org/backdrop) website.
I was grateful for the lowered lights in the audience, because I think I turned bright red at this point in Johanna Drucker’s closing keynote at DH 2019:
> Johanna Drucker: "Quinn, you should cover our ears -- we said 'we'll all learn Drupal', but then library said 'no way, we're giving up on Drupal.' And we said we are too." No worries, Johanna, I've gotten WAY more conservative in the projects I recommend Drupal to. [#DH2019](https://twitter.com/hashtag/DH2019?src=hash&ref_src=twsrc%5Etfw) — Quinn Dombrowski (@quinnanya) [July 12, 2019](https://twitter.com/quinnanya/status/1149683644241461248?ref_src=twsrc%5Etfw)
I do think there’s a place for Backdrop among the constellations of digital humanities tools and platforms, but it shouldn’t be the default. When starting a project, think hard about how long you want to personally be responsible for maintaining infrastructure — not just given your life today, but how it might be different in two years or five years from now. (If I had really been thinking about the consequences of having kids a few years later, I would have done things differently with DiRT and DHCommons.) What are the dependencies for your project to keep running in the form you plan to create it in? What other forms can it meaningfully exist in, in the longer term? How much work will it take to adapt it to that form? Would it be better for you to start the project in that form? What is your exit strategy when the time comes for you to step away? (Your answer should not involve someone else coming along to keep the project going; it’s not impossible, but it is highly improbable, even for projects with a large following.)
Don’t leap into buying a pony. Think hard before building a Drupal/Backdrop site.
_Thanks to Karin Dalziel for nudging me to write this blog post._