Here’s the good news:

AOL announced today that they are opening up their AIM phone line service to third party developers:

AIM Call Out is a pay-as-you-go outbound voice calling service built right into AIM that lets users make calls to landline and cell phones in more than 200 countries. This service complements the existing AIM Talk service, a free PC-to-PC voice calling service available to AIM users.

AIM Call Out offers low per-minute rates with no connection fee or monthly charge. Users pay for call credits in increments as low as $5. AIM users can visit http://call-out.aim.com/rates for a complete list of long distance rates.

Users can also make phone-to-phone calls using the Web Connect feature within the AIM Call Out service. Users simply enter their phone number and then the phone number of a friend. In a few seconds, the user’s phone will ring and then connect them to their friend’s phone.[1] AIM users can manage all of their voice activities using AIM Call Out and Web Connect from their personal Voice Dashboard and can learn more about the services at http://call.aim.com.

Here’s the bad news:

At the bottom of the web connect calling page is some fantastic small print:

Web Connect calling limit: 2 calls/day
You have made 0 call.calls.
Web Connect call cost equals BOTH call destination rates combined. Call times rounded to the next highest minute. Charges by your mobile phone provider may apply.

Two calls a day? Hello? Hmmm… should I call my wife and my son? No, I talked to him yesterday. I’ll call my wife and my mother. Well… my son does have a test later on today. Gosh darn it, I wish I had a phone that I could use more than TWO TIMES A DAY. If someone ever invented that, he’d be a bazillionaire.

And really, if I’m getting pinged for both sides of the call, why the heck are they charging 1.x cents per leg, as if I’m trying to save money. AOL, if you’re going to rip me off, do it right, and really rip me off. Be a man and charge me activation fees, five cents a minute and usage overages (like he used it three times today), not some slimy fine print stuff. You’re supposed to be a corporation, not a two bit prepaid phone card dealer.

Posted by Thomas Howe @ 9:33 am | Filed Under Lead Stories | 5 Comments

The Enterprise 2.0 market, where web 2.0 based technologies are used by businesses to solve process problems, is expected to be a 4.6 billion dollar industry by 2013 according to Forrester:

Enterprise spending on Web 2.0 technologies will grow strongly over the next five years, reaching $4.6 billion globally by 2013, with social networking, mashups, and RSS capturing the greatest share. In all, the market for enterprise Web 2.0 tools will be defined by commoditization, eroding prices, and subsumption into other enterprise collaboration software over the next five years; it will eventually disappear into the fabric of the enterprise, despite the major impacts the technology will have on how businesses market their products and optimize their workforces.

If you’re interested in how these numbers look, including who’s spending what and why, check out Read/Write Web’s excellent post.

Posted by Thomas Howe @ 7:31 am | Filed Under Lead Stories | Leave a Comment

Lypp announced their mashup contest today, and I’m throwing my hat in the ring:

We are less than one day away from opening the doors to the 37signals VoIP Mashup with Lypp. Tomorrow at noon (Pacific) the contest starts.

Developers, build a mashup application or mashup your existing application using both the Highrise API and the Lypp API and win stuff. This is a great way to show off your Ruby-fu and win some great prizes.

Best app:

* $3000 Apple gift certificate
* 20,000 minutes of call time from Lypp (approx value: $1800)
* 12 months subscription for a Highrise MAX account (approx value: $1800)

Runner-up:

* $1500 Apple gift certificate
* 10,000 minutes of call time from Lypp (approx value: $900)
* 6 months subscription for a Highrise MAX account (approx value: $900)

2nd Runner-up:

* $500 Apple gift certificate
* 5,000 minutes of call time from Lypp (approx value: $450)
* 3 month subscription for a Highrise MAX account (approx value: $450

I’ve been grooving on the 37signals API for a bit now, and I’ve got some ideas to kick it with telephony. So, who’s going to climb in the ring with me?

Posted by Thomas Howe @ 11:59 am | Filed Under Lead Stories | Leave a Comment

We’re really happy to be partnering on with Broadsoft as part of their developer’s and extended marketplace. This is the first part of three posts we’ll be doing on the work we’ve been doing with their platform. In this first part, we’ll be talking about the ruby gem we’ve written to be the basis for our work.

Before we get there, of all the carrier platform choices we could make, it was clear that Broadsoft was the one worthy of our attention. First, a few weeks ago, they announced the BroadSoft Xtended program targeted to “Personalize Voice Communications Technologies Through Web 2.0 Integrated Applications.” Secondly, I received repeated assurances that they had a commitment to an open marketplace and an open approach to supporting their developers. Third, and I can give you my assurance of this as an ex-CTO of their competitor, Netcentrex, Broadsoft is winning in the marketplace. Directly from their site, “BroadSoft provides VoIP applications to 7 of the top 10 and 13 of the top 25 largest carriers worldwide, as measured by recent annual revenue, including Korea Telecom, KPN, SingTel, Sprint, Telefonica de Espana, Telstra, Deutsche Telecom’s T-Systems, and Verizon. To date, our platform has been deployed in the most IP multimedia subsystem (IMS) networks worldwide.” When Scott Wharton told me about his program, I couldn’t sign on fast enough.

Our first job was to get a development environment that we could deal with. In the medium term, Broadsoft engineering is planning a complete REST interface to the platform. Until then, they have an XML based interface called “CAP2″. Nothing wrong with that from a carrier perspective, but if you haven’t noticed, I’m a Web 2.0 guy now. (Out damn spot). So, we’ve written a ruby gem to interface our software to a Broadsoft switch. We’ve received permission from Ruby Forge, and we’re posting it up there today. Using this gem, it’s drop dead easy to install, configure and manage a user account.

First, installation is simple. From any ruby development machine with gems installed, say :

gem install broadsoft

That’s it. You’re ready to go. If you want to play around with it, jump into the interactive ruby browser (irb), and have at it. First, include gems and the broadsoft gem:

irb(main):001:0> require ‘rubygems’
=> true
irb(main):002:0> require ‘broadsoft’
=> true

then all you need to do is login.

bs = Broadworks.new(”example.broadsoft.com”, “2208″, “demo@broadsoft.com”, “youdontcare”)

=> #<Broadworks:0×11bc6b8 @user_uid=”270384658″, @port=”2208″, @t=#<TCPSocket:0×11bc604>, @host=”example.broadsoft.com”, @password=”youdontcare”, @logger=#<Logger:0×11bc67c @logdev=#<Logger::LogDevice:0×11bc618 @shift_age=nil, @filename=nil, @mutex=#<Logger::LogDevice::LogDeviceMutex:0×11bc5f0 @mon_waiting_queue=[], @mon_entering_queue=[], @mon_count=0, @mon_owner=nil>, @dev=#<IO:0×2e7d4>, @shift_size=nil>, @formatter=nil, @default_formatter=#<Logger::Formatter:0×11bc654 @datetime_format=nil>, @level=2, @progname=nil>, @call_client=”demo@broadsoft.com”>

that’s it. Your’e ready to go. Want to make your phone call somebody? Eeeeasy.

bs.dial “15088154321″

We also implemented answer, hold and release. (Still have some of the more exotic park and conferencing stuff to implement; we’ll see who actually cares about those.) Call notifications? Eeeeasy too, and in fine Ruby fashion:

bs.assign_call_function { |info|

# your code goes here.
}

As happens in ruby, info is an object containing all of the call variables we need. In our business intelligence application, we use these callbacks to populate a database so we can use it to drive our user interface from a ruby on rails application. Here’s what we actually did:

# Create your AR class
class Call < ActiveRecord::Base
end

bs.assign_call_function { |info|
# We need to put this information into the database. Let’s try that, shall we?

c = Call.find_by_callid(info["callId"])
if c.nil?
c = Call.new
c.user = info["user"][0] unless info["user"].nil?
c.remote_country_code = info["remoteCountryCode"][0] unless info["remoteCountryCode"].nil?
c.personality = info["personality"][0] unless info["personality"].nil?
c.callid = info["callId"]
c.calltype = info["callType"][0] unless info["callType"].nil?
c.release_cause = info["releaseCause"][0] unless info["releaseCause"].nil?
c.remote_number = info["remoteNumber"][0] unless info["remoteNumber"].nil?
c.appearance = info["appearance"][0] unless info["appearance"].nil?
c.extTrackingid = info["extTrackingId"]
c.remote_name = info["remoteName"][0] unless info["remoteName"].nil?
c.state = info["state"][0] unless info["state"].nil?
c.save
else
case info["state"][0]
when “5″
c.destroy
else
c.state = info["state"][0]
c.save
end
end
}

And that’s pretty much it. In the next two posts, we’ll explain how you can use this gem to implement a business intelligence mashup using 37 signal’s Highrise product, and then we’ll show you how we did a quick and simple click to call on the browser using this gem, ruby on rails and a greasemonkey script.

Posted by Thomas Howe @ 8:13 am | Filed Under Lead Stories | 2 Comments

Thanks to the examples of our Web friends the world of APIs is continuing to grow dramatically. There is practically no new technical product or service release that does not mention an API or SDK. The challenge,of course, is to get developers to begin using your API. Unless Google, Facebook, or Apple signs your paycheck a build it and they will come approach is probably not the only strategy you should attempt when releasing an API.

Here are 5 ideas that we view as important considerations when building a developer ecosystem. Our friends from across the industry can take credit for this list through trial and error. The list may stink of commonsense but the supply of APIs seems to be larger (for now) than the developers who commercialize these technologies.

1. Show the world that your company can directly monetize whatever product or service has been created. Expecting developers to be your primary sales channel will fail unless there is a huge branding budget attached.

2. Demonstrate integration opportunities with another software platform or system that already has a developer ecosystem AND customer base built in. An upsell opportunity is always easier than a first sell offering.

3. Be willing to introduce developers to your clients to do work! or at least to hear about their real customer experiences with your products/services.

4. In the CEBP/Mashup world it is very possible to now talk about ROI. Make sure quantifiable success stories are well understood by your developer community especially in a weakening economy.

5. Consumer oriented APIs versus business focused APIs are different animals entirely. The developer ecosystem that builds applications to generate eyeball traffic versus  solving business process problems may have different characteristics/skills particularly on the usability front or approach to project management.

This list can be expanded over time. Fortunately, there are companies in the Mashup/CEBP industry who are doing it right. We will mention them in upcoming posts. Any nominations or additional insights on this topic are appreciated.

Posted by Thomas Howe @ 11:58 am | Filed Under Lead Stories | Leave a Comment