FreePBX design discussion

FreePBX Development
89

So then when something like the Firewall module which is AGPL has a dependency for a commercial module (System Admin) then the only way to have builtin security for the OSS based project is to get the Distro which is considered commercial.

Yes, I know. Which then means the standalone OSS version of FreePBX should have all of its OSS licensed modules not have required dependencies of commercial based modules. Because that just says you can get more OSS out of your OSS software if you have commercial stuff.

1 Like
90

Also accept that the predecessors at least are working on an old codebase around old design decisions with a username that has members who take any change as a personal insult. Without a ROI there would be no FreePBX. This is not hyperbole. History lesson. The project had been saved from the scrap yard at least 3 times. One of those times it was under the ownership of a major company. Tony fortunately got it from them with the help fo PL. “Schmooze” made it a financially viable project. Frankly without paid development there would be no real progress. I can count major non staff contributors on 1 hand. I dare say @miken32 you are the largest non staff contributor to the FreePBX code base.

4 Likes
91

WiseOldOwl left well before James and my time with FreePBX and MichiganTelephone left shortly after my time.

I only interacted with MichiganTelephone as an open source volunteer to freepbx (before I worked full time on it) when I created the Swiss Army knife module which he seemed to like. I also took his advice and added back the free form dial pattern text box which was removed by a former developer who left shortly before I was hired full time. That free form dial pattern text box still exists to this day.

You could also talk about the google voice module contributor leaving as well (mbm? I forgot his handle) which was also before my time with the project. He left for the same reasons as the other two.

92

That was alot to all take in. I am new here to this forum (here only a few months) and I sell and install Phone PBX’s professionally. Started with Cisco and their UC500 hardware with Cisco United Express and then with 3CX up until recently and now with FreePBX. As someone who installed and configured it, 3CX was easier. as someone who manages and implements what the customer wants, I think FreePBX is easier. I hate the parking feature of the 3CX system, ad the parking feature of the other two are essentially the same, which I like. The backup and restore feature is best on 3CX, because it allows you to restore essentially before everything else is done and setup. (as opposed to setting things up enough to get to the GUI and then restore). Both have decent documentation, but I think 3CX is better documented but I also understand that 3CX is a commercial product, FreePBX is not. I believe that would be the Switchvox that would be the commercial product, so you can’t really compare the two given FreePBX is free and OSS and 3CX is commercially setup. I also like the community better at FreePBX, less condescension (for the most part). I have not had GUI issues with FreePBX with the exception that when you make a new extension, you have to save it first then go back in to edit after (atleast on version 13). I hope this has helped anyone at all. Thanks

93

@xrobau didn’t want this actually but it was the only way. Primarily because sysadmin can securely interact as root. Trust me he tried to find a reasonable and secure way to make it work ndependently.

That said it is one example in 130 modules.

1 Like
94

And switchvox has a dedicated UX employee along with Zulu. Whereas freepbx does not.

95

You can always run incredible pbx or @reraikes raspi . Both have zero commercial modules. Or build your own distro. This isn’t a knock against you. You make valid points. But I would think Sangoma builds the distro with commercial components to help support development of not only freepbx but the distro itself.

People are free to write their own distro and they often do.

(Also note I don’t want this to seem like I’m teaming up against you. Just trying to offer an opinion)

1 Like
96

I wasn’t saying that the distro shouldn’t have commercial modules on it. What I am saying is I don’t think the Zulu server needs to be running on my system when I don’t have Zulu licensed. It’s not being used so why does the server need to run? I don’t it doesn’t need to because I disable the module and it stops the service from starting up. Same with iSymphony and Java. No need to have those running when not being used.

The Sangoma CRM is the same thing, it has active dialplan when not in use. Disable it the dialplan and the CRM agi aren’t run. So clearly there is no requirement for them when not being used.

I guess my point is simple Having extra bloat in the dialplan, configs and having services running on the system that are doing absolutely nothing because what they are meant for isn’t licensed and can’t be used anyways is a waste. It eats at resources and adds extra things that aren’t needed because they aren’t being used. It just doesn’t seem optimal.

Edit: So I guess a happy middle ground of the modules still being available and in the menus so you can get to the “License this” options and active it. But until that point all the extra stuff shouldn’t be written out to active configs. Additional services shouldn’t be started until an active license is there. I think that is fair to wish for, wouldn’t you say?

2 Likes
97

I believe it basically does nothing when unlicensed (I could be wrong) so there would be very little motivation to remove it I would think.

I could see this being considered a bug. The dialplan probably shouldn’t generate when unlicensed.

Most commercial module functions simply “return” if they are unlicensed. In “theory” an unlicensed module should do nothing. It may be worth filing a bug for. Not sure how much priority it would give.

98

It is harsh. We can’t stand 4PSA’s Voipnow and for the time-being still have tons of extensions left on it. We thought Voipnow was great until we properly got to grips with the FreePBX GUI on a full time basis, and we absolutely love it. Those using it all day every day might have a very different view to those playing with it for fun on Sunday afternoons. It pays the bills and for business use it’s better than most, IMO.

2 Likes
99

Agreed. For those that know it, it is perfectly serviceable. For those that use it all the time, it does take 2.5 times as long to configure a new system than it used to, primarily because of changes that were made in the last 5 years. However, the GUI is not intuitive to new users for the reasons I’ve discussed.

The fact that I’ve complained about the GUI does not mean that I think that it is terrible. The FreePBX GUI is not terrible. However, like most things, it has room for improvement.

2 Likes
100

I don’t think he is calling them lazy. At least I couldn’t find where he was calling them lazy. I think he was just pointing out that in today’s world programmers are not expected to just create source code. They are expected to do documentation beyond just what is required to commit your source code the cms. This doesnt speak to laziness but to a historical way of thinking and honestly a tendency to neglect documentation if not managed by the manager of the repo. If the FreePBX development mindset was to change or if the repo manager was to stop allowing commits without adequate end user documentation, then it would benefit everyone from a usability and adoption standpoint. However we do have to acknowledge that there are only so many developers. Adding this requirement would mean features will take longer to get released as the developers will have to dedicate some of the time that is currently spent programming to do this documentation. A change like this may also have implications on personnel. What if their best programmer despises documentation? Is it worth potentially losing their best programmer? We dont see what is going on inside the organization so this we will never know. But we have to at least acknowledge that this change would have an impact both positive and negative.

1 Like
101

I agree 100% with Kirk. Like many people who are on the autism spectrum, I say what I mean. There is no need for you to search my words to find hidden meanings. If I thought you were lazy, I’d use the word lazy, and then give specific examples to support it. Since FreePBX is now a corporate sponsored project, the issue here is about allocation of resources. It has nothing to do with personal characteristics.

And since I’ve been accused of calling the dev team lazy, let me meander just a bit. I know for a fact that Andrew Nagy is a hard-working and brilliant programmer, and I have never, ever intended to communicate the opposite. The fact that I disagree with some of Andrew’s decisions does not mean that I think any less of him as a person. We should all be able to agree to disagree. Also, please don’t infer anything negative from the fact that I only mentioned Andrew here. I mention Andrew because he is the only former dev who is particiating here who I have spoken with one on one.

Getting back to the point: It’s not hard to understand how FreePBX got here. When started as an open source project, the coders were writing FreePBX for their own benefit, i.e., as hobbyists. They knew how it worked, because they wrote it. If others found it useful, that was great, but nobody was expecting that FreePBX would become a commercial product. When nobody was funding the project, and nobody expected to sell it, there was zero reason to spend much time on documentation.

Now that FreePBX is a corporate sponsored project, I’m saying that there’s a good reason for Sangoma to allocate more resources to documentation. I agree with everything that Kirk said on this point.

But, in addition to what Kirk said, there is another benefit to having documentation precede GUI changes: It helps to ensure that the GUI stays friendly, easy to use, and avoid unnecessary radical changes.

Forcing someone to think about how to explain a change in writing ensures that the change stays simple and user friendly. The simple changes are simple to explain. If a radical change required radical changes to the documentation, a dev might work harder to find a way to accomplish the same thing without the radical change.

102

Between the 5,000,000 words he has put in this post, many of his posts have 5-10 edits, short of screenshots and some sort of machine learning it is hard to know what he is saying.

There have been countless complaints about the documentation. The documentation is dare I say as good if not better than it has ever been. I spent over 7 years formatting, cleaning and adding to the documentation. There is a team of QA and internal testers that also update the docs. At one point a staff person was even tasked to proof reading and going through all the docs as a layman. She held a non-engineering position with the company. (engineers at least in our realm tend to suck at spelling and grammar)

The complaints are that the devs are not spending time updating docs. That is true but there are people who are paid by Sangoma that are.

The process.

Developer makes a thing. He roughly puts together a design/use doc.
QA person uses that spec to test things, open bugs and write end user documentation.

  1. The average person never looks at the wiki unless someone directs them to an exact page.
  2. The average person doesn’t search these forums or google for the answer to their question. They make a fresh post asking the same question for the Nth time.
  3. The average person who has no issues will not come to the forums or the wiki.

There has been a lot of time making sure #3 is the normal. No news is good news. You can lead a horse to water but you can’t make it drink. There will always be #1 and #2. They are the ones you will see here. That is why the productive forum members typically answer the same question for the Nth time. It has nothing to do with the availability of docs or answers.

There use to be a lot of toxic people here and still in IRC. These folks are the LMGTFY types and the RTFM types. Honestly if there is one type of person any community can lose it is those.

The same person has been making the same baseless complaint any time they get an opening for years. A bunch of nonsensical unformulated pages that covered doing random things to a FreePBX version that was end of life got replaced by proper documentation about how to actually use the modules of current releases. Since then that person has even asked for my job because his law degree gave him some entitlement to do so. That my friends is the history of documentation in FreePBX.

A GUI is like a joke. When you have to explain it, it isn’t that good. The UI over time has been changed to make sure there is no need to leave the UI to know why something is there.

The wiki is underutilized much like google but is well maintained.

You will note there are never any specific examples given, only ever hyperbole and venom.

And he hates being called out.

1 Like
105

Many of my edits were required because TheJames and others are flagged my posts, causing the system to hide them until I edited them. In other cases, I edited my posts to improve them. I’m not sure why anyone feels the need to read the old versions or compare them with the new ones, but you’re certainly welcome to do that if you’d like.

Since the TheJames and Sorvani have turned this into a series of irrelevant and mostly false personal attacks on me, and the mods have declined to do anything to do stop them, I’m leaving what has (except for their participation) been a very constructive discussion of the design elements of FreePBX.

Good luck everyone. :slight_smile:

106

This is excellent! I don’t think @AdHominem or any of us would not recommend this. I think one of the main points he is trying to make is just there is a different workflow that may help improve the documentation. He isn’t saying that you have to do it just that you might want to consider it, as it could improve things. It is possible he has seen it improve things of this nature. I know I have seen it, thats why in my last company those writing the code is required to document it and in the code review both the documentation and the source is reviewed. Now there is a documentation specialist that goes through and independently makes incremental improvements, but their contributions are different from someone who so intimately knows the code and what it does.

I can only speak for me and the IT people I know, but I don’t know any IT person that doesn’t do some research in an attempt to solve a problem before they post on a forum. Now some people aren’t as good at google or when they see a post on a topic they wonder if it applies due to some reason or after trying x,y,z that was on the post they still were not able to solve their issue.
So there are very legit reasons to post in the forum for a topic that has already been covered.
Additionally most admins I know do at least some research before setting up a new system. The absolute first place one would go is to a quick start manual which is on the wiki.

1 Like
107

OK so I’m going to throw this into the and see what backlash I can over it.

Can we, for future releases, make sure that all the key, driving and spotlighted features of the release actually work when the release is done? I mean v15’s driving features where an overhaul on Backup/Restore and GraphQL. As I’ve seen there have been some issues with Backup/Restore but what really concerns me is this:

Now these were all comments in the last week or so. Which says to me that 2.5 months after the stable release of v15 50% of the key highlight features of the new version isn’t even fully ready and what does exist has bugs in it. It also appears to not have completely internal reviews.

Now that isn’t to say I’m not being positive and hopeful with all the new changes that have happened at Digium/Sangoma. I know some things are happening to show that Sangoma is committed to this project and the community and I’m a 100% cool with that. Just do it right. Quality over quantity is always the better path.

108

Reported issues for the backup module in 15 are assigned a very high priority and reports of issues have slowed noticeably since initial release.

The API module is different in that it’s purpose is to be an API framework that all other modules can leverage and ultimately become a comprehensive, system wide API interface. As far as I’m aware, the framework itself is solid, but at present many modules have yet to be updated to hook into it. This is not a path to a door, more of a journey to a horizon, and something the coding community can assist with.

2 Likes
109

I disagree with the statement that Quality over quantity is always the better path. I really think it just depends on what it is. Should we invest time and effort into SIP and backups? Yes, that should always work and should have 100% quality! Should we spend a bunch of time and effort making sure the GraphQL library is complete and works 100% of the time? Probably not so much, since it’s probably a feature that less than 5% of the users actually want to see. The fact that it took 3 months for a bug to show up is evidence that GraphQL may not be a feature that is needed.

I would rather invest quality time and effort into the things that matter and then provide a framework for new features that maybe a bit experimental but help to push the project forward. Otherwise we will be spinning our wheels trying to make everything perfect and new features will never happen.

Now, I’m not saying quality isn’t important. We have a lot of internal efforts centered around unit testing and process revamp that is geared towards better quality software. My point here is that some modules we can afford to be more risky with (GraphQL), while others we can’t (Backups).

2 Likes
110

Code contributions are always welcome.

2 Likes