Key Points

Introduction: Software as a Citable Research Output

  • Software is a research output the scholarly system has mostly failed to catch: uncredited, hard to find, and easily lost
  • A GitHub URL is not a citation: URLs rot, pin no version, and give no formal credit, while a DOI is permanent and version-specific
  • Undeposited software has a “bus factor” problem, and forges do shut down, so durability requires archiving
  • FAIR4RS principles (Findable, Accessible, Interoperable, Reusable) provide the framework
  • Making software citable and discoverable centers on a LICENSE, a CITATION.cff file, a release with a DOI, and rich metadata
  • Reproducible environments (“works on my machine”) are the optional final layer
  • You build up your own fork step by step; view-only reference branches show the target state at each stage

Sharing Research Software Effectively

  • Public repositories increase findability, reuse potential, and citation credit.
  • A well-structured repository lowers the barrier for others to understand your work.
  • The lesson begins with a minimal “before” repository that will be incrementally improved.

Choosing an Open-Source License

  • Without a license, software is legally restricted and not reusable
  • BSD 3-Clause is a common default at research institutions; MIT and Apache 2.0 are strong alternatives
  • Permissive licenses (BSD, MIT, Apache 2.0) maximize flexibility and adoption
  • Always consult your institution’s Tech Transfer or IP office before releasing institutionally-owned software
  • GitHub makes adding standard licenses straightforward

Adding a CITATION.cff File

  • A CITATION.cff file is the foundation of software citation.
  • It can be added before releases, DOIs, or version tags.
  • GitHub displays machine-readable citations automatically when this file is present.
  • Start simple and expand over time as your project develops.
  • A citation file is necessary but not sufficient: a release and DOI make the citation durable and tied to an exact version. That is the next step.

Making Your Software Citable

  • Software is citable as soon as it includes a citation file and a stable version.
  • GitHub releases create versioned snapshots for citation.
  • DOIs are optional but strengthen discoverability, persistence, and reproducibility.
  • Zenodo can automatically mint a DOI for each GitHub release.

Improving Metadata and Discoverability

  • Metadata increases discoverability in GitHub, Zenodo, and scholarly indexes.
  • Use consistent information across CITATION.cff, README, GitHub topics, and Zenodo.
  • Thoughtful metadata supports FAIR principles and helps others reuse your software.

Managing Reproducible Environments with pixi

  • Reproducible environments reduce troubleshooting and support more reusable software.
  • pixi provides fast, cross platform environment management.
  • The pixi.toml file acts as documentation that supports citation and FAIR4RS principles.
  • Use pixi run to execute Python or R code inside a reproducible environment.

Wrap-Up and Reflection

  • You’ve successfully made your software FAIR: Findable, Accessible, Interoperable, and Reusable
  • Even small actions can significantly improve your software’s impact
  • Making code citable and discoverable benefits both you and the research community
  • Start with one change, then build from there
  • Use the UC OSPO resources and templates to streamline the process