[Dspace-general] [Dspace-tech] Development goals

[Lynch, Michael]

As a moderately technical academic librarian, I wanted to chime in and
thank Dorothea for this excellent message.  (I used to be highly
technical, but almost no-one uses VMS anymore and I'm getting too old to
learn all this new stuff!)

My institution is participating in a pilot, hosted, consortial
implementation of DSpace (http://dspace.nitle.org) which certainly
complicates things quite a bit, but I can vouch for Dorothea's general
assessment of the view of DSpace from academic libraryland, for whatever
that is worth in the eyes of the technical developers.

-Mike Lynch 		lynch at middlebury.edu
 Systems Librarian
 Middlebury College
 Middlebury, VT


-----Original Message-----
From: dspace-general-bounces at mit.edu
[mailto:dspace-general-bounces at mit.edu] On Behalf Of Dorothea Salo
Sent: Monday, November 19, 2007 1:36 PM
To: dspace-tech
Cc: dspace
Subject: Re: [Dspace-general] [Dspace-tech] Development goals

(snipped excellent discussion)

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. [...]
Mods and plugins that aren't neatly packaged are just plain
non-starters with us. [...] 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.)

[...]

- Librarians tend to have a passive and narrowminded attitude toward
our software. [...] 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.

[...]

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                dsalo at library.wisc.edu
Digital Repository Librarian      AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general