Re: Creating Institutional Repositories Is Not the Problem

From: Stevan Harnad <amsciforum_at_GMAIL.COM>
Date: Sun, 17 Jan 2010 14:42:00 -0500

On Sun, Jan 17, 2010 at 12:15 PM, Steve Hitchcock <> wrote:

> Stevan,     What you describe on this scale is a repository, not an institutional repository. For it to be the latter it has to have some semblance of institutional backing, either top-down (e.g. policy, mandates) and bottom-up (wide usage by authors).

The question was: What should a small institution do to provide Open
Access to its research output: Can it afford an IR. (Answer: Yes). Can
its authors do better than just self-archiving on their home-pages?
(Answer: Yes) Will that produce the desired visibility, searchability
and usage? (Answer, Yes. It will be harvested by all harvesters,
including OAI harvesters, and jointly searchable along with all other
OA IR contents distributed worldwide.)

> Two mistakes made by many so-called IRs:
> 1 As in this example, they are not institutional, merely repositories operated within an institution. Growing the repository is a problem, and it is hardly a convergent locus.

No problem for OA, as long as the IR's (or "R's") contents are OA,
OAI-compliant, harvested and harvestable.

> 2 Those that make the transition to institutionally-backed repositories tend to overload on costs, administration and bureaucracy without clearly articulating the purpose and objectives.

Yes, IRs tend to be top-heavy on funding and near-empty of OA target content.

Institutional mandates will mend that (and funder mandates will help
reinforce that -- as long as they too mandate convergent institutional
deposit and not, foolishly and needlessly, divergent
institution-external deposit).

> Invariably, the transition to an IR involves costs that are higher than a repository server run by an individual, but this can be controlled with clear objectives.

Yes, if you want to do more with your IR than just host your OA
assets, you can, and you can pay more for it.

But an IR should *at least* host the institution's OA assets, and for
that it needs a mandate, not more money.

> For smaller institutions there are hosted repository services, and these services give a more realistic indication of infrastructure costs for an IR than free software+server costs. People running these services are the world experts on managing the technical aspects of IRs - after all, they specialise in running multiple repositories - so repositories should not be costing more for the level of service offered.

Yes, outsourcing is an option, but it is not a necessity, for 100% OA,
and it is wrong to encourage small institutions to believe that they
cannot host their own IR if they wish.

> The days of running IRs on a small local server are limited if not over already. Institutional infrastructure will migrate to the 'cloud', so large IRs as well as small will be investigating service providers, and repository services will provide both cloud and repository support.

What's missing now is not IRs, or money, or clouds. It's OA deposits.
The solution is mandates. Then those who wish can return to the
clouds. My guess is that for storing and managing their own annual
peer-reviewed research article output, all universities, big and
small, are best to host them in an IR of their own. Outsourcing them
is too close to what conventional journal publication had been, and
look what that brought us. If an institution would not want to
outsource the storage and management of its financial assets, I doubt
it would want to outsource the storage and management of its
peer-reviewed research assets.

But I don't really care, frankly! The only thing worth caring about is
getting those research assets OA at long last. Worries about the
affordability of IRs are bogus (like all the other imaginary obstacles
that have held universal OA back for so many years), but if an
institution wants to outsource anyway, that's just fine, as long as it
mandates deposit...

Stevan Harnad
Received on Sun Jan 17 2010 - 19:43:43 GMT

This archive was generated by hypermail 2.3.0 : Fri Dec 10 2010 - 19:50:02 GMT