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.

Location

Agenda

This agenda is still in draft form and may be updated as OR2025 gets closer.

  1. Welcome and Introductions (Holger, 15 mins)
  2. Overview of the DSpace 9.0 Release and upcoming DSpace activities (Tim, 60 mins)
    1. Overview of 9.0 New Features / Major Changes
    2. Overview of Upgrade process from v7/v8 to 9.0
    3. Update on potential merger discussions with DSpace-CRIS
    4. Update on 10.0 Roadmap discussions
  3. Open Discussion / Presentations (see "Topic Sign Up" below) (Pascal, ~1.5 hours)
    1. Attendees are encouraged to bring anything they have built or are planning to build for DSpace. Demonstrations are welcome/encouraged. This is an opportunity to receive feedback from other developers or find potential collaborators. DSpace Committers will be in attendance to answer questions or provide tips/tricks. Committers will similarly share any new features they may be working on (or brainstorming) for future releases.

Topic Sign Up

In order to present an idea or request a topic be discussed, we ask that you propose your topic in this sign-up form.  Please add your name next to any topic you wish to discuss, along with a brief overview of the topic (including relevant links).  Topics may only be suggested by attendees.  Attendees can also vote for specific topics by adding a +1 in the "Votes from other attendees" bullet.
(While we will do our best to get to as many topics as possible, topics may be reordered by DSpace Committers based on their current priority.)

  1. Answering all your questions about the DSpace-CRIS and DSpace potential merger. Plus, an opportunity to share your hopes, concerns, honest feedback regarding this potential merger.
    1. Proposed by : Tim Donohue
    2. Brief overview:  We open the floor to any/all questions related to this potential merger and do our best to answer them all.  We give everyone (who wants it) an opportunity to express your feedback (positive or negative or somewhere in between).
    3. Votes from other attendees:
  2. Future proof dspace-angular customizations
    1. Proposed by: Ondřej Košarko
    2. Brief overview: A question/discussion topic. With changes like https://github.com/DSpace/dspace-angular/pull/3997 and https://github.com/DSpace/dspace-angular/pull/4019 in the pipeline are there any best practices on how to customize v7/v8, that'd make future upgrades easier?
    3. Votes from other attendees: 
  3. Potential future DSpace contributions from dataquest
    1. Proposed by: Milan Majchrak
    2. Brief overview: At dataquest, we've been upgrading the clarin-dspace fork to DSpace 7, which involved rewriting several core features to ensure compatibility with the latest version, as well as introducing new functionality. We believe many of these enhancements could be valuable to the broader DSpace. The key features we'd like to share include:
      1. Modular licensing framework
      2. Simple sharing of the submission
      3. Enhanced S3 downloads and uploads (using the pre-shared keys)
      4. Handle PID configuration per community
      5. Download all files as a single ZIP
      6. Improved Tombstone functionality
    3. Votes from other attendees:

  4. Making DSpace more extensible

    1. Proposed by: Nick Woodward
    2. Brief overview: This topic came up in the DSpace CRIS merger meetings, and I think it merits further discussion by the larger community of DSpace developers. The idea is to have a stable core repository platform with the ability to install additional modules or plugins, much like popular content management systems such as Drupal or Wordpress. With that in mind, I wonder if we can have a brief discussion. Here are a few questions for consideration.

      1. How extensible is DSpace today? For example: custom curation tasks, custom Entities, UI customizations, and adding a separate Java dependency to [dspace-src]/dspace/modules/additions/pom.xml , such as the Replication Task Suite.

      2. How could DSpace facilitate developers who want to create plugins or modules in the future?
      3. Are there examples of functionality that isn’t core to DSpace today but would be nice to have the option to add in the future? For example, kicking off separate processes during submissions, such as OCR, audio/video transcription, or web archiving services?
    3. Votes from other attendees: 
  5. Python DSpace-REST client
    1. Proposed by: Pascal Becker
    2. Brief overview: We wrote a client that makes it easier to interact with the DSpace-REST-API from Python. It handles Authentication, XSRF Tokens, Search, CRUD-operations, ... It's Open Source, available at https://github.com/the-library-code/dspace-rest-python. We look out for contributors!
    3. Votes from other attendees: 
  6. Example Topic
    1. Proposed by: (Your Name)
    2. Brief overview: (Provide a brief summary of the topic, and whether you plan to show something off, or if you are just wanting to lead a discussion / ask questions.)
    3. Votes from other attendees: (If you support discussing this topic, add a "+1" next to it.  This just helps us to know which topics are the most popular among attendees)

Crowdsourced Notes


  1. DSpace and DSpace-CRIS Merger.

Q: I think it makes sense to discus the possibility of the merger. Are old-timers in the Technology and Strategy groups who remember have having two different UIs like we did with JSPUI and XMLUI. We definitely don't want to have that again.
A: This is why we are discussing the merger. We are aware of this and don't want to have multiple implementations of the same thing. Happy to discuss to align DSpace and DSpace-CRIS and end up with a common source base but it will be involve deprecating features - we'll need to make some decisions where things are done differently in each.
We want a smooth transition.

C: Really interesting from an institutional point of view. For institutions that don't have a CRIS system. If the library is already using a DSpace with CRIS functionality then it allows them to be in the space.
Q: To what extent is Atmire or others tracking what's in commerical systems and what's in DSpace-CRIS. Is there a desire to play in that field? 
A: DSpace-CRIS was built to compete with PURE and other CRIS systems. Institutions that use DSpace-CRIS instead of PURE. Many other institutions are using CRIS systems and repositories together. ORCID / OpenAlex (about OpenScience rather than CRIS but talk about people and institutions too).

C: Most of the differences between DSpace-CRIS and DSpace are what DSpace-CRIS has and DSpace doesn't. So shouldn't be too much change.
A: You can still run a CRIS alongside it but it will be easier to integrate.

Q: Will entities be required for DSpace after a merger? They would definitely need to be turned on to use the DSpace-CRIS features. 
A: We still want to be able to just run everything out of the box. Should be something 
A: Publications, entities and items are all essentially the same thing. If all your publications were updated to entites - you won't really see the difference on the front-end. Entities are much more powerful.

C: Optional entities is another example where DSpace is doing things in two different ways. It would be better to have one way of doing things so the merger could be agency to swap to move using entities.
A: There 

Q: Is there a timeline?
A: We are hoping to make a decision by December this year - it would be welcome if this started earlier. 
A: Groups are a bit slower than governance hoped.

Q: If there is no decision, will there be no DSpace 10.
A: No, DSpace 10 will happen regardless. If no descision, DSpace 9 and DSpace 10 will be very similar.
A: If we decide quicker, there will be preparation for the merger in DSpace 10.

Working group to put a successful plan for the merger should it be decided to go ahead.
The community is doing everything possible to bring everything together.

A: To turn entities on by default is the start of the merger discussion.

What is the relationship between DSpace and DSpace-CRIS.

DSpace 5 and 6, you added DSpace-CRIS added to it.

For 7, DSpace-CRIS is a hugely customised a DSpace 7. DSpace-CRIS is governed by 4Science and DSpace is governed by DSpace Governance.

  • 2. Future proof dspace-angular customizations

Tim mentioned today in several occassions there are breaking changes in the front-end, especially within the themes - how you make the installation your own. Is there any way to better prepare for changes coming up that will break the themes?

How do I extend DSpace in a way that's future-proofed?
It's not possible. We are taking up development from dependencies - like from Angular and Bootstrap. You have to keep up with the developments. 

DSpace managing 7,  8 and 9.
You have to look feature by feature and make the required changes when you upgrade.

Disagreement. Service provider of DSpace. Please can DSpace work on backwards compatability rather than giving breaking changes that need to be updated. Focus on backwards compatibility more. As a service provider, but as a customer they won't have capacity to do this. Should we upgrade and make all these changes.

Support the main 3 major releases. Currently 7, 8 and 9. Security fixes will be backported for those versions. You don't need to upgrade every major release. Rather than every major do every 2nd release. 

Dependencies upgrades have to be updated. Angular, Bootstrap, Solr 3 out of the 5 breaking changes. Dependencies hitting end of life and we need to move to the secure versions.

Can already do the control-flow change in Angular 17. Deprecated in Angular 18 which is why you need to make the change.

Want more stability. "Next two versions it will be fine".
Every major version of DSpace for 2.5 years.

Not sensible to bring an Angular release into a minor release.

Talk about backwards compability. Performing quite well. Integration tests identify for us when something is breaking. 
DSpace 8 and DSpace 9 introducing new Angular which makes the UI better.

Customisation should be a last resort. It creates work. We want everything to be configured. 

We are trying to have something more stable and encourage less customisation.

3. Potential future DSpace contributions from dataquest

clarin-dspace
https://github.com/ufal/clarin-dspace

Some features merged into DSpace 5 and 6 but are missing in DSpace 7.
Modular licensing framework - user asked for additional information re licensing. License will come with the download.
Choose the license (open-license selector) - help user to choose the right licenses - all the licenese are configurable.
Can also edit license of an already existing license.
Download of restrictred - you have to login and agree to license - that is logged in the database including IP address and other info.

Simple sharing of submission
Creates a link for sharing a submission. So you can pass it on to someone else.

Handle PID configuration per community
Alternative handle features.

Download all the files as a single ZIP
Gives a button to download as a single zip.

Enhanced Tombstone Functionality
For items that are withdrawn.
1. Not available in repo but is available somewhere else.
2. No longer available with reason.

Enhanced S3 downloads and uploads.
Don't need to have temporary server side storage.
Using  preshared keys you can communicate directly with s3 cloud.


Review process can be quite slow.

Currently takes a lot of time. 

Want to encourage community to make pull requests and be patient. The sooner you get the pull request in the better.

Dedicate a developer meeting - we need to look at the code and review.



In a situation similar with DSpace-CRIS - fork was in 1.8. Disagreement, DSpace-CRIS has it's own governance etc.
20+ installations of the fork.
Feature by feature, pull request to review

5. Python DSpace-REST client

Shout out to community looking for contributors and ownership.
Want to see some more traction.
We need at least a couple committers to be interested.
We are using it and it has been working really well x 2.

4. Making DSpace more extensible

This topic came up in the DSpace-CRIS merger meetings a couple times. Having a core platform with modules much like other content management system. If you want to add a feature to DSpace, how do you go about it?
Which path do you choose:
Custom curation tasks
Custom entities
UI customisations
Adding separate Java dependencies

Ask insitutions of their running on their repositories on github. Could be a small feature but could be really useful. Shout out TU Bien - entire code of DSpace 6 code - lots of praise for that. Make sure you clean up your github and don't have passwords / other sensitive data.

Assuming the whole merger happens, how could we make the system modular so we can turn things on and off easier. Then easier to make your own modules that will be useful for others. We don't have an answer yet - might be the next big thing.

4Science have some add ons for DSpace that are not open source. 
Pom dependencies.
Patch your source code.
Standalone component.
On DSpace-CRIS - on the pom file, you already see how to add 4Science addons. 
4Science happy to share this and find a better a solution.
Would be a good starting point.

If there are any examples of custom curation tasks, now more complicated with the front-end and the back-end.

Don't want to have everyone doing the same thing in slightly different ways. E.g. 3 different orcid modules in the eprints marketplace.

Hard to do this while the merger is going on - huge redevelopment in DSpace 7 and now on the merger. DSpace 7 - was overcame the gap between two UIs. DSpace 10 - the merger between DSpace and DSpace-CRIS. What's next?

How can we fix the system?

How do we fix the code review process?


10 years ago, find a dspace clone in China. 

Going through the migration all over the place - from Texas Digital Library - Had to use excel - Documented migration paths from products. Found information in 6 different places.
Maybe we need to add something more developer specific. Too technical for DCAT.
Wiki

Will service providers be able to share their documentation.

Difficult to main documentation over time.


  • No labels

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