Page History

...

Goal 1: DSpace will focus on the fundamentals of the modern "Institutional Repository" use case.

Assigned: Tim Donohue

In November 2002, DSpace was initially announced as an out-of-the-box "institutional repository software platform" (see DSpace 1.0 release announcement). While that basic goal has not changed, the common needs and use cases of an "institutional repository" have changed significantly in the last decade or so.  Therefore, this goal is oriented towards striving to retain DSpace's niche while revitalizing it to meet current and future use cases associated with the modern repository platform.

• 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 still need further analysis, cleanup and prioritizationare still being analyzed and prioritized.
• Action 1B: Community Survey (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.Mention   The DSpace Steering Group is working towards establishment of the 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.

Goal 2: DSpace will be "lean", with agility and flexibility as primary goals

Assigned: Tim Donohue

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.[summary of goal]

• Action 2A: Avoid duplicative functionality. 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 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.)
• 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).

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

...