only in section VoIP Asterisk

Asterisk 1.6: Dinosaur or Ostrich… It Really Doesn’t Matter

Filed under:

• Technology
• Telephony

— ward @ 6:00 am

In our last column, we lamented the fact that Asterisk 1.6 development seemed to be on a collision course with the dinosaurs because of developer insistence on deprecating and removing commands from the application programming interface (API) in the name of technology enhancement. The problem this poses is that applications and dialplans written for previous versions of Asterisk no longer function even though the code is barely a year old. In the corporate and government sectors, this would mean major, costly (annual) rewrites of code just to keep a functioning phone system. And, as we noted, these organizations buy phone systems to last a decade so such a development strategy would all but rule out use of Asterisk in the Fortune 500, medical, and government sectors.

Today we want to share the Digium response and address some of the new issues that have been raised. For those of you that haven't met him, Jared Smith, who co-authored the terrific Asterisk: The Future of Telephony books, now serves as Digium's Community Relations Manager. Jared sent us a thought-provoking response which you can read in its entirety here. For ease of understanding, we're going to quote a number of sections of Jared's response and address them below so that you get the full picture of how dangerous the Digium development approach is to the future of the Asterisk project. We've been concerned in the past with Fonality's decision to keep trixbox ce on the bleeding edge while reserving a more stable Asterisk product for paying customers. Now it appears Digium has decided to do much the same thing with the open source version of Asterisk. That's unfortunate for all of us that care about the future of the project.

Jared Smith: "I think we can both agree that the feature set is an important part of any PBX system. Or, as you put it, "It's the Feature Set, Stupid!" There are two major reasons for moving from Asterisk 1.4 to the upcoming Asterisk 1.6 release at all, and the first one is features. Asterisk 1.6 brings a lot of new features to the table over what was available in Asterisk 1.4 and Asterisk 1.2. (The other big change in Asterisk 1.6 is that a lot of its internal plumbing got re-worked, so that it should be more efficient, more stable, and better able to handle larger call volumes.) Unfortunately, your article doesn't differentiate between features of Asterisk and features that third-parties (yourself included) have bolted on to Asterisk. To use the same analogy that I gave when I met you in Charleston, we here at Digium want Asterisk to be the best engine in the world. Whether you make that engine into a Formula One race car or a big brown delivery truck is up to you -- we're simply building the best engine we can. Now, we've gone and built a newer version of the engine ("More horsepower! Higher torque! Faster zero-to-sixty speed!"), and suddenly everyone complains that the starter motor doesn't fit in the same place that it used to. I know it's not a perfect analogy, but hopefully you get my point... "

Uncle Ward: We obviously applaud enhancements which make Asterisk "more efficient, more stable, and better able to handle larger call volumes." It's the rest of the paragraph that highlights the fundamental problem with the current Asterisk development strategy. The point is that, for Asterisk to survive, the developers need to appreciate that they're not building a mousetrap in a vacuum. Asterisk without a dialplan is worthless. Asterisk without application code has little value particularly in vertical markets. To carry Jared's engine analogy one step further, the concern is not about Digium's repositioning the starter motor. It's about eliminating fundamental components that businesses rely upon to keep their communications engine running. It does little good to develop "the best engine in the world" if this year's version requires kerosene while last year's version ran on gasoline and next year's version requires hydrogen. Such changes force a complete reworking of the infrastructure that organizations rely upon to keep their cars and their phone systems functioning.

Jared Smith: "APIs change when major versions of the software are released. (APIs are Application Programming Interfaces -- think of them as building blocks inside of the Asterisk code that both Asterisk and third-party programs can use to do various things.) The problem is, when we make Asterisk better, we often have to change those APIs to do so... I'd challenge you to find any major project that provides source-level API compatibility as a *guarantee* between major release versions. (Look at Apache 2.0 - 2.2, PHP 4 - 5, MySQL 4 - 5, PostgreSQL 7 - 8. They all have the same thing -- Major changes almost always require API changes.) When the Asterisk APIs stop changing from major release to major release, then Asterisk *WILL* be as dead as the dinosaurs are. "

Uncle Ward: We defy anyone to explain why "making Asterisk better" required breaking every dialplan on the planet because some developer thought Set(TIMEOUT(digit)=timeout) was a code improvement in Asterisk 1.4 over DigitTimeout(timeout). No one wants to stand in the way of progress. But moving forward is quite different than throwing the baby out with the bath water. Supporting both syntaxes would have required one extra line of code in the API. In the alternative, Digium could have released a source code translation application which would automatically convert existing code to the new syntax. This almost always has been done with major changes in programming languages. We would hasten to add that most of the developer-inspired changes with which we have been concerned have little or nothing to do with making Asterisk a "better engine." It's just a different engine. And therein lies the problem!

Jared Smith: "Luckily, Asterisk is an open-source project, which means that when Asterisk does evolve, that the changes aren't made in secret. Any third-party developer who wants to make sure his code remains compatible with the latest version of Asterisk can do so at any time. He doesn't have to wait until 1.6.0 is released to find out that his code will have to be changed to fit the new APIs. The Asterisk code is always available to test, play with, qualify against, etc. so that the developer can update their code to be compatible, so that when the time comes that real users want to use it, their applications will be ready."

Uncle Ward: The concern here isn't that third-party developers can't make changes to accommodate future Asterisk API changes. The problem is that businesses that stake their livelihood on a phone system that is Asterisk-based expect it to keep working year after year after year. Third-party developers come and go. So, if a company purchases an Asterisk-based system which includes fax and text-to-speech telephony support, those companies have a right to expect that their applications will work next year with the currently supported version of Asterisk. Jared's response sent me looking for the image to accompany this week's article: an ostrich burying his head in the sand. Third party developers move on or die, Jared. You can't pretend that folks never used their code because you're too focused on future enhancements to your race car engine to worry about preserving the necessary infrastructure to support applications that already work. As we put it last week, "You break it, you fix it. I break it, I fix it." That's a really simple design concept that should be fundamental to any API development changes. This in no way impedes the design goal of "making things better." Just don't make other things worse in the process.

Jared Smith: "The next point I'd like to address is that of responsibility. Your article somehow assumes that it's the responsibility of the Asterisk developers to somehow know about all these third-party apps, and make sure they never break due to API changes. I can see three flaws with that argument -- first of all, there's no way the Asterisk developers could possibly know of every third-party application, it's state of affairs, and so forth... The second flaw is this -- even assuming for a moment that we could keep track of all the third-party apps and try to keep them up to date (which we both know isn't possible), licensing concerns would keep the Digium-paid Asterisk developers from doing so... The third flaw to that argument is the point I made earlier... if Asterisk *were* to guarantee source-code API compatibility between major releases, there's no way possible that Asterisk could continue to grow, evolve, and adapt to the changing telephony market. "

Uncle Ward: I'm reminded of the Venus and Mars book about the differences in perspective between men and women. Are you really saying that Asterisk developers had no idea that folks were using dialplans and text-to-speech applications with Asterisk after Digium just worked with Cepstral to produce an Allison voice?? Come on, Jared. This isn't about whether it is Digium's responsibility to fix third-party developer code. This is about whether corporations and government organizations are going to invest in a telephony system when the business philosophy of the engine manufacturer is that they could care less whether they break existing telephony applications with each new product release. As I read Jared's response, Asterisk developers can't and won't be responsible for making sure they don't break existing applications and dialplan code, and Digium won't do anything to migrate existing code to new platforms. I'm not sure I understand how development of a piece of migration application code requires a knowledge of every third-party application in the universe. Presumably, the Asterisk development team does know when it changes the syntax of some command in the existing API. Why then would it be so difficult to provide another application that translated the "old code" into the "new syntax?" That doesn't require that any third-party apps be reviewed. And it doesn't stymie future development. Just provide the tool to fix stuff that you broke!

Jared Smith: "Last but not least, let's talk directly about your bug report. In it, you claim that 'Lack of native support for either Flite or Cepstral TTS breaks thousands of existing text-to-speech Asterisk applications.' Asterisk has never had native support for either Cepstral or Flite for text-to-speech, so I'm not sure how not having it in Asterisk 1.6 breaks anything. I'm afraid that if I were to follow your logic to its logical conclusion, it would be better to write that as 'Since the developer that wrote app_swift won't update the code for Asterisk 1.6, it's Digium's responsibility to do so.' Again, I've got to point out that Flite and app_swift are totally outside the control of the Asterisk development team."

Uncle Ward: Wrong again. What the Asterisk developers can control is making sure that, when a change is made to the API, they either support the new and old syntax or, in the alternative, that the developers provide a separate tool to convert existing source code to the newly-created syntax. That's what any responsible developer would do. This isn't a problem with a third-party application developer refusing to update his or her code. Many of these developers are no longer available or reachable. So it behooves the proponent of changes that impact the operation of existing telephony systems to provide a migration vehicle to the new platform. It's as simple as that. Give it some more thought, Jared. There's a lot more than either of us may appreciate riding on the outcome of our discussion.