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.

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!

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

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. 

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!

Let’s say you’ve a really fancy Ruby on Rails web application with which you wish to integrate your new Adhearsion app. Though you may only need five or so of the thirty models that exist within the app, they’re inter-related somehow with has_many :through, belongs_to and a dozen other SQL fragments sprinkled about. That’s no good—looks like it’s all or nothing. Oh, and you’ve eight Rails plugins installed, of which five heavily modify ActiveRecord’s internals for your obscure purposes. That’s no good, either. Looks like it all of Rails or nothing.

You can now do this “all of Rails” integration extremely easily in Adhearsion. When you create a new Adhearsion app with trunk, you’ll see the following option in config/startup.rb:

config.enable_rails :path => “/path/to/your/rails/project”, :env => :development

And voila! Just uncomment this line and point it to the appropriate path. Adhearsion will do the rest.

When the Rails application loads, Adhearsion doesn’t bother initializing any of the web servers that may slow it down. The only real penalty is the negligible consumption of memory it brings with it.

Still more features to blog about! Stay tuned…

For the record, I’m totally excited about it. I’ve wished for something like this for over a year and only recently did I discover a way to get around the one technical limitation to implement it.

The problem

The menu() command solves the problem of building enormous input-fetching state machines in Ruby without first-class message passing facilities or an external DSL. After completely scrapping the feature several times and starting over, I eventually settled on my design of a state machine using a second-class message passing pattern. I’ll be writing about this pattern soon here.

Meet menu()

For now, here’s an example of menu():

from_pstn {
  menu 'welcome', 'for-spanish-press-8', 'main-ivr',
       :timeout => 8.seconds, :tries => 3 do |link|
    link.shipment_status  1
    link.ordering         2
    link.representative   4
    link.spanish          8
    link.employee         900..999
 
    link.on_invalid { play 'invalid' }
 
    link.on_premature_timeout do |str|
      play 'sorry'
    end
 
    link.on_failure do
      play 'goodbye'
      hangup
    end
  end
}
 
shipment_status {
  # Fetch a tracking number and pass it to a web service.
}
 
ordering {
  # Enter another menu that lets them enter credit card
  # information and place their order over the phone.
}
 
representative {
  # Place the caller into a queue
}
 
spanish {
  # Special options for the spanish menu.
}
 
employee {
  dial "SIP/#{extension}" # Overly simplistic
}

If you haven’t, take a minute to read the dialplan above before reading on.

The main detail to note is the declarations within the menu() command’s block. Each line seems to refer to a link object executing a seemingly arbitrary method with an argument that’s either a number or a Range of numbers. The link object collects these arbitrary method invocations and assembles a set of rules. The seemingly arbitrary method name is the name of the context to which the menu should jump in case its argument (the pattern) is found to be a match.

With these context names and patterns defined, the menu() command plays in sequence the sound files you supply as arguments, stopping abruptly if the user enters a digit. If no digits were pressed when the files finish playing, it waits :timeout seconds. If no digits are pressed after the timeout, it executes the on_premature_timeout hook you define (if any) and then tries again a maximum of :tries times. If digits are pressed that result in no possible match, it executes the on_invalid hook. When/if all tries are exhausted with no positive match, it executes the on_failure hook after the other hook (e.g. on_invalid, then on_failure).

When the menu() state machine runs through the defined rules, it must distinguish between exact and potential matches. It’s important to understand the differences between these and how they affect the overall outcome:

Database integration

To do database integration, I recommend programatically executing methods on the link object within the block. For example:

menu do |link|
  for employee in Employee.find(:all)
    link.internal employee.extension
  end
end

or this more Rubyish way

menu do |link|
  link.internal *Employee.find(:all).map(&:extension)
end

If this second example seems like too much Ruby magic, let me explain — Employee.find(:all) effectively does a “SELECT * FROM employees” on the database with ActiveRecord, returning (what you’d think is) an Array. The map(&:extension) is fanciness that means “replace every instance in this Array with the result of calling extension on that object”. Now we have an Array of every extension in the database. The splat operator (*) before the argument changes the argument from being one argument (an Array) into a sequence of n arguments, where n is the number of items in the Array it’s “splatting”. Lastly, these arguments are passed to the internal method, the name of a context which will handle dialing this user if one of the supplied patterns matches.

Handling a successful pattern match

Which brings me to another important note. Let’s say that the user’s input successfully matched one of the patterns returned by that Employe.find... magic. When it jumps to the internal context, that context can access the variable entered through the extension variable. This was a tricky design decision that I think, overall, works great. It makes the menu() command feel much more first-class in the Adhearsion dialplan grammar and decouples the receiving context from the menu that caused the jump. After all, the context doesn’t necessary need to be the endpoint from a menu; it can be its own entry point, making menu() effectively a pipeline of re-creating the call.

I encourage you to give this command a try and let me know what you think! Feel free to post on the mailing list or here on my blog.

Enjoy, folks!

Sitting in my cozy dormitory bedroom, the first signs of relief set in as the stretch lasting almost two months was coming to an end—I was tying up the loose ends of my first publicly released version of Adhearsion. The start of the stretch was marked by my irreverent albeit desperate sneaking into Astricon 2006, the big Asterisk conference held ironically just six miles away in downtown Dallas at which security was surprisingly lax. It was there that I first demoed an alpha of Adhearsion to respected players in the telecom industry. My demo’s reception motivated me to pursue Adhearsion further, potentially toward something big. Through connections established there, I was invited to the headquarters of Asterisk’s corporation Digium twice, wrote an article for Linux Journal magazine, and got my first notable Adhearsion speaking opportunity at Emerging Telephony 2007. That was the tipping point.

Since those days I’ve spoken at eleven more conferences and tech meetups, collected hundreds of business cards, written an Adhearsion chapter for O’Reilly’s Asterisk book, and visited three other countries and fifteen states on Adhearsion-related business. To afford the absurd amount of travel, I took up an interesting style of living I later labelled peer-to-peer living: I had no fixed residence and considered myself, basically, homeless. Throughout my travels I managed to develop a support network of individuals with couches to spare for a few days or a few weeks. Needless to say, this all came as a shock to this boy from Texas who had never been out of the South.

This fruitful year is now over, the name Adhearsion is more widely known and, as of last week, I live in a fantastic part of beautiful San Francisco. After twelve months of testing myself and countless days of personal reflection, I’ve confidently decided that Adhearsion is my career now.

Big ’08 holds a lot. In addition to continued development, I want to bring in sub-contractors to assist on increasingly substantial consulting projects and encourage others to start their own independent Adhearsion consulting practice. If you’re a Ruby developer either with VoIP experience or a genuine, keen desire to gain VoIP experience, talk to me. My email address is in the right column of this blog. If you’re a company needing a better phone system or a startup with some telephony component not yet developed, talk to me too and let’s see if using Adhearsion makes sense.

I’ll continue promoting Adhearsion in ways other than speaking at a dozen conferences. Think screencasts, video podcasts, writing, and a revamped website. Development will continue regardless of whether I have work. My first order of business is to get the version 0.8.0 gem out the door. For those that don’t want to wait, you can play with 0.8.0 in Adhearsion’s trunk.

Happy new year folks! Let’s make 2008 the year the telecom industry really changed.

But last night my feeds agreed with my doubts. Resounding through the VoIP blogosphere, O’Reilly announced they have cancelled their Emerging Telephony conference and blog. To help paint the picture, Emerging Telephony was widely considered to be one of the actually fun, innovative conferences every year in this space.

Therein lies the problem. Too little fun and innovation exists in this industry to make a full conference out of it.

Remember the last episode of Star Trek: The Next Generation where the omnipotent Q places all of humanity on trial for being a savage, inferior species? Q asserts that the years since the first time he placed humanity on trial has been squandered with virtually no progress toward enlightenment. I’m convinced Q was so pissed off because of this ridiculous blemish in our history. We are a savage, uncivilized race apparently.

This is a frustration I’ve had since I created Adhearsion. The framework’s name reflects my attempt to unify this godforsaken wilderness. I’m herding cats and fighting the good fight simultaneously.

But I’m not giving up yet.

There are many wonderful things brewing under the covers of the new version of Adhearsion. It’s a maverick, opinionated approach but it may just work. The effect could be truly disruptive:

• A significantly next-generation approach reaches hackers who can finally develop actual open-source VoIP applications.
• An open-source ecosystem forms.
• More people become professional VoIP developers.
• Additional global expertise increases the number of open-source VoIP applications.
• The ability to host the applications becomes predictable and inexpensive through standardization.
• Startups form around new applications.
• A few startups succeed and contribute back.
• Years of contributions improves software quality and lowers barrier to entry.
• Disruptively innovative companies catch big telecom companies with their pants down and chip away at their market share.

The fight will be a long and difficult one, though the next baby step is to get Adhearsion v0.8.0 out the door. Near the end of the this month I’ll outline the changes in the new version of Adhearsion which should see a release by RubyConf on November 4th, 2007!

require 'rubygems'
require 'superators'
 
class Array
  superator "<---" do |operand|
    self << operand.reverse
  end
end
 
["jay"] <--- "spillihp"

Dear demagogues of domain specificity! Yes, this actually works. Now, how about this cutie:

require 'rubygems'
require 'superators'
 
class String
  superator "++" do |operand|
    upcase + operand.upcase
  end
  superator "-~+~-" do |operand|
    puts "Using pretty superators"
    self + operand
  end
end
 
p "Tangy" ++ "Erlangy"
p "Super" -~+~- "ators"

Superators are a superset of Ruby operators. And they’re pretty super too.

To elaborate more, they work by exploiting the way Ruby parses binary and unary operators. For example, the code foo ++- bar is equivalent to foo.+(bar.-@().+@())

and the Superators library keeps track of the unary operators called on the operand in their appropriate order. A valid Superator’s format is simple: take (almost) any Ruby binary operator and tail on an indefinite number of unary operators after it.

These are the Ruby binary operators you can use:

** * / % + - << >> & | ^ <=> >= <= < > === == =~

And here are the unary operators: - ~ +

The only operators you can’t use are the logical ones (e.g. &&, ||, !, and, or, not, etc.) Ruby offers no way of overloading these.

I’m releasing this into the wild to hopefully see what mischief it stirs. But take heed! Superators are second-class citizens still and are victims of vicious discrimination in certain circumstances. In the current implementation the second operand is extend()ed with a Ruby module (unobtrusively setting a flag for later inspection), therefore a Superator can only have a second operand capable of possessing its own eigenclass. Superators will not work with second operands such as true, false, nil, Symbols or Fixnums yet. I’m working on a branch that could fix this if my mad scientist lab experiments bear fruit (or a resentful monster whom I chase to the Arctic Circle after he destroys those I love). Stay tuned.

Despite this limitation, Superators can still be used effectively! Use it when you expect the second operand to be an Array, String, Hash, Range, Regexp, Class, or whatever.

I should note that I strongly frown upon any use of Superators outside of the DSL space. Don’t use it in your company’s Rails app controllers. Use it in your tenderly crafted Ruby DSLs where they make sense.

Enjoy, comrades.

Update: There seems to be some confusion that Superators are a C extension that modify Ruby’s internals. A valid Superator is actually just valid Ruby—something we’ve had at our disposal this whole time!