While the community is having issues with the open source side of FreePBX and zero response on that side. Someone thought, let’s market more commercial stuff.
This reminds me of when Huntsville infrastructure was dying almost daily and I was get “Buy FreePBX swag” mailers during major infrastructure outages. Timing folks, it is all about timing.
Please check out the fix to a decade (?) old open source module security issue that we helped publish last month for OSS EPM on pre-v15: OSS Endpoint Manager - Moderate Security Issue - CVE-2024-47071
What does a 3rd party open source module for FreePBX has to do with FreePBX dealing with their own open source stuff? It was an announcement about an out of date project that was brought back to life recently and a bunch of out dated things were fixed. That was just one of them.
It’s unrelated to how Sangoma is handling its own open source project.
Did you know? There’s been 174 non-merge commits into GitHub so far this year in the FreePBX open source Framework release/17.0 branch.
Quantity does not equal quality. Quality of the project is what is being questioned at this time. It really doesn’t matter how much work is being done if the quality of that work is below par. Pushing out a bunch of commits that haven’t been QA’d properly speaks more to the questions being asked about cutting corners and degrading quality of the output.
This is starting to feel like a bunch of deflection.
And me fighting to make my own commercial modules in addition. LOL 
Did you know? There’s been 399 issues closed on GitHub so far this year in the FreePBX Issue Tracker repository.
And 305 of those have been bugs. So that would mean that 75% of the issues worked on for FreePBX this year were fixing bugs. Which leads to questions such as:
- Why is this number so high?
- How much of the 305 bugs are existing technical debt that needed to be covered?
- How much of those 305 bugs needed to be addressed because they weren’t caught in QA? Since not every scenario or use case can be tested/QA’d there is an acceptable level of bugs getting in the wild.
- Why is such a high number getting past QA?
- How much cost in time, resources and money is being lost on 75% of the work being done to fix work that had time and resources spent on it already?
- What can be done to reduce that 75% while raising the 25% of improvements and feature adds?
Did @penguinpbx turn into a trivia bot all of a sudden?
Well, it certainly helps to add some facts to the discussion, with links.
Ah! You scared me there, I thought we had lost you to ChatGPT.
What would help more is answering some serious questions posed by contributing members of this community like @BlazeStudios. I really does seem like
Thank you to the community members who participated in this process!
The move from CentOS-based v16 to Debian-based v17, as well as upgrading to PHP 8.2, involved a lot of effort.
v17 was in beta until August and beta software has more bugs.
Sky’s the limit for new kitchen sink features now that we’ve pulled a lot of lead out of the plumbing. See OP!
That is the reason for the internal development to take longer than normal. It means there was more work for the QA department. However, those 305 issues that were closed were in response to bugs being released into the production/rc/beta. It means that 305 bugs were not caught by QA or the developer(s) when testing their code. Some of the bugs are very basic like undeclared arrays or variables that should have been caught in QA/testing. If users run a module update and then get pages that can’t load because the code in throwing errors about undeclared variables/arrays or creating dynamic variables without declaring them first is a bug that should have never gotten out.
There’s been roughly 160 issues closed since FreePBX v17 when GA Aug 2nd. Out of that 160 closed issues, 132 where bug reports with about 98% of those being bugs reported after the GA release. There was a small amount of bugs reported during beta that didn’t get closed until after the GA release (up to a month after in some cases). I still have to question the 50% of issues being raised are bugs, since GA.
So 305 bugs in all of 2024 which breaks down to 173 bugs during beta and 132 bugs after GA. There’s been almost as many bugs reported in production as there were in beta/alpha and it’s been in production for 3 months while it was in beta for 8 months (in 2024). This is not a good ratio.
But their was 5 year delay from FPBX 16 to 17. 5 years to do a OS and PHP update. All of FreePBX could of be re-written faster then a update from 16 to 17 took.
Three year delay. FreePBX v16 was released in 2021 and FreePBX v17 was 2024. It is, however, a year longer than the two year cycle of v14 to v15 and v15 to v16.
Please share the links for that statement - could not find a good source - but did want to share some of these relevant points along the time line:
Here’s some other relevant time line tidbits.
- FreePBX v17 bare bones “beta” released late Oct/early Nov 2023 with very limited modules converted. Requires manual installation of all parts.
- The rest of 2023 is spent realizing the beta release is actually an alpha release.
- FreePBX v17 gets an official install process Feb 2024, still with limited modules
- Between Feb 2024 and Aug 2nd 2024 the rest of oss modules are converted, commercial modules get converted.
What this really is telling me is that even though there was a 3 year gap between v16 and v17, that v17 was basically done within a year time frame with the majority of the work being done in a six month crunch. So that answers some of my questions.
Sorry 3 years. I should of pulled up dates before typing 5 years. I stand corrected, it was 3 years.
Even more details:
- FreePBX open source move to GitHub mostly complete by end of 2023, following engineering lead of Asterisk team at Sangoma.
- Community contributions to assist with v17 testing were present by late 2023 even before the GitHub move was complete.
- New Artificial Intelligence Scribe module launched in late 2024.