Introduction

Webpages on this site concerning management details are taken from the report ref. [3], based largely on the work of Ben Dudson, which presents guidance concerning the mechanics of an opensource development by a community distributed across different sites and organisations, intended to produce software intended for widespread long-term usage. Parts of ref. [3] relate more to the technical specification (TS) and are reproduced in Section 4.2, another part concerns operational aspects (OP), see Section 9.1. Its recommendations are broadly consistent with those laid out by Bungarth & Heister ref. [97], and in particular those for the usage of git conform to practice recommended by the ITER organisation. This document is not the place for a general discussion of software engineering practices, and does not cover code coupling, both of which topics are discussed in the open literature, see in particular Lawrence et al ref. [98] for HPC software engineering and Belete et al ref. [99] for code coupling, also see other NEPTUNE reports, particularly refs. [31, 58, 83].

ref. [3] assumes that all the community has signed up to a “Charter" which for NEPTUNE appeared as report ref. [57], reproduced in Section 7.3. The guidanceref. [3] includes important issues that need to be agreed as early as possible. These include practical points concerning frequency of meetings, code review etc., designed to ensure efficient collaboration between a wide group of project partners. The guidance documentref. [3] also seeks not merely to prescribe, but to give compelling arguments for the choices made in respect of guidelines. Acknowledging the possibility of disagreements, it states that efforts will be made to ensure consensus or at least agreement between the two most affected project partners on any decisions taken. However, in the event of continuing disagreement, the technical leader or ‘Lead’ for the project will ultimately decide on the basis of technical evidence presented, subject to ratification by higher management.

One general rule is always to allow two options (‘rule of two’), intended to enable exploitation and possible incorporation of any promising new software (eg. package, library or language) or relevant algorithm which emerges during the course of the project. Since however, each option doubles the potential cost of developing and maintaining software, a good case must be made to the Lead for a new option, and the innovator include provision for retiring one of the existing options should there already be two. Implicitly thereby, as discussed at the end of Section 4.2, a third exploratory option is also allowed.

A similar recommendation (rather than rule) regarding both code and documentation is to ‘write once, re-use many times’. This to a large extent explains a preference for the lwarp package as enabling multiple reuse of the same text and mathematical expressions in different documents and on different webpages.