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