Praxis

The "I don't want to pay that much" department at XM

While I was in Europe, my 90 day free trial of XM ended, so I returned to regular service and a letter from XM inviting me to sign up for a year of service for $144.

Everything is negotiable, right? So I call up XM and ask them for the better deal. They assure me that there are no better deals, although I can save 20% if I sign up for a 5 year plan. Since I was stuck in traffic heading home, I decided to perservere.

"No, I want a one year plan but don't want to pay $144. "

"What credit card would you like to use?"

"We're not really communicating. I don't want to use any credit card if it's going to be $144. I want a one-year plan, but I won't pay that much."

"One moment please, let me transfer you to that department"

Apparently, XM has a "I don't want to pay that much" department.

Sure enough, an agent comes on the line (she's in a call center in Jamaica; I asked) to tell me that they have a "one time offer" of $77 for a year of service, 50% off.  She just needed to verify something with me:

"Is it correct that you would be canceling your service if we don't provide a discount?"

"Yes. In fact, the service is already canceled - I never started paying in the first place."

"OK"

And with that, I qualified for the special deal. An investment of about 15 minutes on the phone.

Another way reading blogs can put money in your pocket.

Sixth Sense Companies

I was chatting with a startup veteran friend of mine recently about the difference between startups where a founder is the CEO and those where an outside "hired gun" has taken the CEO role. I recall a recent blog post* which said that a key difference is what happens when things get difficult, or major issues crop up that threaten the company's viability. Conventional wisdom is that in such situations, the hired gun will cut their losses and move on to the next thing (often without really trying to get past the obstacle), while the founder hangs in there, stays optimistic, and is often seen as being in denial. Any sane outsider would look at it and say "this is futile", or even "it's already dead", but the founder/CEO is sure that there is a customer or product or feature or angel or acquisition or partner or marketing opportunity right around the corner that will change everything.

Our conversation turned to companies where this state of denial is so strong that any sane observer would look at it and say "this company is already dead", but the CEO soldiers on, often keeping their very loyal team equally committed. We were reminded of a scene from the movie "The Sixth Sense":

Cole Sear: I see dead people...Walking around like regular people...They only see what they want to see. They don't know they're dead.
Malcolm Crowe: How often do you see them?
Cole Sear: All the time. They're everywhere.

We decided to call such startups "Sixth Sense Companies" - they are already dead, but they just don't know it.

The question is, are these CEOs really deluded, or are there examples of startups that were "Sixth Sense Companies", written off by everyone, by all rights should have shut down, but were revived by their passionate CEOs and brought back to life? Fred gives us a few candidates, but I don't know these well enough to say if they were "all dead", or only "mostly dead". There's a difference, as Miracle Max tells us:

Miracle Max: WIt just so happens that your friend here is only MOSTLY dead. There's a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there's usually only one thing you can do.
Inigo Montoya: What's that?
Miracle Max: Go through his clothes and look for loose change.

Feel free to comment with nominations for Sixth Sense Companies - the "all dead" ones - that made it back.
________________
*(tried to find it but couldn't; feel free to direct me to it in the comments and I'll link to it) 

API Launch - the Morning After (Facebook edition)

After Thursday's euphoria over the facebook launch, we were all wondering how quickly developers would seize this opportunity, and in turn how quickly facebook users to start using this application.

It took about a day, if that.

As Om reports this morning, many of the 65 companies who participated in Facebooks launch have seen record days for usage of their Facebook-facing APIs, and have signed up record numbers of users.

As often happens in this case, record usage exposes whatever weak links there are in the providers' infrastrucure. Some have withstood the load well, some have had to scramble for more infrastructure, and of course some have had outages.

Whether the catalyst for rapid growth of an API is success on facebook's platform, a post on techcrunch, slashdot or gigaom, or a rapid ascent on digg or techmeme, the result is the same.

Part of the reason for this pattern is that people don't know what to expect when an API is open. Rather than treating it from day one as a new distribution channel to exploit, it is often something to "try and see" if people will use it "and if it takes off" they'll devote infrastructure to it.

Of course, that's the Catch-22. Companies open an API hoping that lots of people use it, but are often unprepared for what happens when people do...in effect, setting themselves up for a low turnout and, once it goes down, ensuring that a low turnout is what they get. We at Mashery, of course, think that an ounce of prevention is worth an awful lot of cure.

Launching your API on day one with Mashery's access control, throttling, usage limits and detailed reporting ensures that you can recognize and control sudden increases in usage; our caching services allow your infrastructure to accommodate more usage than it could handle on its own. And when developers and users come, you'll be ready for them.

Facebook changes the distribution game

Very cool announcement at Facebook today which will get a LOT of play. Well beyond what was in the Wall Street Journal article earlier this week that I linked to...

Facebook has opened their platform to outsiders building applications, or pushing content, through facebook. Very cool, and very expected.

But they have gone one step further - these apps can trigger what they call a "canvas page" an empty block about 80% of the width of the page (the rest of the real estate is wrapped in a facebook header and left hand skyscraper ad) that you can fill with whatever you like. Content. Application. Data.

Or ads.

Your ads. That you keep all the revenue from.

Or your transaction engine. That you keep all the revenue from.

It's one thing to open the platform; but to put their distribution (today they announced they are up to 24 million active users, 50% of whom are active DAILY; they expect that to get to 50 million by year-end, 75% of whom will be off-campus) behind distributing your ads is exactly what APIs and web services are all about, and why we at Mashery believe that free and open APIs are going to be a huge catalyst for building new business opportunities on the web.

Facebook has created a huge new reason for providers of content and data to open APIs, with terms of service that are tailored to this opportunity, and supporting Facebook markup language. Mashery can provide the necessary security, management, caching, rate limiting, and especially metrics/reporting to exploit this opportunity and the others to come. We're already starting to work on this with some pretty big clients.

Facebook Markup Language - A "Reverse API"

Much discussion around the WSJ and Techmeme regarding Facebook's new "open platform strategy". Rafat at PaidContent focuses on a particular use case:

"...an example it cites is where a media company could let groups of users share news articles with each other on a page inside Facebook.  The firm currently has no plans to share revenue with the companies that develop services to run on Facebook’s platform, but the main draw would be visibility and access to users of the Facebook site."

Interestingly, little has been written about how this whole thing works. My understanding is that Facebook is specifying a "Facebook Markup Language", which you will need to use in your site's content (or in a Facebook-specific feed) so that Facebook's system can properly parse your content and publish it as specified.

As I explained to one of our clients who asked us about how this affects an API program, we at Mashery see the world in this way:

1. Facebook Markup Language ("FBML") is the specification of how to encode your content so that Facebook's servers can read and publish it.
2. "Content wrapped in a particular markup language such that another computer can read it and do something with it" is also called  "a web services API"
3. So what Facebook is doing is, essentially, a "Reverse API".
4. As they would with any other API, the provider of data in FBML will want to track how it is used, and will want detailed reporting on any metadata included in Facebook's FBML request.
5. As an added benefit, Facebook offers their own API that will allow a savvy FBML publisher to extract additional data on how their content is being distributed...and use that data to make the distribution even more effective.
6. If FBML is successful in gaining traction, we expect to see other content distribution platforms and social networks adopt it.

Fred Wilson has an interesting take on it, saying:

Instead of the wild west model that exists elsewhere in the social net world, companies that want to play in Facebook's sandbox will be offered the opportunity to build services in Facebook but in a way that works for Facebook.

That's not entirely an open model and may not be what third parties would ideally like. But its better than what exists today and it's big news.

True enough. But it's up to those third parties to make these programs work for them; the way to do that is through gathering the detailed analytics that can help them optimize their content and their distribution to meet their strategic goals.  FBML and other programs like it represent a great new opportunity for content and data publishers to take advantage of the web services distribution channel.

Steve O'Hear quotes Mark Zuckerberg, Facebook's founder, who said:

“We realize that we’re not going to be able to build everything ourselves here, and it’s not the most efficient thing for us to do that.” He added that letting others build services to interact with Facebook is “definitely going to be a bigger part of our strategy.”

That works both ways. Providers of web content and services can't build all the distribution they need any more than publishers and platforms like Facebook can build everything they will distribute. It's a lovely ecosystem.

Heading to NYC

I'll be in New York Monday morning 5/14 through Wednesday mornign 5/16 speaking at the SOA Executive Forum and meeting with current and future Mashery clients, investors and friends. If you want to meet up, let me know.

Busy day on BART

Thanks to all who pinged me to ask how my commute went after the recent conflagration in the maze. No big problems today - glad I kept my BART parking permit even though I don't ride as often as I drive; today was a good day to breeze into the station and get a great spot. First time I've ever seen the casual carpool pickup area devoid of either drivers or riders - no one was going there today. Today is pretty full on BART - by the time we got to the Embarcadero station we were full enough that people couldn't get on. But people were pleasant and patient, so the experience wasn't awful.

We'll see if ridership stays at this increased level after a few days of this...and, more importantly, after the repairs have been completed.

{side note - originally posted from my Treo 650 using typepad's client, which generated a random string of characters where my fascinating narrative was supposed to go. It used to work great; evidently we have some sort of character set problem. Feel free to weigh in if you know what I should do to fix it...]

O'Reilly Warns us of the Danger of Free APIs

Today we are treated to a fascinating post by on the O’Reilly Radar that admonishes us to beware of any free API, because anything that is offered free today shall surely become expensive, or unavailable, if we decide to rely on it.

“Free APIs are a very poor substitute for having the source and the data and thus owning and controlling every piece of your application”.

Hmmm – is there nothing between a free unlimited API and “owning and controlling every piece of your application”?  The O’Reilly site has search powered by atomz – has the conference biz been lucrative enough for Tim that he can afford to have his team write and manage their own search engine? After all, even things you pay for can suddenly become more expensive and threaten your way of doing business...just ask the people who raise howls of protest each time eBay raises its fees.

Take this post and remove the term "API" and substitute other things that people rely on and currently get for free, and you'll have the same "danger".  "VOIP". "Craigslist listings". "Search Engine". "IM". "Twitter". “Digg”. Any of these things can go away anytime our benefactors wish for them to. In the meantime, people who move quickly can build very cool services – and successful businesses – that harness these free services.

I remember when Yahoo Auctions listings were free (the first time around). People would list all kinds of things with no cost to list – as a result, you had much more of a flea market than on a site like eBay. Yahoo decided to compete head-to-head with eBay, and  introduced listing fees in 2001. Many businesses that could only function with free listing fees either had to find a new auction site or find a new business model. And Yahoo promptly saw 80% of their listings evaporate. Four and a half years later, Yahoo once again eliminated its fees in a vain attempt to resurrect its auction business.

What the companies relying on Yahoo auctions did not do is build their own auction engines…or find open source ones to run on their own.  Other auction services stepped in to fill the void.

Building composite web apps out of API building blocks provided by third parties is a fast and economical way to get new services out there. Whenever possible, the most successful strategy is for API providers to provide an effective upgrade path from small-scale free use to large-scale commercial use; this may require payment (as it does in the case of atomz), but I firmly believe that the most successful API providers will find some more creative way to extract value from widespread adoption of a “free” API.

And as for “owning and controlling every piece of your application”, I submit that if that if a developer insists on that constraint on any new web application they build, they will quickly fall behind competitors willing to risk that they might have to unplug one module that becomes unavailable (or expensive) and replace it with a competitor that sees strategic value in encouraging use of its API.

Google and Amazon are the exceptions, not the rule. Yes, Google deprecated their SOAP search API, and we’re all still kind of waiting for someone else to step in and offer a free, flexible search API. I predict that one of the major search engines will offer one within a year; if not, someone will set up a nutch-powered service and offer it as an alternative.

Google recognizes that their brand leadership allows them to end API access and limit third-party use to their widget - they are far and away the market leader in search and there are no other credible alternatives. For now, Google knows will make the most money by requiring that the search box is their widget, and that search results are delivered as google pages with google ads. This will go on exactly until someone else comes along with an API that gains material market share...at which point Google will once again get "open API religion". Amazon has gotten a ton of bad press around the alexa decision and subsequent lawsuit; this has already translated to increased adoption of the compete.com API.

Shortly after Rafer and I started Mashery and sold Josh on investing in the idea, I was told by one of the smartest people in our industry that it will never succeed in attracting many API providers as customers, because all APIs that attract developers will be owned and controlled by Google, Yahoo, Microsoft, Amazon or eBay. Obviously, I think that’s wrong. Decisions like Google’s only make me more certain that there is an opportunity for well-managed APIs to offer immense strategic and commercial value to the companies offering them.

And just as it happened with the internet, the vast majority of the most successful services will be offered free of charge...yet will make  a lot of people who offer then a lot of money, while others who insist on charging for comparable services find that little in the way of revenue results.

Alex Barnett Explains the Why and How of API Throttling

This morning, Alex Barnett, VP Community at Bungee Labs, provided a nice, concise post about the importance of throttling and controlling APIs. His post could have been a slide from my Mashery fundraising pitch. Let's look at his post step by step, with my comments interspersed:

7 Thoughts on the Business of API Throttling

1. Web APIs will be a key driver of future of the networked, services-based economy

Yep. We totally agree.

2. The science of web API throttling is set to become a core business competency - not just a technical competency - for (hundreds of) thousands of businesses

This is a critical point. API management is a necessary part of building and managing the distribution channel that an API program entails. We see what we do at Mashery as a business rules management engine, not as a piece of technology. Sure, there is technology involved, and as Alex notes the needs for the technology will get more complex over time. But the whys and hows of API management are driven by business imperatives far more than they are by technology issues, and the decision to launch an API program (and on what tools and capabilities are needed to manage it) belongs in the product management or business development function.  This has been the case at all of Mashery's customers who have launched so far, and will continue to be the case as the API channel is opened by more and more businesses.

3. Businesses need to learn about the business of API-based business models (an area where there is some experimentation and learning is going on today, but not enough)

Indeed. The evolving range of business models will be the catalyst for more complex needs in API infrastructure management.

4. Business expertise in designing and evolving API-based business models will be a highly valued skill / commodity

How true - very much like how expertise in SEO, SMO, ad keyword optimization evolved from being the realm of a few specialists to being something that hundreds of thousands of web publishers have embraced.

5. Standardized business models need to (and will) emerge regarding web APIs, similar to how there are standardized business contracts today

This is already happening. The most successful established programs, such as eBay's, exist as a means of bringing one's services into channels or verticals that have unique needs not addressed by the API provider's standard service. We'll talk more about current API business models in a future post.

6. API throttling will become exponentially more complex to execute and operate

Like all web infrastructure that seems simple at first, this is definitely the case. It's more than throttling - services such as caching, intelligent routing, load balancing, and service monitoring are already being demanded by Mashery's customers, and with each of these comes the need for more complex reporting and management tools.

7. A significant number of small and medium-sized business (the long tail of today's economies) that want to thrive in the networked economy will need to make a decision in the near future: "do we spend large amounts of resources in the technical operation of API service delivery and throttling expertise in-house, or should we outsource this?"

This, of course, is why Mashery exists. We believe that the resources needed to build, manage, evolve, improve and operate this infrastructure is significantly more complex and expensive than it often appears at first blush, and that for the vast majority of API providers it is not a core function to their business (even though it is a strategically crucial one).

So thanks, Alex, for setting forth the "API Throttling Manifesto", and for helping to bring more understanding of API management needs.

Congrats to Scott and Chasse!

Great way to spend a nice Friday off in the city!