Page History

...

What follows is a series of rough alternative models for a 3.0 release, and some notes about risks/benefits of each (thanks to Tim Donohue for most of these insights), that attempt to capture some of the possibilities and trade-offs. I'm sure there are many others, but these should suffice to provoke reflection and discussion.

1. Status Quo or Evolutionary Release -> Just release Release 3.0 as another evolution of DSpace with XMLUI (as default UI) support (similar to all 1.x releases).
   • Pros:
     • It's what is expected. It's the norm.
     • Provides a straightforward upgrade path for current XMLUI adopters.
   • Risks/Costs:
     • If not now, when do we do a UI/architecture redesign?
     • Will DSpace development activity start to "die away" because the platform is less exciting to develop on?
     • Resources must be devoted to XMLUI when our intention is may be to eventually replace it (i.e. robbing cycles from new UI development).
2. "RESTfUL Rapid Redesign" -> Redesign the underlying architecture of DSpace, to develop a "next generation" platform that would allow us to more easily support alternative UIs, inter alia. As this redesign would be a large project - it would only be worth doing to add significant new system capability (like metadata on all DSpaceObjects) - the end result would likely lack a UI by the 3.0 scheduled release date, but it would have a REST API (on which one or more UIs can be built/backported), and migration/upgrade path.
   • Pros:
     • Potentially exciting project? Can we get others excited?
     • Could be re-energizing – increase development on DSpace platform (new UIs, apps/widgets, etc)
     • Needs to happen sooner or later. May be difficult to do incrementally?
   • Risks/Costs:
     • This binds evolutionary features (metadata on all DSpaceObjects) that can be delivered in a 3.0 timeframe into a larger project to re-envision dspace. Its going to create a bottleneck and not utilize existing work in the community as effectively as it could.
     • Past attempts at redesign DSpace show that unless there is a complete solution that is adopted wholly by the developer community, there is a significant risk of non-adoption at the end of the project.
     • What will broader Community think if it has no UI? How do we "sell it" to them?
     • How does it relate to "DSpace with Fedora Inside"?
     • Do we have enough developer time?
   • Valid Questions:
     • Can we even call this 3.0? Is this more of a "beta" release?
     • Is this still "DSpace"? Or is it something else?
3. "RESTful Rapid Redesign + UI backporting/creation" -> Rapidly build the new platform described in #2, but also backport at least one UI (likely XMLUI). The backported UI may have limited/no support for all new platform features (especially if the new platform were to enable features that were not currently present in the UI).
   • Pros:
     • Same pros/risks as #2 above
   • Risks/Costs:
     • May not be possible by Fall? What is the backup plan?
     • Does this mean 3.0 in 2013? No release in 2012?
4. Dual Release: 3.0 + RESTful Rapid Redesign (Almost a combination of #1 and #2 above). The idea would be to release a 3.0 using minimal work/resources (just releasing features that are "ready at hand"), while simultaneously having another developer team work towards a rapid redesign of the DSpace platform (as described in #2 above).
   • Pros:
     • Allows us to continue to support broader community with 3.0, while also working towards the platform of the future (to hopefully be released in 2013).next generation platform
   • Risks/Costs:
     • Stretches resources even more. Would need to limit 3.0 to features that are "ready at hand".