What are some challenges to doing DH in the library?
You may be familiar with the scenario: the faculty member groaning (often justifiably) that it’s taken so long to get one simple project off the ground that she’s given up on trying to work with librarians. Or the administrator who wonders why librarians aren’t trying harder to learn new skills.
Having actually done some digital humanities in the library, this attitude frustrates me, though I understand where it comes from. In my experience, many of the barriers to completing digital humanities projects in the library arise not from librarians themselves, but from a set of institutional and administrative factors that will be familiar to most people in Libraryland.
This is not to say that DH isn’t done in the library. It is, and well (though, as my colleagues and I found, it’s often being done in a pretty piecemeal fashion that relies more on individual librarians’ persistence than on institutional support). And it’s important to note that DH was being done in the library (and in the archive) well before it made its way into academic departments.
But I’m thinking of the libraries where DH hasn’t really found a foothold, where a faculty member or administrator is starting to wonder what’s wrong with their librarians that they can’t seem to marshall the resources and expertise to collaborate on DH projects.
I’m writing an article for the Journal of Library Administration on some of the barriers to getting DH done in the library, and I could use your help making my list. I think that these challenges all have solutions, and that there are really excellent reasons to persist in doing DH in the library. But as Bethany Nowviskie has said, librarians’ vaunted service ethic sometimes prevents them from being candid with faculty and administrators about the challenges they face and the resources they need. I promise to offer solutions, too, but I think it’s important for us all to be on the same page about what we need in order to do DH well.
I have a number of ideas, based on experience, discussions, and research, but I would really appreciate your additions and corrections to my list in the comments. Or perhaps you’d prefer to email me at firstname.lastname@example.org.
Insufficient training opportunities
This challenge comes up quickly in any discussion of DH with librarians. Funding for training opportunities is often scarce, and it can be very hard to justify to supervisors why one needs to take a class in, say, Python, when one’s job responsibilities don’t currently include Python. Moreover, it’s not always clear where to go for training. Computer science classes are often too, well, computer-sciencey, and it’s very hard to know which language or skill one needs to start with.
Lack of support for librarian-conceived initiatives
In a library, responsibilities and opportunities are apportioned in ways that faculty sometimes have trouble relating to. Libraries are very concerned with metrics, with assigning roles efficiently, and with meeting patrons’ demonstrated needs. Projects often get assigned from the top down, and it’s not unusual for a project sponsor to be asked to prepare a business case to show that an initiative will meet a need and benefit the library. Many DH projects don’t meet any particular demonstrated need — they’re done to find an interesting answer to an interesting question. This can be very difficult to explain to one’s supervisors in the library.
Brian Mathews has urged libraries to “think like a startup“: to “face the future boldly” and “implement new ideas.” But libraries can’t do this unless librarians can do this, and right now, many of them aren’t being permitted to implement the bold new ideas Mathews and others would like to see. (To see what happens when librarians are encouraged to conceive new initiatives, check out the Harvard Library Lab.)
Too many tasks, too little time
With all the hand-wringing about whether the library has a future, it can be easy to overlook the fact that many librarians actually feel overburdened. Most subject librarians cover multiple disciplines, and with purchasing, instruction, outreach, professional development — well, it all adds up. Time for a DH project has to come from somewhere else, and many librarians don’t feel they can keep doing their existing jobs well if they add in something else.
Lack of authority to marshall the appropriate resources
In my mind, this is one of the biggies. When I worked in the library, I’d sometimes fight the urge to hide when I saw a faculty member coming at me with a project idea — even if it was a great idea, even if I really wanted to do it. I’d start tabulating the resources it would take to get this thing done: time from a developer, time from a designer, time from a metadata specialist, time from a sys admin, project management expertise, server space, a commitment to host the project in the long term … I just didn’t have the authority to make all these pieces fall into place, and neither do most individual librarians. In fact, very few individuals within a library have the ability to bring all these parts together. If a librarian has assembled these resources for you, he or she has probably (unbeknownst to you) gone from desk to desk, pleading for time from each of the people involved. That’s also probably why it’s taken so long to get your project off the ground. You can imagine why most librarians aren’t eager to do this over and over again.
Lack of incentive
It may not be all it should be, but for scholars, there’s some professional payoff to accomplishing a DH project: some name recognition, something to take on the conference circuit. It’s less clear what the payoff is for the librarian who has helped to shepherd the project through its development cycle. Too often, the “completion” of a DH project means more headaches down the road (about upgrades and server space and support) for the librarian, while it’s the faculty member’s name that’s associated with the project. If the librarian’s institution isn’t providing support and recognition for librarians involved with DH, it’s hard to see what would motivate someone to subject herself to such hard work.
The complexity of collaborating with faculty
If a DH project involves collaboration between faculty and librarians, it’s important to be attuned to the peculiar dynamics of this kind of relationship. Frequently, faculty approach librarians as service providers (and too often, librarians approach faculty that way, too). The flaw in this relationship becomes clear a few weeks into the collaboration, when the librarian really needs that dataset, decision, or brainstorming time in order to make progress on the project, but doesn’t feel entitled to make demands from an unresponsive professor. There’s no one to appeal to and no one who can help, and so the request languishes. The project will suffer if the relationship isn’t truly equitable.
You’re a faculty member who wants to write a book. Whose permission do you need? No one’s. The book may fail, but it may wildly succeed, and that’s a risk you can take on yourself. If, on the other hand, you’re a librarian who wants to work on a DH project, you’ll probably need to check with your supervisor, maybe the legal department, whoever’s in charge of the technical team, maybe the people in branding. And frankly, for most of these decisionmakers, the safest answer is “no.” When so many stakeholders are involved, the incentives for risktaking become so diffuse as to be almost imperceptible.
Lack of a real institutional commitment
When libraries do DH well, they’re in it for the long term. That means permanent staff, hard funding, real space to work, and an understanding that some projects will succeed and some will fail. But what we often see now is libraries hedging their bets: willing to wager a postdoc or two, but not more. Alas, this strategy often leads to more frustration than cool DH projects. DH takes time, and an investment in relationships across the campus. When that commitment isn’t there, librarians know it, and so do faculty and students.
This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.