Resourcing Repositories for Sustainability

Installation & Customisation | Technical Maintenance | Content Mediation | Equipment | Planning Checklist

This section covers the resourcing issues associated with sustaining an Open Access Repository effectively in the long term.

Staff requirements for a repository vary greatly between institutions depending on the remit of the repository and on existing and available resources.

In some repositories the skills, knowledge and abilities required may be expected of a single repository post with the assistance of general IT personnel. However, many institutions spread the work over two main posts:

1. A Repository Manager- who manages the ‘human’ side of the repository including content policies, advocacy, user training and a liaison with a wide range of institutional departments and external contacts.
2. Repository Administrator- who manages the technical implementation, customisation and management of repository software, manages metadata fields and quality, creates usage reports and tracks the preservation issues.

Other institutions spread the work over several posts or over several departments; typically including library cataloguers, subject librarians, other library, teaching and administrative staff as well as IT services.

For more information on the skill requirements, presented in a form suitable for incorporation job specifications or job adverts, see SHERPA's document entitled 'Institutional Repositories: Staff and Skills requirements'.

Installation & Customisation

Installation/customisation and ongoing maintenance generally require the same skill set, and are usually done by the same staff. The main difference is in the time commitment. While you may decide you need your own dedicated technical repository staff, you are still very likely to need to call on central IT services to help with server and database issues.

In principle, installing and customising a repository is a one-off task, requiring a relatively short burst of intense activity by staff with appropriate IT skills. It is therefore advisable for the relevant staff to be assigned full-time during this phase of the project. The period for which they will be required depends on the software you are using, the degree to which you wish to customise it, and your system architecture. The closer you stick to the out-of-the-box product, its default configurations, and recommended platforms, the quicker it will be.

Ideally, you should engage or assign technical staff to the project who have experience with the software and hardware platforms required by your choice of software. If no one suitable is available, you should allow time and money for relevant training. Your software provider may also run technical courses on their products, and it is generally well worth sending your staff on them.

The popular software choices tend to be fairly quick to install, taking the order of two weeks for a standard configuration. This assumes you do nothing in the way of customisation more than the basics of adding your institution's name and logo, the name of the repository, and the name & email address of the administrator. You should allow more time if you wish to go further in matching the repository with your institutional or departmental web look and feel - anything from a week to a month. As stated elsewhere, it important to record assiduously the changes you make, because you may need to repeat them during a future software upgrade. Such documentation adds to the time required, but it would be counter-productive to skimp on the time allocation.

If you wish to pre-load your repository with material, for instance extracted from PubMed Central or some other resource, you should also allow time for this - possibly a week to a fortnight.

Of course, much of this commitment of resources can be avoided by outsourcing - either by hosting your repository with a suitable service provider, or bringing external people in to do your in-house set-up for you. However, you still need to allow time for setting specifications, liaison and project management, and you should still seriously consider sending your own staff on any product-specific courses for the sake of ongoing maintenance.

Technical Maintenance

A stable operational repository has fairly modest technical maintenance requirements, most of which can probably be handled by your central IT services, or by your outsourcing service provider.

Probably the most important thing is to check the arrangements for back-ups, and ensure that your repository is being backed up on at least a daily basis. You should correspondingly check how you would restore material from back-up, and what the turn round time would be. For this and other ad hoc troubleshooting and support, it tends to be advantageous to secure a named contact - ideally the person who installed the repository - rather than having to use a general IT helpdesk. There may also be advantages in negotiating a service level agreement. If you need to quote FTEs (full time equivalents) for technical support, a day a month, or half a day a week should be sufficient, averaged over the year.

Software upgrades are a different kettle of fish. Experience suggests that upgrades can require considerable effort, especially if major changes have been made to the software and/or the associated database, or you have heavily customised your site. The timescale is very much case-dependent, but you should think in terms of a week to a month of full-time technical work. It can help to do a preliminary scoping exercise to determine the tasks that need to be done, and estimate the effort required. As with installation, it is advisable to assign technical staff full-time for the duration of the upgrade.

Content Mediation

There are two principal approaches to adding material to a repository - self-archiving (in which authors deposit their own papers in the repository), and mediated deposition (where a dedicated member of staff handles the deposition process on authors' behalf). Both approaches require administrative effort for such things as fielding practical queries from authors, PDF-making, quality checking, or even making deposits. Superficially, self-archiving by authors ought to require less administrative effort, but the capacity for authors to make mistakes means that saving may not be as much as you would expect. Mediated deposition tends to yield benefits including improved data quality, and higher deposition rates.

Estimating the time required for administration is highly variable and dependent on your deposition rates - although there is a chicken-and-egg situation here (see Benchmarking and Targets). Advocacy materials often state that it only takes 10 minutes to deposit an item, complicated items can take much longer (for instance, if you need to merge separate files for figures in with the body of a paper). With fully mediated deposition, 30 minutes per item would also make allowance for other administrative activities. This estimate can perhaps only be halved for an author self-archiving system.

Using these figures and your anticipated (or target) deposition rate, you can calculate how many Administrator FTEs you need. For a mediated-deposit system in a large institution, you should really think in terms of whole-FTE posts, with any spare time they have devoted to advocacy initiatives. You may be able to get away with half-FTE admin roles in smaller institutions and/or with author self-archiving.

Equipment

Apart from the usual office equipment for your administrative staff, the main equipment need for a repository is a server. Check you repository software product's 'Systems Requirements' for the relevant specification.

Unless you want the hassle of looking after this yourself, the best approach is to have your server managed by your central IT services. You are likely to be offered the option of a shared or virtual server, or a dedicated server. Try not to get bogged down by equipment costs. The real bottom line is performance. Slow performance will reduce your end-users' willingness to use the repository, so it does nobody any favours to trade off performance against price. If necessary, run a trial to check that the performance will be acceptable. This implies that you have defined your acceptance criteria for such things as time to load the home page, time to log on, time to change pages, time to download a typical PDF, etc.

Some software products expect all your systems software to be on the same server. This tends to be the norm, but you might find that, for example, you institution usually handles web pages on one server, and MySQL databases on another. If this split approach causes undue complications, press for a dedicated server.

Maintenance of the server should be a standard part of your IT services. You should consider what will happen if your server breaks down, or needs to be shut down for maintenance. Ideally, everything should fail-over to another machine.

You should also keep a weather eye out for server, operating system, and systems software upgrades. Your central IT services may already have a rolling programme of upgrades, in which case you should ensure you will be notified well in advance of any upgrades, in case there are implications for your repository software. Additionally, you may need to initiate an upgrade if you find that performance is degrading to an unacceptable level. Assume an operational life of two to three years, and budget and plan accordingly.

Planning Checklist

This planning checklists offers as a series of key questions designed to ‘make you think' about resourcing your repository for sustainability.

References

Mary Robinson (2007) Institutional Repositories: Staff and Skills requirements, http://www.sherpa.ac.uk/documents/sherpaplusdocs/notts-Repository%20Staff%20and%20Skills.pdf, SHERPA, 8th Aug. 2007