InvenioRDM Roadmap

May 2022

Current

A team actively works on this now

Preservation

OCFL Backend Support

Support for storing records and files according to the Oxford Common Filesystem Layout.

@Data Futures

Custom fields: REST API support

Allow instances to configure additional custom fields and make them available in the deposit form and on the landing page. The current task implements the backend first.

@CERN

I18N

Internationalization (I18N)

Finalise the I18N support and provide a german translation of InvenioRDM. Further languages to come later.

@TU Graz & Uni Bamberg

Third-party Integrations

OpenAIRE integration

Integrate InvenioRDM with the OpenAIRE infrastructure by supporting the required OAI-PMH sets, export formats as well as allowing direct indexing of new records to OpenAIRE.

@CERN

IIIF

IIIF image previewer

Enables the International Image Interoperability Framework (IIIF) support and integrates the Mirador v3 previewer for large images.

@Data Futures & Uni Hamburg

Near-term

A team plans to work on this next

Files

Linking to files on external storage systems

Support linking to files on an external storage system instead of requiring the files to be uploaded via InvenioRDM.

@Caltech

Planned

A team has planed this on their schedule

Third-party Integrations

ownCloud integration

Enable selecting files from an ownCloud installation in the deposit form, and download the selected files on the server backend. Part of the EU-funded project CS3MESH.

@CERN

Done 🚀

What we have recently completed

Communities

Communities UI: Members

Implements the user interface for managing members of a community as well as inviting members and allow user to request membership.

@CERN

Persistent identifiers

DOI minting support

Support for registering DataCite DOIs as well as for developing your own plugins for registering other types of persistent identifiers (Crossref DOIs, ARKs, Handles, ...).

@CERN

Communities

Communities REST API: Records/Requests

Implement the REST API and workflows for communities and the requests features. This will enable the integration between communities and records as well as the general framework for communities submission handling.

@CERN, Northwestern University & TU Wien

Communities

Communities REST API: Members support

Adds support for having multiple community owners and members of communities with curation capabilities. This task only deals with the REST API and backend (i.e. the user interface is a separate task).

@CERN, Northwestern University & TU Wien

OAI-PMH sets support

Supports the sets feature of the OAI-PMH harvesting protocol.

@TU Graz

Vocabularies

Funders and grants

Enable the funder/grants field in the deposit form and import the required vocabularies in InvenioRDM.

@CERN

Authentication

EOSC AAI integration

Support logging in via the OpenAIRE Authentication and Authorization Infrastructure (AAI) as part of the European Open Science Cloud (EOSC).

@CERN

Vocabularies

Creator/contributor auto-completion and improved ORCiD integration

Enable auto-completion of creators/contributors in the deposit from a local names vocabulary that can be filled from e.g. ORCiD or your institutional employee database.

@CERN

Basic OAI-PMH server

@TU Graz

Communities

Communities UI: Records/requests

Implements the primary user interface for searching and browsing records associated with a community. Includes the workflow support for submission of new records to a community and the integration into the deposit form.

@CERN

Release dates

Following is an overview over the upcoming planned releases. For more information, please read our maintenance policy.

Long-Term Support (LTS) - production-ready

LTS are releases that can be used for production services. LTS releases are supported with bug and security fixes for minimum 1 year and maximum until 6 months after the next LTS release has been released.

Short-Term Support (STS)

STS releases should NOT be used for production services. An STS releases is only supported until the next release. STS releases are used to ship new features fast so that the community can provide feedback.

2022

Apr

v9.0 (LTS)

  • Maintained until the next LTS release.
  • Planned release date: April 15th (released May 24th).

May

Jun

OR2022

  • InvenioRDM Workshop at Open Repositories 2022 (June 6th)

Roadmap planning

  • Plan next 6-months roadmap

Jul

v10.0 (STS)

  • Maintained until v11.
  • Planned release date: end of July (to be confirmed).

Aug

FAQ

What are your top priorities?
Our top priorities in the coming period is to ship a) communities feature and b) custom fields feature.

When is the roadmap updated?
We update the roadmap roughly every 3 months. The next update is planned for mid-April 2022.

What does current, near-term and planned mean?

  • Current means that a development team is currently working on the feature.
  • Near-term means that a development team has planned to work on this feature as their next task.
  • Planned means that a development team has allocated time on their schedule to start work on the feature in the next 6 months.

Will "current" features be released before "near-term" features?
No. It is not guaranteed that a feature currently under development will be released before a feature in the near-term column. Each feature may vary greatly in size and required effort, as can the team that implements the feature.

When will feature X be released?
New features are released as soon as they are ready in the next coming release. We on purpose do not communicate in which release a given feature will be shipped.

Why do you not tie features to release dates?
We want to communicate clearly the inherent uncertainty in our planned schedule coming from developing a product as a large open source collaboration.

What is the inherent uncertainties in your development schedule?
As a large open source collaboration, most our resources comes as opportunistic temporary resources. Partners may contribute developers on a short-term/long-term basis, full-time or part-time. This means the development teams are rarely stable for a longer period, and each team has different velocity and skillset. In addition, a large part of the developers participate in running services for their institution and services may from to time need immediate attention. We see all these challenges as strengths for the InvenioRDM community, that overall helps build a stronger and more resilient community, as well as building features that serve real needs for our community.

Is your internal development schedule public?
No. Only InvenioRDM partners have access to the internal development schedule.

Why is the internal development schedule not public?
The public roadmap accurately communicates the uncertaines in the development schedule and ensures we set the proper expectations. The internal development schedule on the other is an internal planning tool and therefore does not accurately communicate the inherent uncertaines. The schedule therefore has a high risk of resulting in failed expectations. Alternatively, we should communicate features with quite large buffer times, but this would also not accurately communicate the current fast-paced development.

What is the difference between the internal development schedule and the public roadmap?
The only differences between the internal development schedule and the public roadmap is that the internal schedule assigns a feature to a) a release date b) a responsible person c) participating partners and d) a effort estimate.

Can I use your roadmap to make commitments?
Any commitment you make is your own commitment and made at your own risk and you must evaluate the impact of not meeting your commitment. If you need a specific feature, the best you can do is to help accelerate the roadmap.

How can I help accelerate the roadmap?
We will be happy to explore with you, how you can best help accelerate the roadmap. Please get in touch with the Product Manager (lars.holm.nielsen@cern.ch). Options include anything from contributing developers to contracting out work to other InvenioRDM partners.