OSS is not completely functioning for me. The editor for the provisioning files is not working. Possibly the editor code from the CONFIG EDIT module could be used to upgrade. There may be other open issues as well.
Anyone with the experience and talent to help out would be appreciated. Code is up on GitHub. I am told that it has only one contributor and possibly he or she has other priorities.
Anyone aware of other issues related to upgrading OSS please feel free to chime in with helpful comments.
EndPoint is like all commercial modules, good for those who require its features. For my installation, OSS has served me well and I would like to see it supported. Bye the way, I own a license to EPM.
Are you trying to nag the FreePBX developers into maintaining the code for you, or are you trying to nag us to fix it for you? The OSS in OSS EPM means that it’s Open Source. You pointed out where the code is. I don’t see the problem.
You keep hammering and hammering away on the OSS EPM not doing what you want, but I don’t see you doing any more than whining at us to fix it. If you want it that bad, fix it yourself - that’s the whole point of Open Source.
I don’t have current skills and, for other reasons I don’t have the luxury to update them. I am trying to encourage someone who has them and is interested in helping.
It was a genuine invitation for help from the community to solve what appears to not be actively supported at this time. Since I don’t know you, I am not sure who “us” refers to so I don’t know who you are speaking for and why you feel nagged.
I am not sure I get your seeming attack on a perfectly reasonable community appeal. “If you want it that bad, fix it yourself” is not a very constructive community post.
It is a perfectly acceptable thing to request, to ask the community to provide fixes for a community supported project. At the risk of putting words in @cynjut’s mouth, perhaps he feels that your request should have explicitly acknowledged that you are also part of the community, and that in making the request, there is an implicit expectation that you will assist in the process, in whatever form you can. This is conventionally done by providing code or financial contributions to those who can code. I am absolutely not telling you to do or pay anything, merely pointing out how the process has worked successfully on other community supported modules.
The problem with this request (and the OSS EPM module generally) is twofold:
There is a vanishingly small number of coders with FreePBX module experience, and of the very few that have worked on this module, it seems burnout is inevitable due the the never ending maintenance required. A provisioning module needs to stay current with the device market, which is constantly introducing new products and firm wares. At present, of the 7 billion or so potential contributors, there is a single consistent contributor to the OSS EPM project, and I don’t know if their English skills allow for participation in this forum.
There is a non-free (but modestly priced) module that actually does provision phones, does it well, is actively maintained, and is very widely used. The OSS module predates the Commercial module by years, and the market has absolutely spoken, the verdict being that support, functionality and features are more important than free.
If you want to get a sense of the amount of maintenance required for a provisioning module, use some search filters in the issue tracker. I filtered for tickets for the FreePBX and FreePBX Contributed projects. For the entire FreePBX project, over the last two years, there have been about 5000* tickets created, and 900 of these tickets are for commercial EPM alone. This is during a time interval when version 13 was going through alpha and beta, so the ticket count is probably skewed for that, and even then commercial EPM accounts for about 18% of all tickets created. Of the 906** EPM tickets created over the last 2 years, 223 are of type feature request and improvement, meaning a quarter of EPM tickets opened are user requests for new functionality and, interestingly, half of those requests have been closed with a resolution of fixed. It would take a volunteer team of dozens with competent and busy leader to bring the OSS version in line with what is provided by the Commercial version. Those few of us who have actually maintained community supported FreePBX modules, know that these dozens just don’t exist. Periodically one sees efforts to revive the project, and they inevitably come to naught because of these realities.
* 5000 is the raw number of tickets created. This number should be reduced by significant fraction due to the number of tickets created that are deemed to be support requests which don’t belong in the issue tracker and are immediately closed. If this reality were factored into the stats, I suspect the percentage of EPM tickets would climb to over 20%.
** fun fact, I have personally opened 73 of the 906 EPM tickets, you’re welcome Luke.
Great post. Very interesting. As with most things in life something can be more complicated that it looks.
Since OSS is provisioning my phones successfully (Aastras), I was focusing on getting just the editor working but I definitely here you.
Does it make any sense to focus OSS’s future on loading the vendor provisioning files and just giving the sight the ability to manually customize them. No illusion of support, just tools to download what is needed. OSS appears to have some of that ability now.
I am certainly not aware of all the issues but I stick by my thinking that something for small sites and testing be available over and above logging into the devices and configuring them.
I think kicking some ideas around for the future of OSS or whatever is probably a healthy thing. Would we be stepping on the developers toes?
i would say you are beating a dead horse. the oss epm has had very little support in the last several years and i don’t see any reason why someone would step and update it. the paid epm supports most phones, is pretty flexible and is cheap.
I worked on the OSS EPM a LONG time ago (Asterisk 1.4) and thought then that it needed to be redesigned. Honestly, it may well have been, but I haven’t looked at it in a long time.
The problem then was that there was too much coupling of the input to the output. There were too many edge cases where a generic interface on the front wouldn’t connect to a generic interface on the back end, which means that every phone needed new code added to the existing baseline (instead of adding new classes of phones when required).
It wasn’t really designed - it just kind of happened, and (as with most Hobby Shopped projects) it just bloated and grew until it was unmanageable. At least one part of that problem set (the unmanageable part) still seems to be there.
I wouldn’t go back to work on it in 2004; I can’t imagine it’s improved enough to make it something I’d want to spend the little bit of time I have to work on other people’s projects to work on it.
I’m sorry if I sounded harsh before, but sometimes I can be caught in a bad mood and may speak a little more “frankly” than I probably should.
Having said that, though, the system (especially the Open Source parts) really need to retain the “I found a problem, I fixed a problem” feel. If this was a purely commercial endeavor, then waiting for someone to fix the problem might work, but this isn’t that kind of system, nor is it that kind of a community.
Thanks Dave. My only further thought is that Asterisk/FreePBX is the kind of tool which many, like myself, have adopted in order to make the phones ring. Many of us who “administer” a installation are living on the edge. We are technical enough to deal reasonably well with the complex use of the system but not enough to take on the underlying complexities.
Example, I am not a Linux person. That FreePBX continues to evolve so that the demands for Linux skills are minimized is wonderful. While we hope to contribute from a user prospective, community members present a spectrum of needs and backgrounds. This highlights what a great resource the community forums are at their best.
Be Well.
