What do we need for most (NOT ALL) commercial modules to work other than IonCube and registration support? Firewall and a few other modules will also need the ability to run hooks.
Give us those three items in a “sysadmin-core” module, and leave all other sysadmin functionality limited to the distro.
Additionally all the F2B code should be re-homed to the FW module (where it should be anyway).
If the non-distro community has sanctioned access to hooks, then an OSS-SA" module would be doable and wouldn’t need Sangoma support.
The question still remains if there is a sufficient profit motive.
I no longer have the code for specifics I can only go off memory. That said I would not be allowed to get any more specific because it is NOT an open source module.
Incrond in Debian (and last I checked pretty much any other current build, including the native CentOS versions) is broken and subject to those race conditions.
Sangoma uses their own build of an older version, 5.10 IIRC. Maybe worth trying to build the distro version from source, or alien the Sangoma rpm.
incrond isn’t even available in Debian Bullseye. I had to install the package from Buster. I don’t know what the modern equivalent to incrond is but it seems that it would be wise to move toward that.
As @jfinstrom suggests systemd path units, or direvent.
Direvent may be the easier drop in replacement. I use it pretty extensively, but the various repo packages for it have issues as well, I build from git. The maintainer quickly responded and fixed reported bugs, but never gave it a new version tag.
Systemd paths have their quirks as well, but would probably be the better option for FPBX overall.
will continue to investigate . . .