Asterisk SCF – Pause

Working with the Asterisk community is a privilege which comes with responsibilities – and today I bring news of something that has not worked out as we anticipated it might.

The Asterisk SCF project was started a couple of years ago (you may remember an early demo at AstriCon 2010, in Washington, DC) and since then work has been on-going. While SCF was never intended to be a replacement for Asterisk, it did represent an architectural advancement for open source communications. Currently there is a working version of the code that is publicly available.

During this time period, Asterisk has also evolved: you may have noticed that performance has been improved, many new features have been added, and architectural upgrades, such as improved media handling, have been incorporated into recent versions. While this clearly does not satisfy all the goals of Asterisk SCF, it certainly represents a significant step in improving the experience for Asterisk users.

Although the community has provided assistance in guiding the Asterisk SCF project, Digium has provided almost all of the software development effort. Due to the sheer complexity, the Asterisk SCF project has yet to progress to a point that enables significant development contribution from the community, and the level of resource investment required to adequately sponsor and maintain both Asterisk and Asterisk SCF is simply stretching the company too thinly.

Therefore, the decision has been made to suspend our development work on the Asterisk SCF open source project, in order to more fully support the needs of the Asterisk community.

There may well be some community developers that would like to work with the current version of Asterisk SCF so we will continue to make the code publicly available, although Digium will not be supporting the software in the same manner to which Asterisk community members are accustomed.

Valuable lessons have been learned in the process of working on Asterisk SCF. Some of these are directly applicable to Asterisk, and will be beneficial during the development of Asterisk 12 and, indeed, all future releases.

For now, we would like to thank everyone who has participated in the direction and development of Asterisk SCF for their efforts. If you are interested in discussing how some of the goals and experience from Asterisk SCF can be applied to Asterisk, please join us for the DevCon event at Astricon.

David

About the author

David works with the Worldwide Asterisk Community for Digium, and is an Asterisk enthusiast in addition to being a Chartered Engineer, globally experienced trainer and public speaker. His experience includes Air Traffic Control communications, Wireless Local Loop, Mobile Networks, Computer Telephony, Voice over IP and Asterisk specifically. In addition to many web articles, David's publications include Asterisk 1.4: The Professional's Guide (Packt, co-author) and the contribution of a chapter (on Internationalisation) to Asterisk: The Definitive Guide (O'Reilly). David is a frequent speaker at Astricon (THE annual global Asterisk event, where David often runs an Asterisk-based contest), AsterConference Asia (David has also MC'd at this event), IT Expo (East and West) and a number of corporate events. He has also spoken at numerous other conferences - VoIP Developer, Speech World, CT Expo and UC Expo to name a few. David has also delivered Presentation Skills training and coaches Executives on Public Speaking.

7 Responses to “Asterisk SCF – Pause”

  1. Pejman

    This is a big disappointment for those of us who were patiently waiting for the real carrier grade solution by Asterisk.
    Is there any way to continue this project if some of us out there commit to monetary contributions?

  2. Tim

    I guess my question is the other direction, does this mean Digium will be doing more Switchvox development. I would love to have SV be a real commercial solution, including roadmaps, bug databases, and a feature request system.

  3. David Duffett

    David Duffett

    Pejman, thank you for commenting on this post. Sorry about the delay in responding. As mentioned in the blog post, the code – as it stands right now – is freely available for any individual or group to run with, and so can be continued as those wishing to take it forward see fit.
    When you say ‘real carrier grade solution’, what specific features are you looking for?

  4. Omid Mohajerani

    thanks David to inform us .

  5. Rebecca Robinson

    I’m looking for better clustering capability with the ability to migrate a call to another server in the event that a server dies, and the ability to share a queue across multiple servers.

  6. Peter Styk

    SCF Should continue. Please keep innovating. Don’t end up like one of those companies who thinks it has it all. Remember: “All good things must come to an end”… and they do.

    Your inability to attract talent to this project shouldn’t be confused with lack of interest of the community.

    Your leaders surely understand this will keep the company going for the next 15 years. Look at long term commitment from RedHat to open source projects like oVirt.

    Your technology selection for delivery is also something to think about. I understand mistakes hurt, bad decisions in architecture set you back and you feel like you have not accomplished much. This is bad thinking as well. Imagine Edison gave up with the light bulb instead he kept finding more ways it couldn’t work.

    I vouch for Python, bootstrapping, kickstarts, aws cloudformation scripts. Do not be afraid to have this in clear text. Python will pay back with much demanded community interest.

    And to quote Tim Allen from my fav geek movie “Never give up, never surrender!”

Leave a Reply