Page History

...

DSpace is a turn-key web application for maintaining, disseminating and promoting the digital resources or digital output of an organization and its members.

...

Community /

Assumptions

• We do NOT plan to rewrite DSpace from scratch, for the following reasons:
  • We have a highly active (and global) development community on the existing platform. We are averaging 50+ contributors in recent major releases. We also have a very active and healthy set of service providers.
  • A complete rewrite would require significant funding / centralized resources, neither of which are currently available. There also seem to be few (if any) grant opportunities to rebuild existing, established platforms.
  • A complete rewrite is very risky in the open source world. While in some cases it can succeed, it also can run the risk of fragmenting or fracturing a user community or developer community.
• We ARE aiming for a potentially substantial leap forward in user experience / web user interface.
  • We've heard the feedback that neither of the two UIs (JSPUI or XMLUI) provides an optimal user or administrative experience. So, a UI rewrite or major refactoring would be "on the table".

Based on this proposed value proposition and vision statementsassumptions, the Steering Group recommends the following actions corresponding to each goal:

...

• Action 1A: Verify and validate the needs of a "modern institutional repository". This is instrumental in formalizing the value proposition of DSpace.
  
  • This activity has already begun part of the 2014 Vision Survey and Use Case gathering by DCAT. However, the gathered use cases are still being analyzed and prioritized.
• Action 1B: Community Survey the community on gathered use cases
  • (Do we want another, post OR15 survey of the community based on Strategic Plan, Tech Roadmap & Use Case gathering?)
• Action 1C: Clarify and improve the DSpace value proposition. Enhance our message and goals of the project going forward.  The DSpace Steering Group is working towards establishment of a new "DSpace Marketing Working Group" to help with this effort
  
  • NOTE: This is not really a "Technology" activity, but more of a "Sustainability" activity.

...

Since its initial release in 2002, numerous features, configurations and options have been added to the DSpace codebase in an ongoing effort to keep up with the changing needs of its user base. While many of these changes have helped us to achieve new use cases, in some instances they have also complicated the codebase and made setup and upgrades more complex. Therefore, this goal is oriented towards cleaning up (and simplifying) the codebase and its configuration options, while also working towards avoiding duplication (of code and development efforts). We feel DSpace can be a "leaner" platform, which will allow the codebase to better adapt to the needs of the future and simplify its maintenance, setup and upgrade processes.

...

To be "lean", the DSpace technology platform should avoid duplicative functionality except where necessary to meet use cases or achieve "flexibility" goals.  Where unnecessary duplicative functionality already exists, the technology team should choose a "best option" solution, or propose building a new solution when a "best option" does not exist.

• Examples of unnecessary duplicative functionality, which should be resolved:
  maintaining Action 2A: Converge on a single, out-of-the-box user interface (UI). DSpace will no longer be released with multiple User Interfaces (JSPUI vs . XMLUI)
• maintaining multiple search/browse systems (Solr vs. Lucene)
• maintaining multiple built-in statistical engines (Solr vs Elastic Search)
• Examples of necessary duplicative functionality. Each of these duplicative functions would be considered in line with use cases or supportive of our goal for "flexibility" (of data import/export/storage).
  
  • supporting multiple database storage backends (PostgreSQL, Oracle, etc.)
  • supporting multiple interfaces for deposit (SWORD, REST, etc.)
  • supporting multiple interfaces for export (OAI-PMH, REST, RDF, etc.)
  • supporting multiple external identifier schemes (Handle system, DOI, etc.)
.  A single user interface should be developed as DSpace's out-of-the-box UI. Early discussions on the requirements of this single UI (and some brainstormed candidates) are at Brainstorms on a Future UI.
• Action 2B: Converge on a single, out-of-the-box search/browse system.  DSpace will only support Apache Solr for search/browse, and the older, deprecated Lucene and DB search/browse system should be removed.
• Action 2C: Converge on a single, built-in statistical engine. DSpace will only support a single, built-in statistical engine (based on Apache Solr), and support for Elastic Search statistics should removed or migrated to an optional module. Support for Google Analytics will be retained, as it's an optional integration with an external statistics engine.
• Action 2D: Action 2B: Enhance communication and collaboration. In order to avoid duplicative effort / projects in the future, we need to enhance communication and collaboration between various developers, institutions and service providers, and communicate a common vision / roadmap for the platform.
  
• As a part of this action, we will be developing and maintaining a Technical Roadmap for the DSpace software platform, detailing high priority development projects which can be "claimed" or shared by groups of developers, institutions or service providers
• At the same time, we should recognize that ad-hoc or competitive work can also be beneficial. We should continue to encourage ad-hoc contributions, and even competitive contributions, but make it clear that we will actively discourage further unnecessary duplicative functionality to be added to the platform (see Action 2A for examples).
Develop a basic User Interface "style / layout guide". In order to ensure a consistent user experience across all pages/features within the User Interface, we should provide basic guidelines for layout and styling of common page elements, etc. Examples may include basic guidelines for how errors/warnings/notices should be displayed, what class(es) to use for types of buttons, etc.

Goal 3: DSpace will include a "core" set of functionality that can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools

...