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.

Policies and Guidelines

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.


generic badge Designates a mandatory point (policy).

generic badge Designates a recommended point (guideline).


Headline-only format follows. Click on any header or badge icon for more detailed description

Or try the printer-friendly flat version


Generic badge 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)

Generic badge  Provide a list of dependencies and their associated licenses in SPDX format.

badge  Existing projects should consider moving to an OSI-approved, permissive open-source license for existing projects (e.g., Apache, MIT, or BSD 3-Clause).



Generic badge  Package your installation and provide automated builds of dependencies using Spack.

Generic badge  Compilable projects (e.g. those written in C++ and/or Fortran) must be buildable with CMake.

Generic badge  Provide build options for production (optimized) and debug deployments.



Generic badge  Version number and build characteristics must be easily accessible.

Generic badge  Use a limited, unique, and well-defined symbol, macro, library, and include file namespace.

Generic badge  Use MPI in a way that is compatible with other products.


Version Control

Generic badge  The source code must be version controlled using Git.

Generic badge  Provide a transparent, online contribution process based on pull requests and issues collection.



Generic badge  Publish documentation in a web-based format.

Generic badge  Provide a concise description of the project.

Generic badge  Version control your documentation consistent with and alongside your source code.

Generic badge  Provide a documented, reliable way to contact the development team.

Generic badge  Provide and maintain example source code along with documentation.

Generic badge  Provide a documented policy for handling pull requests from external contributors.


Testing and Continuous Integration

Generic badge  Use regression tests in the development process.

Generic badge  Provide a test suite for verifying correctness of build and installation.

Generic badge  Provide a development test suite along with the source code for external contributors.

Generic badge  Use continuous integration (CI).

Generic badge  Continuously check compatibility with different compilers and versions.

Generic badge  Ensure code quality/health in an automated manner.



Generic badge  Give best effort at portability to common HPC platforms and compiling toolchains.

Generic badge  Support Apple MacOS (Xcode) and Microsoft Windows (Visual Studio).



  1. Better Scientific Software 

  2. xSDK Community Policies 

  3. Smart Libraries: Best SQE Practices for Libraries with Emphasis on Scientific Computing 

  4. Weapons Simulation and Computing (WSC) Software Guidelines (internal LLNL access only)