Configuration and Development

Configuration and development are two methods by which you can customise a repository to ensure that it fits requirements. Configuration refers to options that can be changed in repository platform settings, whereas development refers to larger changes that require development time and effort.

Configuration

Most repository platforms contain basic configuration settings. These typically include settings such as:

• Look and feel/branding: Colour scheme, logos, graphics, fonts

• Metadata fields: Which metadata fields are used to store which bits of information

• Search options: Which fields to enable for search and browsing

• Authentication methods: In-built username and password system, or an external provider such as Shibboleth or LDAP

• Email settings: Allows email server configuration and the address from which system-generated emails should be sent

• Submission forms: Change the metadata elements that are collected during the submission of an item

• Workflows: Adjust the stages and users responsible for different parts of the deposit workflow

Configuration settings are usually set in configuration files on the server or can be set via an administrative interface. It is useful to record configuration changes in a changelog so that the can be re-applied them if necessary after a system rebuild or upgrade.

Development

Sometimes there may not be a configuration option available to achieve the requirements. In this situation there are two options: change your requirements, or perform some custom development. For example requirements may dictate that PDF files should be viewed in an embedded frame within the repository with the metadata showing in a side panel. If this is not an option provided by the repository platform and requirements cannot be changed, then that feature will have to be developed.
If a proprietary/closed-source repository platform has been chosen, then the only option will be to contract the work to the commercial company or one of their approved developers. If the company feels that this is a useful feature that will be of use to other customers they may charge little or no money for the development, or ask that the institution sponsor the development. However if they feel that no other customer will require that customisation, then they will likely charge the full development cost.
If you are using an open source repository platform, then you will have the ability to perform the development work in-house. Most repository platforms provide either professional development services themselves, or have a list of recommended service providers.

You may also find other users of the software are interested in developing the same feature and would be happy to collaborate in order to reduce the development cost. If a new feature is to be developed it is worth informing the community of your intentions in order to find potential collaborators, and to see if it is possible that the development efforts may be included in a future release of the software. The ideal solution is that the new feature is general enough to be included in the next release of the software as this will reduce ongoing development costs. By consulting with other members of the user community, plug-ins,upgrades or workarounds that could be used to achieve the same outcome without having to perform any development work can often be found.

Each open source repository platform has its own method of suggesting new features and contributing code, so if it is worth finding out how the chosen repository platform software community works and how best to work with it.

The probability of having to undertake development work can be minimised by ensuring that the requirements specification is complete for your repository. This ensures that the best match for the specified requirements is found. Where there are differences, it will assist in creating estimates of the development work required as the features that require development work will be identified.

Comparison

Configuration of the repository platform is often quick and easy in comparison to developing new features. When new features are developed both the inital and ongoing developments should be budgeted for. If the development can be contributed back to the community so that it becomes part of the software, then this can reduce that cost. However if a specialised development is required then it is likely that the development will have to be continued over future versions of the software. If this is not budgeted forthe institution may be locked into an increasingly old version of the repository software as upgrades cannot be afforded because of the implications for development work.