Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

Work in Progress

This is an active document. It is not at all finalized, and may change drastically in the coming months as the DSpace RoadMap Working Group and Steering Group create a final draft for presentation at OR15.

Early comments / suggestions are welcome!

While this document is a work in progress, we do still encourage any community members to add thoughts, comments, questions or clarifications. 

We only ask, if you type your comments inline, PLEASE add your name next to your comments. That way we can follow-up with you, as necessary, to ensure your questions/comments have been addressed.

(Very Rough) Summary

Over the last few years, the Steering Group along with various strategic working groups have validated the following vision statements which describe the goals of the DSpace open source product:

  1. DSpace will focus on the fundamentals of the modern "Institutional Repository" use case. We are striving to meet the IR needs of the next 5-10 years.
  2. DSpace will be "lean", with agility and flexibility as primary goals.
  3. DSpace will include a "core" set of functionality that can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools
  4. DSpace will be designed in such a way that it can be easily/quickly configured to integrate with new & future tools/services in the larger digital scholarship "ecosystem"
  5. DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)

These five statements lead us to a proposed "value proposition" for the DSpace platform (DRAFT)

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

Additional notes with regards to strategic direction of the software platform / technology:

  • 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 statements, the Steering Group recommends the following actions corresponding to each goal:

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

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. However, the gathered use cases still need further analysis, cleanup and prioritization
  • Action 1B: (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 establishment of the new "Marketing Working Group"

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

[summary of goal]

  • Action 2A: 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
      • 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:

 

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

Assigned: Richard Rodgers

[summary of goal]   DSpace can be extended. Easy API, etc.

  • Action 3A: (Streamline the core functionality, and provide a better "plugin" model for third-party plugins)
  • Action 3B:

 

Goal 4: DSpace will be designed in such a way that it can be easily/quickly configured to integrate with new & future tools/services in the larger digital scholarship "ecosystem"

Assigned: Bram Luyten

To provide easy and out of the box integration aspects with external services in the following areas:

  • Action 4A: Ingest of complete metadata records (items) from external services, with or without files.

  • Action 4B: Consuming external authority control sources to enrich specific metadata fields 

  • Action 4C: Exposing metadata and content to external services

  • Action 4D: Exposing usage statistics to external services

  • Action 4E: Integration with external Authentication and Single Sign on services

  • Action 4F: Integration with external services providing identifiers (handle, datacite, ...)

To integrate with parallel projects and initiatives (fedora, hydra, islandora) we first need to pin down the use cases of what those integrations will bring to DSpace, or what these will bring to the other platforms. They currently do not fit immediately in any of these five areas.

More examples are in the comment below, but those are probably already too detailed for this page and should end up in the technology document.

Goal 5: DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)

Assigned: Stuart Lewis, Robin Taylor, Claire Knowles

DSpace should be easy to install without requiring Java development expertise, to configure without requiring server access, and to monitor from within the application. Basic configuration options, including the look and feel and selecting themes should be accessible from within the DSpace online administration area.

  • Action 5A: Investigate download, packaging, and installation tools for Java web applications to make it easier to build a working system; What do comparator systems use?
  • Action 5B: Examine options for lightweight installation with setup tasks such as database population undertaken via the web interface upon first use, and creation of initial admin account;
  • Action 5C: Move configuration of basic theme configuration options (colours, logo) into administrative interface;
  • Action 5D: Move most configuration into the database, so that it can be updated via the administration screens;
  • Action 5E: Document options for scaling and load-balancing DSpace;
  • Action 5F: Consider developing a Simple Asset Store as the default asset store that uses a more logical naming structure for human traversal;
  • Action 5G: Create a health check tool that can report on issues, of potential future issues (e.g. low disk space);
  • Action 5H: Ensure no data is stored in transient technologies (for example solr statistics do not have persistent storage and can be easily lost or corrupted);
  • Action 5I: Create alerting tool for new upgrades to alert administrators within the admin user interface;
  • Action 5J: Investigate options to assist with upgrades (for example highlighting changes from core code or configurations)

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.