I got an email at work today asking about how MPOW’s repository is staffed. It wasn’t the first indication I’ve seen that academic libraries are starting to throw more staff time at IRs. With the understanding that I’m just one person running one IR, and not every IR needs to be the same as MPOW’s, here’s my contribution to that discussion.
What is it exactly that I do, repository rat that I am? I would split my job into three parts: system administration, outreach, and content management.
In the first role, I handle routine system updates and monitoring (and call my boss if there’s a crisis), maintain the design, investigate and try to rectify system errors, cope with file-format issues, investigate system enhancements, and customize the code to fix bugs or make the system more usable. This is probably the most expendable of my three roles (though I’m quite fond of the work); it’s possible to outsource this, though at some cost in quality of fit between the software/service and the institution.
(Not that the fit at MPOW is ideal, mind you. There’s lots of things I wish DSpace did that it doesn’t do and I’m not a good enough hacker to make it do. Nor do I feel comfortable installing quite a few desirable DSpace mods, because DSpace’s architecture is such that mods are not forward-compatible. You’ll notice that nobody’s talking about TAPIR or Researcher Pages these days. That’s because neither is 1.4-compatible, and I haven’t heard a peep about making them so.)
In the second role, I do workshops and talks, hit open houses, talk to faculty at department meetings, write squibs, anything to get the IR noticed. This is hard, often thankless work. It does not produce instant results. Frequently it does not produce any results. It still has to be done, and you can’t outsource or ignore it. An IR without an active champion languishes empty. That’s just life. (I am also becoming MPOW’s go-to person on scholarly-communications issues. That’s not in my job description; it happened—well, because I’m slightly obsessed. People have simply taken notice that I usually have the answers.)
In the third role, I’m a bit of a cross between a collection developer and a cataloguer. I get people set up with the system. I monitor Other People’s Metadata, fixing it as need be. I do batch imports of large files, or items with many files, or websites (which usually have to be tweaked first owing to quirks in DSpace’s HTML management). I handle copyright questions and permissions requests (occasionally consulting MPOW’s copyright officer). I plan to start scouring the web for items that are IR-friendly, so that I can contact their authors for permission to archive them.
These aren’t the only possible roles for an IR manager. An institution that wants to do data curation (not MPOW, yet), or that wants to collect learning objects, or that wants to try innovative ways of displaying items or recruiting content, will likely have needs I haven’t mentioned. Well, and occasionally a public-relations issue comes up that I have to handle (including kicking it upstairs if that’s what it takes).
So must a library have a repository rat to run an IR? Well, no, not necessarily. It’s quite possible to split the above functions among several staff members—let Tech Services do the metadata, add the IR to the other services handled by regular library outreach, assign a systems person to the batch imports and system updates.
But.
The problem with splitting up the work is that the IR then becomes nobody’s top priority. IRs aren’t an established library function yet, which makes them easy to ignore for library staff who have plenty of other work. Moreover, my strong (though purely anecdotal) sense is that most librarians can’t tell you why their institution has an IR. Loading bits and pieces of IR work onto them does not make them advocates; if anything, it annoys them, because they don’t see the use. Let’s face it: IRs are a canny investment in the future rather than an immediate library need.
I can’t say this loudly or often enough: an IR without a champion will languish empty at this time. (Should self-archiving mandates become fashionable, obviously that will change.) Now, if the champion in a given institution happens to be in library admin or even among the faculty or the university administration, then splitting up the rest of the work among line library staff can work fine. If there is no real champion, though, I must say (with all due allowance for bias) I’m for hiring one—or at least making one person (not a committee, not a task force, one person) the place where the IR buck stops.
I also suggest finding a library-internal constituency for an IR, to get over the chicken-or-egg “where’s the content?” hump. ETDs are one sensible choice. For some institutions (including MPOW), Special Collections is the choice. Other libraries may decide to create a library-internal self-archiving mandate; I haven’t seen that happen, but I’d certainly be in favor of it, especially for libraries that can’t find any other internal use for the thing.
What skills does a repository rat need? Well, shrinking violets need not apply to be repository rats, because outreach is the rat’s Sisyphean mountain, and as the public face of the IR, a rat needs to have tolerable public-service skills. Enthusiasm (especially of the contagious variety), persistence, and high frustration tolerance are excellent traits in a would-be rat.
Any decent librarian can learn IR metadata needs on the job; they’re honestly not all that complex or difficult for the average IR. Patience comes into play here; editing Other People’s Metadata is deeply unexciting work. For what it’s worth, though, the relevant skills are Dublin Core, perhaps METS and/or MODS, and a basic idea of OAI-PMH and authority control. Copyright issues can also be learned on the job; any would-be rat who knows what SHERPA/ROMEO and the DOAJ are is a keeper, with bonus points for one who knows about one or more of the author copyright retention boilerplates currently available (and there are several).
Most IRs, even the ones outsourcing the tech, will want a rat with some web-design skill. What annoys me most about the current generation of IRs is that their designs usually don’t call them out as something belonging to their institutions—and no, just slapping the institution’s logo on a bog-standard DSpace install is not enough. An IR that sports the library’s or institution’s full color scheme and layout sparks an immediate sense of ownership in anybody from the institution who visits. A design that doesn’t suggest institutional ownership of the IR does suggest that the IR is adrift, somebody’s pet project that will disappear tomorrow as like as not. Do get this right. If you can’t hire a webmonkey as your repository rat, assign your regular webmonkey to refurbish the IR’s look, or pay a contractor to do it.
System administration and programming—it really depends on the library. If there’s nobody else around who can reboot a server when it misbehaves (as DSpace has an annoying habit of doing), try for a repository rat with a little UNIX. Database skills such as SQL are highly useful, especially with metadata work; I’ve saved myself a lot of time and sanity by handling authority control directly in the database instead of fixing mistaken items one at a time. (Danger Will Robinson: don’t do this on your production machine unless you truly know what you’re doing, and keep database backups, okay?)
If you want to do really cool things that the software doesn’t allow out of the box (and frankly, that’s most really cool things) and you don’t have a programmer on staff already, you need a repository rat who can program, preferably in the language your IR software is written in. I think the crying need for this will ease in the next three to five years, but right now, the IR developer community is fragmented and understaffed, and IR software itself is decidedly non-casual-hacker-friendly.
So that’s my spiel about IR staffing. I hope it helps hire a few more good rats; we need ’em.
