All digital humanities projects, even ones which are relatively technically simple, are built in an ecosystem of connected, interdependent technologies. Many projects will experience downtime, or even “break” as various pieces of that software are updated, rendering old connections obsolete or incompatible. Unfortunately, funding proposals in the digital humanities are structured so as to offer limited resources for technical support after the conclusion of project development. Funds may be allocated for the cost of hosting or storage, but maintenance support for a project will be limited. Ultimately, technical responsibility for a digital humanities project will move from the PIs, researchers, and programmers that develop a project to staff (whether in an IT unit, the Library, an institutional or regional repository, or a research center) who will interact with the project from a maintenance perspective. Few DH projects will ever achieve the level of support or traffic that requires having full-time support staff dedicated to the maintenance of that project. Realistically, the maintenance of inactive or archived projects will fall to a staff member at an IT department, the institution’s library, or a DH center who juggles maintenance for a portfolio of projects alongside their day-to-day responsibilities.
The DiRT Directory serves as a useful case study here. With the conclusion of DiRT Directory’s latest round of development, the project will move from the hands of the developer team (comprising staff from UC Berkeley’s Research IT, CUNY, and Agile Humanities Agency) to staff at its new home, centerNet. Though DiRT is unusual for the sheer number of times it has changed hands (this being its fourth move), the handoff from development team to maintenance staff is a common in the DH project life cycle.
As PIs weigh various technical options for their project, they will need to balance out the benefits (and costs) of custom programming with the convenience of pre-existing solutions. For projects with access to dedicated technical collaborators, custom code can sometimes be an elegant, quick solution. Unfortunately, no digital project can be entirely “break proof.” Sites with custom programming present particular challenges for support and maintenance. Hand-coded sites or sites with custom programming may remain vulnerable to changes in the stack that supports them. Custom code can also cause problems for staff who want to add to, update, or extend the project. The idiosyncrasies of one developer's programming or approach to solving problems can be a nightmare to untangle, particularly if that developer leaves the institution without providing thorough technical documentation for the project. The tools and stacks used in the project may be particular to that person. Sourcing consultants or programmers to diagnose and repair these instances may be prove to be extremely expensive and time-consuming, as they are more difficult to find than developers who are interested in starting a new project from scratch.
In its 2011 reformulation, the DiRT Directory opted to build the site in Drupal, an open-source content management system (CMS). Modules (small packages of code create by the open source community and approved through the Drupal module directory) make it easy to customize a site, but without the headaches of writing or maintaining custom code. A complex Drupal site that utilizes a lot of modules may experience difficulties when updates are applied, as these may cause conflicts between installed modules. However, unlike sites with custom programming, the technical difficulties and risks created by updating modules are distributed among a large community of users who will be quick to discover and report bugs or share solutions.
The speed at which these bugs can be discovered, addressed, and repaired will depend on how active the open source community around the particular project is. In the case of Drupal, this community encompasses a wide variety of developers and users in the realms of industry, higher education, and government. Rather than making changes directly to the code, many problems are more easily fixed by someone experienced at Drupal maintenance, which includes digging through forums and technical documentation. On the Berkeley campus, Drupal is used for building administrative sites, departmental directories, and workbenches for coordinating research teams. Users can help each other troubleshoot at groups like the Drupal Developers’ Circle hosted at the D-Lab.
While modern web frameworks like Angular.JS may make it easier for developers to rapidly build a project, they may raise the long-term costs of maintaining or retooling a project. What is a pleasure to build? What is a pleasure to maintain? To ensure the longevity of their project and minimal downtime or outages, project directors who will be working with limited funding and limited access to hands-on technical assistance should favor the latter.