Reproducibility repositories
Zenodo, Dataverse, Figshare, the code forges, and the Open Science Framework after 2026
This module of the companion curriculum is about the other end of the data exchange from the data sources module, which covers where data are obtained. This one covers where a finished piece of work is deposited so that another person can find it, cite it and re-run it. It sets out what a repository has to do, compares the general-purpose repositories that researchers actually use, and then gives the Open Science Framework (OSF) the long treatment, because the materials of the course are held there, because the preregistration you write in Part 4 is modelled on an OSF registration, and because the OSF is changing at the end of 2026 in a way that anyone learning it now has to know about. The closing sections trace the materials of the course on the OSF, define registrations and forks, introduce the preregistration templates and give a route for depositing a reanalysis of your own.
The module assumes no more than the workshop itself does. It is a natural companion to the git and GitHub module, which is about keeping a history of your own work and collaborating on it, and to the data sources module, which is about the archives at the start of the pipeline. The three modules overlap in places, as they do at the UK Data Service, which distributes the national surveys and also takes deposits of project data, and at GitHub, which is both a working tool and a place where code is found.
1. What a repository does
A folder on a laptop, a departmental server and a link in the appendix of a paper have the same weakness, in that none of them outlasts the person who made it. A repository in the sense meant here does six things that those do not, and the six serve as a checklist for choosing one.
- A persistent identifier. A DOI (digital object identifier) or an equivalent that resolves to the deposit for as long as the repository exists, and that a paper can cite. Zenodo, Dataverse, Figshare and the OSF all mint DOIs; a GitHub repository does not.
- Versioning. A new version gets a new identifier while the old one still resolves, so a reader who followed the citation in a 2027 paper gets what the 2027 paper used.
- A licence. A statement, attached to the deposit, of what others may do with it. CC BY 4.0 is the common choice for data and text, and an open-source licence such as MIT or GPL for code; the licence attached to the underlying data limits what you may deposit at all, as the GESIS-derived data of this course illustrate.
- Metadata. A title, creators, description, keywords, related identifiers and dates, in a form that indexes and catalogues can read. The quality of the metadata decides whether anyone finds the deposit who was not sent the link.
- Preservation. A commitment, usually institutional, to keep the files readable over decades, sometimes certified (the CoreTrustSeal is the certification most social-science archives hold).
- Access control. Public by default, with the possibility of an embargo, a restricted file that is applied for, or a private deposit that only a reviewer can reach through a link.
Repositories come in four kinds, and the guidance written by the Center for Open Science for researchers moving off OSF projects sorts them in the same way: discipline-specific archives (the UK Data Service, GESIS, ICPSR, the Qualitative Data Repository), generalist repositories (Zenodo, Figshare, Dataverse, Dryad), institutional repositories run by universities, and journal-based repositories attached to a publisher. The same guidance recommends a first step: “Talk to your institutional librarian about who should host your data and other research outputs.” Funders and journals increasingly require a named repository, and the ESRC requirement that funded data be offered to the UK Data Service is the UK instance of that.
2. The generalist repositories
| Repository | What it takes | Identifier and versions | Cost | Notes |
|---|---|---|---|---|
| Zenodo | Any research output: data, code, materials, slides, reports | A DOI per version and a concept DOI for all versions | Free, hosted by CERN | Records can be linked to one another as parts of a whole; a GitHub repository can be set to archive each release automatically, which is the standard way of giving code a DOI |
| Harvard Dataverse and the other Dataverse installations | Datasets with their documentation; collections nest, so a project can be a collection with datasets inside it | A DOI per dataset, with versions | Free at Harvard; institutional installations elsewhere | File-level embargo and restricted access; the dataverse R package uploads and downloads by DOI |
| Figshare | Datasets, code, figures, presentations, posters | A DOI per item and version | Free for individuals; many universities run their own instance | Quick to use; the institutional instances are often the university repository under another name |
| Dryad | Data accompanying a journal article, curated | A DOI | A data publishing charge, often paid by the journal or the institution | Curation is what you pay for |
| UK Data Service ReShare | Research data from UK projects, in particular ESRC-funded ones | A persistent identifier and a catalogue record | Free | The route that satisfies the ESRC data policy; the data become part of the national collection and inherit its access tiers |
| ICPSR (openICPSR) | Social and behavioural science data, self-deposited or curated | A DOI | Self-deposit free; curation priced | The US counterpart of ReShare |
| Qualitative Data Repository | Qualitative and multi-method data, with curators who help depositors share sensitive data ethically and legally | A DOI | Typical deposit fees of $750 to $2,500, as quoted by COS; often waived at member institutions | Specialised in interview and fieldwork data |
| The Open Science Framework | Registrations and preprints; until February 2027, projects holding anything | A DOI for public registrations and, on request, for projects | Free | See section 4 |
The comparison rows are drawn from the COS guide on choosing a repository, read on 8 September 2026, and from the pages of the repositories themselves. Which one to use depends on what the deposit is. A dataset that other people should find and reuse goes to the disciplinary archive if there is one (the UK Data Service for a UK project) and to Dataverse or Zenodo otherwise. Code goes to a forge (the next section) with each release archived on Zenodo. A finished report, a set of slides or a preprint of a paper goes to Zenodo or Figshare, or to the preprint server of your field.
3. Code forges
GitHub, GitLab, Codeberg and the self-hosted Forgejo are forges: services that host git repositories with an issue tracker, pull requests, wikis and, in the case of GitHub and GitLab, a great deal else, from continuous integration to website hosting. They are where code is written, reviewed and collaborated on, and the git and GitHub module is about using them for that. They are also where most research code is found, which makes them look like repositories in the sense of this page, but they lack the properties listed in section 1. A GitHub repository has no DOI, can be renamed, transferred or deleted by its owner in a minute, and comes with no commitment to preservation. The remedy is cheap and standard: tag a release on the forge and let Zenodo archive it, which gives the release a DOI that the paper cites while the forge keeps the working copy. Every published version of the course workspace is meant to be archived that way.
4. The Open Science Framework, and what is changing
The OSF, run by the non-profit Center for Open Science (COS), has been the general-purpose repository behind almost all of the materials used in this course. Its help pages describe an OSF project as “a flexible, collaborative workspace where researchers can plan, manage, and share any part of their research lifecycle”, and a component as an “optional sub-project nested within a parent project … used to break a large project into smaller parts”. Projects and components form a tree. Each node has files, a wiki, a list of contributors, storage add-ons that connect to Google Drive or Dropbox or GitHub, and its own privacy setting, and a project can be forked, registered, given a DOI and linked to a preprint. That is the OSF that the literature of the last decade refers to, and that the three nodes behind this course were built on.
4.1 The transition
On 27 August 2026 COS announced that OSF Projects are being phased out, and the help pages set out the timetable. The reason given is financial: keeping the projects workflow running “would require COS to raise approximately $4-5 million each year for the next several years”, which the organisation cannot sustain, so the OSF is being narrowed to the parts where it can do most. Two dates matter.
- From 16 November 2026, “no new projects or child components of existing projects can be created on OSF. All other functions remain the same.” Existing projects can still be edited, files added, contributors changed, until the second date.
- From 19 February 2027, “all OSF projects will be converted into a read-only project.” Content stays viewable and downloadable at the same URLs and DOIs, an administrator can still delete a project or make a private one public, but nothing can be edited, added or uploaded, no new component or fork can be made, and a public project cannot be made private again. Private projects stay available to the people who already have access, and COS says it will give at least twelve months’ notice before removing any of them.
COS also states that “Registrations & Preregistrations and Preprints are unaffected by this change”. Both workflows continue, new registrations can be created, and the community-run preprint servers hosted on OSF Preprints keep running (the generalist OSF Preprints server itself has been closed to new submissions since 25 August 2025, with the existing preprints kept). Public projects remain “accessible indefinitely as read-only records”, their DOIs “continue to resolve indefinitely”, and OSF Search still finds them. COS summarises what the OSF becomes as “a free, open-source platform for creating and linking transparent research records”, built around registrations, preprints and links to outputs held elsewhere. The FAQs add that the registration and preprint workflows “are not meant as replacements for Project storage”, and that “Registrations are designed to document and share preregistrations, study plans, and similar practices. You should identify a data repository for sharing data, materials, and other supplements.”
For someone with an existing project, the guidance is to do nothing if the project is a finished public record: “If your public Project does not need further updates, we strongly recommend that you take no action”, because moving a deposit that already has a DOI risks a second DOI for the same work and a split citation record. An active project should be moved to a repository suited to its content before February 2027, with the OSF DOI or URL redirected to the new home through the redirect request, which only an administrator of the project can submit. A private project should be exported or made public. The COS guide on replicating a project structure maps the OSF tree onto the alternatives: on Zenodo, one record for the former top-level project and one for each substantive component, linked through the “Related works” fields as parts of a whole; on Dataverse, a collection for the project with a child collection for each component and a dataset for each folder.
4.2 Working on the OSF from 2027
For a new piece of work, the registration is the record: a frozen, time-stamped document of the plan, created directly on OSF Registries without a project behind it, using one of the templates (the standard OSF Preregistration, the AsPredicted form, the secondary-data template and a dozen others), kept private under an embargo of up to four years if need be, and given a DOI the moment it is public. Files can be uploaded as part of the submission, within a 5 GB limit, but the data are not meant to be kept there. The data, the code and the materials go to a repository of the kinds described above, and their DOIs are entered in the Resources fields of the registration, which is also what earns a registration its open-practice badges for data, code and materials. A preprint on one of the community servers can point at the same DOIs. The OSF then holds the plan and the links while the deposits are elsewhere, which is the use that registrations were designed for and, after the transition, the only arrangement that the OSF offers for a new piece of work.
5. The course materials on the OSF
Three nodes in the OSF tree contain the materials of the EU-frames case, and all three are public projects, which means that from 19 February 2027 they are read-only records at the same addresses.
osf.io/8rtwe – the official Multi100 archival record. The component that the Multi100 project preserved for analyst C6HJR: the materials as submitted, frozen and citable. The transition changes nothing about it, since it was already an archive in the strict sense.
osf.io/6zqct – the analyst’s maintained fork, from which the course fetches its data. OSF describes this node as “a public fork” of 8rtwe, maintained by the facilitator for teaching. It contains a later revision of the analysis script and its exported dataset, revised Task 1 and Task 2 documents, and EUframes_cy.csv in its main folder, which is the file fetched by R/get_data.R in the workspace. After February 2027 it can no longer accept a new file, so the maintained copy of the workspace from then on is the replication-lab repository on GitHub, whose releases are the versions to cite, and the fork on OSF stands as the record of the materials up to that date.
osf.io/h7432 – the full SCORE dossier, one paper put through all three Rs (reproducibility, robustness and replicability). The parent node that contains every reproducibility check made on the case, with one component per check.
| Component | What | Outcome |
|---|---|---|
whp4b |
Original materials collected by the Center for Open Science | View-only |
cf8en |
Author-provided code – two Stata do-files, supplied on request; a statement by the original author (OA) records that the data cannot be forwarded and must come from GESIS | Code available, data restricted |
8fwrt |
Power analysis for the replication | – |
ezhcs |
Push-button reproduction, run with OA’s own code | Failed. “The authors used file names that did not correspond with the names of the files available for download. Additionally 16 datasets are listed on the website as being used but the code references 18 files.” |
4rjbf |
Source-data reproduction | ‘Not reproduced’ – the effect size “could not be extract[ed] nor re-calculate[d]” from the source data |
gr8u6 |
Multi100 robustness – five independent reanalysts, including analyst C6HJR whose materials this course reanalyses | All five coefficients negative; partial r from −0.006 to −0.452 |
zt5y2 |
Secondary-data replication – fresh Eurobarometer and Eurostat waves, preregistered, N = 352,114 person-year observations | Not replicated – sign flip. “We found a positive coefficient for unemployment on cosmopolitan framing”: b = +0.002, p = .046 |
That table is what a well-kept repository record lets a reader establish without emailing anyone: a push-button check that failed for a checkable reason, file names that did not match the files; a source-data check on which the reported effect could not be recovered; a robustness check that held the direction while the size moved by a factor of nearly 80; and a replication on new data that flipped the sign. Each verdict can be checked because the materials are in a public tree, and the read-only status that the tree acquires in 2027 leaves that unchanged. Read-only status does mean that a project that is still being revised, as this course is, needs a working copy elsewhere, with the frozen record pointing to it.
Open osf.io/h7432 and find the zt5y2 component in the table above. Locate the sentence reporting the sign-flipped coefficient in the materials of that component, and note the exact figures: the coefficient, its standard error, and the significance level. This is the scavenger task set in the OSF segment of Part 4. After February 2027 the page will look the same, but nobody will be able to add to it.
6. Registrations, forks and archives
Three pieces of vocabulary from the OSF are needed for the rest of this module, and all three survive the transition, one of them in changed form.
A registration is “a frozen version of your project that can never be edited or deleted, but you can issue a withdrawal of it later”, time-stamped and given its own permanent identifier. This is the mechanism behind preregistration: it captures a study plan before the data are seen, or, for a reanalysis of existing data, before the specific analytical choices are made, so that the plan cannot later be quietly rewritten to fit the result. A public registration receives a DOI automatically, and an embargoed one stays private for up to four years. A registration can be updated through a transparent update that records what changed and why, and it can be withdrawn, which removes its contents but keeps the metadata and the justification. The Multi100 reanalysts worked from a registered protocol of this kind, which is why their five results can be compared on equal footing. From 2027 a registration is created directly on OSF Registries, without a project behind it.
A fork, in the git sense that the git and GitHub module uses, is your own editable copy of someone else’s repository, kept separate so that you can change it without touching the original. The OSF had the same operation for projects, and “a public fork” is what OSF calls osf.io/6zqct. After 19 February 2027 no new fork can be made on the OSF, so forking remains available only on the code forges.
An archive freezes materials and a registration freezes a plan, and the difference is what allows the date of a plan to be compared with the date of a result. The archival record at 8rtwe and the Multi100 protocol are the two halves of that comparison for this case.
7. Preregistration templates
The earlier sections were about materials that other people deposited and the protocol that the Multi100 team registered on the OSF before its analysts ran their reanalyses. This section is about writing your own plan, which Task 5, in Part 4 of the workshop, asks you to do by completing the preregistration block of your report before you run your chosen specification.
An OSF registration is the general mechanism. What varies between registrations is the template, the fixed set of questions that a researcher answers before the data are touched. OSF Registries hosts more than a dozen, built for different kinds of study, and two of them are described here.
The AsPredicted-style short template. Built by the team behind AsPredicted.org and available as one of the registration forms on OSF, this is the simplest entry point and the form on which the preregistration block of Task 5 is modelled. It asks a short, fixed sequence of questions – about the hypotheses, the key variables and analysis, how the sample will be determined, and what would count as excluding data – each answered in a sentence or two. For a workshop its brevity is the advantage, since a participant with no experience of preregistration can complete it in the time that Part 4 sets aside. What it demands is also what a longer template demands, namely that the analysis is stated before it is run, in a form specific enough that it cannot be reinterpreted afterwards.
The secondary-data template (van den Akker and colleagues). A short-form template written for a study whose data have not yet been collected assumes that the researcher has not yet seen the data, which is not true of this course. A reanalysis of an existing public dataset breaks that assumption from the outset. You can see summary statistics, published tables and other researchers’ results before you fix a specification of your own in a preregistration. Van den Akker and colleagues’ template is built around that difference. Where a fresh-data template asks what you will collect and how, a secondary-data template asks what you have already seen and what you have not: which parts of the dataset or its published results you have been exposed to, whether your hypothesis was formed before or after that exposure, and what remains genuinely undetermined about your analytical choices at the point of writing the plan. For a Multi100-style robustness reanalysis this is the more accurate match for what preregistration can promise, which is not that you approached the data blind but that your specific choices were fixed and dated before you ran them.
How the preregistration block of the course maps onto these. The block that you complete in Task 5, in Part 4, has the structure of the AsPredicted form, a small number of short and specific questions, adapted for a specification-menu reanalysis rather than a fresh study. Instead of a hypothesis and a test, it asks you to state your chosen specification, one choice on each of the fourteen axes of the specification menu across Levels 1, 2 and 3, and to justify it against the estimand and the graph you built earlier in the day. It is the lighter of the two templates because the time available in Part 4 favours a form that can be completed and rendered within a set slot. The secondary-data template is the take-home reading for anyone who wants to see how the same discipline scales up to a plan detailed enough to submit as a real registration.
Read the question list of the AsPredicted template at aspredicted.org and, separately, skim the structure of the secondary-data template. For a single specification that you might choose from the specification menu – say the positive composite as outcome, the raw unemployment rate, two-way fixed effects, all years and no weights – write one sentence answering the central question of the secondary-data template in your own words: what, if anything, had you already seen of the results on this claim before settling on that specification? A preregistration constrains your analysis only when that answer is truthful and the plan that contains it is dated before the specification is run.
8. Depositing a reanalysis of your own
Put together, the sections above give a route for a reanalysis like the one you build on the day, written so that it works after the OSF transition as well as before it.
- The code goes on a forge. Put the report, the scripts and the codebook in a git repository on GitHub or an equivalent, with a licence file and a README that says what the repository is and how to render it. The git and GitHub module takes you from nothing to that point.
- Each version is archived with a DOI. Tag a release on the forge and let Zenodo archive it, so that the version you cite in a paper is the version that a reader gets. The concept DOI covers all versions, and the version DOI is the one to cite in the paper.
- The data go where their licence allows. Derived aggregates that you are free to share go with the code or into Dataverse or ReShare with a citation of their sources. Licensed microdata, such as the Eurobarometer files, never leave your machine, and the README says how a reader obtains them from the archive, as the data sources module sets out for this case.
- The plan goes on the OSF. Create the registration on OSF Registries before the analysis runs, with the secondary-data template or the AsPredicted form, and put the DOIs from steps 2 and 3 into its Resources fields. Keep the embargo short, or do without one.
- The report is part of the release. Render it to HTML or PDF and include the rendered file in the tagged release, so that the numbers that a reader sees are the ones that the code produced on the day you released it.
- Cite the data sources properly. Give the citation that the archive provides for each survey wave and indicator, with the download dates, in the report and in the repository metadata.
A reanalysis deposited that way has a public plan with a date, a public record of the code and results with a version, and a stated route to the data it cannot include. The SCORE checks in section 5 needed a record of this kind from the original paper and did not always find one.
Sources and attribution
The definitional material on OSF projects, components, registrations and forks quotes the OSF help pages (https://help.osf.io), linked in place where the quotations appear. The transition timetable, its rationale and the guidance on what to do with existing content are quoted from the announcement by the Center for Open Science, OSF changes, and from the help articles OSF Projects transition, Details of the OSF Projects transition, the transition FAQs, Choosing a repository, Replicate your project structure in other repositories, Redirect my DOI or URL and the Registrations guide, all read on 8 September 2026. The suspension of the generalist preprint server is from the corresponding help category. The three OSF nodes, the component table and the mapping from the course block onto the two templates are the worked example of this course, drawn from the data codebook, the OSF nodes themselves and the facilitator’s notes; the quotations from the component reports (ezhcs, 4rjbf, zt5y2) are reproduced as they appear in those components. COS releases changes monthly, and the dates above are the ones announced, so check the announcement page before relying on them.