> It's not hard to argue that plenty of innovation and contribution has > been stillborn -- a quick look at the patch queue is enough for that. > It's tempting and easy to lay the blame solely at the doorstop of the > technology, however there are many other issues:
(snipping excellent list) I think there's an additional issue that may prove even more difficult to address: the problem of a technical infrastructure widely adopted by non-technical people. I haven't taken a look at the wiki to be sure, but my gestalt sense is that a substantial majority of DSpace instances live in academic libraries and academic-library consortia. As the general run of academic librarians goes, *I am highly technical*. (Tim Donohue is an outright anomaly.) For those who don't know me: I'm a self-taught Python coder, and I've learned just enough Java to muck around a bit at the upper levels of DSpace. I can do a little SQL, though a lot of trial and error is involved and I know nothing of query optimization. I can do a little XSLT, though some of the XPaths in Manakin frankly break my brain. I'm fine with XHTML and CSS, though I'm not up on all the latest CSS hacks. I haven't ever done any serious web programming. I'm good with XML. I'm aware of usability issues and practices, though I don't have any talent for coming up with fixes, and I'm well-grounded in web accessibility. And every single DSpace committer right now is laughing fit to kill, because the above skill list is *pathetic*. As I said, though, I'm atypical *on the technical high end* of librarianship. I don't think DSpace has ever come to terms with what that means. It's not end-user cluelessness that's the problem, as it is with many open-source packages. It's cluelessness *in the managers of the software*, which is a different and rather nastier problem. To tell a story on myself, I told Robert Tansley at OR '07 that I was a beginning-level Java coder and asked what I might contribute to DSpace within the limits of my abilities. He suggested I look at revamping the Browse system, perhaps to piggyback on a Lucene index. I did. Believe me, I shouldn't be *touching* that. I hardly know where to begin, and if I *did* begin, I don't have a solid enough grounding (or, indeed, *any* grounding) in code optimization or testing to know whether what I'd come up with would solve the lingering performance problems. The implications of this disconnect between the developer community and DSpace managers include: - DSpace isn't just difficult to customize for librarians, it is frequently *impossible* to customize, because the box isn't controlled by us but by IT. (Another story: when I interviewed for the position I currently hold, I was told that I could not expect to have server access to DSpace, much less permission to customize it, because to give me those privileges might endanger the library's excellent relationship with the IT group running the DSpace box. This turned out not to be true, for which I am duly grateful, but it goes to show.) Mods and plugins that aren't neatly packaged are just plain non-starters with us. I disagree slightly with Robert that mod adoption is a chicken-and-egg problem, and with Don Gourley that the current API is sufficient for the level of innovation we hope for; I believe that a stable, documented, vetted API and a blessed plugin directory will make a considerable difference in innovation uptake. (Librarians like authoritative sources -- and it's a lot easier for us to approach IT with a "plugin" than with a miscellaneous chunk of Somebody Else's Code.) - Since discussion of DSpace development is (understandably!) heavily tilted toward developers and people with developer-level skills, the developer community has very little access to and therefore comprehension of rubber-meets-road requirements and procedures in real-world library contexts. Surveys are all very well, but are they even reaching the librarians who form the public face of the software (rather than the sysadmins who support it)? I doubt it. I really do. Ethnographic, qualitative study and usability testing with librarians as subjects are likely to be more productive approaches, but they have not been tried. - Librarians tend to have a passive and narrowminded attitude toward our software. (I'll spare everyone the rant about integrated library system vendors fostering this passivity.) What is, is, and there's nothing we can do about it. This means, first, that we just don't think in terms of "this wart can and should be fixed" -- we think instead about workarounds, or we beat our workflows into the ground to match the software. It can be insanely frustrating to elicit requirements and useful feedback from us! Second, it means we don't come forward with suggestions, or even think creatively about how to improve the software; it's not in our culture. - It has historically been extremely difficult for an individual at my level of technical savvy or below to be heard by DSpace developers. The problem is cultural. On the one hand, non-technical librarians do not know how to approach an open-source community. On the other hand, open-source developers are notorious for disdain of non-technical input and the people who provide it, and DSpace has unfortunately not departed from that pattern. Me, I've been aggressive and persistent about engaging anyway, at high cost to myself in anxiety and frustration. I have personally talked to several DSpace managers with useful usability and workflow insights, however, who have turned on their heels and walked silently away from the community after an initial rebuff. I welcome discussion of possible technical and non-technical fixes for the above problems. Myself, I suggest the following technical goals: - Removal of interface customizations from dspace.cfg in favor of a web-based customization interface accessible to repository managers who do not have admin access to the DSpace box. (Even something as bare-bones as Firefox's about:config would be a major step forward.) - Web-based administrative interfaces to input-forms.xml, Configurable Submission, and similar, along the same lines as the metadata and bitstream-format registries. (I'm still working on how to get human-friendly bitstream format descriptions back into Manakin. Anybody solved that problem yet? MIME types are horrible.) And the following non-technical goals: - A serious qualitative investigation into real-world DSpace workflows and where they fall down. I will gladly serve as subject; goodness knows I have a *lot* of frustration built up, and I'm not as bad at articulating it intelligibly as many librarians are. Alternately, a survey of sysadmins to find out where people are having to add or change code might be productive. - Support for the work Tim Donohue, Scott Phillips, and I have done toward training librarians on DSpace customization. Tim and I have both noticed that the DSpace customization materials we wrote up are among the most popular downloads in our respective repositories. *There is a significant need here,* and random pre-conference tutorials aren't meeting it. Online courses might be a real help, especially given DSpace's international reach, and I would be more than willing to develop and teach them if the appropriate infrastructure could be found. (I think the community might find that this lessens repetitive questions on the dspace-tech list, too.) - Mentoring for prospective developers and committers. As pathetic as my skills are, it's not completely *impossible* that I might become a DSpace committer (especially as I *do* sling XSLT a bit better than Java). To accomplish that, though, I would need to be paired with an experienced developer who can help me formulate problems properly, approach them intelligently, and haul myself out when I get stuck. This is a tall order, I'm afraid; we don't have enough developer talent in the DSpace community as it is, so it's hard to justify wasting some of it on tyros like me. Still -- where's the talent pool, if it *doesn't* include people like me? - Open acknowledgement that past development practices and politics have alienated potential developer talent, and a plan to make amends and recruit committers from that alienated group. Ou sont les NSpace developers d'antan? (I know where one of them is!) - A communication and contribution path for non-technical DSpace managers. For the sake of everyone's sanity, it should probably be wholly separate from the developer community, though someone should have the job of summarizing useful suggestions to one of the developer lists (and again, I would happily volunteer). Dspace-general is not a good venue, because too many DSpace managers have abandoned it, or consider it an announcement list only. Dorothea -- Dorothea Salo [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
