Are you a new developer looking for how to get started with DSpace?  Take a look at our New Developers Hub

Contributing to DSpace Software

This page provides links to resources/notes on how you can contribute to DSpace, whether you are a repository manager or a developer.

How to "Hack" the DSpace Community

This presentation was given at Open Repositories 2014 in Helsinki, Finland. It provides some tips on how and why you may wish to contribute to DSpace:

https://www.slideshare.net/tdonohue/hack-d-spacecommunityor14

Ways To Contribute and Participate

You do not have to just contribute code! There are other ways you can contribute:

Platforms for Contribution and Participation

How To Contribute Ideas or Suggest New Features

We always welcome new ideas or suggestions for new features. However, there are a few things to keep in mind which may increase the chances of your feature making it into DSpace!

1. Make Your Request Known to DSpace Developers

You should submit your idea or feature request to our Issue Tracking System (GitHub). However, before going through the process of submitting your ideas, it's always best to search the Issue Tracker to see if others have already requested this feature. If someone else has requested this feature, you can add your ideas as "comments", or "vote" for that feature to be added/implemented.

If this feature hasn't been requested by anyone else, submit a request! (Don't worry, if it ends up being a duplicate request, we'll let you know). Your request will enter the "queue", where it will get a thorough review.

A few things to keep in mind when providing a request:

  1. Always provide us with as many details as you can. A paragraph description is good, but a few paragraphs with some sample use cases is even better. A single sentence description is often very hard to work with, and we may need to ask you for more information before we understand what you are asking for.
  2. If you have use cases or local needs, please describe them to us. Use cases really help developers understand why this feature is important. In addition, use cases may help us locate other institutions with similar needs (who may be willing to help us develop this feature).
  3. Expect that we probably will need to ask you a few questions. Even with detailed descriptions/use cases, chances are we will need to follow up with you later for a few more details, or to make sure we understand exactly what you are asking for. So, please be willing to respond to questions or requests for additional details. Anytime someone comments on your newly created issue, you will receive an email from the Issue Tracker system.

2. Advertise your Request to Others & Help Us Find a Volunteer Developer or Two

All of our DSpace Developers/Committers are volunteers. Let's repeat that: All of our DSpace Developers/Committers are volunteers. This means the core DSpace Development Team (i.e. Committers) don't always have control over how much time they can spend on developing new features for DSpace. In many cases, the Committers can only work on new features which are of interest to their local institution/university.

Therefore, even if the Committers agree that a new feature seems worthwhile, oftentimes, we need to first find an institution that is willing to provide developer time towards that feature.

You may be able to help us expedite this process! Here's what you can do to help:

3. Respond to the Formal Review of your Request (as necessary)

Each Feature Request is guaranteed to get a formal review by at least one of two groups (possibly both):

  1. The DSpace Committers - They review every feature request or bug report that comes into the system, often in weekly Developer Meetings. Note: Because of occasional backlogs, it is sometimes possible there may be a delay of several weeks/months before your request will get a formal review by the Committers. However, it is worth noting that your request will be immediately emailed to the 'dspace-tickets' mailing list. where individual developers may provide immediate feedback before the formal review takes place. So, you may not need to wait that long for immediate response, or even for a developer to volunteer to work on that feature.
  2. The DSpace Community Advisory Team - They review and request additional feedback about any new feature request. This is a team of Repository Managers (or similar) who provide additional feedback to the Committers on new features.

After a formal review, a comment will be added to your request (it will also generate an email to you). This comment will detail the results of the initial review, along with any questions that came up. If you have time, please respond to these questions, or encourage others to do so. These questions are often asked to help us determine more about the request, so that we can ensure we have a common understanding.

4. Keep in Touch about the Request

Let us know if you need updates on the Feature Request's status. Just add a comment to your issue, requesting the latest status, and we'll try to get back to you as soon as we can.

There are many different reasons why a Feature Request may not have had any recent activity:

  1. We may have a backlog of requests, and just haven't gotten to a formal review yet.
  2. We may need to find a developer (or committer) who has time to develop this feature. In these cases, if we can locate other institutions who may be interested, that can often help in the search for a volunteer developer.
  3. We may be waiting for the answer to one or more questions posed in earlier comments. If we need more clarification, we can let you know.
  4. We may be currently performing a "Code Review" on any submitted code, to ensure it is safe & stable enough to release in DSpace. For more information on our DSpace Code Approval Processes, see Code Contribution Guidelines
  5. It's also possible that there are one or more developer(s) actively working on the feature, but that the work is not yet in a "completed" state.

5. Once your Request is Accepted into DSpace

If your request is formally accepted into DSpace, you'll receive an email as soon as we "Close" or "Resolve" the request in our Issue Tracker. At that point in time, the Issue Tracker will also be updated to state which version of DSpace this new feature will be released in.

Once that version of DSpace is released, your name (and a link back to your initial feature request) will appear in our Version History section of our DSpace Documentation. You will also be added to our list of all known DSpaceContributors. This is our way of ensuring you receive recognition for your contributions to DSpace!

How To Contribute Code or Development Time

Where to Obtain the Source Code

If you plan to develop new features for DSpace, we recommend forking and cloning our Source Code via Github:

More information on using DSpace + GitHub is at: Development with Git

More hints/tips on developing with DSpace are available in the following locations:

Our Development Policies / Mantra

For more information on our DSpace Code Approval/Acceptance process (i.e. how to get your code accepted in DSpace), please see our Code Contribution Guidelines.

The overriding mantra is share early, share often. Here are a few things to consider:

Looking for a Project to Work on?

Do you have a developer (or two) with some extra time? Are you looking for ways that you can help the community and improve your local DSpace?

Please take a look at our issues lists

Please, take a look at our current listing of "good first issue" tickets. Any help you can provide would be much appreciated!

(If none are currently listed, as on Slack or via email and we'll find a smaller ticket for you to start with) 

But, before you get started, please make sure to do the following:

  1. Add a comment to the Feature/Improvement you plan to work on, letting us know you will work on it.
  2. If you'd like more input on the feature/improvement, or potential requirements, post your questions and/or plans as a comment as well.
  3. Make sure your developer is following our Code Contribution Guidelines. If you have questions about any guidelines, or want some early feedback/suggestions from developers, please get in touch with us on the 'dspace-devel' listserv. We'd be glad to help make suggestions on ways in which to implement the new feature, and the earlier you get in touch, the earlier we can give you feedback on whether there's anything you may need to change before we can accept it as part of out-of-the-box DSpace. See also the Code Review Process on the Code Contribution Guidelines page.
  4. If you run into any "gray areas", ask questions! If it's a development issue, contact the Developers via the 'dspace-devel' listserv. If it's a policy issue or requires feedback from Repository Managers, get in touch with the DSpace Community Advisory Team, as they can help you query the community for feedback and/or provide you with their immediate opinions

Most of all: Thanks! The more individuals/institutions can give back to DSpace, the better the software is for everyone!

Submitting Code Changes

See Code Contribution Guidelines for guidelines that all submissions must adhere to. That page also describes the general process for how a patch/contribution gets accepted into DSpace. The mechanics of creating a patch file are described in Developer Guidelines and Tools.

Copyright and Licensing of Code Contributions

In the words of the PostgreSQL Global Development Group, which also uses the BSD license, "The simplest explanation of the licensing terms is that you can do whatever you want with the product and source code as long as you don't claim you wrote it or sue us." The BSD License under which DSpace is made available does not require you to make your changes public or open-source. It does allow for proprietary commercial use, and for DSpace-derived creations to be incorporated into proprietary commercial products. Works based on DSpace may even be released under a proprietary license (but still must maintain the license requirements).

You are encouraged, but not obligated, to share your contributions with the DSpace community. If you choose to do so, you will need to sign over copyright and intellectual property rights of your code to DuraSpace, to be distributed via the BSD license. DuraSpace is a 501c(3) non-profit established to be the legal guardian of the code and to remain mission centric on providing free and open source software for management and archiving of digital works. Also, your code cannot rely on any non-BSD compatibly licensed code.

The BSD license means there is no advantage to be gained by your university (or anyone) retaining copyright, and that by having different copyright holders of different sections of the code, we will be rendered inflexible regarding copyright and licensing in the future, we do ask that you transfer copyright of your modifications to DuraSpace.

You will receive full acknowledgment for contributing the code; so we do encourage you to incorporate your enhancements to DSpace's functionality for everyone to benefit. You will also see benefits since you will neither have to re-incorporate the changes with new versions of DSpace, nor maintain this code solely yourself!

If your code contribution uses third-party products/tools, you should also double-check that they use a compatible open source license. Compatible licenses are listed at: Licensing of Contributions section of the Code Contribution Guidelines page.