[Dspace-general] Week 3: Good Repository Software

[wally grotophorst]

I cheated too...and Dorothea's right.

DSpace, for all the many things it does well, really isn't yet a great 
end-to-end solution if you're actually running a digital repository.   
Stretch the system to store digital objects other than open-access 
offprints and it begins to feel unnecessarily cramped.
 
I first got a copy of DSpace up and running in 2003.  At the time I 
thought it was a lot more trouble than it should have been but 
understood that I didn't know all that much about Tomcat, JSPs or 
Postgres.  Here in 2008, I still don't know a lot about Java and JSPs 
but I now realize that not all that many other people around the library 
world do either.   When I see how little actual "work" DSpace does (I 
mean, we're not talking about a transaction-based, real-time processing 
sort of system), why such a complex codebase?  Sure, a certain amount of 
over-engineering seems to accompany software projects that begin life in 
the library but on some level it does seem to end up strangling 
innovation...

I suspect that if the original development team had decided to code the 
thing in PHP with a MySQL database, we'd be much further along in terms 
of user-contributed code enhancement (think WordPress).     Of course, 
if like my toaster it did everything I asked, I wouldn't much care what 
the code looked like or why/how it worked.  So complaining about the 
platform's code is my way of saying there are things that I'd like to 
fix if I could.   Absent a rewrite of the code, I think these specific 
things would help:

-- a way to address an individual bitstream--one that used the handle to 
resolve the hostname.   I'd really like to be able to use other systems 
for display and have DSpace focus on maintaining the bitstreams.

-- a quicker way to add content.  The simple "upload your stuff' way 
that Flickr takes in a digital image and offers a few fields for 
user-supplied metadata could be a big help in getting 
faculty/researchers to add content.   This content could go into some 
sort of "holding area" for review and post-upload editing, of course. 
The design goal would be to help end users bypass the current 
click-happy series of add-an-item pages.

-- in the absence of deleting content, some way to handle versioning of 
documents

-- a way to "hide" content (and associated metadata) on both the item 
level and the collection level.


Wally

Wally Grotophorst
Associate University Librarian
Digital Programs and Systems
University Libraries
George Mason University
Fairfax, Virginia 22030
(703) 993-9005