Project Maintainability Status

Rating: Maintainability Score: X (using A–F scale)

Assessment Summary:

Based on the experience while resolving the following issues in the project:

• Issue 1: Accept empty input source mapping (mapping null)
• Issue 2: Search Process Definition does not filter by version tag (v1 API)

We rate the maintainability of this project as X. The source code is modular and logically separated, but it has changed at a quite fast pace, with many issues being opened every day. There is also some lack of documentation to help new contributors understand the different abstraction levels of the project. This increases the time and effort required to fix the issues raised, especially for the new contributors, but there is strong community support. Below is a breakdown of the maintainability-related knowledge artifacts:

1. Source Code Quality

The project is structured in several modules, which is good since each module isolates different responsibilities. However, it is not clear the responsibilities of each model and how they interact between them. This fact created additional difficulties in understanding what is intended in some of the opened issues since it is not easy to figure out which parts are required to change, despite most of them being labeled with the module where changes might be required.

When comparing with similar frameworks like Flowable, the differences are clear, and we can see that the name of each Flowable module helps new contributors to get the overall picture of the project. So, let's take the DMN modules as an example.

While in Flowable, the modules are well identified, and it is clear where the engine model, API, XML parser, or framework integrations (e.g., Spring) are, as we can see in the following figure.

In Camunda, the modules are not self-explanatory. For instance, the DMN modules are inside the Zeebe, and it looks like this module is only responsible for the workflow part, so that APIs to manage or search for process instances are a part of it, but it is not clear where.

This forced us to perform some reverse engineering to understand some flows so that we could contribute to one of the issues raised.

Besides that, the quality process seems very accurate, with several tests covering the code. It is fair to say that for each contribution, most of the lines of code were adding new test scenarios. At the same time, it looks like the project has a very mature Continuous Integration (CI) pipeline based on GitHub Actions with all the checks running when a pull request (PR) is opened and blocking the merging until all checks are passing.

Some of these checks are important to keep the health of the source code, and since this is an open-source project with many contributors, it is important to ensure that some practices are aligned in terms of:

• Dependency Management
• Code Formatting
• Etc.

2. Documentation

WIP - @Ricardo

3. Community Support

WIP - @Pijus