"Can you say something about using enterprise tools for DH?" Annie Swafford asked towards the end of a recent meeting. I think she knew that prompt was like pulling out a chocolate advent calendar in front of a 3-year-old, and I managed to show some restraint by limiting myself to the short form of my usual rant, so that everyone could make it to their next meetings on time.
For over a decade, I worked in central IT, first at the University of Chicago and then at UC Berkeley. There are lessons (positive and negative) that digital humanities can take from central IT, but it's important to think carefully before adopting their tools.
To begin, let's differentiate two kinds of tools in DH: those that we use for the organization, collaboration, and management of tasks, funding, staff, etc. that surround our work (let’s call them support tools); and those that we use for the work itself (project tools).
I’ve found that self-identifying as "enterprise" is a red flag for tools in either category. While this has started to change, the term "enterprise" has correlated with user experience not being a priority. Even as the marketplace has grown crowded with apps and platforms competing for customers, in an "enterprise" context, there is usually one decision-maker behind a large purchase that dozens, hundreds, or thousands of people will be forced to use for years at a time. Even when there's a committee involved, it tends to be made up of people who think differently than humanities scholars do. For instance, at UC Berkeley we had an enterprise purchasing system that apparently the financial people loved, but problems arose when everyone else had to use it, too. To illustrate the absurdity of this system, the first step to pay an invoice from any arbitrary online retailer was to search for "not found" in the supplier field, so that you could select the controlled vocabulary term "supplier not found" and then get on with the rest of the 8-step process.
The UX situation with enterprise tools is improving, if only in the sense that tools developed to compete in the individual-user or small-group market are trying to reach bigger and more profitable customers by developing "enterprise" features and pricing models. The to-do list platform Asana, which I've used for a couple years, comes to mind as an example. Their "enterprise" page highlights features that have to do with authentication (e.g. single sign-on integration, user provisioning/de-provisioning through single sign-on) and control. Some of the control-based options, such as the feature for exporting all data that was ever entered into Asana, could have some utility in a DH context — though data portability is more important for project tools than support tools. Other enterprise features, like blocking Asana’s integration with other apps, have limited relevance for DH projects.
What does it matter if a tool has extra features that a project doesn’t need? As long as its feature set covers the things your project does need, why should extra authentication or security features be a concern? Microsoft Word is the example par excellence of software adopted throughout the humanities, where most people use only a tiny fraction of its feature set. That said, the designers of Word have largely figured out how to include and maintain a large, complex set of features in a manner that does not disrupt the simpler workflows of much of the software’s user base. I was not, and still am not, a fan of the "ribbon" UI when it was rolled out, but I can do most of what I need using just the options in the "Home" tab, while ignoring the rest of the interface.
I’ve found that "enterprise" features are less good at staying out of the way. Institutionally-based single sign-on authentication systems impose paradigms of access that are at odds with the broadly (and cross-institutionally) collaborative models of project development in digital humanities. Yes, tool-internal authentication is less secure than single sign-on, but it makes adding an account for a collaborator trivially easy. If a tool requires the use of institutional single sign-on, you have to hope that your institution offers guest accounts, and enables those guest accounts for authenticating against the tool. And if you’re fortunate enough for that to be the case, you might have the pleasure of waiting hours, days, or longer for the guest account to be approved and created. Whether or not the tool itself imposes enterprise-style restrictions on integrations, enterprise tools often come with policies that that limit customization, plugins, etc. Not being allowed to install a plugin that would simplify tedious tasks of data entry or formatting is a nuisance in the context of support tools, but these restrictions can have serious implications for the kind of data and metadata you can collect, how you can store it, how you can analyze it, and how you can export or publish it in the context of project tools. Enterprise tools are also built with the expectation that they’ll be installed, maintained, and supported in an "enterprise" environment, by some number of IT support staff with specific technical expertise. In a university context, central IT, library, or divisional / local IT staff typically play this role. Being able to delegate the maintenance and support of this software to those kinds of staff positions, rather than funding a grad student or postdoc out of DH project funds to wrangle maintenance of a smaller open-source software package, may make enterprise tools look like a more appealing option. However, problems arise when the scholar leading the project departs for another institution. The new institution may have made different choices about which enterprise platforms to run, leaving the scholar to choose between a migration (time-consuming and expensive, but mostly a one-time cost), trying to run an enterprise tool on their own (complicated and an ongoing expense), or seeking out a software-as-a-service environment (a potentially cost-prohibitive ongoing expense).
The leadership behind every piece of software — be it open-source or proprietary — has to make decisions about which features to prioritize. Particularly for software that depends on purchases or subscriptions (as opposed to consortial membership) for financial sustainability, the enterprise market is alluring. It’s much more efficient to land a handful of large enterprise contracts than pursue leads for many, many small-scale projects and organizations whose needs are more heterogenous than enterprise environments’. This inevitably influences development priorities: given limited resources, would it be more advantageous to develop (or enrich) a relatively predictable set of features for well-paying clients, or tackle the diverse requests of users who may not be a source of revenue at all?
Some software has found a middle ground — content management systems come to mind as an example. For WordPress, there are plugins and ways of configuring it that are geared towards "enterprise", but the core software itself doesn’t lean heavily in that direction. Drupal 7 also took that approach, before its creator decided to actively court "enterprise developers" with Drupal 8 by replacing much of Drupal’s core with the Symfony framework and object-oriented code. The resources directed towards the Drupal 8 rewrite were immense, but the result is a platform that — more than three years after it was released — is still less usable for digital humanities projects than the preceding version. Its PHP memory requirements for even decent performance are noticeably higher than for Drupal 7, and more than what you get by default through inexpensive shared hosting services (though the difference is insubstantial in an enterprise IT context). Writing modules in Drupal 8 may be more intuitive if you have experience with the Symfony framework, but that’s not a widespread skill among DH developers. And that shows in the number of DH-supporting modules available for Drupal 8.
About a month ago, I attended the Backdrop CMS summit at the Bay Area Drupal Camp and was treated to a vivid example of what it looks like to work with open an open source tool whose intended audience, goals, and priorities align with your own. Backdrop CMS is a fork of Drupal 7, and a small team of developers has spent the last three years fixing most of the annoying things about Drupal 7 that I had grown so accustomed to that I’d stopped noticing them. Backdrop is platform that minimally-technical people can use to build sophisticated websites, without having to write code. The developers have integrated some of the features from Drupal 8 (like configuration management) that are directly useful to their audience, and added new features, like being able to search for and install modules through Backdrop’s GUI. The next release is slated to have an optional feature for automatically updating Backdrop core. Having just spent much of my first two months at this job cleaning up hacked Drupal sites that hadn’t been updated, the possibility of automatic core updates seemed transformative. It’s the opposite of enterprise — shouldn’t updates be thoroughly tested before being rolled out in a version-controlled manner to a live site? But particularly for DH projects that are no longer being actively developed or even maintained, the risks associated with automatic updates might be a trade-off worth making.
DH projects aren’t "enterprise". Our goals are different, our audiences are different, our staffing models are different — in substantive ways that can cause friction when we adopt enterprise tools. DH isn’t unique in its divergence from "enterprise" (as I learned during my time working in research and high-performance computing), but it's an aspect of our work that we can't forget about when evaluating tools.