# Dataverse: a research data repository platform with a REST API and a large Java build > Dataverse is the open source platform from Harvard's Institute for Quantitative Social Science for sharing, finding, citing and preserving research data, with a Docker deployment path, a REST API and an unusually visible test and coverage story. This looks at what it is built for and where adopting it lands. **IQSS/dataverse** — Open source research data repository software - Repository: https://github.com/IQSS/dataverse - Website: http://dataverse.org - Stars: 1,077 · Forks: 568 - Language: Java - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/iqss-dataverse ## A repository for research data, not a file store Dataverse is the open source software platform designed for sharing, finding, citing and preserving research data. It was developed by the Dataverse team at the Institute for Quantitative Social Science and by the Dataverse community, and the stated purpose is to make it easy for research organisations to host, manage and share their data with the world. The four verbs in that sentence define the scope, and they are the reason to pick or reject the project. Sharing, finding, citing and preserving are repository features, not storage features. A dataset in Dataverse carries descriptive metadata, it is citable, it is findable through search, and it is kept for the long term. If your requirement is to put files somewhere and read them back, this is the wrong category of software. The platform is a Java application, and the repository is a Maven project with a `pom.xml` at the root, a `src/` tree, a `modules/` directory, a `conf/` directory for configuration, a `docker/` directory, `scripts/`, `doc/` and `tests/`. There are also compose files for development, `docker-compose-dev.yml` and `docker-compose.override.yml`, a `makefile`, and a `renovate.json5` for dependency updates. The frontend lives in a separate repository, which the readme reveals through the logo asset hosted in the `dataverse-frontend` repository. So a Dataverse installation is a Java backend plus a separate frontend project, and that split has consequences for anyone who wants to change the user interface. The default branch here is `develop`, not `main`, which is the convention of a project where releases are cut from a long-lived branch rather than from the trunk. ## Try it before you install it The readme is short, and one of its first sections is an invitation rather than an instruction. The project invites you to explore the demo site at demo.dataverse.org, and describes it as ideal for testing and evaluating Dataverse in a risk-free environment. For a platform of this weight, that is the sensible first step, because the real evaluation questions, how the search behaves, how metadata entry feels to a researcher, how the API responds, are all observable there without an installation. The rest of the documentation lives on the website rather than in the repository, and the readme maps out what is there: an interactive map showcasing Dataverse installations worldwide, a detailed list of features, information on the integrations that have been made possible through the REST APIs, the project board and the development roadmap, and news and events. The map of installations is the piece worth pausing on. It is a factual statement about adoption that a reader can check, and it is a better signal for an evaluator than any claim about market position, because it shows where the platform is actually running and therefore who has already solved the operational problems. For installation, the readme points at the Installation Guide for downloading and installing the latest release, and at the Container Guide for Docker users. It does not document the commands itself, and the documentation site is where they live, which is a sensible division for a project whose install procedure depends on the database and search stack you choose. ## The test and coverage badges tell you more than the readme does The badges at the bottom of the readme are the most informative part of the document, and they describe a testing setup that is unusual in size for a research platform. There is an API Test Status badge pointing at a Jenkins job on jenkins.dataverse.org, for the `IQSS-dataverse-develop` job, and beside it an API Test Coverage badge that points at a JaCoCo coverage report for the same job. Then there is a Unit Test Status badge for the `maven_unit_test.yml` workflow on GitHub Actions, a Unit Test Coverage badge through Coveralls, and a Guides Build Status badge for a Sphinx documentation build. Read together, those are five badges. The API has its own dedicated Jenkins pipeline with coverage measurement, separate from the Maven unit test workflow that runs on GitHub Actions with its own coverage reporting. The documentation is built in CI, which means the guides cannot silently rot against the code. And all of it runs against the `develop` branch, which is where the work happens. The implication for an adopter is that the API is treated as a first class product surface with its own test infrastructure, not an afterthought generated from the internal model. That matters for a platform whose main integration story is the REST API, and it also means the API has a compatibility contract that the project is measuring itself against. The `.readthedocs.yml` file at the root and the `CITATION.cff` file complete the picture: a citation file for the software itself, which is what a research community expects a citable platform to have. ## The community is part of the product For a research platform, the community channels are not decoration, and the readme treats them as a first class section. There is a mailing list on Google Groups, regular community calls to discuss new features, ask questions and share experiences, real time chat on Zulip at dataverse.zulipchat.com, an annual Dataverse Community Meeting for networking and collaboration, and video content on DataverseTV and on Harvard's IQSS YouTube channel. The pattern is the one used by mature open source projects with a governance model: a forum for announcements, a chat for day to day help, a call for agenda items, a yearly meeting for decisions that need a room, and video for people who cannot attend any of it. A research organisation adopting Dataverse is joining that structure, and the question for a technical buyer is whether it wants to participate in it or just consume from it. The development side is equally explicit. There is a project board on GitHub, a roadmap hosted by the Institute for Quantitative Social Science at Harvard, a contributing guide in the repository root, and a code of conduct. The integrations page on the website lists the tooling that has been built on the REST APIs, which is the practical answer to the question of what Dataverse integrates with. ## Where Dataverse is the wrong tool The boundaries are worth being blunt about, because a research data repository is a serious operational commitment. The first is scope, and it is the one to test first. If the requirement is a data lake, an object store, a feature store or a BI tool, Dataverse is the wrong product, because the metadata, citation and preservation model is the point rather than an add-on. The evaluation question is whether the organisation wants to publish datasets with metadata or just store bytes. The second is the operational weight. A Java application server, a relational database and a search index, with a Docker deployment path and a Jenkins pipeline for API tests. The installation guide and the container guide are separate documents precisely because there is a choice to make about how it runs, and the choice has a cost. A team without Java operations experience is taking on more than a static site generator. The third is extension. The readme documents integration through the REST APIs and lists the resulting integrations, and it does not describe an in-process plugin API. For a university that wants a deeply customised repository workflow, the realistic path is to fork the code rather than to extend it through a supported extension point, and that is a maintenance commitment. The fourth is the branch and release model. The default branch is `develop`, the release tags are cut from it as v6.11 in July 2026, v6.12 in September 2026 and v6.12.1 in October 2026, and a release roughly every couple of months means an upgrade cadence to plan for. The readme points at the Installation Guide for the latest release, so the practical advice is to deploy a release rather than the tip of the development branch. ## A custom licence file and a Harvard trademark On licensing, there is a detail to check rather than assume. The readme links the phrase open source to a file called `LICENSE.md` at the repository root, which is the file to read for the actual terms. The repository's own metadata, however, lists the licence as a custom one that GitHub cannot classify, with a pointer to the `LICENSE` file. Those two statements are not necessarily in conflict, since a licence that adds project-specific terms is not classifiable by GitHub's list, but it does mean the file is the only authority, and a project that ships an ECL or a modified Apache or MIT will make the difference visible in the file rather than in the badge. The trademark point is separate and more concrete. The readme states that Dataverse is a trademark of President and Fellows of Harvard College and is registered in the United States. For an institution running its own instance under its own name, that is mostly irrelevant. For anyone considering a fork with a different name, or a white-label deployment, or a derivative product, the trademark line is a real constraint, and it is separate from the copyright licence. The legal information section is one of the last things in the readme, and the position overall is a well known research platform with a permissively styled community licence, an explicitly trademarked name, and an active release line with the most recent tag published on 2026-10-08. ## Conclusion Dataverse fits a research organisation that needs to publish datasets with metadata, citation and preservation, and that wants its repository to be interoperable with other research tooling through a documented REST API. It does not fit a team looking for a general purpose data lake, a file store or a BI tool, because the metadata and citation model is the product. It is also the wrong choice if you cannot run a Java application server, a relational database and a Solr index, or if you need to extend it through plugins, because the readme documents integration through the REST APIs rather than an in-process extension point. Before you commit, try the demo instance at demo.dataverse.org and read `LICENSE.md` together with the trademark statement, since the name itself is a Harvard trademark. ## FAQ ### What is Dataverse used for? Dataverse is an open source software platform for sharing, finding, citing and preserving research data, developed by the Dataverse team at the Institute for Quantitative Social Science and the Dataverse community, so research organisations can host, manage and share their data. ### How can I try Dataverse before installing it? The project invites you to explore the demo site at demo.dataverse.org, which it describes as ideal for testing and evaluating Dataverse in a risk-free environment, before following the Installation Guide or the Container Guide. ### How is Dataverse tested? The readme shows five badges: an API test status and JaCoCo API test coverage on a Jenkins job for the develop branch, a Maven unit test workflow on GitHub Actions with Coveralls coverage, and a Sphinx documentation build in CI. ### What are the licensing terms for Dataverse? The readme links the open source statement to a LICENSE.md file at the repository root, while the licence is listed as a custom one that GitHub cannot classify. The Dataverse name itself is a trademark of President and Fellows of Harvard College, registered in the United States. ### How does Dataverse integrate with other research software? Through its REST APIs. The project website lists the integrations that have been built this way, and the API has its own dedicated test pipeline in Jenkins with coverage measurement, separate from the Maven unit test workflow. ## Sources - [IQSS/dataverse on GitHub](https://github.com/IQSS/dataverse) - [Issues](https://github.com/IQSS/dataverse/issues) - [Project website](http://dataverse.org) - [README](https://github.com/IQSS/dataverse/blob/develop/README.md) - [Releases](https://github.com/IQSS/dataverse/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/iqss-dataverse