{"id":2312,"date":"2008-08-14T10:31:47","date_gmt":"2008-08-14T14:31:47","guid":{"rendered":"http:\/\/blog.voipsupply.com\/?p=2312"},"modified":"2008-08-14T10:31:47","modified_gmt":"2008-08-14T14:31:47","slug":"jay-phillips-and-mark-spencer-square-off-over-asterisk-critique","status":"publish","type":"post","link":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/jay-phillips-and-mark-spencer-square-off-over-asterisk-critique\/","title":{"rendered":"Jay Phillips and Mark Spencer Square Off Over Asterisk Critique"},"content":{"rendered":"

Jay Phillips, the creator of Adhearsion, a RUBY development framework for Asterisk, recently called out Digium<\/a>for failing to make Asterisk sufficiently accessible to developers. While it is clear that Phillips has his own entrepreneurial agenda, he asserts that Asterisk alienates would-be developers by presenting an often cryptic, non-intuitive interface.<\/p>\n

Jay goes on in detail concerning a laundry list of issues that he believes are limiting the proliferation of Asterisk beyond first adopter types.
\n
\nIn response to Jay’s diatribe, Mark Spencer of Digium responded with his own lengthy counterpoint, the text of which I have reposted below. As I said, Mark’s retort is extensive, but I found it to be a pretty fascinating collision of viewpoints.<\/p>\n

Recently Jay Phillips of Adhearsion fame sent me
\na blog he\u2019s written about Asterisk and asked me
\nto respond to it, which of course I\u2019m happy to
\ndo. First, I have to say that I met Jay at
\nAstricon and was immediately impressed with his
\nenergy and excitement around Adhearsion. To say
\nJay is an out of box thinker is probably
\nsomething of an understatement, and it is great
\nto have people working with Asterisk building the
\ntypes of tools that Jay is developing. Jay and I
\nhave talked quite a bit with each other on
\nsubjects regarding Asterisk and Adhearsion, and I
\nrecall an article on Adhearsion was written
\nby Jay on the dock of my weekend place. I hope
\nthat we can continue this discussion as a
\nconversation of ideas regarding how Asterisk can
\ncontinue to evolve, even if we disagree on some
\nof the notions that each of us bring to the
\ntable. While I may not entirely understand some
\nof Jay\u2019s issues he outlines in his posting,
\nperhaps my comments on some of what I believe
\nare his points will help us both better
\nunderstand where improvements or clarifications
\ncan be made.<\/p>\n

I\u2019m going to try to address Jay\u2019s blog point by
\npoint, but it\u2019s made complicated by Jay\u2019s having
\nmixed so many business metaphors and by leaving
\nterms like \u201cmarket\u201d unspecified or variable.
\nAlso, Jay, like my mother, seems to have issues
\ndifferentiating between \u201cfact\u201d and \u201chis personal
\nopinion\u201d. Much as mom thinks I should like
\nsalmon because \u201cit\u2019s good\u201d, Jay makes a number of
\nassertions which are simply his opinion, but he
\nstates them as fact. I\u2019ll try to point some of
\nthese out, and where possible I will try to use
\nactual metrics to either support or refute those
\nclaims, and where not possible, some research
\nwould be required to be able to support them.
\nLets start with Jay\u2019s largest \u201cone thing\u201d he
\nwants us to understand, that \u201cAsterisk Has Not
\nCrossed the Chasm Yet\u201d. The first, most
\nfundamental problem with trying to address such a
\nstatement is that Jay hasn\u2019t actually chosen a
\nmarket. It\u2019s much easier to try to decide if the
\n\u201ciPhone\u201d has crossed the chasm or not because its
\npurpose is generally clear. It\u2019s a phone, and
\nthe market is consumers. But what exactly *is*
\nAsterisk? Most people think of Asterisk as a
\nPBX, even though it is a great deal more today.
\nIs he saying that it has not crossed the chasm as
\na PBX? Jay is particularly interested in
\nAsterisk as a platform underlying his technology
\nfor developing applications. Is it that Asterisk
\nhas not crossed the chasm of being the defacto
\ndevelopment platform of choice for IVR
\napplications? For conferencing?<\/p>\n

Jay says he feels like Digium has been caught up
\nin the misconception of the growth of the
\nvisionary market. In reality though, Digium\u2019s
\nprimary market is not Jay\u2019s market, because
\nDigium\u2019s *commercial* focus is primarily on the
\nSMB and to some degree Enterprise PBX market \u2013
\nalmost certainly the largest *single market*
\ntelecom products that you can build with
\nAsterisk. Digium\u2019s *primary* business is not to
\nsell to developers like Jay, it\u2019s to sell to
\ncustomers like Joe\u2019s Laundry down the street,
\nthrough resellers and channels that almost all
\nfit in the early and late majority category.
\nDigium\u2019s work on expanding Switchvox and channels
\nclearly indicates that we *clearly* understand
\nthe importance of that market and precisely *are*
\ndoing the right things to cross the chasm in the
\nPBX market. We understand that the early and
\nlate majority customers are looking for a PBX
\nproduct that is feature rich, inexpensive and
\neasy to use, and that\u2019s precisely what we\u2019re
\nbuilding. You\u2019re not going to be able to take
\nregular open source Asterisk without any
\npackaging and try to take it to your average end
\nuser. It needs to look, feel and smell like
\nsomething they can actually use, and doing so
\ndemands the creation of a derivative work focused
\non the market you\u2019re going for, and *that\u2019s* what
\nyou\u2019re going to cross the chasm with. Jay says
\nthat Asterisk isn\u2019t sticky because it\u2019s too hard
\nfor an end user to use \u2014 and for many end users
\nthat may be true, but that\u2019s not the product that
\n*should* be bringing them \u2014 it\u2019s AsteriskNOW or
\nSwitchvox or some other, more cooked product,
\nthat is the right thing if you want a PBX.
\nThat\u2019s like saying that Chevy 350 small block is
\na lousy product because most people don\u2019t use it.
\nIt\u2019s not a bad product, it\u2019s just that people
\nwant cars, not just motors.<\/p>\n

Having said that though, the direct market for
\nAsterisk, as a project, is of course not early
\nand late majority PBX customers \u2014 it\u2019s
\ndevelopers who want to build products that
\ncustomers in turn will actually use. I *think*
\nthis is the \u201cmarket\u201d that Jay is actually
\naddressing with his \u201cOtto\u201d example, and it is a
\nmarket Digium is trying to pursue for Asterisk as
\nthe benevolent maintainer of the software \u2014 not
\nas its primary commercial interest (although
\ndon\u2019t get me wrong, we\u2019re happy to sell our wares
\nto developers as well!) Clearly if he was a
\ntraditional PBX customer without technical
\nbackground, downloading Asterisk and building \/
\ninstalling it on his own newly installed Linux is
\nnot likely the best place for him to start. If
\nOtto is a developer, then that\u2019s probably a good
\nway for him start (although AsteriskNOW might be
\na little better place to start). Jay calls
\nasterisk \u201cprohibitively unintuitive\u201d and if
\nyou\u2019ve never used Linux or a command line, that
\nmay be true, but if you\u2019re a developer, you\u2019ve
\nconfigured tons of things before, and something
\nlike AsteriskGUI can get you off to a running
\nstart from which you can start fooling around
\nwith some of the developer technologies, although
\ncurrently the best single source of those tools
\nmay be Google.<\/p>\n

Jay drives his opinion that \u201cthe average amount
\nof time a developer plays with Asterisk is less
\nthan one week\u201d and that \u201cthe developer retention
\nrate of Asterisk is less than 1%\u201d but in spite of
\nbeing in bold print, these are not statistics but
\nmerely his opinion. To my knowledge, no one has
\never really researched this, and I\u2019m uncertain
\neven anecdotal evidence of \u201csticky\u201d numbers of
\ndevelopers is significantly different than any
\nother major project that sees experimental use by
\nthe overall OSS developer community. In any
\ncase, Jay\u2019s premise seems to be that Asterisk is
\nsimply too difficult for a developer to build
\nfrom. Fortunately for us (and unfortunately for
\nhis argument), such a premise is largely in
\nconflict with reality. For example, lets look
\njust at a series of recent projects built at the
\nInteractive Telecommunications Program (ITP) at
\nNew York University:<\/p>\n

* Botanicalls – Your plants call you when they\u2019re
\nlow on water. Each plant has its own personality
\nbased on its species. Further development is to
\ninclude other environmental factors.<\/p>\n

* I-PLATE-U – Record and retrieve messages based
\non someones license plate. Heavily uses speech
\nrecognition to avoid having to type on the
\nkeyboard<\/p>\n

* Popularity Dialer – Calls you and plays one of
\n5 different pre-recorded \u201chalf conversations\u201d
\nincluding the \u201cCousin needs help\u201d call, to help
\nyou get out of a sticky situation and the
\noriginal \u201cpopularity\u201d call where your friend
\ncalls trying to get you to join your other
\nfriends, but you decline because you\u2019re on a
\nwonderful date.<\/p>\n

* Cause Caller – Automates the process of
\nallowing you to call in to politicians in support
\nof various political causes.<\/p>\n

* Booty Dialer – Automatically calls each entry
\non your \u201cbooty call\u201d list until someone responds
\npositively to the interrogatory, at which point
\nyour phone rings and you are connected with them
\ndirectly, saving lots of time.<\/p>\n

* Canal Street Station – Interactive telephony
\nmystery which is played out by calling a toll
\nfree number from various public pay phones in the
\ncanal street station<\/p>\n

* Rap Happy – Allows you to use your phone to
\nrecord rap music (presumably other music) via
\nyour phone.<\/p>\n

Now, obviously these are extremely creative
\napplications of Asterisk, but what is perhaps
\nmost interesting about these is that the ITP
\nprogram is not an engineering program \u2014 nor are
\nthe creators of these applications engineers \u2013
\nthey\u2019re artists, in the art department. This
\nprogram has taught them to use Asterisk as a
\nmedium for creating telephonic art, or at least
\ntaught them how to accomplish telephony tasks
\nwithout having a CS degree or years of
\ndevelopment and sysadmin experience. Of course
\nthere are lots of other business examples that
\nactually generate revenue, but the point is that
\nlots of people make real applications with
\nAsterisk today, even in its current form.<\/p>\n

So, do I think there\u2019s no truth to anything Jay
\nis suggesting on the API? First of all, like
\nJay, both Digium and myself want to see the
\nadvancement of the technology worldwide \u2014 that\u2019s
\nwhy we invest so heavily in Asterisk. How about
\nthis for a fact and \u2014 the largest single
\nengineering team at Digium is the team dedicated
\nto Open Source Asterisk development. Certainly I
\nagree there are improvements that can be made.
\nAsterisk has at least three different ways to
\n\u201cprogram\u201d it, including the manager API, the AGI
\ninterface and the various extensions languages
\nlike AEL and LUA. Like Jay says, Asterisk and
\nopen source telephony are virtually synonymous
\nbecause Asterisk has been around for such a long
\ntime that it is able to talk to virtually every
\nVoIP and TDM telephony technology. It has
\nvirtually every core traditional telephony
\napplication (like voicemail, call queues, ivr,
\nconferencing, etc) already integrated and has the
\nmaturity and stability to be relied upon by a
\nwide variety of OEMs, enterprises and businesses.
\nWhat Jay, Digium and I all want to do is to make
\nthose technologies as accessible as possible to
\nthe widest variety of developers who are going to
\ntake this core out to new places and create more
\napplications that haven\u2019t existed before.<\/p>\n

Jay proceeds to enumerate several specific
\nconcerns about Asterisk which again I\u2019ll try to
\naddress. Firstly, he mentions that if you build
\nan Asterisk system, you have to be a developer.
\nThis is no more true of Asterisk than it is of
\nApache or even SSHD for that matter. Each of
\nthose applications has various configuration
\nfiles that control its behavior. In each case,
\nyou can either use a graphical interface or you
\ncan choose to configure the system by manually
\nediting the files. That\u2019s a matter of personal
\npreference. By Jay\u2019s suggestion, anyone editing
\na config file is a developer. There is probably
\na continuum between developer and user wherein as
\na system becomes more flexible, and more options
\nare presented to the end user, their need for
\nunderstanding and abstracting concepts becomes
\nhigher. This is precisely why Asterisk is a
\nproduct for developers, and products like
\nAsteriskNOW or Switchvox are for end users, and
\nsimply utilize Asterisk as the functionality
\nprovider. I know Jay is annoyed that
\nextensions.conf is Turing equivalent, but hey,
\nthat\u2019s not how it was intended to be used, and if
\nyou choose to use that even when there are plenty
\nof other, easier to understand, easier to read
\nways of configuring Asterisk, that\u2019s your
\nprerogative just like you can choose to write in
\nassembly language if you wanted to. Just because
\nit\u2019s there doesn\u2019t mean you have to use it that
\nway. What extensions.conf *is* useful for is
\nlisting a bunch of extensions \u2014 precisely its
\noriginal purpose. And if you don\u2019t want to use
\nit, use the Asterisk GUI. Although Jay describes
\nthis as \u201cirrefutable\u201d evidence that configuring
\nAsterisk makes you a developer, it no more makes
\nyou a developer to configure Asterisk than it
\ndoes to use the bash command line, which by the
\nway is substantially more complex, also is Turing
\ncomplete, and people also use primarily for the
\npurpose of simple things (launching applications
\nfor example) and not sophisticated software
\ndevelopment.<\/p>\n

Jay also seems to be concerned that Asterisk is
\nwritten in C. One of Asterisk\u2019s core missions is
\nto scale and be efficient. Writing in a language
\nlike C that supports that goal is important to
\nallowing these creative apps that live on top of
\nAsterisk to be able to scale to the number of
\nusers that end up wanting to actually use them.
\nYes, programming in C requires you to be careful
\nin your programming, but I think it\u2019s worth the
\nextra effort to write a good program once to
\nallow the end user fantastically better
\nscalability in the long run.<\/p>\n

Leveraging Asterisk beyond just being a PBX is
\ntypically done at different levels depending on
\nthe sophistication of what is desired. If you\u2019re
\njust doing a basic IVR, you can largely do that
\nwithin AEL (or heaven forbid, extensions.conf)
\nusing many of the applications and variables
\nincluded within Asterisk. Granted, this is
\nlearning another language, but it\u2019s a language
\nvery specifically designed for operating within a
\nswitch, and its efficiency is tremendous because
\nit\u2019s so tightly coupled to the operation of the
\nsystem. Beyond the basic IVR\u2019s, people start
\nwanting to use a full-fledged general purpose
\nprogramming language. Which language to use,
\nhowever, is clearly not an area of agreement, as
\nevidenced by the AGI and AMI bindings for Perl,
\nJava, PHP, C, .NET, and many more\u0160 and of course
\nAdhearsion for Ruby. One important thing that I
\nthink we can try to do within Asterisk is to make
\nprimitives that more easily support binding of
\nother languages. Jay talks a lot about framework
\n\u2013 and framework is a great concept \u2014 but there
\nare lots of languages out there, and they largely
\neach have different frameworks and programming
\nparadigms about them, and each attract different
\nsorts of developers and lend themselves to
\ndifferent ideal applications.<\/p>\n

Asterisk, as with most telephony software,
\nsuffers from misperceptions about goals, and
\nthere are complaints no matter which side of the
\ndouble-edged sword is being swung. \u201cIt\u2019s too
\nhard to configure!\u201d is the cry that I hear from
\nthis post. But equally loud is the group who
\nyells \u201cI want to control all the details.\u201d We
\nagree that Asterisk is complex; but telephony is
\ncomplex in the details. This is not dissimilar
\nto Linux, firewalls, routers, mobile phones,
\nApache, databases, or a host of other complex
\nsystems which have various and sometimes
\ncompeting layers of control put in place over
\nthem to simplify adoption and integration.
\nIt is possible to abstract complex sets of
\nprimitive elements once you have a full
\ncollection of those primitive elements. It is
\n*not* possible to go the other way around.
\nAsterisk (the project) is working towards a
\n(more) complete set of basic functionality which
\nallows a developer to achieve as many telephony
\ntasks as possible, even when some of those tasks
\nmay be complex to develop if you are creating
\nthem from scratch. When we say \u201cdeveloper\u201d in
\nthis instance, it could mean either someone
\ndirectly building an application, or someone
\nbuilding an API into another programming
\nenvironment. We are hoping and encouraging
\nprojects like Adhearsion, FreePBX, the various
\nlanguage libraries, and others to create
\nabstraction layers and configuration layers on
\ntop of the Asterisk toolset in order to
\naccomplish specific goals which may be far
\noutside our ability to comprehensively predict or
\ndevelop. That is what we envision as our path
\ntowards the \u201cTipping Point\u201d for application
\ndevelopers.<\/p>\n

Jay continues by trying to describe a view of how
\nan Asterisk System and an Asterisk Application
\nare different. If you get at the core of the
\nconcern though, it\u2019s that he thinks people build
\nAsterisk systems in ways that aren\u2019t the ways he
\nwants to do them. He says they\u2019re built the way
\nthey are because of deficiencies in the
\nextensions.conf configuration format. Only
\nproblem with that logic is that if the
\nextensions.conf format was deficient, they would
\nobviously have used one of the other wide variety
\nof programming techniques available (maybe even
\nAdhearsion). If someone chooses to use AEL, or
\neven extensions.conf to create an application of
\nAsterisk, it is precisely because they *were*
\nable to do it with those systems that they chose
\nto do so, not because they couldn\u2019t \u2014 again,
\nhaving those systems doesn\u2019t take away from your
\nability to use any one of the native languages
\nand frameworks that are available for building
\napplications on Asterisk. Said another way:
\nDon\u2019t complain about what languages people use
\n(even if you want to call extensions.conf a
\nlanguage). Use what you like best, and let
\npeople choose what language they want to use!
\nThere certainly are a lot of them! Asterisk is
\n*already* being used as an underlying layer by a
\nhuge number of abstraction libraries – and we\u2019re
\nhoping to continue that trend to make programming
\ntelephony applications easier by developers in
\ntheir own environments. You don\u2019t need to be a
\ndialplan wizard to write applications that use
\nAsterisk: \u201cThere\u2019s more than one way to do it.\u201d<\/p>\n

Now, another point that Jay makes that I think is
\nvalid (and one Digium is trying to address) has
\nto do with how you install additional features
\nand applications in an Asterisk-based
\nenvironment. The Asterisk Marketplace is
\nprecisely intended to be a place to allow people
\nto have applications more readily distributed,
\nincluding through graphical interfaces, to be
\ninstalled not just on Asterisk but on PBX
\nproducts like AsteriskNOW and Switchvox. Sorry
\nto be vague on this one; stay tuned.<\/p>\n

To continue on: I think the \u201cThe Long Tail\u201d
\nillustration cited could not be more perfect. If
\nyou look at the green portion of the curve, that
\nis where Digium\u2019s primary business focus is
\nplaced, and if you look at the yellow portion,
\nthat\u2019s where Digium\u2019s primary focus for Asterisk
\nis placed. The former is best address by a
\nproduct and a company, and the latter by a
\nproject (in this case sponsored by a company),
\nwhere we enable lots of small micro-markets that
\ncan be attacked by a variety of developers
\nenabled by technologies like Asterisk either
\ndirectly or through interfaces like Adhearsion
\nand others. We actually agree on this point-
\nthere are more end users (ultimately) on the long
\ntail, even though that long tail is very long and
\nthin. Asterisk, the project, is doing all it can
\nto help with building apps out on that long tail
\nby creating a free toolset that developers can
\nuse to address their infinite niche markets.
\nThis \u201clong tail\u201d will exist because of tools like
\nAsterisk, not the other way around. Digium, the
\ncompany, is creating a set of products based on
\nor around Asterisk that address the head of the
\nmarket, which by far is the largest single niche
\nin the diagram by far. One end of the diagram
\nsupports the other – the products that Digium
\ncreates around the largest and leftmost portion
\nof the curve creates and supports the tools that
\nwill enable the proliferation of independent
\napplications that fill the \u201ctail\u201d on the right.<\/p>\n

After reviewing this article a few times, I am
\nmore unclear on what the issues are that Jay is
\nactually raising. This perhaps is due to my own
\nmyopia when looking closely at Asterisk and also
\nhaving a pre-conceived notion of what I feel are
\nthe shortcomings of the project today. As a
\npossible continuance of this discussion, perhaps
\na succinct list of problem statements would help
\nme in refocusing what we need to do to solve what
\nare obviously to Jay issues of concern.
\nCertainly I wouldn\u2019t claim Asterisk is perfect,
\nbut the developers in the community and within
\nDigium are interested in hearing the things that
\nare necessary, and then as they are needed, the
\ncode can be written to fit the solution. I
\nappreciate that the requirements are changing as
\nAsterisk becomes more mature – we\u2019ll try to stay
\non or ahead of the curve based on the
\nperceptions, requests, and most importantly, the
\nwork and contributions of the community.<\/p>\n

Reading between the lines in this post, it\u2019s
\nclear that Jay has what he believes is a great
\nidea with Adhearsion. I don\u2019t disagree – it\u2019s a
\nvery neat solution for people working with Ruby
\nOn Rails, and simplifies life for developers in
\nthat particular arena. Perhaps working so
\nclosely with high-level abstractions makes the
\ndetails of telephony a chore – this is
\nunderstandable, but I believe that additional
\ntools have been and will be built that allow us
\nto cross \u201cthe chasm\u201d for both developers and end
\nusers – I think we\u2019re crossing that chasm
\nalready. Perhaps after waiting a few months it
\nwill be the case that Jay\u2019s company will
\nannounce a more commercial solution to the set of
\nproblems he ambiguously identifies today; if so,
\nI would caution him not to become myopic in his
\nown way when identifying the uniqueness of his
\nown solution and how it resolves perceived
\nshortcomings of Asterisk. We\u2019re happy to see
\nmore interest building around the Asterisk
\necosystem, and we hope to help Adhearsion and
\nother firms build on Asterisk as the engine for
\ntheir telephony applications.<\/p>\n

In summary, I\u2019d say that Jay and I share the same
\ngoal of making Asterisk a more accessible
\ntechnology both for developers and for end users,
\nand I\u2019ve invited his participation in the future
\nof Asterisk at the next Astricon 2008 (and
\nsubsequent developer meeting), which he has
\neagerly accepted to particpate in! I look
\nforward as always to working with him.<\/p>\n

Mark<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

Jay Phillips, the creator of Adhearsion, a RUBY development framework for Asterisk, recently called out Digiumfor failing to make Asterisk sufficiently accessible to developers. While it is clear that Phillips has his own entrepreneurial agenda, he asserts that Asterisk alienates would-be developers by presenting an often cryptic, non-intuitive interface. Jay goes on in detail concerning […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1053,1217],"tags":[],"class_list":["post-2312","post","type-post","status-publish","format-standard","hentry","category-voip-commentary","category-voip-news"],"_links":{"self":[{"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/posts\/2312","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/comments?post=2312"}],"version-history":[{"count":0,"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/posts\/2312\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/media?parent=2312"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/categories?post=2312"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.voipsupply.com\/blog\/voip-insider\/wp-json\/wp\/v2\/tags?post=2312"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}