Most institutional repositories work well at launch. Within two or three years, many show signs of degradation — outdated software, inconsistent metadata, stalled workflows. The cause is rarely technical.
An institution deploys DSpace. The IT team handles the infrastructure. The library configures collections, submission forms and metadata schemas. Users start depositing. The repository fulfills its mandate.
Then something changes. The person who knew how to run upgrades leaves. The library changes its metadata policies, but no one updates the submission templates. A new version of DSpace is released — twice — and the upgrade is deferred because “there’s no good time.” The OAI-PMH harvester starts returning errors that nobody notices for six months.
The repository still works, in the sense that pages load and files are stored. But it has drifted from the state it was designed to maintain.
Technical drift is the most visible. DSpace versions fall behind. Java and Tomcat versions are no longer supported. Security patches go unapplied. Performance degrades as the index grows without being properly maintained.
Metadata drift is subtler but often more damaging. Schemas diverge from Dublin Core or local policies. Authority files are not maintained. Mandatory fields become optional in practice. Duplicate records accumulate. The repository becomes less discoverable, less harvestable, and less useful to researchers.
Organizational drift is the root of the other two. There is no clear owner for the repository as a whole — only partial owners. IT manages the server but not the content. The library manages the content but not the infrastructure. Neither has a shared operational model for the system.
DSpace is a socio-technical system. It requires decisions across at least three domains: software infrastructure, information architecture, and institutional policy. In most universities, these domains belong to different departments with different priorities, different vocabularies, and different upgrade cycles.
This gap is not a failure of competence. IT teams are competent. Library staff are competent. The gap is structural — it exists because the responsibilities were never formally bridged.
Repositories that maintain their quality over time tend to share a few characteristics:
Before recommending any intervention, we assess. A diagnostic tells us the current state of a repository across technical, metadata, and operational dimensions. It produces a written report and a prioritized roadmap — not a sales pitch for the next service.
Many institutions find that the diagnostic itself is clarifying. It gives IT and library staff a shared vocabulary and a common picture of the system they’re both responsible for.
If your repository has been running for more than two years without a formal review, it is worth examining. The problems are usually fixable — but only once they’re understood.