[This is the text of an invited talk I gave at the University of Nebraska in April. I’d like to thank my amazing hosts in the UNL Library and CDRH!]
I’m going to back into my talk today, perhaps in part to counter the way I have imagined all of you instinctively backing slowly away from the brilliant and hilarious and slightly horrifying posters I’ve seen advertising it.
My title is “A Skunk in the Library: the Path to Production for Scholarly R&D.” Now, why (oh, why) the skunk? It’s because I’ll be introducing you to the R&D unit within my department, the Scholars’ Lab at the University of Virginia Library, as a quintessential “skunkworks” operation – and I’ll describe what I mean by that in just a second. It’s also because I am not unconscious of the wrinkled noses that can result from an airing of some of the ideas I want to share with you.
To that end, I plan to save plenty of time this morning for conversation, because above all that’s what my gestures here will call for. And I’ll be asking you to help us think together through something of importance to librarians and software developers and scholars alike – namely, the role of libraries and library-embedded digital humanities centers in helping to beat what we might call a “path to production,” both for innovative scholarship and for its supporting technical and social frameworks.
IT staff in the audience will hear that phrase, “path to production,” and think immediately of a set of well-established Web development and release practices. I’ll rehearse those a little bit here, so that we’re on the same page, before I complicate (or possibly just pervert) them.
We’re talking, in essence, about a workflow that moves one’s code in predictable ways from areas specifically carved out for mess-making, idiosyncrasy, and flux to those that have been progressively tamed – areas engineered for greater fixity and stability. In this sense, the “path to production” is a steady migration of new features and systems. You walk from development environments that are in the full control of code creators – over to separate, communal spaces for testing and website staging. And you move – from Development to Test or to Staging – so that others can bang on your system, bugs can be worked out, content added, needs assessed, and (on the policy side) so that agreements can be made about what form a public release will take and how it will be supported. Finally, enough of all of this gets worked out that the products of your labor ascend to the promised land of “Production.”
Production is (ideally) a place where code and content and expectations have been managed and where the thing you’ve created (whatever it is) has been put into real-world use. Ideally, now, the quotidian care and feeding of this “product” can become the direct responsibility not of its original developers, but rather of its long-term stewards – sysadmins. The well-established “dev/test/production” cycle is about sanity. It ensures that systems administrators are not blindsided by a midnight phone call about something they didn’t even know they were supporting, and – on the other end of the equation – that developers have been freed from the burden of ongoing support and can move on to a brand new project – or circle back to a dev environment to work on a future release for this one. They’ve done their jobs and adhered to a social contract: admirably, we expect, with due diligence to testing, and – by following the best practices of a clear path to production – they’ve given their managers and sysadmins an acceptable level of assurance that the product they’ve created is maintainable. They have basically put it on a shelf.
Now just swap out “scholars” for every time I’ve said “developers,” and “librarians” for “sysadmins,” and you’ll see where I’m going with this.
Until quite recently, the path to publication for the fixed products of humanities interpretation (traditionally, articles and monographs) – leading to their apotheosis in preservation and good stewardship – was fairly clear. Everybody knew their jobs, and had – for the most part – worked out the kinks in the expected hand-offs, from scholar to editor to publisher to librarian. We might think a bit in our conversations today (as, to be sure, libraries have done for the past couple of decades) about how the products of digital scholarship complicate that supposedly-terminal condition of preservation and stewardship, or digital curation. (Last stop! Everybody off!) No. It actually doesn’t work that way. If there’s an end-of-the-line, where everyone involved can mostly disengage, we haven’t reached it yet. I don’t believe it exists.
And it’s not the thing I’m most interested in, anyway.
Instead, what I want to offer you is a seriously non-teleological conception of the phrase, “path to production.” Forget the end-point. Let’s view the path as a brand of way-finding that leads perhaps not primarily to the main thing we in libraries tend to think is our job – that is, to stable preservation and access, or helping to curate the neat and tidy products of humanities scholarship. (I do think it takes us in that general direction, for some digital objects.) But let us recognize that walking such a path is also about the walk, about messy scholarly processes. It’s about collectively – in true partnership with the digital humanities community – getting, together (while the getting is good), down a diametrical and simultaneous path of:
- iterative, unfettered, informal, (gonzo?) development;
- mature, responsible, formal continuous integration; and above all
- collaborative imagination of the work of the modern research library as we can make it operate on its very best day.
That’s the most soaring skunk you ever met. So let me explain.
“Skunkworks” is a term that emerged at Lockheed Martin in the 1940s (from an inside joke among a small team of engineers, related to a L’il Abner cartoon). The aeronautics company eventually trade-marked it (at least in its form as two capitalized words), but people raised in skunkworks ops wherever they have sprung up don’t give a fig for that sort of thing, and the name has spread far and wide. It’s come to signal a special kind of organizational form that – I’ll argue – is well worth examination in libraries and library-based DH centers. (Even if the poster for this talk gave you the heebie jeebies.)
A “skunkworks” (all one word) describes a small and nimble technical team, deliberately and self-consciously and (yes) quite unfairly freed from much of the surrounding bureaucracy of the larger organization in which it finds itself. This enviable cutting of slack and tolerance of the renegade is offset by placement, on the shoulders of the skunkworks team, of greatly raised expectations of innovation.
A special group like this only endures on acceptance, at the highest levels of the organization funding and protecting the skunks, of a simple management principle: if you want unusual results, you can’t expect that they will come from playing by the usual rules. That said, a skunkworks is not about pure research, or innovation for innovation’s sake: good stuff is meant to come from this team and be applied by others. Innovations are to be folded into wider operations and larger communities – where continued development and deployment processes can be re-shaped, if necessary, to fit the general paradigms and practices governing the rest of the organization.
The tension here is in keeping developers disconnected enough to do good work – and connected enough that their work can do good. In other words, a primary goal in setting up a group as a skunkworks is to avoid distracting your developers or (as much as possible) their immediate supervisor with everything that constitutes a path to production for the stuff they’re building. On the other hand, you need their stuff to have a path to production. Finding areas of promise and match, negotiating, fitting and reworking the innovations of the skunkworks team into the larger org, and communicating the value of the group – all that is the job of the manager or director who works at one level of hierarchy above the skunk boss. Skunks need patronage, they need protection from distraction, and they need good ambassadors and skillful diplomats. ‘Cause – hey. They’re skunks.
Which brings me to this. “Skunkworks” is a pretty evocative name for this concept, and it’s a slightly dangerous one to apply in a library. Why dangerous? Well, there’s a level of honesty and self-awareness involved in not calling them snuggly bunnies. How easily do you imagine skunks are tolerated within an overall library culture that values consensus and teamwork, rightly wants to see innovation blooming everywhere, seems to be moving (if fitfully) toward erasure of privileged status within its own ranks, and which retains a certain lovely – and, (let’s admit it) often gendered – self-conception of its members as the handmaidens of scholarship, people with a calling – with a vocation to serve?
That last bit (the service vocation) is the kicker.
I consider myself an “alternative academic,” someone who trained and was acculturated as a humanities scholar before moving into higher ed administration. I continue to practice as a scholar, but I am not a tenured teacher and researcher. There are increasing numbers of us in libraries and in the digital humanities across a variety of cultural heritage institutions. Here’s the recipe for what’s already cooking: take one methodological turn (across the disciplines) in graduate training, combine it with the contraction of the job market for tenure-track academics and an explosion in #alt-ac positions, and add to the mix what becomes, for some people, an undeniable attraction toward building things and collaborating in new ways with others within a blossoming information economy. This “building” includes not just digital humanities tools and archives, but new social and institutional systems as well.
Sprinkle the field liberally with positive choices and good role models – and even if it’s half-baked, this suggests that librarians and faculty working in DH centers can expect to see more and more #alt-ac employees among their ranks. For librarians, (as we were recently reminded by bitterly contentious commentary after a talk by McMaster University Librarian Jeff Trzeciak at Penn State) this shift comes not without a great deal of anxiety about the future of the profession. What we can perhaps all agree upon is that PhD-holding librarians and digital scholarship staff come at their work from a certain useful vantage-point: they have extensive experience not only as researchers, writers, and teachers, but as library patrons. They are our new colleagues who have looked at librarians from the other side of the reference desk.
I’ve written a bit, from that kind of vantage point, about what I see as a fundamental misunderstanding that librarians make in our dealing with faculty – and it comes down to what is, honestly, one of the most lovely qualities of library culture: its service ethic. There’s a distinct danger in one clear impulse I see in many libraries, my own included. The impulse is to provide a level of self-effacing service – quiet and efficient perfection – with a goal of not distracting the researcher from his work. You start this with the best of intentions, but it can lead to an ad-hoc strategy, in good times and bad, of laying a smooth, professional veneer over increasingly decrepit and under-funded infrastructure – effectively, of hiding the messy innards of the library from your faculty, the very people who would be your strongest allies if the building weren’t a black box.
And then there’s the degree to which an organizational service mentality prevents librarians and library staff from engaging with faculty as true intellectual partners — from developing the kind of relationships that foster frankness and fellow-feeling. Both of these issues complicate a notion of service. Our ingrained assumptions about how libraries best serve scholars are relevant to the idea of a skunkworks, because this is one group in the library who will never appear immediately service-oriented.
So we’re talking today about skunkworks not only as sites for innovation but as an organizational experiment in breaking out of old brands of service relationships. As part of this I must acknowledge that not every institution is at the same stage in these matters – and that what I’m suggesting will never be a straight and perfect path, or even the right one for everybody.
Cultural heritage institutions do tend, however, to share one common direction – and even independent digital labs and centers, not administratively part of one, are waking up to this. The library world is deeply and rightly concerned with its role in digital preservation. The most proactive libraries establish metadata & (generally) digitization consultancy programs for scholars’ projects. These are informed by & feed directly into the library’s digital preservation service. (There’s that word again.)
Now, that’s critical work, & if I’m critical about it I don’t want to give the impression that I’m proposing we de-emphasize it. (In fact, many libraries with less intimate and longstanding relationships with the digital humanities than I see here in Nebraska – or at home in Virginia – actually need to start programs of this kind.)
They are well-meaning. They’re necessary. But we start them and then wonder why we sometimes feel like we’re kept at arm’s length from the intellectual excitement of the scholarly projects they are meant to benefit – or why the staff of units like this are seen by faculty as service providers more than partners.
Well, let’s listen to ourselves for a moment. We talk about somber things like “digital curation, for the whole life-cycle of a scholarly project.” We propose to create a “scholar’s workbench” as a great social good: an end-to-end system that will permit your project to be collected and preserved by the library because – hey! the bench actually turns out to have been a shelf, and you, O digital humanist, you never really got off it. I’m encouraging us to look at these professionally-designed prophylactic, advisory, and end-stage services from the scholar’s point of view. “Metadata requirements for digital preservation.” It’s as if your nutritionist were your undertaker!
But I think we have more than a PR problem. I think we have an opportunity.
What if part of our obligation – part of the service libraries provided to the DH community – were: to experiment; to iterate; to assert our own intellectual and research agendas; to be just as bad at service as some of them are at being served? What if we were to advocate ephemerality of digital resources in those cases where that’s a healthy approach that gets scholars where they want to go – in cases where we may only be assuming that they cared about the preservation angle? What if our obligation were to play? To make things we want to see made? To collaborate like mad – with local scholars, with other librarians, & with the wider open source and open access community that encompasses them both?
What if we were to enable sectors of our own organizations to demonstrate a path to production for scholarly R&D? – to demonstrate it, that is, by walking it, and by sharing narratives like the one about Project Blacklight one I’m going to share with you in a minute.
All of this is to say: what if we saw our libraries’ obligation to the digital humanities community as being less about the provision of smooth and reliable services and more about modeling the digital humanities being done right for traditional faculty and grad students – and for the present & future generations of DH scholars & #alt-ac professionals?
What’s needed to do it right? I think you need a digital humanities R&D group that is deeply scholarly, and liberated enough to be skunky (that is, that can pursue its own research agenda in a way that is recognizable as scholarly to fellow scholars) and that is integrated enough into the larger library to understand what it takes and demonstrate high-profile successes at getting its work “into production.” Then you need to make sure that others are learning from you – when you succeed and when you fail.
I want to get to specifics. I’ll tell you a little bit about how my department is organized and where it sits, and give you an example of an R&D project of ours that walked a path to production.
My department at UVa Library (Digital Research & Scholarship, for which the “Scholars’ Lab” is really a brand name) sits smack-dab at the nexus of two large internal divisions which we have been working hard, organizationally, to merge and to blur. These were at one time called “Public Services” and “Production & Technology Services,” and you can’t start an endeavor like the SLab without either balancing or obliterating the distinctions between them.
The Scholars’ Lab was opened in 2006 in a beautifully-renovated, sunny space – the West Wing of the main floor of our most central library building, Alderman Library. I came in to direct it in 2007, from a position with the NINES project on UVa’s research faculty of English and Media Studies. I had a lot to work with. The SLab includes a suite of open offices, with a layout that keeps our staff close to the patrons who use our 4000-square-foot public lab. The lab itself is set up for individual and group work at well-equipped workstations, “collaboration cubicles,” and around coffee-tables and regular tables. We hold lectures, luncheons, and workshops in the Common Room of the SLab and in its adjacent classroom. There’s a little “ThinkTank” for small-group discussions, and a big lounge and workspace just off our offices, reserved for our Graduate Fellows in Digital Humanities. The Scholar’s Lab is a striking space – black and white and red all over. Art Deco meets the Jetsons. It’s one of my favorite places in the world.
Organizationally, the SLab was a combination of three existing centers at UVa. Two were long-standing services of the Library: the Electronic Text Center (or Etext) and GeoStat, a Geospatial and Statistical Data Center – both of which had been in operation since the mid-1990s. Employees from third center, ResComp, had come to my department not from the Library but from UVa’s central IT division. ResComp was a “research computing” support group for everything from software licensing, distribution, and use, to consultation on high-performance computing.
The combined staff of Etext, GeoStat, and ResComp knew their mission: they were here for content-production and for walk-in and by-appointment consultation on tools and methods related to teaching and research with geospatial and statistical data, and to the analysis and production of electronic texts. They were the highly-educated service personnel of the Scholars’ Lab, and at this point – despite holding higher degrees in the disciplines they supported – they all occupied staff positions. (Later we’d convert some existing lines and create new ones as Library faculty.) In fact, the whole space of the SLab had been subtly designed to point patrons to a gigantic, always-on service desk that had sometimes been described as “your one-stop shop” for digital scholarship in the humanities and social sciences.
But that wasn’t the whole complexion of the department. There was also a little rag-tag crew lacking a name – a few developers who had migrated to Digital Research and Scholarship from elsewhere in the Library, and who had been in a holding pattern, waiting for a new director. At the time I came in, they had not really thought of themselves, yet, as part of the SLab. Interestingly, this is the group that, in the digital humanities community outside of UVa, is now perhaps most visibly identified as the Scholars’ Lab. These are the people who became our little skunkworks R&D – a team of 3 to 4 developers, first managed by Bess Sadler and now by Wayne Graham.
Scholars’ Lab R&D is a skunkworks operation by virtue of its somewhat protected position and the contrapuntal mandate we’ve developed for it within the library. This is not a technical group charged with supporting mission-critical systems like the catalog or our digital repositories, or with developing only those things that can be clearly specified and whose utility and desirability is well agreed-upon. Don’t get me wrong: the team does a great deal of immediately useful work – helping to solve problems and improve services both within the Scholars’ Lab and in the larger Library. Recent projects along these lines have included design and deployment of a discovery portal and web-services delivery system for GIS data and scanned historical maps, and the implementation of Omeka (together with plugins we’ve created for Fedora objects, Solr indices, and TEI) as a more stable and maintainable way for our Special Collections curators to offer online exhibits. They also do teaching (a popular series on Ruby for Humanists), collaborate on a number of specific projects with faculty, and are the home base for an effort called Neatline, centered around geo-temporal visualization of archival collections.
A lot of this falls under the rubric of a basic principle I’ve had for the Scholars’ Lab, since the moment I realized that – even though were are organizationally a department of the Library, we were resourced adequately and given enough latitude to constitute a major digital humanities center in our own right. The principle is that we would never forget to make our library-embeddedness meaningful.
Primarily, however, Scholars’ Lab R&D is a lab for… speculative computing. (I named a think tank that, once, as well as a dissertation.) A quintessential skunkworks, this group is about what Jerome McGann called “imagining what you don’t know.” (He said that, as many of you will know, in articulating the research aims of the Rossetti Archive, another skunky little endeavor.) The difference between this group and the purely scholar-driven digital humanities teams with which I’ve been involved in the past is simple: the folks in Scholars’ Lab R&D know their best development and deployment practices, and understand the technical aspects of the path to production.
Another thing they understand is the way that open source communities are cultivated and the benefits of investing in them. The digital humanities community pays a good deal of lip service to open source, but not many scholarly projects do it well. Most “open source” DH is only nominally so, in the sense that project owners may zip up and share their code with you on request, often with a degree of hemming and hawing about how it really needs to be “generalized out” from the idiosyncracies of their content or domain. This surely comes from the way scholars in traditional humanities disciplines are trained to work almost in secret, only sharing their findings when they’ve polished them to perfection. Library technologists, more used to working collaboratively and for broader audiences, can more easily do open source right – and thereby demonstrate its value.
And – for a group that is collaborating closely with faculty and graduate students and responding to a research agenda of our own collective making – those understandings (how open source collaboration can operate, and how you move projects from conception to production) themselves can make library-embeddedness meaningful. Scholars’ Lab R&D serves for us as a conscious experiment: an experiment in modeling effective relationships of research-and-development work by librarians & library IT both to the digital humanities as an exciting community of practice, & to our own future – the future of libraries within a scholarly communications ecosystem experiencing rapid reconfiguration.
The challenge (brought home to me again in preparing my notes for today) is in talking about what we do to a library audience. As I suggested, running part of your department as a skunkworks in a library setting can be uncomfortable. Now, the Scholars’ Lab gets the Good Citizenship Award frequently enough from our colleagues to keep us out of trouble – and we are much beloved of our Graduate Fellows and credited for a re-blossoming of digital humanities grad culture at UVa. We win some grants; we launch some nice projects; we get some good press. All of that helps – and all of that can sometimes tempt us to think that the skunky side of what we do is undetectable by our peers.
But if there’s one thing we know about skunks, it’s that there’s no mistaking them.
Running a skunkworks operation as one unit of a larger department can require a constant internal and external PR campaign. Within the department, it’s often a question of shared priorities and collaborative spirit. Our own Outreach & Consulting staff are not at all out of line to ask, “What have you done for me lately?” (In fact, I want them to press more in this way.) Outside of our department, resource disparities come into play – with time itself being everyone’s greatest resource. Here, in the larger library, the question is: “What makes you so special?”
The same management practice I use to keep things reasonably fair within the Scholars’ Lab probably just pushes the unfairness out to its borders. Faculty and staff in my department, across the board, are granted 20% of their time to pursue self-directed (often, as it happens, collaborative) R&D projects. This goes for developers in our R&D unit as well as for GIS and stats consultants and outreach staff and the departmental administrative assistant. Sounds great, right? It’s a philosophical decision I stand behind: it makes it evident that the Scholars’ Lab promotes a culture of research and experimentation, top to bottom. But you don’t put something like that in place, as a director, without neighboring departments taking notice, and without hard questions being asked about differences in management styles and job descriptions across an organization.
Which brings me to my second truism: nobody is especially excited to have a nest of skunks as neighbors.
I have seen groups that operate like mine – but almost in secret. The value of a skunkworks to your larger, more traditionally organized and oriented institution is diminished or maybe even obliterated if you hide it. In fact, if you hide it too much (probably with good intentions – in an effort to protect it), you might not be operating a deliberate skunkworks at all. It might just be a disconnected, possibly wasteful, private empire. And it’d be pretty easy to pull the plug on.
As hard as some conversations can be with colleagues who want or – because their team does a radically different kind of work – actually need to run their departments differently, transparency about what we are doing is absolutely critical. In the long run, I’m operating on the theory that openness about the existence of a skunkworks (and talking about how a skunky attitude permeates everything we do) will create more spaces for innovation throughout the Library, and more opportunities to collaborate and learn from our peers. If nothing else, it’ll help us, together, interrogate the notion of “good service.” And I’m hopeful that it’ll also promote conversation about how projects walk a path to production – no matter where they come from in the Library, and regardless of whether they are technical innovations or other kinds of changes in operations, and whether they originate with librarians and library staff or digital humanities scholars.
So I want to conclude by sharing a story about one such project. It’s in part a story about what you get when you open up space for skunkworks operations – and it’s in part a story about what you might lose and what you need to be prepared for.
Before I worked in the Library, I worked in the library. As a post-doc with the NINES group, a effort to peer review and federate nineteenth-century electronic scholarship and create a suite of tools for digital pedagogy and analysis, I designed a tool called Collex, and worked with a group of fantastic developers to implement it for NINES. Collex, which is still in use by projects like NINES and 18th Connect, is about metadata aggregation, scholarly mashups and creative content re-use, linked data, and faceted search and browsing over a heterogeneous corpus of materials – full digital resources (including some prominent archives here at Nebraska) and catalog entries or citations. Because UVa Library has had the longstanding practice of hosting DH projects within its walls, NINES benefited from a lot of hallway conversation with librarians and software developers. One of those was Bess Sadler, who was just as excited to talk with us – because she saw immediately what we didn’t – that Collex (with its adjustable relevancy ranking of search results, ability to index in different datastores at once, and its easily-edited facets for browsing content) offered a solution to a problem the Library faced – an inability to customize its vendor-provided OPAC, or Online Public Access Catalog, in a way that suited our local collections and our users’ needs. Bess and Erik Hatcher, our lead developer, began to collaborate on a prototype, using the same framework as Collex: Solr and Ruby on Rails. This was entirely a nights-and-weekends project for the two of them. I contributed some user interface design, and the three of us published a chapter on the project in a book about “Library 2.0 initiatives.” Erik christened the thing “Blacklight,” as a play on UVA + Solr: ultraviolet, or black light. There was a conference presentation or two, but then – everything stalled. No path to production.
Several months later, I found myself directing the Scholars’ Lab, and Bess was working for me as the head of our nascent R&D unit. I knew immediately what she’d choose as a research project with her 20% time. What I didn’t expect was that others in the department would be so interested, or inclined to use their research time to explore all the fascinating little nooks and crannies of the Solr index, or our code for facets in Rails. Eventually, it was clear that we had a skunkworks project on our hands. I’ll gloss over all the development of the Blacklight, and how we slowly built trust and demonstrated value in it – but if you’re thinking of making the case for a new project and/or testing out the dynamics of a skunkworks team, I have two words for you: “code sprints.” (Nobody can object to a plan to buckle down and try something out for a very limited time period. Two weeks was the magic number for our sprints. Two weeks and then up for air and a demo of what was accomplished.)
Before too many of these, we had a sanctioned skunkworks team and a real project that was eventually going to walk a path to production. More with the glossing over, now – but the end of the story for the Scholars’ Lab was the beginning of it for others – for, in fact, the whole new Library department that was created to continue development of Blacklight and deploy it as a wholesale replacement for our online Sirsi catalog. And this group was put together to do more: after Blacklight began to be adopted by other libraries (among these are Stanford, Johns Hopkins, Northwestern, University of Wisconsin, and others), it emerged as a key component in a collaborative project with Stanford, the University of Hull, and the Fedora/Dspace initiative. This project is called Hydra, and newer partners include Yale and many others. It’s an open source partnership about anchoring a variety of rich and flexible applications to a solid repository infrastructure – for preservation, publishing, discovery, etc.
No English majors or Classicists were involved in the naming of this initiative. (In fact, related project names include Hydrangea – poisonous to housecats – and Hypatia, who was flayed alive with broken pottery.) The Hydra name is meant to signal collaboration in the open source community (if you have many heads it’s clear that no one institution is driving the endeavor) and to evoke the notion of a central core (Fedora) with many possible Blacklight-based extensions. And in terms of our local experience with Hydra, the whole unstoppable monster thing is – cheerfully – not far off the mark. At any rate, you could easily view this project as the creature that ate Scholars’ Lab R&D – because one of the primary results of the success of Blacklight and its key role in sparking the Hydra collaboration was the need to move some of the people who were now expert in these tools and hugely energized about them out of the skunkworks and into other departments — departments that were going to be more about above-board development integrated with the rest of the Library, about deployment to production, and about the long-term care and feeding of the product.
And that was A-OK with me. Who wants to be the place where careers come to stagnate?
So, one thing to be clear-eyed about in setting up a skunkworks is that your successes will mean staff turnover. We’re comfortable with this in my group, so long as we keep just a couple of steady and long-term folks with an inclination toward mentorship of their newer colleagues – and so long as we continue to demonstrate that it’s worth everyone’s while to make sure we’re fully staffed. What’s nice is that the success of Blacklight as a skunkworks project helps to demonstrate that value. The other thing it demonstrates for us – and I trot this out repeatedly – is the incalculable value of those hallway conversations with scholars and digital humanities project staff – the reason you want DH projects outside your library or center and therefore beyond your control to stay near you, physically. There are a hundred positive reasons why this is a lovely state of affairs. If you need to cite a mercenary one to help make the case, it is this: keeping lines of communication open with outside DH projects turns them into skunkworks teams you don’t have to pay for!
So, what came next for us? We’ve been investing heavily over the past few years in spatial approaches to humanities and social science scholarship. This engagement means that many of our staff have had the opportunity to experiment with and get interested in geospatial tools and methods. One project stemming from 20%-time experimentation by a couple of us has slowly grown – first into an NEH Start-Up project and now into a 2-year, $700,000 Library-of-Congress-funded collaboration between the Scholars’ Lab and the Roy Rosenzweig Center for History and New Media. The goal of this collaboration is to enable rich, scholarly interpretation of archival collections in an explicitly graphical, annotative, and above all geo-temporal framework. The project is called “Omeka + Neatline,” and I’d be very happy to chat about it with anyone who’s interested.
I’ll just highlight one aspect of Omeka + Neatline that is relevant to our conversation today. The partnership between the Scholars’ Lab and CHNM on these tools demonstrates that you can’t stereotype libraries and DH centers as service-oriented on the one hand and research-y or renegade on the other. CHNM (as most of you will know, a fantastic faculty-led center housed within an academic department) is the partner building Omeka, Zotero, and other tools conceived (as managing director Tom Scheinfeldt describes) as “broad, populist, stable services.” Scholars’ Lab R&D, on the other hand – a Library department – is the partner going for crazy research questions and experimental interfaces. We need both approaches – and I’d argue that we also need examples of organizations like these two, playing against type.
Many of us are sensing that we’re moving into a kind of “alternative academic” universe where some of the long-held stereotypes of faculty and librarian personalities, research interests, devotions, inclinations, and native capacities are breaking down. If that’s true, it might be because there are always more skunks than you think.
What I’ve tried to convey this morning is that it profits us little, at the present moment, to protect or maintain sharp professional distinctions between the ranks of researchers and service providers — but that the potential benefits of creating a protected space for skunkworks R&D within a larger, service-oriented institution (like a library) are truly great. That said, the organizational and management challenges to fostering R&D done well are also great. And by “well,” I mean R&D that is well-informed and -integrated into the larger stream of scholarly inquiry and that is legible to scholars not only as something that promises to meet a need (which is the way many library projects try to sell themselves) but that is research in its own right, that matches a scholarly mindset, or scratches an itch, or speaks to an ethos. Well-done R&D, to me, is also — despite all the temptations it faces to hunker down and hide — frankly brazen about what it is doing and why, and thoughtful about the way it moves its own innovations into engagement with the open source community and into solid, well-supported cycles of test and production.
For library-based R&D meaning to play a role in the exploding arena of the digital humanities, this last piece is key. As the DH community grows, it desperately needs projects that can serve as role models in demonstrating healthy paths to production. Of all sectors of the academy, I believe that libraries and library-based centers are uniquely positioned to do this — if we take seriously a role in fostering both the teleological and non-teleological notions of the “path.”
How lucky we are to have this opportunity! If we wasted it… (sorry!) it’d really stink.