Moving on from OSF: a simple GitHub + Zenodo workflow 

For a long time, I've used the Open Science Framework (OSF) to collaborate with co-authors on a project and, later, to publish the datasets and code that came out of it. It's been a reliable part of my workflow - one of those tools you stop thinking about because it just works. I have almost 20 projects on OSF organized this way.

That's changing. Starting in November 2026, OSF will no longer support this functionality. For those of us who built our open science habits around it, it's worth taking a moment now to find a new home for these workflows, rather than scrambling later.

After looking around, I've settled on a combination that covers the same ground: GitHub for collaboration during the project, and Zenodo for long-term archiving and citation once it's done.

GitHub handles the parts OSF used to help with day-to-day - version control, working with co-authors, tracking changes as a project evolves. Zenodo picks up where that leaves off: it archives a snapshot of your work, assigns it a DOI, and makes it something people can reliably cite.

I've put together a step-by-step guide on how to set this up, which I'm happy to share if it's useful.

Workflow: Private GitHub Collaboration → Manual Zenodo Publication

A step-by-step guide for working privately with a small team on code, data, and documents, then publishing everything on Zenodo with a DOI when the project is finished.

Phase 1 - Set up the private workspace

Create a private GitHub repository.

Go to GitHub → New repository → set visibility to Private. Give it a clear, descriptive name (you can rename it later if needed).

Add your collaborators.

Repository → Settings → Collaborators → add each person by GitHub username or email. Private repos support unlimited collaborators on free accounts.

Set up a logical folder structure from the start.

Plan this now - it saves work later, since this structure is what you'll zip and upload to Zenodo. A common layout:

   project-name/

   ├── README.md

   ├── LICENSE.txt

   ├── code/

   ├── data/

   │   ├── raw/

   │   └── processed/

   ├── docs/

   └── results/

Start a README.md immediately, even if brief. Note the project's purpose, contributors, and how the folders are organized. You'll expand this before publishing.

Phase 2 - Work on the project

Commit regularly with clear messages. This gives you full version history if anything needs to be reverted or reviewed later.

Keep large files in mind. GitHub has a hard 100MB per-file limit. If you have larger data files, either:

Store them outside GitHub during the working phase (e.g. institutional storage, a shared drive) and add them into the Zenodo upload at the end, or

Use Git LFS (Large File Storage) if you want them version-controlled too, noting LFS has its own free storage caps.

Keep the repo private throughout. Nothing needs to be public until you're ready to publish - you can make it public later, independently, if you also want a live browsable version, or leave it private forever and only publish the Zenodo snapshot.

Phase 3 - Prepare for publication

Do a final cleanup pass.

Remove temporary files, drafts, `.DS_Store`, `__MACOSX`, `.Rhistory`, or other clutter.

Make sure file and folder names are clear and consistent.

Confirm the folder structure makes sense to someone outside the project.

Finalize the README.

Include: project title, short description, authors (with ORCID iDs if possible), how the folders are organized, software/package requirements, and how to cite the work.

Add a LICENSE file.

Choose one appropriate for your material (e.g. CC0 or CC-BY for data/docs, MIT or GPL for code). Zenodo also lets you set a license in the metadata, but including one in the files is good practice too.

Decide how to split the deposit.

You can publish everything as one bundle, or split into logical pieces (e.g. one Zenodo record for code, one for data) and cross-link them in each README. One bundle is simpler; splitting helps if code and data have different licenses or if data is much larger than code.

Phase 4 - Package the files (Zenodo has no folder support)

Zip each top-level piece you want to preserve as a folder.

Zenodo's upload interface is flat - it does not preserve subfolder structure for individually dragged-in files. To keep your organization intact:

• `code.zip` → contains the full `code/` folder with its subfolders

• `data.zip` → contains the full `data/` folder with its subfolders

• Leave `README.md` and `LICENSE.txt` unzipped at the top level so they're visible immediately without downloading anything

Check zip contents before uploading - open each zip and confirm the folder structure looks right and no junk files snuck in.

Phase 5 - Publish on Zenodo

Log in to zenodo.org (ORCID or GitHub login both work).

Click "New Upload."

Upload your files - the zips plus the loose README/LICENSE. Zenodo supports up to 100 files and 50GB total per upload on the free tier.

Fill in the metadata carefully:

• Title

• Authors (add ORCID iDs - this links the record to your researcher profile)

• Description (can mirror your README)

• License

• Keywords

• Related identifiers, if relevant (e.g. link to a paper DOI, or to the paired code/data deposit if you split them)

Save as draft first if you want a final review, or publish directly if you're confident it's ready.

Click Publish. You immediately receive a permanent DOI.

Phase 6 - After publishing

Add the DOI badge/link back to your GitHub README (and/or your paper) so readers can trace between the live repo and the archived, citable version.

Decide the fate of the GitHub repo:

• Leave it private permanently, or

• Make it public separately if you also want a live, browsable, forkable version - this is optional and independent of the Zenodo record.

For future updates: publish a new version of the same Zenodo record rather than a new one. This gets its own version-specific DOI while staying linked under one shared "concept DOI" that always resolves to the latest version.