Adhearsion Blog by Jay Phillips

I’ve been surprised by the amount of hostility to the iPad out there. Some disinterest I can understand but most of what I hear is just unimaginative trolling.

I’m excited about the iPad. Here’s why.

iPad as a Minimalist’s Laptop Replacement

My personal history of computer use has been a story of habit hacking and employment of various tools for self-control. As everyone reading this surely knows, it’s all too easy to lose valuable time endlessly browsing the internet or trying to fight off applications competing for your attention.

To figure out how I work best, I experiment. I’ve tried all kinds of them over the years. For a few months several years ago I even used a Gentoo install with no graphical system installed whatsoever as my main desktop. I used vim for coding, links for web browsing, mplayer and mpg321 for listening to music, pine for email, ircii for IRC, and ssh (naturally) for managing remote servers. I switched back to GNOME because doing serious CSS development wasn’t practical without a GUI. I’ve also experimented with the ideas outlined in Getting Things Done, The Pomodoro Technique, and Time Management for System Administrators. I care a lot about trying to hack my brain to balance efficiency, entertainment, and ingestion of information. I’m still not happy at all with my daily routine and probably don’t work any better than the average person, despite the diligence I’ve put into exploring my options.

If there’s one thing I’ve found that does help my productivity, it’s attention to User Experience (UX) design. Few can dispute that Apple is the vanguard of that space. Switching almost entirely to Apple products (from generic PC hardware running Linux) was probably the most success I’ve had managing complexity. I think they do such a consistently great (not perfect) job at making things I enjoy using with just enough minimalism.

Now that I have a fantastic desktop workstation at home, I find that I use my aging laptop only for mostly trivial things. I go to a lot of conferences, go on a lot of business trips, fly in a lot of planes, watch a lot of movies (or Star Trek) while browsing the web, and occasionally hang out at a coffee shop to ameliorate acute cabin fever. In these cases serious computer usage is not a priority. In fact, for these uses, most of the hardware and software of a laptop is a liability and only adds weight and drains battery.

For just about all the reasons that I use a laptop, the iPad would do the job better. The 8-10 hour battery life is fantastic and two to five times better than what I can get out of my laptop.

The iPad doesn’t have first-class multi-tasking but the authors of the productivity methodology resources I mentioned would likely say this is fortuitously useful. If I’m writing a blog post on my iPad in a coffee shop, does it really matter whether I can make a Skype call or browse the web concurrently? I expect OS upgrades to the iPad to add some level of multi-tasking in the future but, for what I plan to use the iPad for, I probably wouldn’t use it very much. Like the iPhone, I’d still get push notifications and be able to listen to music while I write so it does have the rudimentary mutli-tasking that I would personally care about.

Although I rarely use my laptop for serious programming anymore, I figure I could still do it on the iPad with the keyboard dock and a ssh terminal application connecting to my main development machine at home. This would be no different from my text-based Gentoo days that I enjoyed quite a lot. As MacRuby matures, I’m sure someone will build a Ruby development environment similar to TextMate in which I could program graphically. I don’t see why the lack of multi-tasking should affect the usability of that IDE much if the app is capable of executing the code and letting me switch to a modal embedded web browser.

iPad as an Innovation Playground

And then there’s my geeky imaginative side.

When I contemplate the iPad as a platform for applications and games, I can’t stop ideas from wildly popping into my head. The iPhone as a platform was nothing short of a success and I expect the iPad to have a lot of pleasant surprises in store (pun intended!) for everyone.

Whether you like the gadget or not, you have to admit that it’s a turning point in the evolution of personal computing. The long-fabled touchscreen paradigm is finally making inroads into the market. As a newbie iPhone/CocoaTouch developer, I look forward to writing iPad applications for a truly unexplored world of computing.

Constructive Criticism

Why wasn’t there this much criticism when Google Chrome OS was announced and seeded out to the developer community? If critics of the iPad have such a hard time imagining what a user would do with one, Chrome OS should seem like an elaborate exercise in pathological lunacy. I suspect we’ll never hear proportionately impassioned criticism of Chrome OS because objectivity isn’t their objective — unconditionally denigrating Apple is.

Granted, Chrome OS wasn’t hyped up to the the extent that the iPad was. I don’t think the iPad deserved so much furor — it’s unfortunate that others’ actions are backfiring on it. The first-gen iPad does feel like a letdown in a number of areas. Here are a couple things that annoy the crap out of me:

• The iPad marketing campaign, especially the promo video. Way too childish.
• Steve Jobs’ announcement keynote. Jobs is usually a great presenter. This was the worst presentation I’ve seen him give.
• The Micro-SIM dependency. This is absolutely outrageous. I definitely won’t be buying the 3G version. This is the sleaziest thing I’ve ever seen Apple do. Epic fail.
• The lack of a front-facing camera. I don’t care about a back-facing camera but video conferencing would be pretty sweet. Would I ever use it? Hard to say.
• The website saying “140,000 apps from day one.” This is only half-true. Except maybe some of the games, I don’t want to use iPhone apps on my iPad, Apple. It’s hard to argue with the critics who say it’s “just a big iPhone” when this is how they market it. I’m excited by the iPad-only apps.

Conclusion

Like I said, I experiment with varying levels of minimalism. I’m proud of the fact I bought an iPhone on the day it was released and I’ll probably buy an iPad also on its first day. Whether I’ll be proud of that remains to be seen. For my personal needs, the iPad seems to be the best thing on the market with which to replace my laptop and generally make my life more enjoyable when I’m not in my typical work setting. If I’m lucky, I’ll also get the thrill of building useful or fun apps for a totally new class of computers.

All things considered, I think it’s a cool little device.

Since I’ve been in the telephony space I’ve noticed a huge change in myself: I went from being a passionate dreamer to a cranky cynic in a very short time. Although I no longer consider myself a part of the telephony industry, I like to follow where it’s going and occasionally pontificate. My Twitter account has killed my blogging to a large extent but I recently tweeted about something worthy of this full blog post.

Last week the blogosphere went abuzz reporting that a very widely-used algorithm used to encrypt cell phones’ audio has been cracked. I’m not a cryptogeek so my original reaction was basically “Fun! Go hackers!” After all, it was just like that scene from the hacker movie Takedown when Tsutomu Shimomura, the guy credited with catching Kevin Mitnick, is sitting in front of a congressional panel with a phone in his hand actively eavesdropping in on surrounding phone calls. Cool, right???

After looking into the details of how the hack works, I find it warranting much more seriousness than a flippant dismissal. This isn’t a cryptogeek issue. This is a real exploit warranting real concern and offering the fortuitous potential to bare a new industry and cripple another. Enter VoIP.

What happened to VoIP?

In my dreamer days, I expected VoIP’s merits to have fatefully forced Big Telecom’s capitalistic abdication by now. Today, in a new decade even, I don’t see much of any progress at all in the VoIP industry by anyone besides Skype. Instead of residential users switching from landlines to VoIP, they’re switching from landlines to a cell phone. Makes sense; modern cell phones are the perfect candidate for truly “personal” computing demands. The PC at home is for less “personal” stuff.

You might think that’d be the end of the story. VoIP stays the solution for business desk phones and backend infrastructure. Maybe not. Compounding the cell phone vulnerability news, AT&T now loosely forbids sale of iPhones to customers living in New York City due to chronic network congestion. This is yet another reminder why we’ve culturally accepted the screaming of profanity at phone companies like we do the government. My own city of San Francisco is often cited as the 2nd worst place for cell phones after New York City (but we’re #1 for cursing about the government!) and I can wholeheartedly testify to how miserable, often useless, the reception is here.

VoIP as a solution

At the risk of seeming melodramatic, let me pose two totally plausible anecdotes to make my point:

Before: Imagine taking a business trip to New York City in the near future. You’re walking to your customer’s office while talking on your Google phone with a business associate back home. Somewhat frighteningly, you can scarcely hear your partner discussing details about the meeting you’ll soon attend. When you get to the lobby of your customer’s skyscraper, you notice the signal strength is fantastic and call your associate back with little concern about further drops. Unbeknownst to you, however, a device about the size of a chair is servicing your phone call in a small office in the building rented indirectly by a hacker. Every phone call and text message in the skyscraper are being systematically recorded, decrypted, annotated with metadata, and sold on the information black market. No one in the skyscraper has suspected that their cell phone provider of all things is the enabler of their identity theft and espionage against their employer.

After: On your way to the customer’s office, you and your associate are intensely discussing the meeting you’ll soon attend. You’re using the cell towers but, hey, you have five bars. As you walk into the skyscraper’s office, you notice a brief hiccup in the audio and suddenly the call is in wide-band “high definition” audio. To prevent others in the lobby from overhearing your sensitive conversation, you walk to a more private area near the elevators. After a few minutes, a women steps out of the closest elevator and looks at you for a moment, perplexed. She asks “How do you cell reception here? My calls always drop near the elevators.” You reply “My phone switched over to wifi when I walked into the building.” The hacker won’t be selling your calls’ audio to anyone. Your high-definition calls are fully encrypted by your VoIP provider, whom you use for the phone at home, at the office on your desk, and on all domestic and international business trips (with no roaming fees).

Put simply, I think mobile VoIP can solve NYC’s congestion problems and solve the impending cell phone privacy crisis in one stroke. Mobile VoIP providers have existed for several years now. Skype, Truphone, and Fring all fight over this space. Truphone has even had the seamless carrier to wifi transitioning since early 2007. (Disclaimer: I was a Truphone consultant a few years ago.) The reasons I think mobile VoIP hasn’t caught on are threefold:

• Until very recently, carriers have been forbidding VoIP. That’s changing. Because of this, however, …
• Consumers haven’t demanded mobile VoIP, therefore …
• Most mobile phone platforms don’t support the features in my example that would make it convenient.

I refer to news about GSM being cracked as “VoIP’s Best News, Ever” because, finally, VoIP gets a new selling point that everyone can understand: security. If I ran a mobile or residential VoIP company, I’d do everything I could to assist the commoditization of GSM cracking tools, especially for A5/3, the encryption algorithm to which carriers have begun switching. Not because I enjoy Schadenfreude as the world laments but because it’s the quickest way to solve the problem: motivate the movement of control away from the oligopoly to the innovative market.

The last mile now requires iPhone and Android to follow Symbian’s lead by baking VoIP stacks into their platforms with encryption support. Like with Symbian, applications must be able to mimic an incoming call and intercept the default phone applications’ “Dial” button to launch VoIP calls. Android is far more prepared to do this than the iPhone is. In light of rumors about Google Voice’s iPhone and Android apps having built-in outbound VoIP, I think it’s only a matter of time before Google offers something just like the service in my anecdote above (sans inquisitive businesswomen).

Sorry for not posting anything at all for so long. I am still alive.

The video for the panel on which I spoke recently at the Golden Gate Ruby Conference is now online.

Click here to watch it.

Last July I spoke at what has become one of the most notorious Ruby conferences ever held: RubyFringe in Toronto. It was widely reported to be an enormous success and, in the punk-rock open-source spirit, RubyFringe did it without any corporate sponsors. Only fun, fringe projects and people allowed.

InfoQ, one of my favorite technology blogs of serious substance, was there interviewing the speakers and, just recently, they posted my interview on their site.

Click here to watch the interview.

If there’s even been a pivotal turning point for the Adhearsion project, it’s now.

We have several announcements to make all rolled up into this hugely important, albeit intentionally bite-size blog post. Each is extremely exciting and collectively I think they show the escalating pace of the Adhearsion space.

Meet Jason Goecke

Firstly, you may have noticed that I said “we have” instead of “I have.” Jason Goecke has been working with Adhearsion for many months and, until now, I haven’t properly introduced him to you all. Jason found the Adhearsion project in its earliest days and followed it at arm’s length for a few years as it matured. When we both found ourselves living in Silicon Valley, we met in person frequently and were excited about the potential future of Adhearsion if we combined forces. Jason has a strong background in telecoms and enterprise call centers. He was one of the earliest employees of Genesys, an early player in computer telephony integration, and is credited as an inventor on several of their patents.  Jason brings broad international business expertise and a deep technical competence to the project.

He’s joined the Adhearsion project full time and will become an increasingly familiar face of it. With his help the project’s progress has already been accelerating and, I’m excited and confident to say, will continue to do so.

New Adhearsion Version!

I’ve been talking about Adhearsion v0.8.x for a long time now and it’s finally here. What started as a simple revision became a complete rewrite with more irresistible features bolted on, causing bittersweet delays. The delays were painful and perhaps a cause of community worry but they were an important tradeoff with the inconvenience of forcing people to work with leaky abstractions or us maintaining backwards compatibility with dramatically different codebases.

We feel the fruits of our due diligence now exemplify the innovative philosophical and technological standards to which the Adhearsion project vehemently adheres. If you’re the technical type and would like to peruse what’s new, check out this page.

New Website

This has been a long time in the coming. If you periodically checked the Adhearsion site, you probably noticed quite a few different approaches we’ve taken as we bounced from wiki engine to wiki engine. I’ve finally settled on Confluence for docs.adhearsion.com and a custom Rails app to serve the only slightly dynamic main site Adhearsion.com. Communicating and organizing a lot of information effectively is always a problem for sophisticated open-source projects and the solutions we have now will be more future-friendly.

Free Adhearsion Sandbox

We’re especially excited about this bit of news. The Adhearsion sandbox fixes the problem we’ve had with enticing people to try telephony development. Setting up the underlying telephony platform has always been the most difficult task for Adhearsion newcomers and the sandbox makes this downright trivial.

Every new Adhearsion app now comes with an initially disabled component named “sandbox”. When this component is enabled with a user’s sandbox username and password, the newly started Adhearsion app will control any calls coming to the SIP URI username@sandbox.adhearsion.com. The user doesn’t even have to have ever heard the name Asterisk.This is a huge advancement in bringing voice development to the masses and the fact that Adhearsion is able to function this way by just enabling a plugin clearly affirms the potential the new Adhearsion version offers.

Try Adhearsion!

If you have been lurking in the community and waiting to give Adhearsion a try, now is the time. Check out the new Adhearsion.com site for more information!

Chris Matthieu of the Rubyology podcast interviewed me earlier today about Adhearsion. I was actually taking a nap just before he called me so the first few minutes of the podcast are me still waking up. Sorry that it starts out slow. It gets better further into the podcast, I promise.

Listen to the interview on the Rubyology website.

On the phone interview, I was using my Apple Bluetooth headset which, in retrospect, was an awful idea. Sorry if my voice sounds muffled at times.

Many thanks go out to Chris for having me on the show! You can subscribe to their feed with this link.

---

Quick Adhearsion update: Mark Spencer, creator of Asterisk, replied to my blog post entitled What We’re Not Admitting About Asterisk. I’ll be posting a full response to his comment soon. I’ve been caught up in some professional obligations which have delayed the effort.

I’ve migrated the hosting of the Adhearsion code base to Github.com, a site I’ve been super excited about and one which will immensely benefit the Adhearsion community. Github is the first site to get Web 2.0 right in the context of software development. If you haven’t heard of it before, you’re lucky you’re reading this post.  :)

You can click here to go view the Github Adhearsion project.

If I had to boil down the benefits of Github into one quick point, it’s basically this: hosting with Github increases the frequency with which others contribute code to you. It does this by making it dead simple. I explain the development workflow later in this post to give you a better idea of what I mean.

Github is founded around the Git SCM tool originally developed by Linus Torvalds to handle the Linux kernel’s massive quantity of code and contributors. Unlike Subversion or CVS, Git is a distributed version control system, thereby empowering users to work independently from a centralized system and merge their own version of the repository with peers as appropriate. The fantastic features that Github offers would not be possible if it it weren’t for this distributed, non-linear SCM paradigm.

Getting Adhearsion from Github

There are now three ways to get Adhearsion:

1. Install via RubyGems: gem install jicksta-adhearsion --source http://gems.github.com
2. Clone a local Git copy: git clone git://github.com/jicksta/adhearsion.git
3. Download a tarball of the latest code: http://github.com/jicksta/adhearsion/tarball/master

The Github development workflow

The development workflow of a Github project goes something like this:

Everything revolves around you, the user. Other users “fork” your project, make changes, commit to their own repository forked from yours, then send you a pull request when their contribution is implemented and tested. If you have doubts about their code you can view their commits’ colorized changelogs by simply clicking a link within their account’s modified clone of your repository. If you wish to try their code out yourself, you simply clone their repository to your hard disk. If everything checks out with you, you issue a Git command to merge their histories into your repository’s own. If you find an issue with their code pre-merge, you can make comments on a particular changelog or a particular line of code in a changelog.

There’s a subtle bit of clever Web 2.0 trickery going on with this forking action. When a user forks a repository, let’s say Adhearsion, her account page displays “adhearsion” among her projects. Users who watch her receive a notification that she forked it. Users who watch her see each of her commits to the forked repository. Her changes accepted upstream fully reflect her commits with her full name, username, email, and even her account avatar. See how the social graph comes together with reputation incentives? It’s totally brilliant.

Other perks include:

• Interactive visualizations of forking activity, as seen above
• For Ruby projects with a .gemspec in their repository, Github can automatically generate a RubyGem and store it on the Github gem server, accessible to anyone with the gem command.
• Open-source projects are free to host with Github
• Github projects can use “web hooks” which will notify other services of commits. For example, any commit to Adhearsion is logged in the Adhearsion IRC channel. Github also supports Basecamp, email notifications, Twitter, Lighthouse, a raw JSON HTTP POST, and more.
• Giving commit rights is dead simple
• Don’t have Git? Github lets you download a tarball of the code.
• RSS feeds are generated for just about anything
• Github will auto-detect README files and display them.
• You can “watch” other repositories which interest you and others can “watch” you.
• Syntax highlighting in the code browser

Fork Me!

If you ever considered contributing to Adhearsion, it’s never been easier. Here are a few good Git resources:

• Github guides
• Git-SCM.com
• Git PeepCode Screencast ($9 for a 1 hour screencast!)
• Git crash course for Subversion users

Go register a Github account, fork the Adhearsion repo, and give it a shot!

The JAOO conference recently released the following video of Chad Fowler, Marcel Molina Jr. and Glenn Vanderburg answering the question “What is the next killer app for Ruby?” The video starts by them diving into a flattering discussion about Adhearsion as a candidate.

UPDATE: In response to this video and What We’re Not Admitting about Asterisk, the O’Reilly Radar blog mentioned this as well.

It’s time to clear up several restraining misconceptions in the telephony space. These are points I outlined during my presentation at AsteriskTag in Berlin recently, though they bear repeating for everyone’s sake.

This post is not the end of the discussion. Please feel free to leave comments on this post and subscribe to my RSS feed. This post gets a lot off my chest but I’ve a growing list of things to address very soon.

If there’s one thing I want you to understand, it’s this:

Asterisk Has Not Crossed the Chasm Yet.

I’m referring of course to the chasm in the technology adoption curve, best illustrated in the graph above (after which Geoffrey Moore’s book Crossing the Chasm was named).

To those unfamiliar with the concept, it defines five demographics of technological adopters. The first two, innovators and pragmatists (visionaries), give a new technology its first breaks; the bleeding edge is either a passion or a competitive advantage to them. Beyond these demographics exists a chasm which every technology must suffer and overcome to enter the lucrative early majority market.

One fascinating characteristic of technology adoption (which Geoffrey Moore introduces early in his book) is the false sense of security it can create when the rush of enthusiasm comes from the early adopters (left of the chasm). To the company, it’s easy to assume this adoption will continue linearly into eventual ubiquity. This misconception has crushed many a dream when the unsuspecting company ramps up just as their adoption profile plateaus at the chasm. I feel Digium has been caught up in this misconception.

I’m convinced because, in my 2.5 years of trying to make Asterisk better, I keep seeing the same kind of person approach me either online or offline at a conference. Let’s call him Otto. He’s the young, inspired hacker fascinated with the thought of controlling a phone. I was Otto once. He finds documentation, overcomes the installation, gets a “Hello World” working, then stops. Beyond that point Asterisk becomes prohibitively unintuitive and that impression sticks and becomes a reputation.

This quintessential newbie we’re calling Otto can then do two things: leave the community altogether or stick with it and complete a single project or even series of Asterisk projects. My experiences in the open-source telephony space have revealed two observations of mine you should consider:

The average amount of time a developer plays with Asterisk is less than one week.

The developer retention rate of Asterisk is less than 1%.

These observations encompass everyone who has ever considered toying with Asterisk and taken the first step. A first step may be an “apt-get install asterisk”, buying the O’Reilly Asterisk book or even cracking it open online. I’d love for you to prove me wrong on these with real market research. I actually think the median time spent using Asterisk is just one weekend and the retention rate is less than 0.1% when you consider international hackers (like those to whom I spoke in Germany recently). I passionately care about this issue because, for the time being, open-source telephony and Asterisk are virtually synonymous. I want to see the entire ecosystem ramp up their expectations. And I want to help us win this fight for the advancement of technology around the world. That’s really what’s at stake.

The error is not a marketing error. Digium is a multimillion dollar company with a clear image: they make hardware and appliances for the SMB PBX market. This brand extends to the open-source Asterisk software which inherits the reputation and the hardware from this umbrella company. People understand what it is. Otto was already sold when he dove in.

The error here — the reason why Asterisk has not crossed the chasm — is technological.

Digium and its surrounding ecosystem has not engineered a Tipping Point. Specifically, they have not engineered Asterisk to be “sticky” enough to spread like wildfire, a task which should be the core to any open-source umbrella company. After all, open-source’s strongest advantage is its propensity to cause a wildfire effect. Many companies open their source because it’s free help that has an inextricable marketing effect. (I’m loosely citing Malcolm Gladwell’s book The Tipping Point here, another must-read for technologists.)

So what the hell is wrong here? Below I enumerate four more misperceptions that I think are immensely damaging to the Asterisk ecosystem and are preventing Asterisk from becoming “sticky” enough to cross the chasm.

Truth: If You Build an Asterisk System, You’re an Asterisk Developer.

An improper (and more common) way to phrase this sentence would be “If you configure Asterisk, you are an Asterisk user.” Though only a subtle terminology difference, thinking of Asterisk “users” as “developers” opens the door for us to treat them as such.

Geeky internet citizens can likely remember seeing at some point the notorious video of Steve Ballmer running around a Microsoft stage screaming “DEVELOPERS! DEVELOPERS! DEVELOPERS!” Microsoft is starting to understand what has empowered the open-source world to become an unstoppable deus ex machina: it’s about the developers, man! Open-source is a philosophy which places developers at the forefront with the fewest restrictions. And it’s extremely successful! Last year Steve Ballmer said with a straight face “I would love to see all open source innovation happen on top of Windows.” He’s an enemy and, because he understands this principle, he’s an especially dangerous enemy. Microsoft has entered the voice market and is now competing with Digium. And Microsoft’s even doing many things right technologically! We need to react.

We can react by treating users of Asterisk as developers, not system administrators. This is a technological truth that has been glaringly obvious but shamefully ignored. By “developer” I do still mean someone who touches only the “configuration” files which Asterisk provides, not someone who modifies the C code with which Asterisk itself is written. I call these people developers for the following reason.

Truth: When You Write extensions.conf, You Are Writing Software.

To those unfamiliar with the technicalities of Asterisk, extensions.conf is the main “configuration” file in which the dial plan is written — the logic that controls the procedures that occur during calls that go through your Asterisk system.

My stating that extensions.conf is software always gets an amusing reaction from the average Asterisk hacker. It usually goes something like this:

“When you write extensions.conf, you’re writing software.”

“Well, extensions.conf started out as a very simple solution to solve Asterisk’s initially simple problems. It was not designed to be a full-feature programming language.”

“But it’s now a language with functions, control statements, loops, labels, conditions, variables, even macros and subroutines!”

“Yeah, but it’s not a programming language. It wasn’t mean to be.”

I’ve heard this from several people over and over. The Asterisk hacker with whom I’m conversing generally concedes the point after various facial color changes. Let’s at long last admit this, guys: the extensions.conf grammar (and the derived syntactical alternative AEL) are very poorly designed dynamically-typed scripting languages. Someone who modifies this file is called a programmer. The extensions.conf file is what we call software. A .conf file extension should only be used for configuration files. With these (irrefutable) assertions in place, we can start to frame the picture of what the next approach should be.

Our oversight of this subject has had an interesting effect. I’d say the biggest demographic of Asterisk users is the sysadmin type who feels no anxiety toward a “configuration file” but may feel a little anxiety toward modifying a “.c”, “.java”, “.rb” or “.py” file. This distinction between a .conf and “real code” is mostly superficial. I say “mostly” because, when the Asterisk developer must modify a C file which performs the same function as extensions.conf, the distinction is greater because she knows that there are a lot of ways to easily screw up the entire PBX, having disastrous consequences. This is exactly why Asterisk’s monolithic voicemail system has gained a bad reputation: it’s written in C and difficult or dangerous to modify.

When we acknowledge that extensions.conf is a scripting language, one abstracted deeply from the dangers of the machine language paradigm in an attempt to improve productivity, the discussions to “improve the Asterisk developer experience” inevitably conclude that a real scripting language must be used. For today’s and tomorrow’s complex uses of Asterisk, the scripting language in place now completely breaks down on several fronts.

This is not a blog post about Adhearsion, but this is where I have extensive experience on this subject through my years implementing it. When we take the first step and begin developing scripting language support for a telephony platform, I’ve found that what’s also really needed is a framework that further abstracts the legacy Asterisk paradigm into what should be a DRY (Don’t Repeat Yourself!) user experience. The framework can provide a plugin system so people can trade small units of functionality at little risk. The framework can allow better bundling of those applications. The framework can make deployment assumptions. The framework can evolve and provide new framework-level hooks into other disparate technologies that were previous unthought of.

I’m extremely passionate about this subject and can continue extensively on it. Let’s save that for later and continue. Grab my feed if you’re interested.

There’s a Difference Between an “Asterisk Application” and an “Asterisk System”

On this point it seems I diverge completely from the Asterisk status quo. During Mark Spencer’s great keynote at AsteriskTag, he gave a fun list of Asterisk applications as a way of inspiring the community to innovate. The list included about nine Asterisk “applications” such as the Botanicalls project to receive phone calls from your anthropomorphized plants when they’re thirsty, a tongue-in-cheek queue game “application” that makes people waiting in a queue play a game instead of hear music (winners move up in the queue), an application for pilots to get aviation reports from any cell or landline phone. These are all great examples of using Asterisk, but they’re not “applications.”

These are examples of Asterisk “systems.” A non-trivial use of Asterisk (such as these) usually requires many custom shell scripts that adhere your program to other technologies. Frequently they’re tightly coupled to machine-specific assumptions such as the Linux distro choice, use of CURL, directory paths, sip.conf trunk names, extensions.conf context names, hardcoded database information, IP addresses and so forth. This tight coupling prevents easy distribution, therefore no one trades implementations and everyone reinvents the wheel.

These “systems” of interlocked clockwork are required because of the deficiencies in the extensions.conf scripting language. If dial plans were written in a high-level language, there would be no need to shell out to accomplish some small unit of functionality. Everything would be a part of your dial plan software. For this reason, the solution to this tight coupling is for a scripting framework to standardize what’s most commonly done in an abstracted, high-level way. Features that were not thought of are implemented as plugins. Plugins are shared and configured to achieve the desired effect.

I think of an Asterisk application like a desktop application. If I want a call center with a sophisticated, fine-tuned web interface that shows agents prompts with AJAX from a MySQL database, I should be able to go online and click a “Download Now” button somewhere. If I run a skydiving dropzone and want an application to manage the jump schedules with telephone reminders, I should be able to go online and download something pretty close to that. This expectation of “yeah, someone’s probably thought of that — let me go check online” is one that we’ve all grown familiar with in the open-source economy. For desktop software, this expectation of abundance is fundamentally powered by the ease with which desktop applications are distributed. For telephony software, this is completely not the case.

This is also one of my motivations behind Adhearsion’s design. It should be a default expectation of an Adhearsion app that the author wants to eventually distribute it online and help build a greater telephony application community. If they don’t want to, that’s fine, but I shouldn’t stop them.

And if an open-source economy emerges around telephony applications, we’ll begin attracting people who would have never otherwise thought that they could actually use telephony to their advantage. By increasing our reach and relevance, we’ll be engineering a Tipping Point.

Telephony is Too Complicated for Every Hacker to Have a PBX in Their Closet

This is something that Asterisk has little control over. Someone building an experimental personal application inevitably must use one of these two technologies: SIP trunks or a POTS (Plain Old Telephone Service) line with an analog telephony PCI card. There are fundamental problems with both of these approaches unfortunately. I’ll start with SIP trunks.

SIP trunking is a way for any computer to terminate a call onto the Publicly Switched Telephone Network by using a premium service. The VoIP software you’re using (e.g. Asterisk) places a pure-VoIP call to this service using your account credentials. With metadata that comes along with the VoIP call, the service operates the other leg of the call and terminates your packets in a way that can reach any phone in the world.

The problem with SIP trunking is simple economics. The people making the real profits in PSTN termination realize it’s not worth the overhead to deal with small fries who push only 1,000 minutes a month through their service. Instead, they’re looking for three orders of magnitude more usage. Small fries like you and me get service through people who resell the real providers’ services and operate at scale. Most companies you’ll find online for SIP trunking are actually three to six companies downstream from one of the multi-billion dollar companies that are really doing the terminations.

The effect is poor support, poor quality, and poor features. It’s a race to the bottom and the solo telephony hackers lose most.

One thing that’ll definitely work reliably is an analog card (like those that Digium sells) that handles the analog signaling into the landline phone jack on your wall. Unfortunately, these require a considerable financial investment and, by nature, don’t spread like wildfire. One can’t take a wild ride through the world of telephony development for a weekend as just an experiment when one must to drop hundreds of dollars and spend hours configuring Linux kernel modules to get started.

I vent this here because it’s stifling the Tipping Point of open-source VoIP and there is a solution. I’ll mention that in my conclusion.

Most people want something other than a PBX

I’m going to cite another technology book to make my point here: The Long Tail by Chris Anderson.

The Long Tail is a graphical concept which visualizes diverse products in the same market. It’s a fascinating subject and is perfectly applicable to the telephony space. There are certain applications that everyone wants: they form the Big Head. Fixating on this space is the orthodox business model. Then are are thousands of niches in The Long Tail that have legitimate business needs but the demand for a product that fits their needs is much smaller. In the past, production costs made producing for these niches economically infeasible. Now, open-source, VoIP and the World Wide Web has made it possible to not only develop these niche applications on a dime but actually reach the customers as well!

This is where the importance of the application comes back around. The PBX, albeit important, is just one application and the aggregate demand of non-PBX voice apps exceeds the demand for PBXs. Voice is something that’s now universally accessible (thanks to cell phones) and universally understood (everyone understands how to make a phone call). Given the needs of the entire world in this space, it’s a no-brainer that the SMB market is a minority. If you can apply voice to a problem creatively, you can spin straw into gold. Consultants take note.

The Manifest Telephony Destiny

It’s absolutely inevitable that voice applications saturate the Long Tail over time. Thanks to the internet and the fruit it has borne, the niches will become much less ignored. Let me call this the Manifest Telephony Destiny. Just as the pilgrims settled along the east coast of America and dreamed about spreading the country’s borders across all the way to the Pacific Ocean, we’re now the pilgrims who’ve settled on the Big Head of the Long Tail graph peering toward and dreaming about what lies to the right. It’s our Manifest Telephony Destiny to reach across far, far to the right of the graph. If you’re a businessman or businesswoman in voice today, understand this principle and believe it. Talk about it at your next board meeting. It’s coming, there’s money in it, and it’s about to pass you up. Open-source telephony is the enabler and the experts will reap the rewards.

The Bottom Line

Hopefully this post shoos away the aforementioned elephants in the room. We must change these perceptions because they are damaging to the open-source space and, by association, the entire world. I really believe that.

I’ve been thinking very critically about this industry for over a year now with my entrepreneur hat on. Over the past eighteen months I’ve been to over fifteen states and six foreign countries almost entirely on Adhearsion-related business. I’ve talked to many industry visionaries, newbies, respected technologists, entrepreneurs, and the technologically illiterate. This post crystalizes some of the lessons I’ve learned on this amazing journey, but an even more amazing journey awaits in the new company I’ve formed to ameliorate in a fundamental way my many frustrations with this industry.

Here’s what I’ll let out: its name is Adhearsion Inc. and it’s not consulting. We’re currently seeking private funding. If you are or know of investors, send me an email at jay-at-adhearsion-dot-com. We think we know how to turn the industry around.

Stay tuned for more from my mind. 

Lots of people have been asking me about this blog. When this site was actually up and reachable, which in itself was seldom, visitors would find that I’ve left it entirely untouched for over five months.

Well, it’s back and better than ever now. I’ve come full circle in my choice of blog engines:

• I initially used Wordpress in the very early days
• I then migrated to a blog engine I wrote with Ruby on Rails called Gosling in mid-2006
• Frustrated by leaving features behind, I moved to Mephisto in its early days
• I then tried Typo after finding Mephisto green at the time
• And I’ve now switched back to Wordpress

Wordpress is one of the few blogging engines that’s both open-source and has a profitable company backing its development. I’m impressed with what they and the amazing community around it have added in the past two years and I’m sure they’ll continue impressing me.

There were two initial compromises:

• Comments from before have been temporarily lost.
• Your RSS reader may show every post on this blog to be new and unread.

Apologies to those who care at all. Now onto blogging again!