DSpace governance update
History of DSpace governance
- 2002: released after HP/MIT collaboration
- through 2004: HP/MIT
- 2004: “committer group” created, DSpace open-sourced
- 2006: it was felt that community needed more structure
DSpace community
- @175 registered live sites
- 40K downloads of the software (in SourceForge’s top 2%)
- @700K digital assets and growing
Adopters
- mostly higher ed, research institutions
- cultural heritage orgs
- some commercial-sector
Mailing lists
- 900 on dspace-general
- 700 on dspace-tech
- 200 on dspace-devel
5 official user-group meetings
- more occurring regionally, because the official ones are so hard to get to
- how do we handle coordination, with all these scattered meetings?
DSpace development
- 9 committers, none full-time
- Australia, Canada, Europe, UK, US
- @45 patches from @50 programmers in the last couple of years
- many institutions have a dedicated developer
Research around DSpace happening all over the world
What’s wrong?
- no coordination, no direction, no leader
- feature creep, forks
- need a roadmap and resources
- can’t form relationships because no one “speaks for” the community
- ad hoc community support, can be somewhat patchy
- legal headaches (how to link, contribute, distribute code)
- tech leadership relies entirely on 9 volunteers
- they are badly overloaded
- better to break out responsibilities, create specialized work groups, streamline process, add new people
- need to reduce reliance on MIT and HP
- need a more formal decision-making process for feature roadmap, technology standoff
2006 Progress Report
- Interim Governance Advisory Board met March 2006
- decisions: need to create a technical review group, a 501c3 nonprofit to handle community governance, initially to be based at MIT but will hire an exec director
DSpace Consortium will
- manage IP
- build relationships with businesses, support organizations (grants etc.)
- help develop and maintain relevant standards
- manage and support the community
- facilitate technology discussions
Next steps 2007
- 501c3 paperwork in progress
- Get funding from MIT etc.
- execute system re-development
- establish centralized release management, community collaboration infrastructure
- hire CTO? (not a developer or chief systems architect, but a coordinator)
And then…
- DSpace continues to evolve
- Will be more stable and better-supported
- lower risk of technical failure, being stranded
- effective innovation pipeline from research to product