InvenioRDM Roadmap

May 2022


A team actively works on this now


OCFL Backend Support

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

@Data Futures


Internationalization (I18N)

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

@TU Graz & Uni Bamberg

Custom fields

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


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.



A team plans to work on this next

Back office / Admin

Implement a basic an back office administration interface for InvenioRDM. The tasks focuses on setting up the main skeleton for the administration interface, and add the first couple of administration actions into the form.



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.



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.


Done 🚀

What we have recently completed


Funders and grants

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



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


IIIF image previewer

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

@Data Futures & Uni Hamburg


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.



Communities UI: Members

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


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, ...).



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

Basic OAI-PMH server

@TU Graz

OAI-PMH sets support

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

@TU Graz


EOSC AAI integration

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



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.


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.



v9.0 (LTS)

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




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

Roadmap planning

  • Plan next 6-months roadmap


v10.0 (STS)

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



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 ( Options include anything from contributing developers to contracting out work to other InvenioRDM partners.