Demeanor and community

DSpace’s market position in the IR software industry is “the out-of-the-box, one-size-fits-all solution.” It doesn’t demand the up-front coding investment that Fedora does, nor is it as narrow-focused as regards ingested material as EPrints. Since DSpace is open-source software, it attracts those who cannot afford hosted IR solutions; such adopters, owing to poverty, are not likely to be overblessed with technical staff.

This has consequences for the composition of the DSpace user community. I’d bet my entire net worth and a bit over that DSpace adopters contain many, many more non-techies and accidental techies than Fedora adopters. (I consider myself among the “accidental techies” group, incidentally. I’m not trained for DSpace sysadminning or code-monkeying and I’m far from expert at either, but I do them anyway.) I suspect, in fact, that these are the great silent majority of the DSpace community—emphasis on the “silent.”

I have some fairly direct evidence to bolster this notion. I got a considerable number of back-pats at OR ’07 over the DSpace customization guide that Tim Donohue and I wrote for JCDL ’06. A considerable number. Toss in that Tim must have gotten a lot too, that the self-selected OR ’07 crowd is in all probability more technical than the general run of DSpace administrators, and that the guide we wrote is actually pretty basic, and… look, you tell me how technical the DSpace adopter pool is.

Over at Five Weeks, we have several participants who worry over their perceived lack of technical savvy. We’re doing our best to reassure them, in part because honestly, too many librarians feeling uneasy and defensive about this look for any reason to back away from the keyboard. Confirming their perceptions about their own skills only leaves them less likely to learn, while superciliously casting aspersions on their abilities sends them fleeing headlong away. Reassure them, and be rewarded with wider adoption than you’d have thought possible—Five Weeks’s forty participants are blogging and wiki-ing great guns over there, and the course hasn’t even started yet!

Do I think this lesson extends to the DSpace community? I surely do. Do I think the core of the DSpace community—coders, mailing-list participants, documenters, et cetera—is generally friendly to the community’s less-technical members? I surely do not.

When I started at MPOW, I did as many newbie DSpace administrators do: I ran into roadblocks, problems the FAQs and mailing-list archives didn’t solve. (Heck, I still run into roadblocks. Ask me why the repository I run doesn’t have RSS feeds running. I can’t answer you, because I have tried everything I can think of and I don’t know why they still refuse to work, but feel free to ask.) More often than not, asking the dspace-tech mailing list produced no reply. Not “no helpful replies,” not “no useful replies,” but no replies whatsoever.

Frankly, I didn’t think much of the DSpace community after that, not for quite a while. Things have changed for the better in the year and a half I’ve been doing this, but I still see problems going unanswered (not just unresolved, unanswered), and I wonder how many current newbies have the same bad taste in their mouths that I had back in the day.

I also see a disturbing tendency toward non-techie-bashing by DSpace techies. I offer examples not to shine a spotlight on individual people, because I admit I’ve had my share of eye-rolling “what a maroon!” moments on reading the mailing lists, but only to establish that this is a genuine phenomenon. For that reason, I’m not attributing examples in this post; the links will have to do.

This weblog post regarding the University of Calgary’s search for an ETD solution, for example, contains the bald order “DSpace is an Open Source product, where words like ‘cannot’ should not be used unless you really have looked into it. The underlying search engine can do all of the things required for Calgary, and all it requires is the alteration of the UI to support it”.

Hey, where did “out of the box solution” go? Like it or not, ETDs are a major IR use case. If DSpace doesn’t support them out of the box, that is not the problem of DSpace administrators, it is DSpace’s problem. Getting huffy at managers who may not be able or even allowed to mess around under the hood solves nothing. It certainly doesn’t fix DSpace to work right with ETDs.

(Think “allowed” is not a real problem? Think again. I won’t be DSpace-sysadmin-in-chief at MnewPOW, which suits me fine because Tomcat gives me ulcers. At the interview, though, I received several strong hints that my coding chops, such as they are, would not only not be required, but would be actively discouraged by the actual sysadmins. Fortunately, this seems not to be entirely the case, but you’d better believe I will be walking on eggshells at MnewPOW until I sort out what I can and can’t do.)

Now consider this reply to a list of feature requests. The content of the reply is great, thought-provoking stuff. The manner of expression of the reply is unnecessarily scornful, completely failing to address the actual content of the original post in its zeal to scold the poster. Also consider that as of this writing, that reply has been the only reply.

Look, it takes considerable courage for a non-programmer to post feature requests to the mailing list or Bugzilla page for an open-source software project. I’ve been around the block some; I know how OSS programmers generally react to that. Most DSpace admins, techie or not, probably have the same awareness, so if someone speaks up, trust me, it’s about something important. Dumping on someone for politely opening a conversation about features is a sure road to never hearing from him or her again—and never hearing at all from dozens of DSpace adopters just like that one. That in turn is a recipe for DSpace to set poor development priorities.

So consider this my public call to the core of the DSpace community to watch its communication style and demeanor. We weaken the DSpace project when we turn people off. We weaken the DSpace project when we fail to offer help. Given its market position, we weaken the DSpace project when we make unwarranted assumptions about DSpace admins’ technical capacity. Let’s not, okay?