Open-source languages
Learning objectives:
- Define free and open-source software (FOSS).
- Understand why FOSS is recommended for reproducible analytical pipelines (RAPs).
- Identify FOSS options available for discrete-event simulation (DES) projects.
Relevant reproducibility guidelines:
- NHS Levels of RAP (🥉): Data produced by code in an open-source language (e.g., Python, R, SQL).
❓ What is it?
Free and open-source software (FOSS) is a type of software that anyone can use, change and share with others.
“Free” means you have the freedom to do what you want with the software - i.e. you are free to use, modify and distribute the software. However, “free” in this context refers to freedom, not necessarily price - some FOSS may be sold for a fee, but you still have the rights to use, modify, and share it.
“Open-source” means that the software’s source code is publicly accessible, allowing anyone to look at, change and share it.
Reference: “What is FOSS?”, FOSS United, 2024.
🔁 Using FOSS for reproducible analytical pipelines (RAPs)
Technically, you can build a reproducible analytical pipeline (RAP) using proprietary software. However, FOSS is strongly preferred - and often a requirement (such as in the NHS Levels of RAP Baseline tier 🥉).
This is because there is:
- No licence barriers. Anyone can run and check the pipeline, without needing to buy or manage licences.
- No restrictions on distribution. You can freely share your code and workflow.
- No risk of losing access. There’s no danger of losing the analysis if a company changes its policies or you can’t renew a licence.
- Transparency. FOSS code is always open for inspection. While you can share proprietary code, the underlying software itself is often a “black box,” making full transparency harder to guarantee.
💻 Discrete-event simulation (DES) in FOSS
The two most widely used FOSS programming languages for healthcare DES are Python and R. Within both languages, you can either:
- Build simulations from scratch using general-purpose libraries, or-
- Use purpose-built simulation packages - for example:
Building from scratch offers maximum flexibility and control, but is much more complex, requiring significant time and expertise. You are responsible for thoroughly testing all aspects of your code, including both the core simulation mechanics (such as event handling and resource management) and your specific model logic.
Using a simulation package is often preferable, especially if it is well-established and widely used. Such packages benefit from peer review, community testing, and ongoing maintenance. With a package, the core simulation components should already be well-tested by the package developers and user community, allowing you to focus your testing on your model’s logic. This reduces development effort and the risk of errors. However, it is important to choose a package that is actively maintained, as older or less popular options may become outdated or unsupported.
Which packages have we used?
| Tool | Purpose | Link |
|---|---|---|
| 🐍 SimPy | DES in Python | https://simpy.readthedocs.io/en/latest/ |
| 🧮 simmer | DES in R | https://r-simmer.org/ |
These were selected as they are the most established, well-maintained, and widely used FOSS DES packages in their respective languages, as identified in this article by members of the STARS project team:
Monks, T., & Harper, A. (2023). Computer model and code sharing practices in healthcare discrete-event simulation: a systematic scoping review. Journal of Simulation, 19(1), 108–123. https://doi.org/10.1080/17477778.2023.2260772.
Both have extensive documentation, active user communities, and proven track records in healthcare and operations research.