Page 349 - Asterisk™: The Future of Telephony

contestants in an episode of Junkyard Wars, trying to create functional devices out of
a pile of mismatched components.
The development methodology of a proprietary telephone system dictates that it will
have a huge number of features, and that the number of features will in large part
determine the price. Manufacturers will tell you that their products give you hundreds
of features, but if you only need five of them, who cares? Worse, if there’s one missing
feature you really can’t do without, the value of that system will be diluted by the fact
that it can’t completely address your needs.
The fact that a customer might only need 5 out of 500 features is ignored, and that
customer’s desire to have 5 unavailable features that address the needs of his business
‖
is dismissed as unreasonable. Until flexibility becomes standard, telecom will remain
stuck in the last century—all the VoIP in the world notwithstanding.
Asterisk addresses that problem directly and solves it in a way that few other telecom
systems can. This is extremely disruptive technology, in large part because it is based
on concepts that have been proven time and time again: “the closed-source world can-
not win an evolutionary arms race with open-source communities that can put orders
of magnitude more skilled time into a problem.” #

Open Architecture

One of the stumbling blocks of the traditional telecommunications industry has been
its apparent refusal to cooperate with itself. The big telecommunications giants have
all been around for over a hundred years. The concept of closed, proprietary systems
is so ingrained in their culture that even their attempts at standards compliancy are
tainted by their desire to get the jump on the competition, by adding that one feature
that no one else supports. For an example of this thinking, one simply has to look at
the VoIP products being offered by the telecom industry today. While they claim
standards compliance, the thought that you would actually expect to be able to connect
a Cisco phone to a Nortel switch, or that an Avaya voicemail system could be integrated
via IP to a Siemens PBX, is not one that bears discussing.
In the computer industry, things are different. Twenty years ago, if you bought an IBM
server, you needed an IBM network and IBM terminals to talk to it. Now, that IBM
server is likely to interconnect to Dell terminals though a Cisco network (and run Linux,
of all things). Anyone can easily think of thousands of variations on this theme. If any

‖ From the perspective of the closed-source industry, this attitude is understandable. In his book
The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley), Fred Brooks opined that “the
complexity and communication costs of a project rise with the square of the number of developers, while
work done only rises linearly.” Without a community-based development methodology, it is very difficult to
deliver products that at best are little more than incremental improvements over their predecessors, and at
worst are merely collections of patches.
# Eric S. Raymond, The Cathedral and the Bazaar.

The Promise of Open Source Telephony | 321