A Successful Failure: Community Requirements Gathering for DSpace

4,710 views
4,503 views

Published on

Delivered 19 November 2008, just after SPARC Digital Repositories.

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,710
On SlideShare
0
From Embeds
0
Number of Embeds
2,413
Actions
Shares
0
Downloads
20
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

A Successful Failure: Community Requirements Gathering for DSpace

  1. 1. “A Successful Failure” Community Requirements Gathering for DSpace Dorothea Salo University of Wisconsin 19 November 2008
  2. 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. 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. 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. 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. 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. 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. 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. 9. The venues ★ DSpace-general and DSpace-tech lists ★ Meebo (got bot-spammed, so moved to...) ★ DSpace IRC channel ★ My email
  10. 10. The questions ★ Most-wanted changes ★ Statistics ★ The “ideal repository system” ★ The deposit interfaces ★ Documentation
  11. 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. 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. 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. 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. 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. 16. The next launch is yours to plan and execute.
  17. 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.

×