FAF Software Guidelines

Requirements

The requirements for the FAF system landscape result from the following conflicting objectives:

1. FAF is based on donations. Therefore any software used must either be free software or the producer must grant a free license for FAF as an open source project.
2. FAF should be a central platform. Therefore we try to avoid dependencies to third party services, but rather integrate them into our system landscape - if possible (examples: Replay-Parser, UnitDB).
3. FAF has only a few core developers and even fewer administrators. Every additional service ties up administrator capacities. Every self-developed software binds developer capacities. From this follows:
   1. Recurring tasks must be automated as soon as possible
   2. The FAF infrastructure should always be reproducible with as little effort as possible. This enables automated tests and a simple environment for newcomers.
   3. Readability and maintainability are more important than performance.

For software development this means the following:

1. If possible, new problems should be solved with standard software. Standard software is well tested, well documented and should therefore be easy to use.
2. If there is no suitable standard software, it should be checked whether standard software can be adapted, e.g. with plug-ins.
3. If this is also not possible, an own development may be necessary. In this case, programming languages should be used which are mastered by the FAF core developers (currently these are preferably Java and Python).
4. If a service is hardly used, it will be switched off sooner or later.

The same applies to faf-stack services:

1. If possible we use Docker images from the manufacturer and configure them. If available, we use LTS versions.
2. Only if the original manufacturer does not offer a docker image, third party providers should be used.
3. Only if this is also not possible, we build our own (or fork from existing). This must be done in a separate Git repository with proper versioning.