[This is a roughly-edited version of a keynote talk I gave last month at #code4lib, a fantastic annual conference for software developers and systems folks working in libraries. If you want to hear my bad jokes and attempts to pander to the crowd (or at least to let them know that I was conscious of the back-channel), or if you’d like to see what happens when I indulge my nerdiest tendencies in slide production, I recommend the archived livestream. I’m skipping a long pre-amble that included the Super Friends, hostile IRC bots, and a description of my own professional background – in which I slowly moved from literary and bibliographical scholarship to working with independent DH projects in scholarly think-tanks and projects that sat alongside libraries, to working in and for a library, and as a part of the blended digital humanities/library community that many of us inhabit now.]

The biggest surprise I had about my emigration to Libraryland will be of no surprise to those of you who have been here longer, or who came out of an I-school, or otherwise basically grew up in the culture. And that is that the shift radicalized me. Coming to the Library woke me up: on matters of privacy, on labor conditions and class issues in higher ed, on the sucky practice of training of humanities grad students for non-existent jobs, on free & open access to information, and (especially for those of us who work at publicly-funded institutions) on the rights of taxpayers to expect quality work for the public good out of what they help pay for.

So it may sound like I’m going to give an activist talk. That’s true to some degree, but I’m mostly going to give an impatient one — a talk that comes from where I am now. Although I used to be on the design and development side of things, I am now a soulless administrator, and therefore I thought the most useful function I could perform at code4lib would be to bring something back to you from that perspective. My title will therefore not immediately suggest an activist agenda.

Welcome to… “Lazy Consensus.”

Could anything sound less like “How impatient people can change the world?” This is a phrase that rings of nothing more than lying in a hammock, singing kumbaya. But my goal will be to introduce lazy consensus as a tactical approach for moving committees and organizations and institutions (and, hey, maybe even nation-states!) despite themselves. And I have another message today. “Lazy consensus: you oughta wield it — because it’s already being wielded against you.”

There’s not much chance that a code4lib attendee hasn’t heard this term before or even had some personal experience with lazy consensus as it is formalized in situations like committee voting. It works like this: when a decision needs to be made, someone steps up with a proposal about how to proceed, and the whole group gets a certain amount of time to speak up against it. People in favor might, lazily, give it a +1. (That’s three languid taps on the keyboard for approval, Lebowski.) And there’s no obligation even to do that much — because (here’s the important thing) the default answer is always yes.

This shift in perspective alone, for group that can agree on lazy consensus as a tactic for vote-based decision-making, can be major. Lazy consensus turns the very worldview of places that have a habit of issuing knee-jerk “noes” on its head. Yes becomes the default.

If yes is your lazy-consensus default and the clock runs out with no major objections to the original proposal being voiced, the group moves forward with it. If you have to go back to the drawing board because people do object, you go – but the comforting thing about this tactic is that at least you didn’t stay there, at the starting line, forever and ever amen. You’re always moving quickly to concrete, generally reasonably-implementable proposals that (in most cases, in my experience) only need some iteration and adjustment before they’re good to go. And the beautiful thing for large, slow-moving, and bureaucratic organizations (like libraries) is that, to stop you from rolling forward, somebody had to be paying enough attention to notice, and then had to care enough to craft and voice an opinion behind which others might see a plausible rationale. This lies in contrast to the situation in far too many organizations and groups, where, oftentimes, an untoward amount of institutional inertia or even disengagement must be overcome before anybody feels licensed to move.

You might be tempted to sum all this up as “Fortes fortuna adiuvat.” But the basic idea behind lazy consensus is a little less Gladiator and a little more Downton Abbey. It’s a social contract, which works like this. If we operate in by lazy consensus, we already agree on one thing: if you can’t be bothered to say yes or no to my proposal in a timely fashion, you probably don’t fundamentally care about what happens on this occasion – so we’re not waiting on you, and will assume (no harm, no foul!) that you are getting yourself out of the way while those of us who do care carry on.

As a principle, lazy consensus understands that inertia can work with you or against you. After all, an object in motion tends to stay in motion. An object at rest tends to stay at rest.

When you’re using it on the up-and-up — in social-contract mode — lazy consensus requires that everybody understand and agree to the rules. In fact it is probably written it into your by-laws. But we live in the messy, unwieldy, largely un-regulated real world. It’s no accident that I use a physics metaphor, Newton’s First Law of Motion, to describe how we might apply the concept of inertia to decision-making in organizations. This is because lazy consensus is not only a tactic to use under clinical conditions (such as opinion-polling of members of a committee). It may be a social contract — but in all frankness it’s also a practically a natural law.

You can no more effectively deny the power of lazy consensus than you can deny gravity or thermodynamics. It will act on you whether you acknowledge it or not.

And that brings me to something about which it is important for me to be crystal clear. My whole talk today is governed by a moral imperative. [Here I exercised the prerogative of the second keynote speaker in a conference, by inserting a slide that positioned my own chaotic-neutral talk against that of our very lawful-good opening speaker -- that paladin of code4lib, Dan Chudnov. ...You had to be there.] This a moral imperative I want to make sure you understand — because I’m about to give you my most reckless advice. You will shortly hear me advise you to do the very thing that (done poorly) regularly earns even the best library-based software development groups a reputation for being un-governed, disconnected. For being loose cannons.

My reckless advice is that your team — collectively, not individually, mind you — begin to operate by lazy consensus not only on special occasions (as, for instance, a refreshing change from Robert’s Rules of Order), but instead as your default mode: the way you function every day, in almost every corner of in your working lives.

In order to give you this advice in good conscience, I need to paste warning stickers all over it. And this is what they say: “You must only use lazy consensus to do what you know is right.” That’s the moral imperative. And yes, we have reached the schmaltzy portion of our program.

How do you know what’s right? How do you know what lazy-consensus action you (the collective you) might take for the collective good? The answer itself (just like this tactic’s desired outcomes) is not lazy at all. It requires some inward-directed energy on your part. If you operate in this way, lazy consensus will require a gut-check every day from here on out. (And I’ll talk in more specifics in a moment about how to make sure your gut is trustworthy.)

I’m here today to advocate what I’ll call an extreme bias toward action – but also to urge you to do your damnedest to make sure you’re one of the good guys. If you’re going to be somebody who acts – who acts as a matter of course, instead of feeling frustrated and thwarted by others’ inaction – then your actions need to be to the best of your conscience in service of the Right Thing.

This is an inherently dangerous position for me to take, and for you to act on. The danger we place ourselves in comes from beauty and from power. The beauty is that following this moral imperative within the laws of Lazy Consensus turns out not just to get things done, but to be a prime mover. It’s going to make you one with nature, my friends. Lazy consensus wielded wisely and justly is capable of galvanizing comatose organizations back into motion and even of reversing terrible inertial trends.

We find a recent example in the SOPA/PIPA blackouts. [More geekery and self-indulgence when I play the "Shut it down -- forever!" clip from the great film Dark City.] Here’s a case where legislative consensus seemed to be sliding almost inevitably in one direction, when suddenly it was tipped in the other by a group of infrastructure and content providers — who did not merely lobby and educate, but who acted, and acted in a way that provoked many, many people also to act, in this case, to call and write their representatives. It was a speaking-out that provoked others to speak up where they had been silent, where they had been the ones therefore assumed not to care. The result was a change in many legislators’ expressed opinions, but even more noticeable was the shift of the politicians – similar to the one we saw first among the citizenry — toward taking a position at all. The resulting abandonment of the proposed legislation reflected not only the will, but the engagement of the people. No more silent, assumed-to-be +1s.

Now, that was a pretty big gesture. It was disruptive — and not entirely signed-off-upon, and viral and in my opinion a force for good. It’s hardly ever this dramatic day to day. But lazy consensus also applies to our little, diurnal decisions – which, taken cumulatively, can have a huge impact on the people and concepts and institutions we care about. The cultural shift that comes about when you make lazy consensus your default mode is a fundamental permissioning. You’re giving yourselves (the collective you, that is, the technical team) permission to do what you know is right – and to assume that the answer to “can we move on this?” is unless directly countermanded, a resounding yes.

I think you can use lazy consensus on the side of Good anywhere, at all levels, without going entirely rogue. But what creates the ideal conditions for it?

I have five. Your mileage may vary. I offer them simply to get you thinking about your local conditions — about what would work for you.

1. First on my list? Being in an organization that deliberately makes room for a skunkworks or a pure R&D operation. Benefits ripple outward, even if you are not a member of that group – with one big proviso: that you and others generally trust the skunks and know that they have a solid plan for getting the most worthwhile of their creations into stable production.
2. If a healthy skunkworks or a dedicated R&D team is not in the cards for your organization, try negotiating something like 20% time, on the Google model, for R&D work done by developers across the board. This is a model we have used to excellent effect in the Scholars’ Lab, where, among other things, it resulted in Project Blacklight and work that evolved into the multi-institutional Hydra project.
3. I strongly advise spontaneous, developer-driven, grassroots rabble-rousing that (here’s the important part!) looks enough like your local structures that you’re able to build on whatever cultural capital and normalized (preferably positive) expectations those structures have earned — whether they are committees or interest groups or task forces or even book clubs. Organize!
4. Next up? Know your enemies. They are fewer than you may think. Middle-management sucks? They are probably well aware of that at the top. But what I find key, and often offer as advice, is that you do whatever level of work your own psyche will require such that you can extract personalities from the mix and realize that you are generally fighting bad trends, not bad people. Or at least try to make yourself think this, even if you have a feeling it’s not true. Frustrations stemming to personalities and egos will only distract and deter you as you fight the good fight.
5. Finally, find your friends! Where are they? If you’re a software developer in the library, you will possibly find them in that department that needs you and annoys you the most — or maybe in the skunkworks org that lives among you and is getting a little disconnected. But I also guarantee you’ll find friends out among your institution’s digital humanities faculty and open-access or data-preservation-minded scientists. You also can’t do better than to seek out like-minded allies at whatever library your library looks up to and wishes it could to be.

On with the lists! What are your ethical obligations, if you adopt a standing, lazy-consensus tactic in Libraryland? Another five.

1. Embrace the loyal, engaged opposition. They get the same info everybody else gets. If you withhold information from smart and willing people who disagree with you, even if you happen to make things move your way in the short term, you will fail at the ethical game of lazy consensus. The opposition does get its chance to object. It’s a courtesy you’d expect from them.
2. Never ever ever shut out UX and Public Services. Depending on the climate in your institution, that could be a variety of the former bullet, but it’s important enough of a danger for library-based software development to stand on its own.
3. Practice what you’d teach. By this I am advising you to act every day like you would if you were consciously mentoring a promising novice developer in your department. That might mean anything from employing test- & behavior-driven development, to producing impeccable documentation, to working hard toward healthy deployment practices for the betterment of vampires & werewolves everywhere.
4. If you f*ck up, ‘fess up. That is (not to put too fine a point on it), if you try this approach and fundamentally screw up, be prepared to confess your sins and use the conversation as an opportunity to become more savvy about your place of work. The main point is not to hide your messes. Even though in a moment I will tell you something that may seem to run counter to this principle, lazy consensus works best within an open information economy.
5. And try not to screw up in the first place. That sounds incredibly flip, but I mean something more specific by it than you might think. It’s a twinned notion that ties together some of the other items in this list. First, as library-based developers, to my mind, your “not screwing up” means trying your hardest to deliver the highest-quality conception of whatever end-user experience your organization is striving toward. It’s also a charge to accomplish that goal in a way that, on reflection, will not make you ashamed of yourselves.

You’ll have to address your own conscience on that last point, but I want to be clear that, from my own vantage-point, this does not need to mean, “deliver the code that a non-coder told you to write.” (We’re now verging into the excessively dangerous portion of my talk.) It also doesn’t mean “deliver something that uses every half-baked component imposed on you by somebody who wouldn’t know if you actually used it or not — or won’t even remember, three months from now, that they forced it down your throat.” [Notable frisson in the room, not least from the podium, where the speaker momentarily wonders if she’ll get fired.]

I bring these things up because I’m about to tell you two things I’ve observed about library administration. It’s also the reason I stressed that you have to wear your white hats when you take my advice.

If your leadership is imposing truly bad technical decisions on you (I’m not talking philosophical decisions, mind, but software engineering ones), there’s a secret you should know: they are probably not technically smart enough to understand whether you have implemented those directives to-the-absolute-letter or not. I find no shame in openly acknowledging that good-hearted administrators can sometimes seriously over-reach on the technical front, simply out of a desire to do the jobs we have been given, with the conceptual tools we have at hand. (The structure of our working lives can leave once-bright tools to rust. This may be the subject of another talk.) For you to be a successful lazy-conensus dev team, it’s important to know that, no matter what it seems to say to you, your administration cares more about the spirit of its law than about the letter of it. That is, they care more about the end than the means.

That said: try! Before you take a lazy-consensus approach that organizes a collective of smart people to route around bad directives, genuinely try to explain and to teach, at all levels of your organization. If you intend to wrest back a level of technical decision-making that belongs appropriately with the developers in your organization — don’t do it as an individual. Don’t go it alone. The word “consensus,” after all, is in there for a reason. Please make sure, when you take initiative on things you know that members of your leadership will not entirely grok, that there are enough of you who agree on the direction to take that you can implement it reasonably and with some assurance of sustainability. In other words: don’t be that guy or gal – the one whose renegade, unsupported crap we’re all cleaning up when we discover it five years later – or the one who has, out of ignorance about how the whole library works, imposed an un-workable workflow on other departments. Be talking with each other, and especially with the people you might not see everyday, but who depend on you.

You need to have some common sense in other ways, too. There’s a level at which people will notice that you acted counter to a half-baked directive. But the thing is – that level, of noticing? It’s generally a lot higher than you think. I am belaboring this point because I have been saddened to see good people in more than one slightly clueless organization assume that squishy, cloudy, misguided directives from middle management are the rule of law – when in fact the folks at higher levels are hungry for push-back and are actually expecting the degree of healthy friction that indicates all of their people are thinking hard. I might sum up my advice in this regard as follows: don’t fall on your sword every time you turn around.

This gets back to my other observation about administration. Admin wants momentum more than it wants to micro-manage. So, produce. If you are the team that produces highly usable and sustainable systems, somebody will have your back.

This does mean that you have an obligation to deliver a product that your non-lazy allies, your +1s, can get behind and be proud of. And even more than that: I’ll go so far as to say that if you’re wielding lazy consensus tactically, you are bound to make even the laziest slugs among you, the deadweights in your organization, the people who can’t be bothered, come out of the whole affair smelling like a rose. (My tendency is not to worry about them: they’ll get theirs.)

Okay, let’s zoom out from the library a little bit. I said you ought to wield lazy consensus, because it’s already being wielded against you. (And here’s where I’m going to get a tad political.)

Where is lazy consensus working against us? Most likely, at the policy level at your college or university, where labor issues intersect with intellectual property rights. Specifically, many universities have antiquated, outmoded policies governing IP and patents – which are designed to bring in money from Big Pharma, but which accidentally stomp all over digital library and digital humanities stuff, where you actually bring in more money and prestige by not trying to monetize anything. I suggest you go home and check out your school or institution’s IP policies. You’ll probably find that they limit the ability of non-faculty developers and researchers, who typically fall under the category of work-for-hire, to make fundamental decisions about their own code and content – specifically whether they can share their work as freely, in the form of open-source software, as most of us in this community know we should, and as other types of knowledge workers at the institution may already be allowed to do. It’s no wonder that lazy consensus has worked against us on this issue. How many developers that you know show up for Faculty Senate meetings, or weasel their way onto policy committees at the university level? Hey, how many of your managers do?

This kind of passive disenfranchisement extends to the public sphere, in issues like the corporatization of higher ed. Or the irrational political separation in our country of the humanities from the sciences. (For organizations like the NEH and the IMLS, being left out of policy conversations means being left out of funding decisions.) Or look at the shambling zombie of the No Child Left Behind Act, in which K12 education has become a game of teach-to-the-test.

And then we’ve got Fight Club Soap — the scholarly publishing situation we’re all so familiar with — in which universities pay for the research and writing of scholarly articles, and for the time of their faculty to peer review and edit them, only to turn right back around and purchase the products of that labor back from publishers at an exorbitant mark-up and in unbreakable bundles. (I’m heartened to say that the tide is beginning to turn on this, with researcher boycotts and a shift from librarians calling foul to faculty doing so. The emphasis on Elsevier alone at this point is probably unjust, even if hugely symbolic, but my feeling is that we see in the current grassroots boycott a case where the crucial constituency, who have previously been silent and therefore assumed to give lazy consent, are finally speaking up. And just in the nick of time, because the Research Works Act is on its way. [Note: at the time of the publication of this transcript – "Ding, dong, the witch is dead!" – at least temporarily.]

Now, my point with these examples has not been to push any one agenda at you, but to suggest that lazy consensus has already been working against us in every case where we don’t engage. You can easily see its negative side in the wider political arena. But on the very local level, it kicks in and becomes a factor in any set of decisions where we developers and systems folks and middle management get so busy that we go completely heads-down and become oblivious to larger trends and directions. When that happens, we end up not having a voice. We end up being the people who don’t speak up even though we’re nominally represented, and no matter what we may really think, we are therefore assumed to be a +1.

“Feeling shut out” from decisions in your library, by the way, is not a valid excuse. In a worst-case scenario, if you don’t have a trustworthy conduit in management or any reasonable forum for direct contact with leadership, it’s your job to make one. This gets us back to the notion of finding your friends: storm the barricades! (By which I mean: do your homework so that you are impressively well-informed and then knock on your AULs’ or deans’ or library director’s doors. Knock politely. After all, it’s a library.)

That should be your first step. But then try a lazy-consensus approach. If you and your group are really feeling fundamentally blocked and disconnected, try announcing that, unless you hear otherwise, you will plan to attend the next meeting of your library’s leadership group to discuss the issue. Not the subcommittee for blah-de-blah, mind you. I’m assuming you’ve tried them – tried in earnest. In true lazy consensus mode, you will not really be requesting, but rather stating that, for this one, you expect a seat at the grown-ups’ table. Make your leadership tell you that you can’t have it. (My prediction? They won’t.) In fact, it often surprises me how often decent, smart people on either side of the management/labor divide in organizations seem to be waiting, middle-school-dance-fashion, for the other to make the first move. If your team feels like it’s been ignored or stonewalled, it should put its own (audacious, if weirdly collective) ass on the agenda. I guarantee that your specific problem or your overall working conditions (whatever it is you needed to talk about) will be thoroughly discussed — both with you in the room and (this is the scary but needful part) after you leave.

I want to wind my talk up by making a straightforward assertion. In the public sector and in higher ed, libraries are collectively facing enough challenges to warrant a fundamental attitudinal shift in organizational thinking. The shift is to implement, at all levels in each organization, a bias toward action. But do not forget the primary mandate of this talk. When you’re taking advantage of a lazy-consensus technique, it should have the effect of keeping you in the best possible conscience. You should undertake this only in order to do what you know is right. I am offering you license to be an agent for positive change — not the biggest jerk your library has ever seen.

Please know that I had to think really hard about whether I wanted to advocate this kind of behavior to you today. It’s risky all around: personally and institutionally. Ultimately, I decided that, at this moment, for libraries, stagnation is a far, far greater evil than the taking of reasoned risks — and that, by and large, your library directors and deans would agree with me that fighting stagnation would be worth having to cleaning up the odd, renegade mess or two. You’ll have to make your own mind up about when and whether any personal risk is worth it to you.

In the sort of weird, hybrid job I have now, I work with a lot of different kinds of people: not just developers in the digital humanities and in libraries, but students and scholars (from undergrads to grad students to adjuncts to professors emerita). I work with university administrators, outside consultants and vendors, heads of professional organizations, book and journal publishers, librarians from across the metadata-to-public services spectrum, and probably more that I’ve forgotten to name.

drive it like you stole it

[Our scene closes with a slide of my 8-year old boy, smiling at the tableau he’s created: two GI Joes from his father’s childhood closet, riding a plastic Taun-Taun. The caption? "Drive It Like You Stole It." Exeunt Nowviskie & Code4Lib 2012, pursued by a bear.]

[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.

Here’s where I am. It’s nearly Hallowe’en, and kids have settled into school routines. I have little ones in my own house and big ones in the Scholars’ Lab — the youngest of whom are newly, this year, exactly half my age. Other kids are dead, and it’s still bothering me a good deal. Mornings in Virginia feel cold now, and acorns are everywhere underfoot. We’re tracking leaves inside.

It’s a melancholy way to begin a post, but it situates us.

It’s October 2010 in the social scene of the digital humanities, and (yes, I’m feeling wry) our gathering swallows Twitter in the skies.

I tweet a lot. It’s a mixture — the writing and the reading — of shallow, smart, and sweet. I answer lots of email, too, lots of messages from strangers asking questions. We’re doing a good job, my team, and people are asking how. I stuck my neck out on a thing or two, and people are asking why, or for more. This fall, I worked with friends to launch a website that I’m proud of — which is for strangers, asking questions. I’ve stopped answering to the phone.

There’s a bit of a joke around the SLab, about the degree to which the boss-lady is not service-oriented. It’s funny (as they say), because it’s true. But it’s only true insofar as I let it be — and most local colleagues realize that I put on this persona consciously, as a useful corrective or (at least) a countering provocation to that strong and puzzling tendency I have noted as a scholar come to work in libraries: the degree to which the most beautiful quality of librarianship — that it is a service vocation — becomes the thing that makes the faculty, on the whole, value us so little. Service as servile. The staffer, the alternate academic, the librarian, the non-tenure-track digital humanist, as intellectual partner? Not so long as we indulge our innate helpfulness too much. And not so long as we are hesitant to assert our own, personal research agendas — the very things that, to some of us once expected to join the professoriate, felt too self-indulgent to be borne.

I’ve written about these things. Others have, too. And — even though service under any banner is undervalued in the academy, and a fully-fledged digital humanities center administratively embedded among library services is a rarity — near and far, DH stays nice. (Just think: how many other academic disciplines or interdisciplines work so hard to manifest as “a community of practice that is solidary, open, welcoming and freely accessible” — a “collective experience,” a “common good?”)

Here’s the irony. And it’s how we’ll move from a dwindling Virginia October to the eternal September of the digital humanities.

If, on the local scene, I strive to give a habitation and a name to the administrator (yes, even that!) as driven intellectual partner — for outreach and service to the DH crowd, I’m your girl. The kinds of things I volunteer to organize and do (hosting training institutes, grad fellowships, and friendly un-conferences, helping raise the big tent, and providing signposts or lacing bootstraps for bootstrapping), together with my role as VP and Outreach Chair for the ACH, put me in a position to observe and appreciate the depth of generosity in DH. A truly remarkable and frankly heartwarming percentage of the digital humanities community gives unstintingly of its precious time in these ways, solely for the purpose of easing the path for others. And it’s not all organized initiatives. To a degree I have not noted before, the DH community has become conscious that we operate in a panopticon, where our daily voicing of the practice of digital humanities (and not just on special days — every day) helps to shape and delimit and advance it. That voicing operates wholeheartedly to welcome people and fresh ideas in, if sometimes to press uncomfortably (one intends, salutarily) against the inevitable changes they will bring. Some of us take this unending, quotidian responsibility too seriously.

I hear, and hear about, our back-channel conversations.

“Eternal September” is a notion that comes from Usenet culture — the early peer-to-peer newsgroups and alt.* discussions that were, for many of us, an introduction to networked discourse and digital identity. Because Usenet activity centered around colleges and universities, a large influx of new students each September had disruptive effects on its established, internal standards of conduct, or netiquette. About thirty days in, newbies had either acclimatized to Usenet or they had dropped away, and the regular roiling of September could be left behind for another eleven months. As the mid-1990s approached, Internet access became more common and less metered by the academic calendar. Once AOL began offering Usenet to its subscribers, September was eternal.

The Wikipedia article for Eternal September reads “See also: Elitism.”

I mention this because I am not unaware of the awkwardness of my position. I have worked in humanities computing for fourteen years. I direct a department dedicated to digital scholarship, I’m a steering or program committee member or executive councillor or associate director of several DH groups, and an officer of (arguably) its primary professional society. My dissertation and almost all of my publications and public presentations have been in the area of digital research, scholarship, and pedagogy. (Still, I still have a hard time thinking of myself as a DH insider, or as part of the establishment. This comes, I’m sure, of a profound respect for the two living generations of computing humanists under whom I trained — and because I matured in the field before Twitter and THATCamp made everybody instant pals.)

That said, I am positioned to hear the private rumblings of many of the people most inclined — indeed, perhaps most known for their inclination to be generous to colleagues in the digital humanities, old and new, and that over the course of years and sometimes decades. I also hear from some I’d consider new to this field, but experienced in ways that make them sensitive to the tides of online collectives. What I most hear is a tension between goodwill and exhaustion — outreach and retreat. I’m sympathetic to the weariness of these people, treading water, always “on.” I feel it, too. But it’s their voicing of frustration and possible disengagement that alarms me.

DH is not in Usenet’s eternal September, precisely. That is, truly rude or tone-deaf or plainly infelicitous tweets, comments, and postings are few enough that they’re of little import, even when they grate. I also remain hopeful that we’ll soon figure out, among so many bright and sensitive readers, the right balance of promotion for our programs (large or small) with genuine expressions of enthusiasm for our work — the rhetoric of always-on. And, for the most part, niceness itself is catching (which may be part of the problem). Fatigue will come in waves, to different segments of the networked community at different moments. So it goes. But the Eternal September of the digital humanities most threatens to exhaust us all when our newer colleagues, who are most visible online, make two assumptions: they think that all of this is new; and they think that the current scene is all there is.

Most of us are newer and more insular than we realize.

What does it mean to practice as digital humanists? Some cold mornings, I don’t care. We are here to help each other figure it out along the way — by enacting community, building systems of all sorts, doing work that matters in quarters predictable and unexpected. We are devoted now like nothing I’ve seen before. But have you begun to sense how many good people are feeling deeply tired this autumn?

Some of you are hiding it. Some of us should take a breath.

There’s a scene, in the filmed version of Chuck Palahniuk’s Fight Club, in which Tyler Durden leads our Everyman narrator on an expedition for biomedical waste. They’re raiding the trash bins of a liposuction clinic for lipids that can be rendered into soap. This is expensive soap, boutique soup — value-added soap. It’s the kind of soap probably only bought by the kind of woman who frequents a liposuction clinic.

“It was beautiful,” we hear. “We were selling their own fat asses back to them.”

This week, a powerful letter was distributed to all faculty of the financially-imperiled University of California system — the libraries of which are now faced with a 400% price increase if they would like to continue to provide access to 67 important scientific journals distributed by the Nature Publishing Group. One of these is NPG’s flagship journal, Nature. The price increase would bring the annual cost of a single NPG journal from approximately $4500 to over $17,000. When, in conversation today, I’ve shared this number with my librarian colleagues at home and abroad, I’ve heard a lot of incredulous laughter. But laughter turns to quiet musing (“would that work here?“) when I go on to say that the California letter threatens complete boycott, in clear terms and with the support of a system-wide advisory group on scholarly communication, of all UC faculty involvement in the production machine of the Nature group, if the costs for these journals cannot be brought in line with reality.

The UC/Nature story was covered swiftly and well by Jennifer Howard of the Chronicle of Higher Education. Her article was followed today by a set of must-read musings by Dorothea Salo, from the perspective of a repository librarian and open-access advocate. And, of course, all of this is contextualized by any number of scholarly committee and task force reports, and by the work of thinkers like Kathleen Fitzpatrick. I thought I had nothing to add, at this early stage of the UC system’s game. However, I’ve already noted enough bafflement on the part of humanities faculty and graduate students at the affair to think I should talk in a pithy way about Fight Club soap — and then share a conjecture about the bizarre, perennial surprise that seems to be attendant on these conversations.

The position in which libraries find themselves vis-a-vis Nature, Elsevier, et al is laughable — once you’ve shed a tear for all of the humanities collections (monographs and periodicals) that have already been cut in response to previous gouging by journal providers. Large companies have cornered the market on access to scientific research which universities see as mission-critical, and can therefore name their own prices. The first victims of the hard decisions forced on collections stewards at many institutions have been less costly, lower-profile, slow-knowledge, lower rate-of-use, disorganized and a la carte humanities publications — with the dire results we have seen across the academy over the last decade. Libraries have cancelled standing orders with university presses. Many presses and journals, having lost their best (sometimes almost only) clients, have responded by reducing the number of worthy book manuscripts and articles that make it into print. Others have folded entirely. A generation of humanities scholars, still struggling to meet the “or perish” tenure and promotion expectations of a bygone era, feel they have nowhere to publish. Students and faculty have lost access to whole threads of our shared, cultural conversation — conversation that continues in humanities publications their schools now cannot afford. Other threads (genres of work, areas of inquiry) have been cut short entirely.

Ready to laugh again? Let’s look at the statistics provided by the California Digital Library in its letter to faculty, and then let’s talk about soap. Articles published by UC faculty in NPG’s flagship journal, Nature, numbered 638 over the past six years. And that’s just Nature. Sixty-six other journals are part of NPG’s proposed rate hike. Approximately 5,300 articles by UC faculty have appeared in them in the same timeframe. But that’s not the kicker. Pause now for a moment to imagine the countless, unquantifiable hours of UC faculty labor that have gone not only into the research for and writing of these articles — but also into their vetting. How many UC faculty have spent how many hours engaged in peer review or serving on advisory committees to the journals that their libraries now cannot afford? How much intellectual labor already paid for by the University of California system is now being sold back to UC’s own libraries at exorbitant costs? How much Fight Club soap are we willing to buy?

And how long have we all seen this train wreck coming?

I’m a humanities PhD who has worked in an administrative position in a major research library for nearly three years. I’m still new enough to feel productive cognitive dissonance and the occasional wave of culture shock. Often this centers, for me, around the beautiful service ethic of librarians, and their desire to make things easy, and make things work for the faculty and student researchers they serve. It’s a different kind of monasticism from the “life of the mind” for which I was trained, but I recognize devotion of all sorts, and I bet you do, too.

There is, however, a distinct danger in this impulse — to provide a level of self-effacing service that does not distract the researcher from his work. With the best of intentions, it can lead to a strategy of hiding the messy stuff, or laying a smooth, professional veneer over increasingly decrepit and under-funded infrastructure. And then there’s the degree to which the service mentality prevents librarians from engaging with faculty as true intellectual partners — developing the kind of relationships that foster frankness. (Of course, we need to be met half way. Why is it that librarians’ advocacy for open access initiatives has provoked such discomfort among faculty at so many institutions that the word on the street is now: don’t speak up, don’t be pushy, know your place?)

Combined, these factors can mean librarians fail to blow the whistle on journal pricing and subsequent collections implications until it’s too late. (Witness the shock and anger of many faculty bodies at recent cancellations of humanities subscriptions or closures and consolidations of whole libraries at institutions around the country.) The University of California’s statement, its coverage in the Chronicle, and the open discourse that I hope it promotes among researchers and librarians is a great social positive — even beyond the impact I predict it will have on pricing models by monopolistic journal providers and the visibility it will provide for open-access alternatives like those outlined in the UC letter. We shouldn’t let this crisis go to waste, or overlook what it can reveal about the way we work together in higher ed.

We’re in untenable and intertwingled positions, all of us. I advocate the talking cure. Why should the first rule of Journal Club be, for librarians and faculty alike, not to talk about Journal Club?