This article in the Wall Street Journal is vaguely… nauseating.  Nortel, once a juggernaut boasting a $250 billion dollar valuation, is currently valued at $199 million dollars.  For Nortel.  Let me emphasize that for you. Nortel, $199 million dollars. For those of you keeping score at home, let’s do a quick analysis:

• Ribbit is worth 50% of Nortel?
• Only eight years ago, Zhone raised $500 million, and it’s too bad they didn’t have a time machine, as they could have purchased Nortel twice over, and still buy Ribbit.
• Hold on – you mean not a single large carrier wants to avoid purchasing a softswitch ever again?
• Hey Vonage – sick of Verizon beating you up for patents?  Listen – I’ve got this little company up in the great white north you ought to look at.
• Here’s a crazy idea: let’s buy it, lay off everybody, and collect the licensing revenue – just for fun.
• Tonight, just in, Calliflower purchases Nortel as a hedge in case the conferencing business goes pear shaped.

No more debate, folks.  Find a mattress and stick your money under it. Quick.

Well, at least I hope so.

Over the holiday weekend, I dusted off TextMate to send my entry in the Broadsoft XTended competition called “The Disaster Dispatcher”. Like most of my work, it’s business process oriented stuff, this time aimed at the emergency management market. I wanted to make this entry very light and fast, just like a mashup should be, and Gustav was all over the TV. (So was Sarah Palin, but apparently she wasn’t as inspiring. Must be getting old.)

So, I hereby offer my custom made voice-mashup, the Disaster Dispatcher, for your consideration. It is running live on Amazon’s EC2 at http://ec2-75-101-244-168.compute-1.amazonaws.com for your mashing enjoyment. This voice mashup is written in exactly 594 lines of Ruby, and integrates broadworks, Twitter and RSS to create an emergency services mashup. I wrote it over two days: Labor Day, when I wasn’t running errands with the wife, and tonight after work. I’m making this application open source to serve as an example of how to integrate Broadsoft and Ruby together to make an effective application. The complete source is now at github: http://github.com/howethomas/disaster_dispatcher/tree/master

No, I don’t think so, but boy do I want to.

I caught a link from mashup meister John Musser from Light Reading called Telco Web 2.0 Mashups. In it, Caroline Chappell speaks about the impact Web 2.0 technologies are having on IMS deployments in her new report. I think Caroline what has is mostly right from a technology standpoint, but misses on some critical cultural points. For instance, the mashup phenomenon has, at it’s core, this idea of the perpetual beta. Without regard to how mashable the carriers make their offerings, it won’t make them any more fleeter of foot. That said, I am in complete and violent agreement with Caroline, and I hope my industry has the good sense to listen to her advice.

Now, if I were to brag, I’d point my readers back to something I wrote nine months ago….

There’s no denying an exodus is underway. So far, I’ve seen Pat, Moshe, Alec and a host of other go over to Facebook from LinkeIn, all in the space of a week. Is it just me, or do you find this remarkable? I mean, not only for the abruptness of it, or the lemming like nature by which it’s happening, but for what it says about Web 2.0 principles?

Gaboogie is a pretty cool idea. How often, in your professional life, do you find yourself trying to setup a conference call? Gaboogie aims to make that easier for you, in classic 37 Signals fashion. Gaboogie’s service makes it easy to setup a conference call between a small number of participants, and then when the time comes for the conference, dials everyone on the list. It keeps dialing until it gets you, and if you miss the call, you simply call back the number that you missed. Add a dash of modern design, a few nice features like call recording, and presto – you’ve got gaboogie. Gaboogie has a simple, volume based pricing structure, going from around 12 cents a minute down to 2.

I know that I rail about horizontal services all the time, and frankly, I think that gaboogie will have the same issues as well. It will suffer from the twin challenges of customer education (most people won’t know it exists) and customer habituation (people have to change their habits to use it). In my book, the saving grace is the Internet’s long tail effect, which would be since the cost of incremental delivery is nearly zero, there may be enough scattered demand to make a decent business for them. I hope so, as I think this is a real problem that begs for a simple solution.

How does it stack up?

• Technically, my first impressions are a B+. I love the simple design, and I caught wind from a job posting that they are using Freeswitch in their network. (Rock on with that one). The mapping of functionality is sparse, and I hope it stays that way, as it eases customer education. As a rapidly aging telecom geek, I have the suspicion that ease of use will be dashed upon the corporate IVRs that will inevitably be in the call flow. The fact they give you a dial in number will really help here, but I gotta think that it will be a jarring experience for those involved. No API yet, or I would be mashing it up with 30 boxes this morning.
• From a business perspective, a solid B. Getting conference calls started on time is a real problem, and they have the basic right solution for it. In time, I’m sure it will be an excellent solution. I have a marketing issue though, as I believe that they have a consumer company name for what is essentially a business offering. (I’m not the only one with the opinion.) It won’t be that difficult to reproduce the service today, but there’s opportunities to create community and hard to replicate data with time – I hope they exploit that.
• Buzz, another B. They have today’s look and feel, a sense for the problem, and a decent approach to solving it. They certainly aren’t leading the charge, but they are solidly in the pack.

“OK, so let me understand this… you guys do IVRs, right? I don’t really understand what’s new here. We’ve had IVRs forever.”

To live in the real world means to live with constraints. I am unable to jump over a tree. I will live less than 100 years. I am unable to add numbers as fast as my computer. I cannot fit three cars in my bedroom. As we move through our lives, we make decisions based on these constraints so often, we no longer understand that we do it. Good thing too, because if we did have to run through the list of what we couldn’t do all the time, we would be paralyzed. (I have to be in the Cape Cod office in 90 minutes, so there is no time to swing by Paris for breakfast.) Our minds are honed to consider the possible by a clever method: we tend to construct our understanding primarily based on our current knowledge, giving rise to an endless series of deltas. I remember an English class where we were working on a dictionary entry formula : you define a noun based on two parts, the first being what the noun is like, the second is how it’s different. A tiger is a 1) CAT that 2) has stripes, a big body and large fangs. You define a tiger using what you know (a cat) and then describing why that first thing is insufficient (which can eat you for lunch.)

Of course, engineers are no different, except that when we design, constraints are quite at the top of our attention. I would even posit that we understand and describe our designs through constraints. Like a sculptor, removing the stone to reveal the statue, we draw boxes on whiteboards to explicitly limit the functionality of what we design. We understand that, unless we limit our tasks aggressively, we will be unable to see our design come to life. It why we cringe when the marketing man comes in the room, as his motivations are quite different than ours. They make us draw more and bigger boxes, removing our constraints and adding to our worries.

What might not be apparent from the outside is that an amazing has happened recently in the world of technology. The combination of web services, lightweight programming models and Internet architectures based on open source tools radically reduces the constraints on hosted application development. The advent of Web Services means that you can publish your functionality to the Internet in a controlled, standard way. Since the cost of publishing is so low, the amount of customer traction you need to break even is low, making the amount of web services that are available to you as a designer to be much larger. An example would be a web service that verifies that a person’s name matches an address, and will be valuable to any company looking to avoid fraud. Lightweight programming models radically reduce the cost to create web applications by reducing the skills required to write them, and the number of people required to author and maintain them. Internet architectures are naturally resilient and scalable, removing many of the stability constraints that dog other forms of software development. As a concrete example, I would have you consider that both Yahoo! and Google run their infrastructures on off the shelf hardware and open source software, versus Verizon who runs their infrastructure on gold plated, multi-million dollar telecommunication switches. The difference is in architecture, which removes the constraint of having each element be bullet-proof and stable. In the Internet architecture, servers can go down because there are multiple paths to your web page. In telecom architecture, the phone on your wall is connected to exactly one central office.

The combination of these forces makes the development and delivery of hosted services much, much less expensive, for services of all kinds. My career interest is in telecommunications, thus, I am looking at how the constraints of typical voice services are lowered. IVR is a good example, of course there are many others. Using an online service from a place like Voxeo, I can draw a box on my white board called IVR that I can implement quickly and inexpensively. How might I use it? In any way I wish, blended into any sort of application I wish. I am no longer constrained by having to purchase equipment, or by having to learn an esoteric language to run it, or to be locked into a particular vendor, or to have troubles interfacing it to my software. It is no exaggeration to say that I am now able to make function calls that retrieve data from an IVR script as easily as I can that retrieve information from a database. In fact, given that it takes me a couple of hours to setup a database, the IVR might be easier. I can tell you the same thing about a whole host of telephony services, like SMS. I could also make the same argument about any other web service used from my IVR, like I could call a phone number and make my google maps on my screen do things if I wanted. I could – any up-to-date software engineer could.

So, given that these constraints have fallen through the floor, what does my company do? We are figuring out exactly which hosted solutions, especially those that use real time communications, work inside businesses to make the business faster, more efficient and makes their customers happier. Then, we work with businesses to implement these new services into their business process. IVRs are a part. So is SMS. So is Google Maps. So is…. you get the point. What is different is not the functionality, but the constraints. The implications are endless.

As regular readers may have figured out by now, I’m not a big fan of most carrier applications, as I am unconvinced of their long term value due to commoditization, and customer eduction and habituation issues. For me, it’s got to be really (really) good before I’ll fall in love with it. Iotum gets my nod, and now GrandCentral joins that illustrious crowd.

Grand Central is a one-number service done (nearly) perfectly. You can take your GrandCentral number and point it to all your numbers. It does automatic call screening, forwarding and voice spam handling. During a call, you can simply press 4, and the call is now recorded. Like any good iPBX or VoIP carrier play, you can see all your calls, contacts and messages online. I especially like the Web 2.0 look and feel of the site, although I wish they would go all the way with a Web 2.0 approach (more about that in a bit). It’s even adroit enough to put the call on hold for you as you switch from one phone to another. As a personal call solution, I have never seen better. Insanely great.

How does GrandCentral stack up?

• Technically, a definite A minus. I love how they have solved the problem of call handling, and takes a hard problem and makes it easy. Almost on the order of the iPhone UI design, from where I sit. I give them a minus because I think they should go whole hog and publish an API so I can mash it up. I can’t begin to tell you the good ideas I have for that one. Otherwise, perfect, perfect.
• Businesswise, a strong B+. Real value here, and well worth my investment of time to learn how to use (and it’s really easy to use.) I’m going to knock them for two points : they should start charging for this service… I would pay $20.00 a month for this. Come’on guys – make some money. Secondly, it is still a horizontal service, and replication of it isn’t rocket science, so sustainable competitive advantage from the features looks difficult. However, it’s easy for me to see how it might become entrenched in people’s work flows, and there’s many Web 2.0 data mining / social networking opportunities there too. They’ll do alright.
• Buzz, A+. Call me jaded, but this level of excitement over a telephone service doesn’t happen too often to me. Anyone who isn’t jazzed about this service isn’t paying attention.

Wednesday is NOT Prince Sphagetti Day… it’s API day. APIs connect service providers to applications in Web services architectures. Application designers use the functionality provided by the API to build their mashups or to build their business process applications. Service providers make money with their APIs in a number of ways, including directly paying for their use, by expanding their business base, or by providing the API for free, and deriving value from the data that they gather. Today, most Web APIs are free, but are expected to have licencsing costs for commercial deployments. Most communication APIs have some pay-per-use associated with them, since they expose transactions, such as SMS, which cost money.

Today’s API is Voxbone, a provider of DID numbers to the VoIP community. DID stands for Direct Inward Dial, and essentially, it’s how you get a phone number. With the Voxbone API, you can find phone numbers and purchase them for your VoIP service. Once you purchase your phone number, you can set it to point to any SIP (a common VoIP protocol) address you wish. This has some direct business implications, because it allows providers to offer phone numbers world wide, without keeping an inventory of them, increasing functionality for the users, and saving money for the providers.

Why would you, the application designer, wish to do this? I’ll give you one, and I’m sure you can fill in the rest: temporary numbers. Wouldn’t you like to have an anonymous phone number? Classified ads are a fantastic place to use a temporary number. With the Voxbone API, you can get a phone number, assign it to your cell phone using a SIP URI that maps into a direct line into a PSTN number, and off you go. Return it when you’re done. I’m going to take my number and point it to a Voxeo script.

So, in your toolbox, you can now get a phone number, whenever you want, and put it back when you’re done.

I might be misquoting here, but I believe I once read in Playboy Interview with John Kenneth Galbraith that his biggest disappointment with people was that they sought out data that supported their currently held postions and opinions, and rejected all other data. With that firmly in mind, I nonetheless want to share Guy’s post entitled : By the Numbers: How I built a Web 2.0, User-Generated Content, Citizen Journalism, Long-Tail, Social Media Site for $12,107.09. In it, he details what he spent, in time and in money, to launch his often reviled, and often visited, new site called Truemors. Of course, his initial success has a lot to do with the fact that it’s Guy Kawasaki that launching it, but let’s face it : $12,107.09. As I recall, that was probably the monthly fedex bill for the smallest of the 2000 class of VC funded startups.

I call your attention to it to illustrate my currently held belief, that service providers are so easy and simple to deploy that the game for all businesses has fundamentally changed, not only for service providers. As the costs to deploy these sorts of services goes down, the required market share to support a busines is much smaller, allowing much more targeted businesses to be created. This drives my focus into the new Web services based architectures, which are ideal to support businesses exactly like this. I was not surprised to see an Amazon Web services URL flash by on Truemors…

As I look at the recent crop of Voice Over IP startups, I use this picture of the future to predict the success of my industry peers. It’s why I like Twitter as a small, bootstrapped place, but have a hard time seeing valuations that would support massive investment into it. The technical implementation of Twitter, to telecom standards, is nearly trivial. The mob effect and it’s value to the mob seems marginal to me, but the service and infrastructure are useful, and if they stay close to customers that will pay, they’ll do quite well. Apparently, Twitter is out to raise some dough. For their sake, I hope they fail there, and succeed by sticking to their knitting.

I think I ought to get some sort of report card together to help me keep my thoughts. How would Twitter fare?

• I’d give them a B for technology, as they did a good job with integrating existing technologies, but have not really made any new technology or architecture improvements. A decent job there, but not exactly Stanford or MIT.
• I’d give them an A- for business if they don’t take investment (and a definite C if they do). Twitter’s service is still very horizontal, and as such, can be commoditized. However, the service itself is quite cool, and has many applications, and they have first mover advantage.
• We need to give the Twits an A for buzz. Like a friend of mine in the Valley says, they love Twitter because they showed that using text messages was something that people might even like to do. I agree. I’m a fan.

I had the pleasure of working for a man named Chuck Holland in the mid 90’s. Chuck is a wonderful, bright and generous man, now semi-retired after a wonderful career as a high tech entrepreneur, even including a part in Tracy Kidder’s Pulitzer Winning Novel “The Soul of a New Machine.” Chuck told me something I have never forgotten, and I’m happy to pass it over to you. “The only thing you should expect from a startup is that, when it’s done, you can do it again. If that’s not enough for you, then don’t do startups in the first place, because that’s all you should expect from it.”

Well, Chuck, I want to introduce you to The Thomas Howe Company, the third company I have started. I am pleased to announce that my business partner and I have signed a lease on some space in Osterville, we’ve hired our first people, and most importantly, we’ve signed up our first four customers. In the coming weeks, we’ll introduce ourselves to the world. Wish us luck.

Our mission is simple: we want to help our customers integrate real time communications with the business process. Why? Because it makes businesses faster, makes businesses more efficient and makes customers happier. How are we doing this? We take our own assets, including a yet-to-be-announced service and software components, along with our partner’s assets and provide professional services to integrate them into our customer’s infrastructures. Our customers? Enterprises of all sizes, especially in the healthcare and financial verticals. We long for the day that carriers will understand this new world of communications and offer it to their customers…. but I hope you’ll forgive me if I seem dubious about that possibility.

To all of our friends, family, partners and well-wishers – thank you for all your support. We’ve appreciated it in the past, and we’ll depend upon it in the future. If you are ever in Osterville, we’ll buy the coffee.