The RADIUSS project promotes and supports a broad set of open source software developed over many years at Lawrence Livermore National Laboratory (LLNL) for use outside of their primary funding organization and within the broader scientific research community. With these libraries and tools we cover a wide range of features a team would need to develop a modern scientific simulation code, particularly when targeting High Performance Computing (HPC). Each of these products are used in applications that support the LLNL science mission, and will be supported and continuously developed for the foreseeable future. These are not research projects that will simply vanish if a lead developer finds other interests - but well-supported software backed by programs and sponsors, and supplemented with support through the RADIUSS project for broader use and external engagement.
As part of the RADIUSS project, these open source products follow a set of policies and guidelines (listed below) based on best practices for open source development learned and adopted through years of research and development supporting production software running on the worlds largest supercomputers. Some of these policies were derived directly or indirectly from other similar documents 1 2 3 4 listed at the bottom of this page. By sharing these policies publicly, we hope to encourage others to adopt similar standards for the betterment of the open source software community, and welcome a dialogue on where we could improve.
These policies and guidelines are not meant to be a comprehensive set of recommendations for good software quality assurance (SQA) practices (although many of them do promote that). Instead, these are policies that we feel are particularly important for developers of open source software to follow. We strongly believe that open source software will not succeed by just being “put out there”. These policies are our attempt to capture the things we feel are most important to a successful open source project, beyond just good SQA practices that any software engineer would promote.
We intend to continuously evolve these policies and guidelines in the future. In particular, tools mentioned are not eternal and best practices evolve rapidly, demanding flexibility in our approaches. However, we attempted to make these recommendation as generic as possible, so that they could apply to the various types of projects RADIUSS supports, and likewise may serve to others. While we try not to interfere in project’s management, with found it important and relevant to focus our support effort on a subset of fundamental tools, so that knowledge and practices can easily be shared, and for the sake of interoperability.
RADIUSS and the projects it covers are open-source and primarily (or by now, exclusively) use GitHub for repository management. These policies and guidelines are themselves part of the GitHub repository that automates the building and updating of LLNL’s Software Portal, to which you are welcome to submit an issue or pull request to help us evolve these policies.
Headline-only format follows. Click on any header or badge icon for more detailed description
Or try the printer-friendly flat version
New projects must use an OSI-approved, permissive open-source license (e.g., Apache, Apache-2.0 with LLVM exception, MIT, or BSD 3-Clause)
Existing projects should consider moving to an OSI-approved, permissive open-source license for existing projects (e.g., Apache, MIT, or BSD 3-Clause).
Package your installation and provide automated builds of dependencies using Spack.
Compilable projects (e.g. those written in C++ and/or Fortran) must be buildable with CMake.
The source code must be version controlled using Git.