Which Data Repository Should You Use?

The Center for Open Science has announced that from November 16, 2026, no new projects can be created on the Open Science Framework. After February 19 all projects will become read-only, and eventually, they anticipate that all private projects will be deleted. The OSF has raised a generation of scientists that is able to practice open science. These scientists will need to take these skills to a new data repository in the future.

 

Choosing a New Data Repository

 

There are many data repositories, each with their own strengths and weaknesses. Before I compare them, I want to make it clear that the fact that organizations are willing to store your data for free for a very long time is an amazing service. You should be incredibly grateful that any and all of these services exist. As someone who had a free Hotmail email account in 1997 with 2 mb of free storage, the fact that we can now store up to 50GB for every project we create in a data repository blows my mind.

Some common data repositories used in psychology are Zenodo, GitHub, ResearchBox, Dataverse, and PsyArchives. I will compare these services on properties that I think are important.

1. Longevity

We are all grains of sand in the desert of eternity. Nothing lasts forever. But it would be nice if our data repositories will keep going for a while. Zenodo is hosted by CERN and commissioned by the European Commission through the OpenAIRE project. CERN has been around since 1954, and it will be around well until anyone who will ever read this is dead. GitHub is too big to fail, and was bought by Microsoft in 2018 for 7.5 US billion. It will be around for a while. PsychArchives is hosted by ZPID, which started in 1971, and which will be around for a while. The first Dataverse repository was hosted by Harvard in 2006. Dataverse is not a single repository. For example, Harvard Dataverse and DataverseNL are different instantiations of the service. The Open Science Framework started in 2013 and is hosted by the Center for Open Science. ResearchBox started in 2020, and is hosted by the Wharton Credibility Lab, and funded by the Wharton School of the University of Pennsylvania.

Predicting the future is notoriously difficult. I think the order in which I discussed the platforms is also the order in which I would rank their longevity, but I would not dare to give a number on how long each service will last. As the team behind ResearchBox explains, they set up the system to minimize misuse, but their costs will continue to grow, especially if more researchers start to use the platform. I would guess that for the next decade, all these services are likely to continue to exist, and the ones earlier in the list will continue to exist for a long time. Note that data hosted on these platforms will continue to exist in any case. ResearchBox uses Zenodo as one of its long term back-up solutions.

2. API

Although you might think that data re-use will mean that a person will browse through your data, data and code sharing is done as much for re-use by people, as re-use by machines. To enable re-use by machines, platforms need a good API (Application Programming Interface). GitHub, Zenodo, and Dataverse have good APIs. The OSF has a usable API, but it is not well-designed, and requires some effort to use. PsychArchives has an API, but it is hidden – it is not documented, so if you want to use it you have to discover it yourself. This is suboptimal. There is an additional challenge for PsychArchives: While public files on PsychArchives can be downloaded automatically, files shared under more restrictive licenses can be downloaded manually, but not by software.

ResearchBox has no API. This is the biggest weakness of ResearchBox, and it is serious enough such that it prevents me from recommending ResearchBox as the main alternative for people looking for a new data repository. ResearchBox can make an API, and if it does (and it does it well) the platform is an excellent alternative to the OSF. But currently, software can’t automatically interact with (e.g., download from or upload to) ResearchBox, and this is a problem for re-use. It is possible to scrape the ResearchBox website, but this breaks too easily and is not a long-term solution.

Dataverse is open-source repository software rather than a single service: it is run independently by many institutions (e.g., Harvard Dataverse, DataverseNL, and various university-hosted installations), each on its own domain. They all have the same API, but a tool first needs to recognize which of the many independent Dataverse installations a given link belongs to. It is possible to work around this if one has a list of all Dataverse repositories, but it adds complexity that is not present for all other services.

3. Metadata

Metadata might be a bit boring, but it is how re-users will find your data and code when they are not approaching it through a link in a paper. That makes it very important (but boring).

On the OSF, a project (or component) carries a title, a description, a controlled `category` (e.g., project, data, hypothesis, methods and measures, software), an optional custom citation, free-form tags, a license, a discipline classification from OSF's own subject taxonomy, and contributors. This is rather limited as we will see compared to other repositories. When it comes to metadata, there is a lot to gain by using other repositories.

Zenodo's metadata model is richer and more structured for citation purposes: alongside title, description, and creators (name, affiliation, ORCID, GND), a deposit requires an `upload_type` (e.g., publication, dataset, software, poster) and, for publications, a `publication_type` (e.g., journal article, preprint, report, thesis). It also supports free-form keywords, and a controlled `access_right` (open, embargoed, restricted, closed) with an associated license or embargo date. It also has `related_identifiers` linking the deposit to other DOIs with a typed relationship (e.g., isSupplementTo, cites, isNewVersionOf). You are not as excited about this as you should be. Links between files matter a lot in understanding what files are, and how they can be re-used. There are also `contributors` (e.g., DataCurator, Supervisor, RightsHolder) distinct from creators, and `grants`, which link the deposit to a funder-registered grant ID so it appears in that funder's own reporting.

Dataverse is even better when it comes to metadata, and it places strong emphasis on structured, repository-level metadata that supports discovery, citation, and interoperability. Each dataset is described through a citation metadata block containing fields such as title, author, contact, description, subject classification, keywords, producer, distributor, publication date, and related publications. Dataverse repositories can also enable domain-specific metadata schemas, including social science, geospatial, life science, and astronomy extensions, allowing much richer description than a generic file upload. In addition, datasets receive persistent identifiers (typically DOIs), versioning metadata, and machine-readable metadata exports in standards such as Dublin Core and DataCite, facilitating integration with external discovery services and repository networks.

PsychArchives follows a metadata model designed around the needs of psychological science and the FAIR principles. Deposits are assigned DOIs and can represent a wide variety of digital research objects, including articles, preprints, datasets, code, preregistrations, tests, and multimedia content. Metadata record fields support detailed descriptions of authorship, affiliations, object type, publication status, licensing, keywords, and links between related research outputs from the same study. Because PsychArchives is embedded in the ZPID ecosystem, metadata are also optimized for indexing by services such as PsychPorta, Google Scholar, and other scholarly discovery systems. The repository's emphasis is not only on describing objects individually, but also on connecting related outputs into a coherent research record. Once again, you are not as excited about this as you should be, but knowing a dataset belongs to a supplement that belongs to a paper is something we all want even if we do not realize it.

ResearchBox takes a somewhat different approach to metadata, prioritizing usability and transparency of research materials by people who browse the website over highly formalized archival description. Public deposits are organized into standardized "Bingo Tables" that indicate which research components are available, such as preregistrations, materials, datasets, code, and manuscripts. ResearchBox automatically generates dataset codebooks and supports searching within datasets, variable descriptions, and code files, making metadata partly file-derived rather than solely author-supplied (this is very good, and something other repositories can learn from – I strongly believe that if we ever have FAIR metadata, it is because most of it is automatically generated). As there is no API, this metadata can only be searched manually on the website, which is the biggest limitation of ResearchBox.

4. Anonymous Peer Review

Many journals still value and require anonymous peer review. PsychArchives, ResearchBox, and the OSF make it possible to share an anonymous link to the datafiles for peer review. GitHub repositories can be made anonymous for blind peer review through https://anonymous.4open.science. Zenodo allows users to create a new upload in Zenodo, keep it private, fill in the metadata while not disclosing any personal information, and without publishing the record, click Share, Links, and create a secret link with the permission that people with the link "Can preview draft". This allows reviewers to access the unpublished draft, while the files remain invisible to the public. Dataverse offers a similar but more automated solution: from an unpublished draft dataset, selecting Edit, then Preview URL, offers a choice between a "General Preview URL" (a secret link giving access to the draft, comparable to Zenodo's) and an "Anonymous Preview URL". The anonymous option automatically strips author names and other identifying information from the citation, version history, and metadata fields before showing the page to anyone holding the link, rather than relying on the depositor to avoid entering identifying information in the first place.

All platforms allow anonymous access to files, but ResearchBox, OSF, and PsychArchives make it really easy. Dataverse accommodates it well, it takes some getting used to on Zenodo, and it is hacky but possible on GitHub.

5. Usability

When it comes to data sharing platforms, they need to excel at two things. First, it should be easy to upload and share data, and second, others should be able to find and download the data. One of the continuing complaints about the Open Science Framework was that the user experience got in the way of data sharing and re-use. When it comes to sharing your data, ResearchBox and PsychArchives offer a much smoother experience for users who want to manually upload files, and especially ResearchBox cares a lot about ease of use. Dataverse and Zenodo are also quite intuitive, but a bit more bare-bones and it has some peculiarities we will need to get used to. The biggest is probably that Zenodo does not support folders – all files are uploaded in a flat structure – so users need to learn how to use file names or zip files to organize the files they upload. Using GitHub probably requires a short course, and the biggest difference with other platforms is that you are not supposed to interact with it directly. Instead, you use software (or, if you are a hardcore programmer, the terminal) to push and pull files from the platform.

When it comes to finding files, ResearchBox has the most useful search, as it allows you to search not just for filenames, but also inside data and code files. However, the lack of an API means you can only perform these searches manually, and machines can’t access the file content. This is a major limitation. Dataverse also allows you to search inside tabular data. This means you can search for the word ‘PANAS’ and try to find datasets that have data from the positive and negative affect schedule measure. Dataverse can be searched through an API. All other platforms only allow users to search variable names and metadata.

Personally, although I appreciate ‘first-order’ direct manual usability of a platform, I care a lot more about ‘second-order’ indirect programmatic access to a platform. We will always have different data repositories. If I want to search for datasets that contain the ‘PANAS’ I do not expect that I will visit all repositories one by one, but I will use a search engine that covers all existing databases. Indeed, I am pretty sure that these search databases will have downloaded and processed all files on data platforms using algorithms that extract all data they can from the files. Searches will in the future be performed on a custom database. I also think that we will rely less on the user interface of a website. One thing my master students have recently taught me is that nowadays you ask an AI to create the user interface you want, instead of manually using a website. An example of this for the OSF is BetterOSF by Gilad Feldman. Making a custom interface on top of an existing data repository (or on top of multiple data repositories) is something AI can code for you relatively easily, but it requires the data repository to have a good API.

6. GDPR

As a scientist in the EU, I have to follow the General Data Protection Regulation (GDPR). For fully anonymized data, the GDPR does not apply, and I can store the data anywhere in the world. However, most of my data is pseudonymous. There is a participant ID in the data I share that links the participant to a datafile that is not public, but that is stored in the data archive our department uses to store research data. Even if the shared data has no personally identifiable information, the fact that it is possible to link it to an email address or IP address through the participant number makes the data pseudonymized, and I need to follow the GDPR.

As far as I understand the GDPR, it suggests (as they say, #NotALawyer) that there are routes to sharing pseudonymized data outside of the EU, but either the data repository needs to be Data Privacy Framework certified, or there should be a Standard Contractual Clauses agreement, or I would need to document the procedure for pseudonymization, and formally ask for approval from national supervisory authority, and inform participants about it. Sharing anonymized data on Harvard Dataverse or ResearchBox is easy – sharing pseudonymized data is not easy.

Zenodo is an interesting case, and I learned something new and important while preparing this blog. Cern is located in Geneva, so you might think this makes data storage on Zenodo simple from a GDPR standpoint. But Cern is an international organization with special legal status under international law. It is not subject to the GDPR. CERN instead processes personal data under its own internal framework, which it and Zenodo describe as built to the same standard as GDPR, without being a legal GDPR obligation. This means it is legally not possible to share pseudonymized data with them under the GDPR. They explicitly state they can’t sign data processing agreements. They explicitly say other repositories might be better for data that originated from or contains/ed sensitive personal data. Even though I was not aware of this, and I think I have often heard it said the Zenodo is GDPR compliant, it can’t be, as the GDPR does not apply. This is a weird legal loophole that applies to all International Organizations (this is an interesting discussion).

The easiest way to comply with the GDPR for pseudonymized data is to use PsychArchives or DataverseNL (squarely GDPR compliant, in the EU) – or other local repositories you might have access to (for my own universities, there is the 4TU.Research.Data repository). The downside of this is that research data might become distributed over a large number of local repositories, each with their own rules and standards, which will make it more difficult to automatically find and integrate all data in a field.

Conclusion

We live in a time where you get to pick which service to use to freely store your research data. This is truly amazing, and I am immensely grateful to all the people who have built and maintained these infrastructures. It also means there is something to pick, and that platforms can learn from each other. This is also why ResearchBox gets so many things right – as the newest addition to the data repository landscape, it could learn from and improve on existing repositories. However, they really need an API. Without one, it is difficult for me to recommend the platform, even though it scores at least as well as other platforms on the other dimensions. PsychArchives similarly needs to document their API, and allow programmatic access to files shared under restrictions (some files are publicly available under license restrictions, but can only be downloaded after manually clicking a box).

Dataverse and PsychArchives support metadata in the most systematic manner. Although very few people want to learn about DublinCore metadata standards, people who create data repositories should, and repositories that support these metadata standards will turn out to be more useful a decade from now than platforms that do not. However, as I personally prefer metadata to live as a standalone .JSON file that is shared alongside data (similar to how we now recommend a readme file) I think it is not that problematic if repositories do not follow a metadata standard.

The best choice for a repository also depends on your computer skills. If you interact with the internet by pointing and clicking, you will feel more comfortable on ResearchBox and PsychArchives than on GitHub. But if you interact with the internet through R or Python, you will need to use Zenodo, Dataverse, or GitHub.

If you have pseudonymized, formally Zenodo can’t be GDPR compliant (you either make data anonymous, or switch to another repository). Every make the data fully anonymous (e.g., delete any identifying information, but this makes data provenance more difficult, and is undesirable) or use GDPR compliant data repositories (e.g., DataverseNL, PsychArchives).

It is clear to me that everyone will need to make their own decisions about the repository that is the best fit for their use-case. In my case, I will likely use Zenodo for anonymized data and projects that have code (probably by creating a GitHub release and linking it to Zenodo), and – surprisingly, as I did not expect it when I started this blog post – the local 4TU.Research.Data repository for personal data that needs to adhere to the General Data Protection Regulation.

Coda

When we compare the Open Science Framework against the alternatives, it is clear we are losing an important player in the data repository landscape. It does well in terms of GDPR, has a decent API, and facilitated anonymous peer review. The usability could be better, but for small projects, it worked well enough for me (at least until the last redesign). Big alternative platforms such as Zenodo, GitHub, and Dataverse were around at the same time, but it was the Open Science Framework that managed to convince researchers in the social sciences to share data, code, and materials. That is a huge accomplishment, and if users move on to these other platforms, it is largely because the Open Science Framework got people started in practicing open science.