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 I expect to exist many years from now.
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 data, formally Zenodo can’t be GDPR
compliant (you either make data anonymous, or switch to another repository).
Either 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.