Caveat Lector

Ursula K. LeGuin’s magic system in her Earthsea novels is predicated on names and naming. If you know the so-called “true name” of a thing, you can use your power on it, you know something about it that lets your power work on it. (The name without the power is useless, as demonstrated by Ged after his struggle with death, and Tehanu before she comes into her power.)

At one juncture, in the context of bodies of water, LeGuin points out that names are relative; we all have many, and part of what names do is draw borders around us. But whose borders? We are named individually and as classes of people and things; also, we are named because of the use we are to a mage, or a dragon. (Does an individual rabbit have a name? To a mage, they are all kebbo: a mass plural, or at best an adjective, masquerading as a singular noun. Does dragonspeech even have plurals?) Our names rub up against the names of groups we belong in, and the perspective of the mages who give and teach and remember names.

Naming is power. Using names is power. Remember that.

I’ve been called a lot of things in my life—only a few of them, before you ask, profane. Aside from my own given name’s usage, what I’m called is fundamentally not under my control. Even with my own name I don’t always win; if you look in the ASIST conference-schedule index, you’ll see that I’m listed as “Dorothea (Dorothy) Salo” because of a panel-moderator error, even though my name is not and has never been Dorothy. (Nor is it “Dorthea,” or “Doretha,” or any of the other various manglings. “Dorothea.” Please. If you don’t have eight letters in it, you’re spelling it wrong.)

Oh, I try to guide. I very deliberately pick phrases like “conversion peasant” and “repository rat,” because my stance toward the world is generally one of captatio benevolentiae. But there’s only so much I can do. Not very much at all, really.

Often I am surprised by what I’m called, nominally or adjectivally. I still remember the shock of “wait, what?” when a high-school acquaintance called me “sophisticated.” It was just miles, miles away from anything I would ever have thought of myself. Or when an OEBPS working-group colleague told me in all seriousness that I was a software engineer specializing in workflows. Oh, hell no. I just make stuff work, when I can. Software engineers are people with fancy degrees and advanced skills in math and logic and programming who get paid a lot of money because they’re valuable.

Last night a professional colleague called me a “social epistemographer.” Well, that’s a new one—I had to look it up just to think about it! It doesn’t feel like a name I can comfortably inhabit. Like software engineers, social epistemographers have a context, and that context isn’t the one I live in. I may do social epistemography. I may even do software engineering now and then (though I have significant reservations about that one). That doesn’t entitle me to the name. Naming is power, but it isn’t infinite power.

The names I get aren’t always benign. The mean stuff tends to be just as askew from the truth as the nice stuff. I’ve seen my anger and confusion about graduate school and academia called bitterness. Resentful, okay, yes, but bitter? I’ve been called crazy, and not in nice ways. I have been crazy, but I’m mostly not. “Intimidating” is one I hear with more frequency than I’d like. CavLec is substantially to blame there, as I’m quite a bit meaner here than in more social contexts; the rest of it is physical presence, which there’s little I can do about at this late date.

Another colleague pointed out to me this morning that one reason for the first-initials-last-name practice that drives me (as a librarian who would like a little more authority control in her life) crazy: female scientists can avoid having their work automatically dismissed by male scientists when they go by initials rather than name.

Ouch. Cage match, librarian self and feminist self, tickets on sale outside. This is a real problem—just ask female orchestral instrumentalists—and for an individual female scientist, using initials helps solve the problem. It’s a “go along to get along” strategy, though, and any such strategy has an unfortunate externality: it divides and defeats the universe of female scientists, because it lets the men go blithely on ignoring and undervaluing those they can quickly identify as female by their names.

When I replied to my colleague that using full names may destabilize the implicit sexism of the current system, she answered, in toto, “Some women just want to do science, not be martyrs.”

I get that. I do. I just wanna be a geek, some days; I don’t want to be a martyr either. I don’t have the privilege of martyrless geekdom, and my name shows why. Not because anything particularly pernicious is attached to my name insofar as it identifies me—but a lot of pernicious stuff is attached to it, stuff that I can’t do anything about, insofar as it identifies that I belong to the class of women. Context, again. My name, in some contexts, is harmful to me; it gives powerful others a way and a social license to hurt, exclude, and demean me.

It’s frustrating. I loathe that particular externality. Not only does it mean I both am and look more isolated than need be, it’s at the root of some of the rhetorical tricks I hate like poison, the “I don’t see sexism!” trick, also known as “I’m doing fine; what’s your problem?” Not to mention the “If you’d just stop kicking up a fuss, we’d all be fine, including you” trick.

I’m fond of my name, for all its polysyllabicity and the spelling difficulty it causes others. I guess when it comes down to it, I’m willing to live with a little martyrdom to keep my name. I shouldn’t have to choose, though—and neither should anybody else.

As batch projects accumulate, I have slowly been building up little bits of Python hackery that make the path to a batch import a little smoother. I have a Name class for parsing author names (and I can see a Namelist class on the horizon, because I do more damn HTML screenscraping than any six people should), I have a DC class for writing DSpace’s goofy little dublin_core.xml file without me having to think about it (and I can see a Contents class on the horizon—that one’s pretty easy, but I shouldn’t be rewriting the code all the time as I do now), and I’ve got a fair amount of actual code from previous import projects to analyze.

And it gives me to think more broadly about the repository’s getting-started and ingest processes and how they may be getting in my way. Call it my techie bias speaking if you will, but when Stevan Harnad quite rightly says “the only thing that has been standing between us and 100% OA for years now is keystrokes,” my response does not accord with his “an administrative keystroke mandate is all that is needed.”

My response is “Fewer keystrokes!”

It isn’t just keystrokes, though. It’s the notion of cognitive load, and it’s a simple notion: the more we make people think about putting stuff in the repository, the less of it they’ll actually do, because don’t we all have too much to think about?

I already reduced some of the cognitive load involved in getting set up to use the repository by shortening and clarifying the forms involved. Now I’m thinking to myself, “… forms?” I should find a way to get rid of them. It would help if I could bless other people to create DSpace communities and collections, or at least to access the web form involved and have me bless the creation later—that way they could actually do something instead of filling out a form to have me do it.

But, honestly, even that is too much. A faculty member interested in depositing content is interested in depositing content, not in navigating stupid DSpace hierarchies. So to hell with the hierarchies, to hell with forms, to hell with communities and collections. I want a bucket collection that any person signing up with an appropriate email address automatically gets deposit rights to. I’ll deal with the oversight, moving, and mapping myself, as need be. I’m the librarian; organization is my job. When they’re ready to move beyond the bucket and have a space of their own, damn straight they’ll let me know, and I’ll be happy to oblige.

What scares me about the above possibility (and it is technically feasible to do this, with the repository I run at least) is the vast undergraduate horde… but Shibboleth may be coming soon to a repository near me, so that would presumably solve the problem. Faculty, academic staff, or grad student? You’re in. Undergrad, check with the librarian first.

Also, this licensing thing, argh. It’s ridiculous to do this on a per-item basis. The relationship between faculty and repository is an ongoing one. It shouldn’t be formalized per-item. It should be formalized via something more like a memorandum of understanding, or—hey! Websites have those! They’re called Terms of Service agreements! So I want me one of them, and the legalese to back it up, and the tech to make new registrants click through it once when they sign up, record that they have done so, and never bother them with licensing again. Just as legal, and less cognitive load on every single deposit. Win!

(Creative Commons licensing does have to be done per-item, and I don’t have a problem with that. But the contract between the depositor and the IR doesn’t change—or shouldn’t—per item, so let’s just deal with it once, okay?)

The other big cognitive-load problem is, in a word, backfiles. Everybody but the newest, greenest faculty has a publication history. Nearly everybody who has come to me with a collection idea has some kind of backfile to deal with. Nobody wants to face the hassle of doing all that themselves, and quite right, too. Hassle is my job.

So I need another bucket, probably outside the repository altogether (because the thought of hacking DSpace to do this gives me heartburn), where they can just dump the backfiles and let me deal with them, with my little library of Python hacks and a lot of patience. Additionally, I need some kind of workflow that involves the least metadata-typing possible on my part. (Bum wrists, don’t you know.) Once I’m through with a project I’m doing now that involves an EndNote RIS export (and that I’m very happy about because it’s essentially simple, unlike HTML screenscraping!), I believe I am going to investigate what Zotero can do for me. I think it’s within my capacity to write an export filter for it that dumps stuff out in dublin_core.xml, and once that’s done its metadata-sucking capability should save me a lot of typing and get me better metadata than the usual run. Win!

And Zotero is something that I could teach other people to use. Since I’ve got 26 campuses to worry about, that’s a major desideratum.

So. Anybody in the LazyWeb, especially DSpace hackers, interested in helping me with any of this? I’ll be bringing up the policy and legal parts at my next DSpace meeting.

I’d dearly love to know just what the heck I was on when I wrote the code following. It must have been potent stuff.

			if file[0] == “.”: continue #no .DS_Store
			elif file[0] == “.”: continue #no .DS_Store

So since I haven’t mentioned it yet, I’ll mention that I’m part of this NISO/PALINET day workshop on institutional repositories. (In my humble repo-rattish opinion, it’s a bit misnamed. I don’t know any rats who care nearly as much about getting something out of IRs as getting stuff into them! Anyway.)

My slides are due the 21st, so I have been getting my rear in gear to work on them today. And in so doing, I discovered a Keynote trick I probably should have discovered long ago but didn’t.

Sometimes it’s nice to replace one thing on a slide with another thing. You can do that by duplicating the slide except for the one thing that changes, but that’s sort of obnoxious. Keynote has a better way.

Put both things on the slide; it’s completely okay if they overlap. Then hit the Inspector button, and go to the Build tab (which is the yellow diamond with the speed-marks to the right). Pick the thing you want to go away, then do a Build Out with it. Pick the thing you want to replace it with, do a Build In with it, then make sure that the build-in starts either on click or after (but not with) the build-out. Sounds complicated, but do it once or twice and you’ll get the idea.

I’ve now got a slide of blue-sky myths about IRs, each one of which is blasted to smithereens and replaced by a reality check. I had much too much fun putting it together, which probably says things about my sanity that are best not examined too closely.

I’ve gotten a couple of interesting responses to my note on fixing repository ingest processes, which I will pass on without attribution (though I’d rather credit, and I hope people will email again to let me).

One university’s repository manager Sarah Shreeves of UIUC reported to me that they are thinking along very similar lines, which is both pleasant validation and hope for the future.

Another DSpace repository manager let me know that he had implemented a system very similar to my second bucket. Faculty are presented with a web form consisting of an upload button and a place to paste a citation. At this point, control goes to the librarian, who evaluates the submission for appropriateness, fixes the metadata, and sends everything to the DSpace batch importer. The developer of this system looked at incorporating some kind of citation parser to further automate metadata creation, but (as I can attest!) writing one of those to handle a wide variety of citation styles is work.

(Like MARC, citation styles are an example of analog habits not friendly to digital environments’ needs. Somebody emailed me about APA style, which insists on initials rather than full names. Right. Example of print-culture need for shorter citations in conflict with the digital world’s need for better authority control. I can’t fix that. APA needs to.)

Two things interest me about the system described. One, that DSpace is so brain-dead rigid that the developer had to go outside the system altogether to innovate. I hope with all my heart that I am not the only person who sees this rigidity as a significant threat to repository platforms in general (because how much better are EPrints and Fedora?) and DSpace in particular.

I’ll make it simple: either repository platforms do what repository managers need them to, or they die. There are days I’m ready to spork DSpace to death myself. Nota bene: repository managers, not repository developers. “You can hack it in!” is not an acceptable response to this problem; nor is “you can do it as long as you have administrator access to the server and you change this arcane configuration file buried three layers deep, then run this little script from the bin folder, then restart the system.”

The other thing that interests me, and is somewhat more hopeful, is that I think the above scenario will be very close to implementable in DSpace 1.5, which will integrate Tim Donohue’s Configurable Submission. Cut down the submission forms to one (or one plus licensing if you must), and dump the submission into the workflow process for a librarian to clean up. The big hurdle I envision is that DSpace expects certain pieces of metadata to be in place before it will consider a submission complete enough to put into workflow. I don’t know what (if anything) Configurable Submission does about that… but hacking DSpace to let it accept on-the-cheap submissions seems like a soluble problem.

Another correspondent asked me about searching (for example) ISI Web of Science for author affiliations, pulling down citations, and feeding appropriate content into the repository that way. This is part of what my esteemed colleague Eric Larson is doing with his BibApp project, with collaborators from the University of Illinois at Urbana-Champaign, and I think (with some reservations, to be discussed in a moment) that the BibApp represents one of the few viable futures for institutional-repository content recruitment from the peer-reviewed literature and discipline-based collections of gray literature (such as disciplinary repositories).

Not all is rosy, however. The biggest stumbling block is rights. Just now I happen to have BibApp-collected content from IEEE and APS, because they allow archiving of the final PDF. For publishers who do not allow this, which is most of them, the most the BibApp can do is try to semi-automate the process of nudging faculty to provide preprints and postprints. (In fact, the BibApp isn’t there yet, and my sense is that there would have to be a lot of high-level discussions with department and school administrators before it could reasonably go there. As yet, I don’t think the political will exists at MPOW to do this work.)

The rights issue does not stop at publishers; some disciplinary repositories that would otherwise present tempting harvest targets look to be off-limits. I am particularly concerned about SSRN, which is aggressively expanding into the humanities; Peter Suber briefly mentions some of the problems there. I hope that some of the leading lights of open access will take this on as a policy issue—there isn’t much point in moving from greedy publishers who embargo access to greedy repositories who prohibit data replication (which is, let us all remember, a key element of any responsible preservation strategy).

Another stumbling block, as with many repository initiatives, is the sheer amount of work it takes to build the appropriate searches in the appropriate databases, weed through the resulting citation lists, match them up with PDFs, and get it all ready to import; this is especially a problem in the context of backfiles. (Ongoing work, we have learned in our experimentation with the BibApp, is actually fairly manageable, especially when semi-automated via RSS feeds of particular searches.) Since so many library administrators are stuck in the abundantly-discredited “build it and they will come” mode of thought around institutional repositories, acquiring staff and resources for such a content-recruitment initiative is a Sisyphean struggle.

At MPOW, aside from our BibApp pilot initiatives, the demarcation line is stark and simple: If I can accomplish something by myself, or with the occasional and strictly time-limited assistance of our most excellent repository sysadmin (who wears several other sysadminly and developer hats), it can be done. If I need any kind of help, whether it be dedicated staff time, specialized equipment or software, or financial resources, it can’t. Reread this post with that in mind, and you begin to understand the perennial repository content-recruitment problem. There’s only so much I have the skills, time, and political influence to do!

Moreover, I am not alone in this. The situation at MfPOW was essentially the same, and honestly, many repository managers have even less to work with than I do: they only work on the repository part-time, or they are constrained by IT restrictions, or they don’t have even the basic hacking and web-design skills that I have. Again, active rather than passive content recruitment for institutional repositories is a library-policy issue that leading open-access advocates could make inroads on if they chose to, and I wish they would.

The last phenomenon I want to call everyone’s attention to is the hiddenness of the conversations I am recounting. I didn’t know that someone had put together a bucket implementation around DSpace. I didn’t know that other people shared my thinking about streamlined deposit procedures. My correspondent who spoke of ISI didn’t know about the BibApp. And none of the people who wrote to me know about each other!

This is wrong. This is pernicious. This is pluralistic ignorance at its worst. Repository managers need a community of practice and we need it badly, because as sui generis workers, we do not get appropriate support and knowledge-sharing opportunities, not from the institutions in which we work and not from our professional organizations.

Why is there no such community already? Partly, we are fractured across software lines; since our first needs as repository managers are typically technical needs, we naturally gravitate toward software-specific mailing lists. I know a fair few fellow DSpace managers, because those are the lists I live on. Les Carr and I email each other occasionally; that’s all the contact I have with the EPrints landscape, and I don’t know anybody running a Fedora repository (now that Leslie’s moved on)!

Partly it’s that not all of us are dedicated wholly to this work. I don’t know what fraction of the repository community represents full-timers like me as opposed to those who have repository duties loaded onto an existing full-time workload, but my sense is that most of us are part-timers, and by a long shot. It’s hard to build a community of practice out of part-timers. Many part-timers, in my experience, don’t have sufficient current awareness to know about the conferences, journal issues, and blogs that already exist!

Partly, it’s that our presence in the normal knowledge-sharing environment of librarianship is fractured and scattershot. We don’t have a journal; we only have “special issues” of umpteen different journals. We don’t have conferences we can reliably attend. DASER is dead, as best I can tell. Open Repositories travels all over the world, which is more than I can afford to do. Although ASIST contained a lot of repository-relevant content this year (did anybody else notice that both the dissertation proposal and paper of the year were open-access–related?), it’s a research conference, not a practitioners’ conference.

And partly it’s that we repository managers (with help from the dismissive and the just plain clueless) have internalized the general failure of the “build it and they will come” ideology. We think it’s our fault our repositories languish empty and we haven’t changed the world. So we aren’t looking to ourselves or to each other to move the discussion forward.

We’re looking to the research literature and to our professional organizations, and both of them are letting us down. The research literature is full of useless quantitative investigations that do not tell us what we as repository managers can do to improve matters. Such qualitative investigations as exist interrogate the experience of faculty, not repository managers—again, one way we might talk to each other (if a rather indirect and roundabout way) has been foreclosed on.

Our professional organizations are not helping us talk to each other either. Instead, they’re getting Big Picture Thinkers to talk at us rather than to us, and heaven forbid said Thinkers should listen for five minutes! Frankly, the Big Picture Thinkers (including, I regret to say, the otherwise excellent Cliff “institutional repositories are essential infrastructure” Lynch) are responsible for “build it and they will come” in the first place. They need to sit down, shut up, and let those of us talk who have lived out the consequences of the failure of their Big Picture Thinking. We’re not insisting on that, mind you, because of our internalized sense of failure; we still believe the Big Picture Thinkers can haul us out of the morass, so we listen quietly and hope.

I don’t have a good answer to this problem, not for lack of stabbing in the dark. I helped try to start a journal (though I didn’t help enough, not by a long shot). It didn’t fly (and I own a lot of the blame for that). I tried going the Library 1.0/2.0 route with a listserv and bulletin board. I mercy-slew them a couple of months ago. The chief blog around which a repository-manager community might coalesce—Open Access News—is a link-and-commentary blog that doesn’t allow reader comments. I think NISO/PALINET inviting me to speak at their workshop is a good step, but recollect for a moment that I’ve been doing this for two and a half years and this is the first invitation I’ve gotten to speak directly about what I do—and think about all the insightful, pragmatic, innovative repository managers who aren’t getting invited anywhere because they’re not loud and obnoxious the way I am.

The best we may be able to do at this juncture is to have one of our sadly few conferences try to jumpstart an online community. Open Repositories, are you listening? Because the current sad situation has got to change.

I have extolled xkcd’s feminist sensibilities before. I must say that today’s strip is both far subtler and far more refreshing.

(And funny. I cringed and laughed at once! As usual, don’t miss the tooltip.)

See, what happens (mild spoilers, so click over now if you’re going) is that a woman goes and does something highly technical as well as highly ironic.

And it’s not pointed out as unusual.

And she isn’t portrayed as unusual. Or undesirable. Or pure T&A. Or brainless. Or the butt of the joke. (If anything, the joke is purely linguistic/social, playing on specialized meanings of “write” and on the sillier things that women are “supposed” to commit to paper.)

More like this, please! And once again, a loud shout out to the extreme awesomeness that is xkcd.

The lifeblogging has been a bit slow lately, largely because my life has been (and still is) crowded. But I will say that it’s nice to be back where November feels like November instead of, I don’t know, late April.

Miss Mouser got through her spaying just fine. She was groggy and stumblebummy for a day or two, and then she was her regular chirrupy, house-tearing-through self. For her next trick, she’s going to learn that housemonkey food is not for small gray kittens. She will learn this if it kills us.

The geese on the bay are getting restless, and the cootilla has been back in full force for about a month. I saw the first half-dozen arrivals, which doubled the next day… and the next… and the next, until coots covered quite a bit of available surface area.

There’s a little grebe-gang that hangs out with them, seven or eight strong as best I can tell. I’m not sure what the attraction is for the grebes; coots are clunky, awkward birds while grebes are highly streamlined and elegant divers. Maybe they’re just poking fun. I haven’t seen the kingfisher or the green heron for a while, but that doesn’t mean they aren’t still around.

The muskrats swim slower these days. There’s only so much tail a skrat has, and what with the fall fattening-up, that tail has to move a lot more skrat. Muskrats don’t have any truck with those fly-by-night coots. I’ve seen outraged coots flap-and-paddling across the bay to avoid a muskrat chugging on heavily toward his home in the bank. The rabbits are on extra rations too. I see them whenever I walk home after dark, and dark’s quite early now.

I’ve a lot to accomplish today, talk prep and grading and whatnot, so I’ll let you folks go for now. Suffice to say that I welcome the Wisconsin fall as it shades gradually into winter.

I am the Annoyed Librarian. Come the heck on, people, didn’t you all suspect already? There ain’t nobody in this here biblioblogosphere more annoyed than I am.

Library school? All over it. The stupid job-shortage lies? Oh yeah. Technology uberhype? Annoys me past reason. Pointless ALA shenanigans? I’ve expended more verbiage on that than anybody, and I don’t even belong to ALA.

You knew. ’Fess up. You all knew all along (because hey, writing styles like mine aren’t a dime a dozen, you know?) and you’ve just been humoring me.

Jenica, Michelle, Rochelle, Laura, just give it up. Poseurs. You can’t out-annoyed me. I practically invented annoyance!

I am impressed by the RAND report on digital preservation and scholarly communication. It has been researched and written by smart people who know this field and understand all the angles. I would happily use it in a classroom, and that’s high commendation—a lot of these report things don’t make any sense to someone who doesn’t already have the background. Well done, RAND.

That said, I’m not as enthusiastic about emulation as they are. I reluctantly admit that for some things we’ll have to learn to do it. However, a lot of the perceived need for emulation is caused by a dearth of proper open data standards. Give me those, and “emulation” becomes “manipulate and use the data in the best way possible,” which goes far beyond mere aping of obsolete systems.

I’m currently wading through the scholarly-communication SPEC kit 299 from ARL, and shaking my head at the surveys we’re apparently supposed to be spraying hither and yon. If I tried to have the liaisons at MPOW do the Opportunity Assessment Instrument, I’d be lynched. Or lynched and then fired. Or fired and then lynched; I’m not sure what the protocols are around here.

Whose tail do I have to yank before the reality of “no resources, no help, no buy-in” sinks in? Please, tell me, whose?

To be fair, ARL/SPARC does better than most. (Cough, cough, ALA/ACRL.) Less happytalk, more substantive attempts to help. But even they are a bit distant from reality. I appreciated, though I don’t entirely agree with, the snarktastic interviewee in the SPEC kit talking about how open-access pitches are so violently out-of-touch that they alienate the very faculty we’re trying to win over.

That’s reality. The snark, I mean. If you’re a repo-rat and you’re not even a little snarky by now, you haven’t been around long or you’re just not paying attention.

(I posted a lengthy polemic to the DSpace-Tech mailing list in response to a gentle question about projected DSpace support for electronic theses and dissertations. I think the content is relevant to more than just the DSpace community, so I reproduce it here, with an added link or two.)

With the understanding that I’m not a DSpace committer and not involved in any way with DSpace or the DSpace Foundation except as DSpace user and occasional bug or patch submitter…

My sense is that DSpace development has only vaguely and loosely been guided by real-world use cases not arising from its inner circle of contributing institutions. E.g., repeated emails to the tech and dev lists concerning metadata-only deposits (the use case there generally being institutional-bibliography development), ETD management, true dark archiving, etc. etc. have not been answered by development initiatives, or often by anything but “why would you even want that?” incomprehension or “just hack it in like everybody else!” condescension.

There are hacks for some of these uses, yes… but from a sysadmin’s perspective, hacks endanger smooth upgrade paths, and from the perspective of many librarians, hacks are entirely out of reach because IT rather than the librarian controls the box DSpace lives on.

When innovation has occurred around DSpace, it has generally died on the vine because of the aforementioned threat to smooth upgrade paths. TAPIR and Researcher Pages may serve as the requisite gruesome warnings here; they died not because the ideas underlying them were bad (they emphatically weren’t! if we still had TAPIR, Susan wouldn’t have had to ask the question she just did!), but because almost nobody dared adopt them. I see all kinds of nifty conference presentations involving DSpace mods — but they provide me no practical benefit whatsoever, because the code isn’t out there and I probably couldn’t use it if it were!

DSpace’s lack of a plugin/mod API, coupled with the amazing spaghetti dinner under its hood, has stifled service innovation in the repository space for years, and will continue to do so until the defect is rectified. Neither EPrints nor Fedora is in a much better position just now, but in all honesty, I predict that the first platform to have a half-decent mod API (especially one that welcomes mods written in friendlier languages than Java) will experience an explosion of innovations that will eat the other platforms’ lunch. Manakin assuredly helps, but not quite enough.

SWORD may also help, rather backhandedly, by providing an ingest path that doesn’t rely on the horrendous web UI or the awkward batch ingester. We’ll see; I’m hopeful. I’d far rather build an ETD app that used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs myself, much less try to push the committer group to do so.

It may be worth noting at this point that I put my votes where my mouth is; when the DSpace development survey came out, I put a mod API at the very top of my desiderata. I encourage other repository managers with unmet needs to speak up for this! It’s vastly more important for the long-term health of DSpace and the services we are building around it than are (for example) controlled vocabularies.