There’s been a lot of coverage of Ribbit, self-proclaimed “Silicon Valley’s first phone company,” which came out of stealth mode this week (for more background, read a bit here: TechCrunch; GigaOm).

In short, Ribbit — ridiculous name and questionable tag-line aside — has tremendous potential to be the startup that drops into the voice 2.0 application market and shakes things up a bit. Whether it “wins” (by building a solid business) or is acquired or scares larger players into copying its model is irrelevant. It’s done enough right that it its launch feels like a tipping point event on the path toward next-generation telephony services.

Technically, Ribbit has developed a carrier grade softswitch, integrated it into a nice telco-style stack of APIs to OSS, billing and other back-office services and made the whole thing accessible on the front-end via Flash. Yet another layer in the stack “normalizes” different (mainly Web-centric) communications protocols including XMPP, Skype, Flash Media Server and various IM clients, with a standard SIP stack handling the voice side of things.

But Ribbit’s value equation and point of differentiation starts and ends with its appeal to developers (the company claims it had 600-plus developers at a developer meeting last week).

By providing developers (Web developers, telephony developers) easy access to call control and service APIs, it hopes to unleash a wide variety of voice-enabled applications (see here for our debate on voice-as-a-feature versus voice-as-an-application). It will develop some of those services/applications itself, but it is really counting on a growing a developer community that will take its offering and run with it.

It’s an interesting model, and an inevitable one. Some new companies have played around with such an approach (from VoIP providers like Oomah or Jaxtr to vendors like BlueNote and LignUp to Asterisk-driven open source projects to telco efforts, most notably BT Web 21C). But few have made such a textbook play of it as Ribbit or come out of the box with such hype.

Let’s go deeper:

How Ribbit Works And What They Really Want

To handle the telephony call control and routing side of the equation, Ribbit built — and is hosting — a SIP softswitch (which the company claims it even put through some switch testing with Lucent). The switch is located in Northern Virginia and hosted at managed hosting provider Opsource (which even has a small case study on the set-up), with VoIP peering handled by IntelePeer.

Those capabilities are skin in the telephony game. The software in their set-up — handling typical BSS/OSS functions, including managing billing for their developers — is interesting in that they expose it too to developers. Banking on Flash and Flex scripting as the basis for application logic provides an easy developer entry point while ensuring integration with more developer-class IT tools like Eclipse, while avoiding telco-style development languages and APIs altogether (you can read the Ribbit call control API docs here; see the screen shot below for an example). The Flash-based demo phones Ribbit is showing on its Web site (see the screen shot at top) and talk of consumer services at best represent a reference application and at worst are a distraction to its core business.

Ribbit’s real target — which in an interview co-founder Crick Waters (who helped manage AT&T’s VoIP business, by the way) called “the big fat middle of the curve” — is to make it easy for companies running software-as-a-service applications to integrate voice into their workflow. Their first deal is with Salesforce.com, a good place to start, and Waters demoed a variety of voice functionality integrated into the Salesforce.com interface. The key, said Waters, is treating voice “as a first class data object” within the programming environment, enabling voice calls to be launched, voice messages to be appended to customer profiles and much more — all from within standard CRM business processes.

If Ribbit can effectively serve customers in that way and make their Salesforce.com deal work, they can then perhaps spin that success story up into a few more SaaS (software as a service) deals. Then they may have something.

The key, however, is that in the end Ribbit is NOT the be-all-end-all of “voice 2.0″ companies — despite a flashy (no pun intended launch) launch and the over-stated claim to be ‘Silicon Valley’s Phone Company.’

Rather, Ribbit represents one of the first high-profile, venture-backed startups to get into the voice application platform business — a business that service providers are aiming to get into themselves via service delivery platform (SDP) deployments. The opportunity is that Ribbit, and a handful of others, can build real businesses by targeting real markets (small business CRM, for example) that would benefit from Web/voice-integrated apps.

That is if Microsoft (with Microsoft Office Communications Server) and Google (with its Grand Central acquisition and Google Apps strategy) and all the world’s service providers don’t catch up to them first.

“We’re not displacing the functioning telephony system [a business] may have,” CEO Ted Griggs told me. “We want to take voice communications and integrate it into the [application] workflow on which they run their business. It’s a tremendous opportunity.”

---

Service Provider Bottom Line:Carriers that view voice as a monolithic application rather than as a feature in service of countless applications could miss the boat. Read on…

---

We’ve written about and talked to (podcast) Thomas Howe in the past — he’s doing great work exploring and building voice-enabled enterprise applications.In a story written for VON magazine, he gives a great explanation at what is driving the intersection of telephony and Web development and what it all means (emphasis mine):

There is a simple truth behind voice innovation, and it is that voice is a feature, and except for a relatively small number of very voice-centric situations, it’s not an application. You can take a thousand non-voice applications, like disease management or credit scoring, and enhance them in very interesting ways using voice. The reason why these applications aren’t the primary focus of our industry today is not because adding voice to a human resources application is difficult.

In fact, given today’s mashup architectures, it is very simple and cost-effective to do for organizations of all sizes. The reason is because voice used to be difficult, and so we had to spend decades learning about the technology and large amounts of money to deploy anything, so we simply stopped looking outside of our cubicles.

The logical consequence is that we focus on voice services for the masses because that’s all that was practical, and we really know nothing about the applications that the masses require outside of ringing phones. It works in the other direction, too. Since telephony was difficult, the vertical application developer never stuck his nose into the world of voice, and thus the gulf was created. Like a puppy that’s kept in a cage too long, we run around in circles long after the door’s been opened.

I’ve run into just this situation myself when trying to understand new voice development models and businesses, like Ribbit or new telco-delivered service models.

It’s very easy to get stuck thinking that voice is an application delivered to a handset rather than a feature or capability that could be used to support any number of applications — that is, things you wants to accomplish. In the enterprise, those things are a business process. In the consumer world, it’s some sort of activity — scheduling soccer practice, distributing family photos, getting a Christmas gift lift for your grandkids, etc…Voice is one way to do this — as is IM, email, etc.

When service providers start to think like this, and help developers to code like this — then you’ve really got something.

But voice as an application is a tough mindset to break.

A very forthcoming Lowell McAdam, CEO of Verizon Wireless, told Business Week that despite not signing on at launch, VZW will support Google’s Android open mobile software project.

Telephony’s own Kevin Fitchard has done a great job covering Verizon’s recent moves to open up its network, a move that seemed to be motivated by Android. McAdam’s admits it was: “Android really facilitated this move,” he said.

The move to open its network is about two things: one, keeping Verizon Wireless growing even as mobile phone penetration in the U.S. reaches saturation level, and two, a very candid admission of a search for cost savings Says the Business Week article:

When Verizon Wireless was founded in 2000, it ran 27 call centers to provide customer service. The company cut back to as few as 17 centers at one point, but the count is now back to 25, each with about a thousand employees. The company’s 2,300 stores, staffed by 20,000 employees, are also costly. While workers in those stores used to spend nearly the entire day signing up new customers, now only a tenth of their time is consumed by new subscribers. Instead, the bulk of their energy goes to helping current subscribers with questions and problems. McAdam & Co. decided the business model was not sustainable. “If we get to 150 million customers, boy, that’s a lot of overhead,” says McAdam.

In an open-access model, though, Verizon Wireless won’t offer the same level of customer service as it does for the roughly 50 phone models featured in its handset lineup. Though the company will insist on testing all phones developed to run on its network in the open-access program, Verizon plans only to ensure the wireless connection is working for customers who buy those devices. “They have to talk to their handset provider or their application provider if they have particular issues,” McAdam says.

Philosophical drivers of “open” networks are nice, but a service provider CEO admitting a business model consideration — especially one, that if you cut through it, can basically defined as “lower costs through less customer service” — is refreshing in its honesty.

Hard to say how subscribers will take to it, but they asked for an “open garden” didn’t they ; >

Bell Labs was the crown jewel spot for hard scientists to work in the commercial realm.

What’s the Web 2.0 equivalent? Why Google of course. Writes Ethan Stock, founder and CEO of Zvents:

A huge portion of Google’s opex is people, and many of those people are the systems guys who built fundamental software infrastructure like UNIX, C, and TCP/IP. Those guys aren’t there for their halo effect - they’re there, despite Google’s youth bias, to build software infrastructure.

Scan this Bell Labs alumni list, and see how many times Google comes up as a current gig.

Answer: 21.

To the left: picture of the lobby of Bell Labs in Holmdel, N.J.