I actually sat down and had a conversation with Sangoma on this. Support of 3rd party is definitely part of PBXact but it is conditional. In other words, if you have a 3rd party module you want to use, then either it’s developer or you are expected to provide the muscle to get it working, but Sangoma isn’t going to toss you into the weeds to fend for yourself, either. If you run into trouble they will help, but their support is basically restricted to helping your developer code to the APIs and the FreePBX and Asterisk platform, and repairing those APIs if while in the process of doing this, you find something broken in the implementation.
For example, I have the Open Source Endpoint Manager installed in my FreePBX 17 system, I’ve had it installed for the last year. (I don’t actually use it to provision phones, mainly because after installing it I realized that learning how to use it would represent a lot of work and I had already put in the work to understand how to provision phones manually by modifying .XML so why would I go to the extra effort to figure out the interface to the open source EPM) However, it does “work” insofar that all buttons of the interface work, the interface does not crash, it generates phone files, etc. Sangoma has not gone out if it’s way to cause the interface to break in the last year nor would I expect them to do so - and, if they DID make a change to FreePBX that caused the interface to crash, then I would expect Sangoma to explain what that change was - that’s the support aspect from Sangoma - and that the open source EPM would be modified by it’s maintainer to conform. (or modified by me to conform)
Support of 3rd party modules is always a collaborative effort between the developers of the project and the 3rd party developer. The 3rd party maintainer is expecting the developer of the project to support what they say - that is, if they provide an API, as Asterisk does for the channel drivers - that if they make a change of the API that it’s done for a critical reason that’s important and required, and that the project maintainers document it, and that the API change operates per documentation, and changes are not capricious for no reason or malevolent where they intend to break things. All of that is a part of support by the project of 3rd party add-ins. In exchange, the project developers expect the 3rd party add in writer to write their code to properly conform to the API.
Even when the API is documented in minute detail, there’s going to be grey areas subject to interpretation. With PBXact, I would expect that because I am paying Sangoma for it, they would support the 3rd party chan_sip driver by clarifying those areas, and working with the developer. In the case of chan_sip it should be EXTREMELY easy for Sangoma to do this because they already provide code for pj_sip and so if chan_sip malfunctions in the API access then the pj_sip code can be used as an example on how to properly access the APIs. And, if chan_sip accesses an API that pj_sip does not, then I’d expect Sangoma to provide accurate documentation of that API and fix the API code if it does not conform. With FreePBX, I also expect them to provide documentation of how the API is supposed to work - but because I’m not paying them for FreePBX, if the API does not work the way it’s supposed to, I don’t expect them to drop everything and fix it. I kind of expect them to fix it in the next release but I’m not banking on it, and so my choice is either pay a developer to fix it and submit the patch for the correction to Sangoma and hope they accept it, or buy PBXact.
That is what Sangoma, Asterisk, FreePBX, and PBXact support is all about, according to my understanding of generalized Open Source Software projects and how they work, and my conversation with Sangoma. It is not black and white as you are implying.
