Caveat Lector

Oh my gosh, this is just brilliant. I have no words for how brilliant this is. Take an externality and make it internal. Make it hurt. Pure beauty.

Now if we could just get everyone everywhere to do it…

I started thinking to myself yesterday that it was just about time to do the yearly update on the ol’ master CV, before my sievelike brain lets everything leak out into a foul-smelling goo all over the floor…

… and then I got to thinking that it’s actually been quite a year, professional-achievement-wise-speaking. I didn’t think at first that it had, because changing jobs and locales tends to muck with the flow of things rather, but things just kept popping to mind:

• Five Weeks to a Social Library
• half a reference book (well, a good bit less than half, really)
• a preconference, two panels, and a poster at ASIST
• an invited talk (curiously, this is the second year in a row one of these has turned up at the end of the year; I shall be interested to see what happens in 2008!)
• an invited article which just as a preprint is generating rather more buzz than I expected
• designing and launching a new graduate course with (I will say) some success—not perfect, but not bad for a first stab
• being in enough demand that I’m starting to turn down opportunities now and then

Can’t put that last on a résumé, but it’s important to me nonetheless; it’s a signal that I have the profound and profoundly welcome privilege of considering opportunities purely on their own merits, rather than on grounds of professional advantage. Résumé-grubbing can be soul-killing. I’m glad I don’t have to.

Lest I be accused of cerebral edema, I just lost out on a repository consulting gig, which was a bummer, not just for the money (which I don’t mind saying I’d have appreciated) but because I genuinely would have been good at it. Nor I’m none too pleased at my apparent non grata status in the DSpace community, but that’s as may be; they don’t have to like me as long as they listen to me, and my voice is loud enough these days that it appears they haven’t much choice. So I’m irked, but basically content.

(I will note, though, that within two days of Roach Motel going up, Les Carr was in my inbox asking about how mediated deposit ought to work. I owe him a blog post on the subject. But it goes to show, one repository-software dev community can take a hit with class, and is genuinely interested in making the damn things work right. Rock on, EPrints.)

I’d be a perfectly happy camper… if I didn’t have the nagging sense that the world is passing institutional repositories by, and me along with them. We’re just not where the action is right now, not in preservation and not in open access. Mind, I’m not worried about open access; it’s doing just dandy these days. I’m not even worried (much) about green open access; disciplinary repositories are popping up like mushrooms and growing like weeds. But I’m not an open-access advocate at MPOW, just a repository-rat—and it’s a damn big ship I’m on, and I’m one very small rat.

This… perturbs me. I see endless opportunity in the preservation sphere, none of which I can actually do anything about, because the platform I’m stuck with won’t do for a lot of it, and I don’t have (and am not smart enough to build) appropriate ingest facilities for the rest. Plus all the analog stuff out there that I can’t do anything about. It’s frustrating, is what. Lots to do, only I’m stuck in the mud and can’t do any of it.

I mean, take the new Zotero gizmo that is causing angst, to me as well as to Laura. Action? Plenty of it, and well there should be; this is the kind of thing I’m talking about, that digs into where people really do their work. We, we libraries, suck at this, and IT isn’t much better, so why are we surprised that academics are solving their own problems without us?

And yet… I happen to know that CHNM’s digital preservation practice is, er, not so much. I’ve worked with their stuff. Their modus operandi has often been to throw up some PHP and call it an archive, which is great from a getting-stuff-to-preserve standpoint, not so great for those of us who want to take care of it. There’s a role for us in all this. But we’re not taking it, partly because we’re so fixated on these craptastic IR software platforms, partly because (as Laura mentions in her comments) we’re so fixated on the authoritative, the vetted, the final that we’re letting opportunity pass us by.

Ah, well. I’m still working on this being-stuck business. When I have something, I’ll let everybody know. In the meantime… it’s been quite a year.

So the new DSpace Foundation wants people with plain-vanilla DSpace installations to chime in and say how long it took ’em to get set up.

Plain-vanilla? I said. Who the heck stops at plain vanilla? Why is that even a useful benchmark?

Naughty Dorothea, no biscuit. (Note to SourceForge: friendly URLs for mailing-list threads, plzkthx.) “Given your experience, passion and know how it would be great if you could work with us in a positive fashion,” quoth the Foundation’s head honcho.

I don’t even know what to say about this, it’s so goofy. Except to note that I do believe there’s a bit of a gender issue lurking, as I’ve never seen a male participant called out for anything by anyone except when I’ve done it myself—good old unladylike me.

I’m willing to stand on my record vis-a-vis DSpace: even if we leave all my snark and criticism aside as wholly unproductive (which I dearly hope is arguable!), I’ve couple-three patches, two extremely successful customization workshops (and wikifying the handouts to boot), a number of how-to blog posts, and some mailing-list answers to my credit. That’s all I need to say, really.

By kind permission of the editors of Library Trends, I have placed a preprint of “Innkeeper at the Roach Motel” in the institutional repository I run.

Download, read, ponder, scoff, et cetera.

Edited to add: Boy, posting something in public is the first step to finding all the little mechanical things that are wrong with it. My apologies for the unexpanded abbreviations, misplaced punctuation, inconsistent spelling, and all the other stuff that the poor copyeditor will get stuck cleaning up.

This morning’s reading was the admirably honest and straightforward “Taking EPrints to the Next Level” report. In a field drowning in useless happytalk, it’s good to see an effort as important as EPrints stepping back and taking a good hard look at its missteps as well as its (considerable) successes.

(I am also personally chuffed because I came to one or two of their same conclusions completely independently in “Roach Motel.” I always welcome evidence that I am not in fact stupid or useless, when events conspire to paint quite a different picture. Also, I need to bug the Library Trends editors for permission to post a “Roach Motel” preprint, now that I’ve sent the draft in. Somebody kick me about that.)

There’s a lot of talk in the report about marketing, and failures thereof. Seems to me that what happened—and this insight could be extended to the entire institutional-repository premise—wasn’t so much a failure of marketing as a failure of market research, a serious and ongoing failure.

Simply put, just as libraries charged gaily into running repositories without understanding how the entrenched structures and reward systems of academia would hinder them, repository software developers charge gaily into development without understanding how libraries work, or how repositories work inside libraries. (Yes, yes. I know libraries are not the only venue for repository software. You can’t tell me the market research got done for those other venues either. If it had, I wouldn’t have to keep telling random people who call me on the phone that no, sorry, DSpace doesn’t have any paid vendor-support or consulting options.)

So here, free gratis and worth what you paid, are a few hints about libraries and repositories that ought to inform development and support decisions.

First, the usual open-source “scratch own itch” development model doesn’t work as well in libraries. The reason for this is that with a few exceptions, librarians are not programmers and do not think like them. Most librarians aren’t aware they have itches; we’ve been so beaten down by our software vendors that we won’t scratch our own noses without an RFP! And when we do know we itch, we typically outsource the scratching, not least because we’re not taught to program in library school.

I have personally experienced having my own programming skills wildly overestimated by a DSpace committer. And I’m more technical than most in my field! By a long shot! So repository software developers cannot count on a ready-made bunch of talented, trained itch-scratching developers. Folks, I’m as close as it gets, and I’m not half good enough for your needs. How you fix that I don’t know, but you won’t fix it if you don’t first acknowledge it.

Second, the community-based development models that are so fashionable just at present in the repository community are equally if not more precarious. This just isn’t how libraries are accustomed to acquiring their software and having their needs met! The EPrints report goes into the results of this disconnect in considerable sheepish detail, so I don’t need to; I will merely remark that I’m not bullish on Fedora Commons or the DSpace Foundation.

What are libraries accustomed to? RFPs. Vendors. Hosted services. Black boxes. Fee-for-service, not fee-for-input. Passive, reactive technology management involving minimal technical staff. Saying “no” to anything, from chat-reference services to blogs and wikis to open-source repository software and its associated pay-to-play community structures, that doesn’t fit into those categories. We libraries don’t get involved with standards development except in our own community (and that only rarely); we don’t even have that model to look at!

When communal software development happens in libraries, as it occasionally does, it’s worth noting that the genesis appears to be handshake agreements among individual libraries (or even librarians) who know and trust each other. That’s a very different model from “Hi. I’m the Community Federation and I’m here to help you (if you give me lots of money)!”

So talk about community-based development models is just so much “blah blah blah how much is this going to cost me and why should I pay it at all?” to a library administrator (who, I reiterate, typically knows as much about software development as my cat knows about Christmas). These federations and commonses and foundations and stuff had better get to work on some kind of fee-for-service funding model, because they’re fish in a barrel if they don’t.

Third, this is not a good time to be asking libraries for resources for repositories. Institutional repositories are in enough trouble as it is. MacKenzie Smith asked me rather peevishly on the DSpace tech list why I couldn’t just go get a developer assigned to the repository for a year. Trust me: if I could, I would. For reasons it would be unbelievably inappropriate of me to discuss onblog or on-list, that’s about as likely as the foot-plus of snow on the ground in Madison melting to bare earth by tomorrow.

I’m not alone in this. “Repositories operate on limited budgets, if they have specific budgets at all,” says the EPrints report (page 10). This squares with my experience—and if open-access advocates want to know why this is, they need only examine screeds from some of our more vocal advocates proclaiming that repositories are cheap and easy and fill themselves like magic. That (false) ideology is now coming back to bite would-be repository communities hard.

Fourth, a good many library technologists hide themselves—from their administrations, from their fellows, from the world—because the risk is too great of being shut down abruptly if one is discovered doing this sort of work. I wish I were making this up, but I’m not; I’ve started and supported a couple-three skunkworks projects myself, because there just wasn’t an open way to get the work done. This reticence means first, that the oft-touted egoboo benefits of open-source development do not typically motivate work in the library context; second, that developers in libraries have a tremendous incentive not to share work with other libraries or developers.

Fifth, most libraries don’t have any library technologists. Any. At all. This means that if you put functionality in a server config file, or require a server restart to change it, most libraries won’t be able to tinker with it. At all. “Out of the box” means very different things to developers and librarians; I’ve yet to meet a developer who understands that it means “I don’t have to mess with it, ever, because even if I wanted to I couldn’t” to librarians.

What all this means for open-source software such as DSpace, EPrints, and Fedora is that many itches do not get scratched, and those that do are only scratched locally, these local enhancements never fed back into the software. It certainly doesn’t help the situation that the average open-source developer regards user questions as an annoyance, rather than free requirements-gathering for the next dev iteration. I was roundly mocked for saying something along these lines on the DSpace technical list, but eppur si muove.

Take DSpace. (Please.) To my certain knowledge there are at least four DSpace hacks to create embargoing out there. One (the Minho hack, and for future reference, Yankee devs: that’s pronounced MEE-nyoh or MEE-nyoo, depending on whether you prefer to sound Portuguese or Brazilian) is available publicly in some kind of documented fashion. All were developed wholly independently of each other. None is on track to be put back into DSpace. And those are just the ones I know about; I’d be shocked if there weren’t several I haven’t heard of. There is clearly an itch here. DSpace refuses to scratch it—so we get a lot of useless flailing about, and multiply-redundant efforts that could unquestionably be better-employed. We don’t have so much development talent that we can waste it solving the same damn problems over and over again!

So. What do we do about this knot of snakes?

The strategic-minded development community will do whatever it can to protect skunkworks library developers. I find that a carrot-stick approach consisting of public accolades and the delicate threat of public embarrassment for library administrators is the best shield: sending kind letters of thanks and support on official Foundation letterhead to every single code contributor with a separate copy to his or her boss, coupled with public acknowledgement of all contributors on a website, is a cheap, easy aid. (Any library administrator who reams out the dev over this, or forbids him/her to continue developing, is risking opprobrium in the wider community, and believe me, they’ll get that right away and won’t do it. A project near and dear to my heart at MPOW has been protected from summary execution in more or less this fashion.)

The next avenue of attack is through library vendors, paid developers, and the campus IT units who do most local hacking (since librarians, as I may have mentioned before, are mostly not coders). The strategic-minded development community courts these people like royalty, and does everything possible to ensure that their code gets thrown over the wall instead of hoarded locally. All three open-source repository packages have severe problems with this, for somewhat differing reasons—although none of the three, it is worth noting, has good procedures in place for vetting and adopting third-party code. In DSpace’s case, the biggest problem has historically been MIT’s Not Invented Here-ism, which notably caused certain of them to brush off (in a fairly nasty manner, I might add) the developers of NSpace (PDF), which was a visionary proposal that the current DSpace developer group is only now starting to catch up to nearly three years later.

And where are BioMed Central’s Open Repository developers? I bet you they’ve got some damn interesting code.

Sure, a lot of the code that gets thrown over the wall will be the kind of crap that I produce. Here I invoke Open Source 101: even crap code is better than no code, because crap code can be improved, and it’s a significant hint where the scratch-needing itches are.

(I mean, DSpace knows what it needs, if it cares to look. All anybody has to do is go through the tech list archives. ETDs. File-less submissions. Embargoes. Real dark archiving, not the half-assed kind where your metadata is flapping in the breeze via OAI-PMH. Language-switching interfaces. Statistics that don’t suck. Deposit interfaces and workflows that don’t suck. None of this is news!)

Campus IT is a bit of a harder nut, because they don’t necessarily feel any solidarity with the software package in the way that the librarians do. But developers speak developers’ language. Contact can be made, and should be.

So here endeth Libraries for Developers 101. There’s more to the story, but just what I’ve said here could in my opinion make a substantial difference to the viability of open-source software in libraries if taken seriously.

Only in Wisconsin is the thumping bass coming from a car at the stoplight the underlying oom-pah beat to a polka.

I am extraordinarily fond of Terry Pratchett’s Monstrous Regiment. It is, in fact, one of my favorite books.

I’d love to see it made into a movie. It’d be a cracking good ’un, except…

… I just cannot imagine who on earth could play Sergeant Jackrum.

The Frozen North, she has been welcoming me back with an extra-special display of frozenity. If barely making it out of town after an ice storm wasn’t enough, it snowed again the day I got home, and then again again while I was walking home from class. In between was the coldest morning I remember in quite a while.

Though I dressed for it, so well that I’m still not sure the weatherfolks weren’t exaggerating, because the walk to work didn’t feel bad at all. The home-from-class snow was fairly gentle, and it wasn’t hardly cold out at all, and I enjoyed the little diamond pinprick lights of fresh snow, and the snow-fog over the bay.

The ice fishers are out already. Those people? Are crazy. For my part, though, I still have a sneaking fondness for winter, though I know that fondness will have snuck entirely away by late February.

This morning I wandered into the kitchen and saw a right forest of icicles from our kitchen windows. (This does not surprise me, in a rental house. I love this house, but it needs better care than it’s getting.) I went for the camera to capture the pretty, and Mouser promptly went for my leg to climb high enough to capture the lens cap dangling from its string.

This hurt. Quite a lot.

But I still like winter.

The sad thing is, I’ve never installed a Firefox plugin for web developers before. Yes, I know, I know. I’m kicking myself, believe you me.

I installed Firebug the other day, because my Firefox profile managed to hose itself (grrrr) and I had to reinstall a bunch of plugins anyhow, so why not pick up a few new ones?

This morning, I had one of those horrible moments when you click on a perfectly innocent link in your new design and the resulting page is oh-noes b0rked.

Firebug found the problem within thirty seconds of my figuring out how to use it (which itself took less than five minutes). Isolating it on my own would have taken me hours of cussing and fiddling.

My slides for the NISO/PALINET talk are now up, here and in PDF at NISO’s own site.

Enjoy. Be warned. Or something like that.