Open-source languages
π― Objectives
This page will introduce free and open-source software (FOSS).
- β What is it?: Definition of FOSS.
- π Using FOSS for reproducible analytical pipelines (RAPs): Explaining why FOSS is recommended.
- π» Discrete-event simulation (DES) in FOSS: Describing FOSS options for DES.
- π Further information.
π Reproducibility guidelines
This page helps you meet reproducibility criteria from:
- 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.
π 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 Bronze 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.
SimPy (Python) and simmer (R) were selected for this work because they are the most established, well-maintained, and widely used FOSS DES packages in their respective languages. Both have extensive documentation, active user communities, and proven track records in healthcare and operations research.
π Further information
- βWhat is FOSS?β from FOSS United 2024.