After the initial feedback on lack of Asterisk support for FreePBX, the dust have now settled.

But let's take a step back in time - approximately 15 months. Back then, the Trixbox people decided to spawn off their own version of FreePBX. I then stated that I really hoped that the FreePBX developers would not loose faith over this decision.

Fast forward to the last days announcements regarding version 3.0 of FreePBX.

Granted - it does not yet have Asterisk support, but keep in mind that this is a developer release, this means the support will eventually be there. As I will show in this article, is really does not matter if there is no Asterisk support yet.

There are two very important things we should take a closer look at with regards to version 3. One is the system becoming agnostic in lieu of which switch to use, the other is it's modularity.

System agnosticism is good for you

Before version 3, FreePBX was bound to Asterisk. This meant that people that wanted to use something else than Asterisk - but liked what FreePBX had to offer, did suffer. Both FreeSWITCH and Asterisk are quite capable systems used to build a PBX. However, there are also other systems out there like YATE and Bayonne which have their share of followers.

Becoming system agnostic means that developers of smaller systems, like YATE, suddenly have the ability to have a well designed Graphical User Interface for their systems. In fact, they can now piggyback on a very active project, which FreePBX is. No need to re-invent the wheeel to suit just their own platform.

This should, for all practical purposes, boost the number of supported soft switches - but only if developers from the various soft switch project see the the good thing FreePBX brings to the table (i.e. a well worked infrastructure for administrating a PBX). What remains to be seen, is if there are any of these projects that are willing to ditch their own work, and instead become FreeSWITCH contributors.

If the Phonebooth people, and TCAPI people, are willing to donate their code to the FreePBX project - then other should consider doing the same.

Modularism is always good, even for you

Yesterday I wrote that we could end up with FreePBX becoming a system only supporting the common lowest denominator with regards to the underlying soft switches in use.

Due to the modularity of the project, this should never happen.

FreePBX have chosen Kohana as their actual underlying programming framework. The little I have read about Kohana on their web page looks quite good. In fact it looks so good that I will have to spend some time with this framework in the near future. I was planning to use CakePHP, but Kohana looks something more for liking. In tandem with the Kohana framework, Doctrine was chosen as the layer between the underlying database and the programming framework.

Having really done my share of database development over the years, I have always regarded such middle-ware layers be in my way. True, they do speed up the development process - but they also make things extremely out of proportions when you have to debug. I hope for the FreePBX project's sake that they have done some really hard due diligence when choosing to add a database abstraction layer. For all I know, Doctrine may not be infested with all the diseases a lot of these abstraction layers have. Let's hope I am right.

An Open Source project done right from the start

Documentation and ISO images.

FreePBX version 3 have both. The documentation is extensive, even for a project in this phase. And - they have even taken the resources to create a fully functioning ISO image (coming soon to a HTTP server near you).

I have only one small gripe: Documentation by Wiki. Wiki's are good for unstructured information, however documentation is not unstructured information. A better solution would be to use the same principles that the PHP project itself has: The actual documentation appended by user comments. If one also throw in a discussion page (like what Mediawiki have), that would give the developers the best of both worlds.

However, a Wiki approach is good if there is a caretaker who will in fact create a STRUCTURED Table Of Content of the various wiki articles.

Ancestors

When we look at the ancestors for version 3 of FreePBX we quickly see why FreeSWITCH was supported from start.

The FreePBX project has incorporated code from two other, FreeSWITCH, based projects: Phonebooth and TCAPI.

Phonebooth was a FreeSWITCH Web Frontend, and TCAPI was a configuration API and GUI framework.

Incorporated is a weak word in this case. Incorporated is more suitable. TCAPI and FreePBX is now merged into the same project. It would also not make much sense for Bandwidth.com to fund two Open Source telephony front ends - to folding Phonebooth into the project makes a lot of sense.

There are no indications on the TCAPI or the Phonebooth web sites that these projects has been merged into FreePBX. This can thus be confusing for new users of Open Source telephony.

Commercial ramifications

What will happen to the many small companies that have invested a lot of resources in selling their Asterisk based system with their own GUI? Some of these GUIs are so good that FreePBX will not be able to compete within the foreseeable future. The number of such suppliers are very few.

The rest of the rat pack will either have to create better GUIs - or better - donate their time and resources to the FreePBX project. With the new FreePBX there is no reason why anyone in their sane mind would spend resources reinventing the wheel - unless of course they have some really radical approaches to PBX frontends.

If I where to start up a company selling Open Source based PBXes today I could then use FreePBX and have the choice of which underlying switch to use. This is good for business. I would also be sure that a lot of QA work would be done on the front end. In effect, my business model would not be selling a closed Open Source system, but access to my support and services.

Impact on Open Source Telephone Appliances

For "PC Based" appliances with a lot of CPU to burn, FreePBX could still be a very good choice.

For smaller, embedded solutions, like the ATCOM IP-series (soon to be reviewed on this blog) FreePBX is simply too heavy.

The future

With the release of version 3, FreePBX have gotten an even stronger hold on the Open Source telephony GUI market.

This is both good and bad, however I think it's mostly good.

It is good because the Open Source Telephony world could now have one centralized, platform agnostic, GUI. Hopefully people will acknowledge this and be willing to contribute.

On the bad, we could now have a monoculture - both technically, but also mentally. Depending on the people who manage the project we might after a while see lack of innovation and lack of willingness to incorporate innovative (i.e. disruptive to the project) extensions.

With such a strong code base, strong support (financially), and strong community - it will very hard for other Open Source telephony front ends to even begin to compete.