Skip to content

Project identity & people

Before anything technical, a software project needs a name, a small set of named people responsible for it, and a clear statement of whether any external regulations apply.

Software title

A title is the public name of the software. It travels everywhere: in citations, in the URL of your repository, in package indices, in pip install <name> commands, in import statements, in slide titles, in Google searches by future users. Renaming later is expensive, and there will be old papers and stale links forever.

A good title is specific, unique, and short:

  • Specific. Someone who has never heard of your project should be able to guess, within one sentence, what it is broadly about. "ALSGenoTyper" tells you something; "Project Phoenix" tells you nothing.
  • Unique. Before you finalize a public name, search the places where collisions may occur: GitHub and GitLab, PyPI, conda-forge, CRAN, Bioconductor, bio.tools, Zenodo, and Google. Generic names, such as "Pipeline", "Tools", "Analyzer", almost always collide and usually with something better-funded than you.
  • Short. Long enough to be informative; short enough to fit on a CLI prompt, in a citation key, and in a project banner.

Common pitfalls worth avoiding:

  • Internal codenames as public titles. An informal working name is fine during development; rename before publishing.
  • Naming after the cohort or department only. "ALS-tool" and "LUMC-Pathology" are hard to disambiguate at scale, even within LUMC.
  • Putting the version in the name. MyTool2, MyToolPro, MyToolFinal. Versions belong in tags, not in names.

If the project might in the future be renamed (this happens), keep the name and identifier layers separate: the GitHub repo URL, the package name, the documentation site, and the DOI on Zenodo are all things that can be migrated cleanly if the title is the only fixed point.

In the Software Management Plan (SMP): the Title field should contain the final public name as it would appear in publications or presentations.

Keywords and discovery terms

Keywords are how people and machines find software they did not already know existed. A good keyword set answers three things: what field is this, what method does it implement, and what biological or clinical context does it apply to.

Prefer controlled terms where they exist. EDAM topics are the standard vocabulary in the life sciences and are what registries such as bio.tools index on. Free-text keywords are fine alongside them, for terms EDAM does not cover: a cohort name, a local platform, an emerging method.

Three rules of thumb:

  • Be specific. "Genomics" alone rarely distinguishes anything. "Variant calling", "long-read sequencing", or "Alzheimer's disease" can be a better fit.
  • Cover more than the method. Include the domain and, where relevant, the organism, tissue, or disease.
  • Use the words your users would search for, not only the ones your field prefers in print.

Keywords also belong in codemeta.json - as keywords for free text, and applicationSubCategory for EDAM topics. See Software metadata.

In the SMP: the Keywords list offers an EDAM topic lookup and accepts free text for terms outside the ontology. Five to ten well-chosen terms are more useful than thirty generic ones.

Authors vs. maintainers

In research software, two roles get conflated and then confused. The SMP separates them deliberately.

  • Authors are people who made scholarly or creative contributions to the software. They go into CITATION.cff, into Zenodo deposits, and onto publications. A reasonable test: would they appear on the paper that describes the software, if you wrote that paper today? If yes, they are authors.
  • Maintainers are people responsible now, for this version: the repository, releases, issue triage, support, and continuity. A maintainer must be reachable; an author from three years ago need not be.

In most projects, maintainers ⊆ authors ⊊ contributors: every maintainer is an author, every author is also (trivially) a contributor, but plenty of contributors (who fixed a typo, opened a useful issue, reviewed a PR) are neither authors nor maintainers.

Why a project needs at least two maintainers

The single most common failure mode of research software is: the only person who knew how it worked left. A second maintainer with repository/admin access can:

  • triage issues while the primary is on leave or no longer at LUMC;
  • review and merge pull requests, so the project is never bottlenecked on one person;
  • keep the project from quietly orphaning when someone moves jobs.

The backup maintainer does not need to be the same person across the lifetime of the project, but at every moment there should be two. If you cannot find a second maintainer at LUMC, consider whether your supervisor or a collaborator with adjacent skills can serve in that role.

ORCID, affiliation, and contact

For every author and maintainer, record at least full name, affiliation, and a contact route. ORCID iDs are strongly recommended as they survive name changes, affiliation changes, and disambiguate people who share names. Zenodo, GitHub, and ORCID can be linked so that a release automatically credits the right people on a Zenodo deposit.

In the SMP: the Authors list captures credit; the Maintainers list captures responsibility. Both will appear in CITATION.cff (see Sharing & licensing). Aim for at least two maintainers.

Funding and project context

Recording the funder, grant number, PI, and internal LUMC project code seems bureaucratic until you need it for a Zenodo deposit, a funder report, or a hand-over.

Where they exist, prefer persistent identifiers over free text: they are unambiguous and machine-readable, which makes funder reports and metadata records easier to generate. Large funders (NWO, ZonMw, Horizon Europe) issue proper identifiers for both the organization and the individual grant; smaller foundations may not, in which case the plain name and grant number are sufficient.

Where to find identifiers:

In the SMP: the Funding section captures funder name, project title (often a working acronym), grant/internal code, and PI(s). Where a funder or organization has a persistent identifier (a ROR ID or Crossref Funder ID), record it alongside the name. Repeat for each distinct funding source. Use the legal-entity name (e.g., "ZonMw", not "ZM"; "Horizon Europe", not "HE").

Regulated software

Your software may be subject to a legal, clinical, institutional, or sector-specific regulatory regime, now or as it develops. Decide early whether it is, and be conservative. Recognizing that a project needs regulatory attention is not the same as claiming it is already compliant.

Common situations at LUMC where this applies:

  • The software is or will be a Software as a Medical Device (SaMD), in vitro diagnostic (IVD) product, or otherwise covered by MDR, IVDR, FDA, or comparable rules.
  • The software is or will be clinical decision support: anything that influences diagnosis, treatment, monitoring, or triage.
  • The software is part of a validated laboratory workflow (ISO 15189, ISO 13485, IEC 62304, ISO 14971).
  • The software runs under departmental SOPs that have regulatory implications.
  • The software falls under NEN 7510 (Dutch information-security standard for healthcare) or comparable institutional security requirements.

A research prototype can become regulated when it starts influencing decisions about real patients. Re-evaluate whenever the project's scope materially changes.

If your software is regulated, the SMP is not a substitute for the regulatory artifacts you will need: IEC 62304 software life-cycle records, ISO 14971 risk file, MDR/IVDR technical file, and so on. Contact Techno Infopoint MDR/IVDR (TIP) (techno-infopoint@lumc.nl) early.

In the SMP: this maps to the regulated-software flag. Answer "Yes" if any regulatory regime applies now or is plausible during the project's lifetime. The SMP captures only the fact that the regime applies; the regulatory documentation lives elsewhere.

Further reading