Dieser Beitrag wurde ursprünglich Englisch auf der privaten Website unseres Autors veröffentlicht: https://sites.google.com/view/alex-miklashevsky/for-students-and-colleagues/osf-alternatives-to-publish-projects
Für die Version auf diesem Blog haben wir den Beitrag übersetzt und ein Bild und weitere Links hinzugefügt.
Seit langer Zeit nutze ich das Open Science Framework (OSF), um mit Co-Autoren an einem Projekt zusammenzuarbeiten und später die daraus resultierenden Datensätze und den Code zu veröffentlichen. Es war ein zuverlässiger Bestandteil meines Arbeitsablaufs – eines dieser Tools, über die man gar nicht mehr nachdenkt, weil sie einfach funktionieren. Ich habe fast 20 Projekte auf OSF, die auf diese Weise organisiert sind.
Das wird sich ändern. Ab November 2026 wird OSF diese Funktionalität nicht mehr unterstützen. Für diejenigen unter uns, die ihre Open-Science-Gewohnheiten darauf aufgebaut haben, lohnt es sich, sich jetzt einen Moment Zeit zu nehmen, um eine neue Heimat für diese Arbeitsabläufe zu finden, anstatt später in Eile nach einer Lösung suchen zu müssen.
Nachdem ich mich umgeschaut habe, habe ich mich für eine Kombination entschieden, die denselben Bereich abdeckt: GitHub für die Zusammenarbeit während des Projekts und Zenodo für die langfristige Archivierung und Zitierung, sobald es abgeschlossen ist.
GitHub übernimmt die Aufgaben, bei denen OSF früher im Alltag geholfen hat – Versionskontrolle, Zusammenarbeit mit Co-Autoren, Nachverfolgung von Änderungen im Verlauf des Projekts. Zenodo knüpft dort an, wo GitHub aufhört: Es archiviert einen Momentaufnahme Ihrer Arbeit, weist ihr eine DOI zu und macht sie zu etwas, das zuverlässig zitiert werden kann.
Ich habe eine Schritt-für-Schritt-Anleitung zur Einrichtung zusammengestellt, die ich gerne weitergebe, falls sie nützlich ist.
Workflow: Private GitHub-Zusammenarbeit → Manuelle Veröffentlichung auf Zenodo
Eine Schritt-für-Schritt-Anleitung für die private Zusammenarbeit mit einem kleinen Team an Code, Daten und Dokumenten sowie die anschließende Veröffentlichung aller Inhalte auf Zenodo mit einer DOI nach Abschluss des Projekts.
Phase 1 – Einrichten des privaten Arbeitsbereichs
Erstellt ein privates GitHub-Repository.
Geht zu GitHub → Neues Repository → stellt die Sichtbarkeit auf „Privat“ ein. Gebt ihm einen klaren, aussagekräftigen Namen (ihr könnt ihn später bei Bedarf umbenennen).
Fügt Eure Mitwirkenden hinzu.
Repository → Einstellungen → Mitwirkende → fügt jede Person über den GitHub-Benutzernamen oder die E-Mail-Adresse hinzu. Private Repositories unterstützen eine unbegrenzte Anzahl von Mitwirkenden bei kostenlosen Konten.
Richtet von Anfang an eine logische Ordnerstruktur ein.
Plant das jetzt – es spart später Arbeit, da Ihr genau diese Struktur später komprimieren und auf Zenodo hochladen werdet. Ein gängiges Layout:
project-name/
├── README.md
├── LICENSE.txt
├── code/
├── data/
│ ├── raw/
│ └── processed/
├── docs/
└── results/
Erstellt sofort eine README.md-Datei, auch wenn sie nur kurz ist. Haltet den Zweck des Projekts, die Mitwirkenden und die Struktur der Ordner fest. Ihr werdet diese Datei vor der Veröffentlichung noch erweitern.
Phase 2 – Arbeiten am Projekt
Führt regelmäßig Commits mit klaren Nachrichten durch. So erhaltet Ihr einen vollständigen Versionsverlauf, falls später etwas rückgängig gemacht oder überprüft werden muss.
Denkt an große Dateien. GitHub hat eine feste Obergrenze von 100 MB pro Datei. Wenn Ihr größere Datendateien habt, habt Ihr folgende Möglichkeiten:
Speichert sie während der Arbeitsphase außerhalb von GitHub (z. B. auf einem institutionellen Speicher oder einem gemeinsamen Laufwerk) und fügt sie am Ende zum Zenodo-Upload hinzu, oder
Verwendet Git LFS (Large File Storage), wenn Ihr sie ebenfalls unter Versionskontrolle stellen möchtet – beachtet dabei, dass LFS eigene kostenlose Speichergrenzen hat.
Haltet das Repo durchgehend privat. Nichts muss öffentlich sein, bis Ihr zur Veröffentlichung bereit seid – Ihr könnt es später unabhängig davon öffentlich machen, wenn Ihr auch eine live durchsuchbare Version wünscht, oder es für immer privat lassen und nur den Zenodo-Snapshot veröffentlichen.
Phase 3 – Vorbereitung auf die Veröffentlichung
Führt eine abschließende Bereinigung durch.
Entfernt temporäre Dateien, Entwürfe, `.DS_Store`, `__MACOSX`, `.Rhistory` oder andere überflüssige Dateien.
Stellt sicher, dass Datei- und Ordnernamen klar und einheitlich sind.
Vergewissert Euch, dass die Ordnerstruktur auch für jemanden außerhalb des Projekts verständlich ist.
Stellt die README-Datei fertig.
Fügt Folgendes hinzu: Projekttitel, kurze Beschreibung, Autoren (wenn möglich mit ORCID-IDs), Informationen zur Ordnerstruktur, Software-/Paketvoraussetzungen und Angaben zur Zitierweise.
Fügt eine LICENSE-Datei hinzu.
Wählt eine für Euer Material geeignete Lizenz aus (z. B. CC0 oder CC-BY für Daten/Dokumente, MIT oder GPL für Code). Zenodo ermöglicht es zwar auch, eine Lizenz in den Metadaten festzulegen, aber es ist ebenfalls empfehlenswert, eine Lizenz in die Dateien selbst aufzunehmen.
Entscheidet, wie Ihrdie Einreichung aufteilen möchtet.
Ihr könnt alles als ein einziges Paket veröffentlichen oder in logische Einheiten aufteilen (z. B. einen Zenodo-Eintrag für Code, einen für Daten) und diese in den jeweiligen README-Dateien miteinander verlinken. Ein einziges Paket ist einfacher; eine Aufteilung ist sinnvoll, wenn Code und Daten unterschiedliche Lizenzen haben oder wenn die Daten deutlich umfangreicher sind als der Code.
Phase 4 – Dateien verpacken (Zenodo unterstützt keine Ordner)
Komprimiert jedes Element auf oberster Ebene, das Ihr als Ordner beibehalten möchten, in eine ZIP-Datei.
Die Upload-Oberfläche von Zenodo ist flach – sie behält die Unterordnerstruktur für einzeln per Drag & Drop hochgeladene Dateien nicht bei. Um Eure Struktur beizubehalten:
`code.zip` → enthält den vollständigen Ordner `code/` mit seinen Unterordnern
`data.zip` → enthält den gesamten Ordner `data/` mit seinen Unterordnern
Lasst die `README.md` und `LICENSE.txt` unkomprimiert auf der obersten Ebene, damit sie sofort sichtbar sind, ohne dass etwas heruntergeladen werden muss.
Überprüft den Inhalt der ZIP-Dateien vor dem Hochladen – öffnet jede ZIP-Datei und vergewissert Euch, dass die Ordnerstruktur korrekt ist und sich keine unerwünschten Dateien eingeschlichen haben.
Phase 5 – Auf Zenodo veröffentlichen
Meldet Euch bei zenodo.org an (sowohl die ORCID- als auch die GitHub-Anmeldung funktionieren).
Klickt auf „New Upload“.
Ladet Eure Dateien hoch – die ZIP-Dateien sowie die separaten README- und LICENSE-Dateien. Zenodo unterstützt in der kostenlosen Version bis zu 100 Dateien und insgesamt 50 GB pro Upload.
Gebt die Metadaten sorgfältig ein:
- Titel
- Autoren (fügt Eure ORCID-IDs hinzu – dadurch wird der Datensatz mit Eurem Forscherprofil verknüpft)
- Beschreibung (kann der README-Datei entsprechen)
- Lizenz
- Schlagwörter
- Verwandte Identifikatoren, falls relevant (z. B. Link zur DOI eines Artikels oder zur zugehörigen Code-/Datenhinterlegung, falls Ihr diese getrennt habt)
Speichert den Eintrag zunächst als Entwurf, wenn Ihr eine abschließende Überprüfung wünscht, oder veröffentlicht ihn direkt, wenn Ihr sicher seid, dass er fertig ist.
Klickt auf „Veröffentlichen“. Ihr erhaltet umgehend einen permanente DOI.
Phase 6 – Nach der Veröffentlichung
Fügt das DOI-Logo bzw. den DOI-Link wieder in Eure GitHub-README-Datei (und/oder Eure Arbeit) ein, damit Leser zwischen dem aktiven Repository und der archivierten, zitierfähigen Version hin- und herwechseln können.
Entscheidet über das weitere Schicksal des GitHub-Repositorys:
- lasst es dauerhaft privat oder
- macht es separat öffentlich, wenn Ihr auch eine aktive, durchsuchbare und forkbare Version wollt – dies ist optional und unabhängig vom Zenodo-Eintrag.
Für zukünftige Aktualisierungen: Veröffentlicht eine neue Version desselben Zenodo-Eintrags, anstatt einen neuen Eintrag anzulegen. Diese erhält einen eigenen versionsspezifischen DOI, bleibt aber unter einem gemeinsamen „Konzept-DOI“ verlinkt, der immer auf die aktuellste Version verweist.
Weiterführende Informationen zu den anstehenden Änderungen bei OSF
OSF - Open Science Framework: https://osf.io/
OSF announcement - OSF is Changing: https://www.cos.io/osf-changes
OSF Support - Projects Transition: https://help.osf.io/article/727-osf-projects-transition