Policies & Guidelines


Home About Policies


LLNL’s RADIUSS project—Rapid Application Development via an Institutional Universal Software Stack— aims to broaden usage across LLNL and the open source community of a set of libraries and tools used for HPC scientific application development

About RADIUSS

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.


Legend

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.

Licensing

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.

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

Build

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.

Packaging

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.

Documentation

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.

Portability

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).


References