Small Changes Big Consequences

I sat around this Saturday morning clearing out some recent bugs so I could head off to Maui tomorrow with a clear conscious and enjoy my vacation. As I did so I pondered what to blog about having just given you a well received sneak preview of the next v2 release. One of today’s bugs made me think it would be good to talk about the hard choices of what goes in a release and what does not. Before I go on though, if any of you readers are out in Maui in the next 1.5 weeks, send me a PM, maybe we can have a drink!

Many of you have a favorite feature request you want in the next release. Sometimes it may come complete with a fully functioning patch sitting in the tracker and it can be very frustrating to you when we decide it is not going to go in the release. “Why won’t you just put it in, it’s just a few lines of code and it’s all right there…” is something I’ve encountered on more than one occasion. It may appear to be simple and sometimes things are, but more often then not they are not. Unfortunately when looking at your own feature you may not always see the subtle things it may break, and often we don’t see them right away either but experience has taught us that they are there.

An example is the addition of the CallerID field for outbound routing that was introduced in 2.7. It was presented to us at the tail end of the 2.6 release cycle by a very knowledgeable community member who said “look, if you simply modify the javascript validation that restricts the use of “/” in dialpatterns for outbound routes, we can add the ability to support outbound routing by extension with the use of the CallerID field.” This sounded harmless enough that one of the developers decided to checkin the code even though we were in feature freeze and close to release. Well one of the privileges / curses of being the project leader is that I get to be the one who says “that has to go, it’s too late to add features so put it in the next release.” Something that is never appreciated. None the less I took it out and moved it into 2.7 where it would have ample time to be tested and run through proper beta cycles.

Needless to say, small changes can have big consequences, especially when they are sitting in a critical call flow path. The first issue that came up and was included in the original checkin was the fact that we don’t even know the true “CID” of the extension until Macro(user-callerid) is executed which doesn’t happen until you are in the route. Well that’s just a minor change, we’ll just move that instruction out of the route and in the outbound-allroutes context. Sure enough that does the trick and all looks great, or does it? Eventually someone comes along with a route that has multiple trunks and you start scratching your head wondering how a call is completing on a trunk that is not part of your route?!? Oops … the CID is changed by Macro(outbound-callerid) so if the trunk falls through to another trunk, “everything has changed.” Well that’s an easy enough fix once again (after many hours of scratching your head..), We’ll just reset the CID each time we exit one of the Macro(dialout-trunk) or equivalents. Now we’re getting somewhere, it all seems to work, right? So far, so good but that’s not to say that everything else that used to work is still working.

Our first casualty comes in, the popular third party module Custom Contexts is broken. This is not one of our modules so who cares, right? Isn’t that why it is not a core module and not supported by the core team? Well technically that’s true however it is not in our interest to break other things that worked and FreePBX has always tried hard to not break compatibility and things that used to work. So after spending yet more time thinking about the failure mode and what we could do differently out comes another change and this time we are feeling pretty good about “that small change to the javascript validation allowing the “/” character” finally being put to rest. Then comes the day before my trip to Maui and in comes the next report, the AMPBADNUMBER=false configuration that allows “Early Dial” configured phones to work properly has been broken by our nifty little fix of moving Macro(user-callerid) into outbound-allroutes. So once again off to spend more time thinking about and testing various alternatives to resolve the newest bug without knocking down the rest of the card castle… For now, once again we think its finally licked, at least until the next issue gets presented. (If that happens in the next couple weeks though, you can rest assured that I’ll let the power of open source solve the problem in my absence because despite how much I may enjoy working on FreePBX, it’s not going to happen in Maui!)

I hope this digression helps to understand that there is often much more than meets the eyes when thinking about new features and capabilities for FreePBX. When you have an installed base counted in the hundreds of thousands you are going to find people doing all sorts of things that you haven’t anticipated. We try to take this into account when considering new feature development. We look at many other factors as well. Who’s interested in doing the feature? How popular is the request? Are there other ways of doing certain things today that may make one feature less urgent then another one? What do we anticipate the consequence and required support to be? Is the author of a requested feature going to be around/willing to maintain the new code and be responsive to issues when they come up? Is the feature important enough that a customer is willing to pay the true anticipated cost of implementing and future support of that feature? (Remember the javascript change above; imagine the reaction if a customer had made such a request and were told it would cost them $1000, which would have been a bargain when considering the time it has taken so far…).

So … next time you are wondering why that small feature of yours may still be outstanding, or why a knowledgeable developer may have quoted you what sounded like an exaggerated sum for something that seemed easy and small, I hope you can appreciate the job and challenge we have when evaluating such requests and considering what is in or out of a release.

For now, I’m signing off and thinking about beaches and sunshine….I’ll be back in a couple weeks!

Philippe – On behalf of the FreePBX Team

FreePBX 2.7 Is Final

I’m excited to announce FreePBX 2.7 Final available for immediate download. We have over 2000 systems running 2.7 at the time of this posting and continue to see more features and increased stability as FreePBX evolves. The bugs encountered during this release were minimal and most of those addressed in the bug tracker were already existing bugs from earlier releases fixed during this Milestone (and most of those not back ported to 2.6.

The biggest changes in 2.7 were around the Fax handling and the new FAX module which provides a much more intuitive GUI for dealing with FAXes with both shared voice/FAX DIDs that require detection or dedicated FAX DIDs. It also introduced support for FAX For Asterisk (FFA) in addition to the legacy support for spanddsp based FAX reception. You can get more details about the changes in the 2.7.0 Beta1 Release announcement.

Outside of FAX, you can see a more comprehensive list of features and bugs addressed as well as an overall summary in the 2.7 Milestone along with direct links and stats to all 142 closed Feature Request and Bug tickets addressed during this run!

A few highlights include some great enhancements to Queues and Backup, as well as additional abilities in Outbound Routes, Follow Me, Ring Groups, Trunks and Conferences to name just a few. If you are particularly interested in Queues you may want to have a look at the recent Heavy Queue Usage in FreePBX Technical Corner article we just put out which talks about various advanced capabilities in the Queue module that may be of interest.

With 2.7 now final it means that FreePBX 2.5 is now off support so if you are still running 2.5 or older versions, you may want to seriously think about an upgrade plan. The project’s support policy is to support the current and previous major releases.

We have started to compile up a list of what we want to target for our next v2 release and you can see the plans as they evolve in the 2.8 Milestone. More to come on that as we better define it. We will also be working hard to get our v3 General Preview Release Candidate out with support for both Asterisk and FreeSWITCH. It has been available as a Developer release since last August and is now getting to the point where we will be able to get more user feedback to really shape its development going forward!

For now go have fun with all the great new stuff we are getting out to all of you and we will be back shortly with more news to come!

Philippe – On behalf of the FreePBX Team!