Thoughts on the new Xymon organization - feedback appreciated

Hi all,

First of all, many thanks to everyone involved in the new Xymon organization and the recent work around the project. A lot of effort has clearly gone into modernizing and stabilizing the codebase while still preserving the spirit and simplicity of Xymon.

1. The new governance model is a very positive step for the project:

The fact that at least two people are now involved in validating and merging changes gives much more legitimacy and long-term stability to the project. It certainly slows things down a bit, but for infrastructure software this is probably the correct tradeoff. It reduces the risk of unilateral decisions and helps keep the technical direction coherent.

2. The modernization effort is also going in the right direction.

One major goal of the new organization is bringing Xymon back to a stable and maintainable upstream state, while progressively reintegrating improvements that historically existed only in downstream FreeBSD and Debian repositories (and some in the 4.4 alpha branch).

The work achieved so far in this direction is very encouraging. Several important steps have already been achieved:
- GitHub Actions now automatically builds and validates Xymon across multiple platforms,
- many Linux, FreeBSD, NetBSD, and pkgsrc portability and build issues were fixed upstream,
- parser cleanup and hardening improved robustness,
- several memory leaks and stability issues were corrected.

As many changes have already been completed, the project is progressively moving toward a new “ready to release” phase, with a growing number of downstream fixes already consolidated upstream, even if the work is not fully completed yet. It may be better to iterate additional fixes in future releases instead of trying to consolidate everything at once.

This first release will also impact Roland and Mark as Debian and FreeBSD maintainers, so it should happen when they feel ready, as they will also need to prepare and publish updated versions on their side.

Keeping the current focus on reducing historical technical debt and reintegrating long-standing downstream work upstream still appears to be the correct priority for now.

3. That said, there are still some weak points:
- documentation is still fragmented between SourceForge, mailing lists, distro patches, wiki pages, and GitHub discussions,
- the maintainer pool is still relatively small, which can slow reviews and create some continuity risk,
- and the project still lacks a clearly centralized long-term roadmap defining modernization priorities and release direction.

Overall though, the direction feels healthy, pragmatic, and technically credible.

4. It would be very interesting to hear what you think as well:
- What could still be improved?
- What is currently missing?
- How could more people become involved?
- And what should the priorities be for the next phases of the project?

Bruno