[This is an edited version of a talk I gave today at the 2009 convention of the Modern Language Association. I omit here some of the local details and concrete examples I offered at MLA. At this point, I feel more comfortable voicing these specifics than publishing them online – but I do commit to seeking out further opportunities to open the kind of frank and important conversations I advocate below. This text (like everything posted on my personal website) reflects my opinions only – not those of my colleagues or employers. I welcome comment, including correction and instruction.]
I’ve decided to spend my 10 minutes of introduction on the MLA convention’s “Links and Kinks” panel indecorously – in opening conversation about one of the least genteel, least talked-about aspects of collaborative work in the digital humanities. I’ve been active in this community of practice for 14 years – and can count on one hand the number of interchanges I’ve had about these issues that were both unguarded and productive.
The policy issues related to institutional and academic status that I want to put before the panel are so uncomfortable that they tend to make good-hearted, collaborative folks like all of you behave as if they can be wished away – as if they’ll shrivel up and die if they are studiously ignored. But here, as in other areas of the academy, benign neglect is bad behavior. Consciously ignoring disparities in the institutional status of your collaborators is just as bad as being unthinkingly complicit in the problems these disparities create. This is because of the careless way your disregard reads to the people it damages. These people are: your junior colleagues; your graduate students; academics on the “general,” “administrative,” or “research faculty;” the lost souls euphemistically referred to as academic “contingent labor;” and the least privileged among us, members of your institution’s staff: those of your collaborators who are classified as service personnel. This latter group includes programmers, sysadmins, instructional technologists, and credentialed librarians and cultural heritage workers.
There is another reason, beyond discomfort, that we don’t really talk about how status factors in collaborative work. The people best positioned to articulate the personal and professional impact of HR and academic research policies either can’t afford to make trouble, or quite rightly fear they’ll lose the little bit of collegiality they’ve earned from you, the faculty, if they publicly align themselves with the wrong side of the equation. You’ll rarely hear them yelling about the violence inherent in the system.
Because they highlight the degree to which new works of scholarship are the work of many hands, the digital humanities bring into focus any failure to acknowledge our collaborators appropriately (by which I do not mean merely “to acknowledge them at all”). And it is in the digital humanities that I believe we will have our first and best opportunity to address inappropriate and counter-productive academic policies relating to intellectual property. These policies are – in my varied experience as a graduate student, a post-doc, a senior member of the research faculty at an R-1 institution, and (now) a higher ed administrator – where the rubber hits the road.
I hail from the University of Virginia. “Monopolies of Invention,” the title of my talk, is from a highly relevant passage of writing by UVA’s founder, Thomas Jefferson. Its explication will be left as an exercise to the reader.
Several of my own past projects, including projects in the literary field, have done a delicate dance with our IP policy in Jefferson’s “academical village.” These policies require that we disclose inventions or innovations (including the development of new software or digital humanities methods) to a governing body that will determine whether they should be patented and monetized. As a disclosure incentive, the person designated “inventor” is offered some portion of potential profit, which is owned by the University if the work was done using “significant University resources.” Significant resources are anything that goes much beyond a low-end laptop, electricity in your office, and the brainpower of a teaching faculty member. As a determining factor in the patent process, the “significant resource” designation certainly kicks in when general faculty and staff reporting to me, in my role as director of a digital humanities lab and department within our library system, collaborate with teaching faculty on scholarly projects.
By some interpretations of the policy, I may well owe this governing body conversations about four different collaborations we’ve undertaken with English Department faculty in the past year alone: projects that use technology to teach poetic scansion, analyze 19th-century biographies of women, data mine 18th-century texts for metaphor, and present searchable audio files of William Faulkner lectures. I frankly don’t often talk with faculty about patent policy before we start working with them, because it would scare them all away. Instead, I rely on my sad ability – if called upon — to convince local arbiters that innovations in the digital humanities are fundamentally worthless, and that we should get a pass. I don’t think this is good institutional practice.
The intellectual property system in universities is geared toward big profits from big pharma, not little websites on prosody. My happiest conversations with our Library’s brilliant IP lawyer happen when a project’s grant money comes with strings that absolutely require open source code and open access content, no matter who contributed to its construction. All of the Mellon Foundation’s grants do, now, for instance, and that’s what saved the NINES project some huge headaches. The open-access mandate of the NIH is bringing this approach to federally-funded medical research. What would it take to expand the mandate to the NEH? If you value open access and the liberties it grants to your collaborators, you should explore this issue with the funders of your research.
I’ll shift now, not without significant discomfort, to a more specific example from the intellectual property dirty-laundromat: a project from my past. This project was of keen interest to a large community of users, was hugely provocative in the challenges it posed to theory and method in its field, and was ready for implementation, — but it has lain fallow for many years even though most of its team wanted to take it forward. I was one of those people. Why did it die? It died because the professor who served as PI on the project’s grant experienced a waning of interest after we exhausted our first round of funding and hit proof-of-concept.
This kind of thing happens a lot and is, frankly, not a big deal. Waxing and waning of interest among collaborators is just a part of the scene, and the digital humanities community has largely found ways to work around this natural consequence of life beyond the lone-scholar model. (The broad survey Dot Porter and I have conducted of times of transition and decline in digital projects confirms this, and we will share our results this summer.)
So, if losing a key collaborator doesn’t automatically spell doom for a digital humanities project, what was the problem? The problem was this professor’s assertion of a right — granted to lead faculty members on collaborative research projects by our institutional policies — to intellectual property over the whole concept of our shared work.
I do not wish to sound ungrateful for the experience I gained on this project; it was a transformative period in my intellectual and technical growth, and in my growth as a pragmatist, which is to say a higher-ed administrator. Friendships are intact, and in fact – years later – we are amicably poised for a revival of the project with new partners. But my institution failed me in allowing a collaborative digital humanities effort central to my scholarship to be treated like a patent-able widget created by a sole inventor. The contributions of all team members besides the sponsoring faculty member fell under the category of “work for hire,” no matter how intellectually rich and critical to the project these contributions were. Our programmer and designer felt like they had no leverage at all to argue against this system. And what about me, the person who had conceived and designed a software approach to our research problem and had shepherded all aspects of the software’s development? I chickened out and did not press the matter. What grad student facing her dissertation defense would do more?
Now, years later, the patent, copyright, and intellectual property policies that governed this incident are somewhat more refined. Although “work for hire” is still a major factor for determining the right to ownership of software and ideas, our institution also now offers delicate and charming guidelines for when you, as a faculty member, may classify your collaborators as “a pair of hands” or as merely “an information provider.”
We should stop now to remind ourselves that digital projects require serious investments of energy and critical thought by expert collaborators who did not train in the same way we did and emerge (or diverge) from our conventional paths. Faculty collaborators and graduate students are part of our teams, but even they come increasingly from other departments and schools with different norms. Or they’re English Department grads who set out on unforeseen trajectories. And, often, our research and development groups are not only interdepartmental and ad-hoc, but also include undergraduate and professional-school students, designers and programmers both within and beyond higher ed, computer systems administrators, administrators of less holy sorts, and professional librarians or other instructional technology and information specialists.
The scholars I’ve known who are most obviously at school when working with programmers and other digital humanities collaborators invariably break new ground. That is to say, in my experience, the most productive and interesting collaborations are grounded in a kind of intellectual egalitarianism, or openness to the contributions of all team members.
However, this does not mean that the social boundaries inherent in digital project-work can or should be ignored. Policies about intellectual property and open source impinge differently on the rights and responsibilities of teaching faculty, research faculty, students-as-students, students-as-employees, and staff members of all kinds. These groups may have differing career arcs and intellectual agendas, and their participation in projects is often understood and evaluated differently within their professions and disciplines. If you do nothing else after this conversation, I hope you’ll go home and read your local policies with an eye toward how they work for the people with whom you collaborate.
We may worry that acknowledging cultural and administrative distinctions in the academy will reify them – but, in fact, ignoring differences can result in much poorer outcomes for our projects and personnel – particularly for the increasing number of collaborators who fall into hybrid professional categories. What do we do with those people whose training, research, and publication profiles do look exactly like ours, but whose right to claim intellectual property in the work they undertake as an equal partner is curtailed because of their status in the university’s HR system? The “ignore it and it’ll go away” strategy has not been helpful.
The biggest question for you may be how you’ll open potentially awkward conversations about status in a way that strengthens your team, creates – rather than limits – opportunity, and permits the kind of fluidity and professional growth we all want to foster over the course of long-term, collaborative initiatives.
[Note: this presentation and the larger conversation in which it participated at MLA was later described by Jennifer Howard in the Chronicle of Higher Education.]