Delivered 19 November 2008, just after SPARC Digital Repositories.

1. “A Successful
Failure”
Community Requirements Gathering for DSpace
Dorothea Salo
University of Wisconsin
19 November 2008

2. Disclaimers
★ Nobody asked me to gather requirements for DSpace.
★ Nobody vetted or co-wrote this presentation. It is entirely
my own work, and I own any errors in it and any offense
it causes.
★ I am a notorious gadfly and crank.
I make trouble. Ask anyone!
Me.

3. That said, then...
... we all understand that this presentation represents
my opinion only and does not represent that
of my employer or the DSpace Foundation, right?
... because if anyone’s going to land in the soup for this,
it should be me, okay?
... oh, good. Onward!

4. DSpace, socially
★ Too-small developer pool...
• ... which has led to a self-reinforcing problem spiral, as
• patches and hacks languish in the queue, and
• end-users get more and more annoyed, and
• devs placate them, losing coding time, and
• potential devs decide to code elsewhere.
★ A great many silent end-users
• Show of hands!
• Consider DSpace’s market position... and history.
• DSpace devs: “The price of a voice is code.”

5. DSpace, technically
★ Lagging behind other open-source IR packages
• EPrints: much more usable, sell-able; easier to install
• Fedora: much more flexible, scalable; better data model
★ Lagging behind service offerings
• BePress: Selected Works
• Common reaction from service purchasers: DSpace is too
difficult and staff-intensive to run in-house, and too
inflexible to run consortially.

6. DSpace, techno-socially
★ Hacks, hacks everywhere!
• Show of hands—who runs DSpace unmodified except for HTML/CSS?
• Embargo hacks, ETD hacks, statistics hacks, persistent-file-URL hacks,
authentication hacks, researcher-pages hacks, streaming-multimedia
hacks...
• ... never make it back into the DSpace codebase!
★ Hack = end-user need not being met
• And yet we have controlled vocabulary support.
• Who’s setting priorities here?
• Who’s being heard and who isn’t?

7. So I said to myself...
★ IR managers don’t feel they have a voice. Let’s give them one!
★ Developers don’t feel that the community supports them. Let’s
show different!
★ Best-case...
• Engaged IR managers can make the case to their
administrations to throw more resources (dev
time, Foundation support funding) at DSpace.
• Potential devs will see a functioning community
they want to participate in.

8. The plan
★ Asynchronous and synchronous discussion...
• DSpace is global!
• IR managers are accustomed to the mailing lists; not so much to IRC.
★ ... with an option for private communication...
• (because the current atmosphere can feel intimidating!)
★ ... of a “question of the week,” which would then...
★ ... be summarized to the wiki for future reference.
• No more “gosh, when did you say you wanted that?!”

9. The venues
★ DSpace-general and DSpace-tech lists
★ Meebo (got bot-spammed, so moved to...)
★ DSpace IRC channel
★ My email

10. The questions
★ Most-wanted changes
★ Statistics
★ The “ideal repository system”
★ The deposit interfaces
★ Documentation

11. The participants
★ Committer pool extremely active and respectful
• Brad McLean, Mark Diggory, Tim Donohue, Claudia Jürgen, others
• The process had their attention, and they were willing to listen!
★ Repository managers: “OK Houston, we’ve had a problem here.”
• There are at least a dozen of us to each committer!
• Yet only a bare handful participated in any way.
• Even fewer participated in a sustained fashion.
• Heroes: Shane Beers, Christophe Dupriez

12. The results
★ Six questions went out. Five-and-a-half chats were held.
★ By the sixth, participation by the key community (not
developers! IR managers!) had dropped
so low that it was clear the project was
not viable.

13. Why did it fail?
★ Was I the wrong person to do this? (Very likely!)
• I got very jammed up for time in September and early October.
• I am not popular in the community (and now you know why).
★ Were email and IRC the wrong venues?
• Conferences? Surveys?
★ Do librarians know how to give good feedback on software?
★ Are the right people on the mailing lists?
• Do the lists reach local customizers and developers?
★ ... or is it something I haven’t thought of? (Very likely!)

14. Why was it a successful
failure?
★ We did surface, clarify, and document some unmet needs!
★ Those of us who spoke up were heard.
• Though what that means for development remains to be seen...
★ I’m here, talking to you frankly and openly about this.
★ Edison: “One more way it won’t work.”

15. “Community”
★ Is there really a “community” around DSpace?
• Where are the library administrators?
• How much faith do institutions have in DSpace’s processes and outcomes?
★ If what DSpace has isn’t a community, what is it?
• Librarians aren’t used to the open-source “community development”
concept. Might a different model work better?
★ If there is no community, or if it isn’t
powerful enough, will DSpace survive?

16. The next launch
is yours
to plan and execute.

17. Credits
★ Fly: http://www.flickr.com/photos/laserstars/
★ All other images: NASA, http://www.nasaimages.org/
This presentation is available
under a Creative Commons
Attribution 3.0 license.