Praxis

No one knows the future - that's the point of APIs (or, Teri Takai has it backwards)

Thanks to Jen Pahlka for twittering an important (if troubling) comment made by California CIO Teri Takai at an event today:

Asked my own ? to Teri Takai: what are plans for CA to open up data to citizens?

A: we want to know what will provide value b4 we do it.

Teri, you have it backwards. The whole point of opening data through APIs is that you have no idea what will provide value. You have no idea how the data will be used. 

APIs and open data allow innovation to occur outside the organization, which is what makes it so important that all levels of our government open as much data as possible and let citizen-developers experiment with it to find opportunities. That is the whole point of transparency in government. 

Open data is a necessary ingredient for innovation, transparency, and the creation of all kinds of value that none of us can predict today. If you only open what you think has value now, you will miss all the opportunities that you can't anticipate. 

Sir Tim Berners-Lee, who invented the worldwide web (so he knows a thing or two about open data) implored all of us at TED - now is the time for data to be open. Teri, our state should be the leader in this. It is our data. Please open it up to us and let all of us help promote change, and build value.

Facebook, APIs and Monetization

Image via CrunchBase

One of the topics we frequently talk about at Mashery is "how does a company monetize its API?". More often than not, the answer is that the API is a new distribution channel for the company's core service, and as such is monetized however the core service is.

So if you are a content company, you monetize your API through driving more traffic to your site (as the New York Times does) or through including advertisements with the content served over the API (as the Guardian does).

If you sell monthly subscriptions to movie rentals like Netflix, you monetize your API by improving the subscriber experience, so your subscribers get more value from your service. Churn goes down and revenue goes up.

Or if you sell access to specialized data like Urban Mapping, you monetize your API directly by selling access to a premium API.

So where does this leave facebook?

So many pundits are scratching their heads about facebook's new activity stream API.

"They are going to lose so much traffic!"

"How will they sell ads?"

"Isn't facebook giving away a potentially valuable source of revenue?"

Take a deep breath and think, everyone.

I think we can all agree that facebook's core competency is not around creating a universally acclaimed user interface. What they have done is created a sharing and communications engine accessible in a variety of ways that, for a variety of reasons, two hundred million people find to be compelling and useful. Along the way, they have gathered a ton of really useful information.

Google claims that their mission is to "organize the world's information and make it universally accessible and useful". Lovely, laudable and largely true. But when it comes to information about individuals - what and who they are passionate about; self-reported demographic info; social graph; employment and job title; you name it - facebook has organized a ton of information that Google can't offer.

It is this information that is facebook's core asset, and their sharing and communications engine that will ensure that the value of this asset continues to grow. It's true that at this point, facebook monetizes that asset by running ads on its site, but the API unlocks many more ways to generate revenue - and to grow a lot faster.

Advertisers buy ads on facebook because they're not just buying keywords - they can buy people who work at specific companies, or like specific movies, or have specific demographics...or all of the above. That won't stop; plenty of people will continue to buy ads on facebook.com because many people will continue to use facebook.com as their primary means of accessing facebook.

But just as Google brought us Adsense, so will facebook be able to monetize the users who access facebook through third party sites and apps. Except rather than being the mess that Adsense has evolved into - many advertisers have found that spending money on the "content network", as Google refers to Adsense publishers, is not nearly as effective as buying the Adwords that are displayed in google.com search results, and smart publishers are able to manipulate their sites and pull in spam links to attract the appropriate ads and clicks - the facebook network will be every bit as effective for advertisers as facebook.com.

So how can facebook monetize the activity stream API? Here are a couple ideas...

1. Adsense 2.0 - people place ads with facebook with the same ultra-tight-focused targeting that they can on facebook, and facebook pushes those ads to the third party sites or apps and shares revenue
2. Facebook sells the targeting data itself through an API, and the third-party apps/sites can query the API to figure out the appropriate ads to serve. Facebook either shares revenue or gets a CPM fee for access to that API that is lower for basic demographics and much higher for more specialized information (employer, job title, university, favorite movies, etc, etc). One opportunity with this model is that not only can the developer serve standard ads, but they can also do a whole range of enhanced sponsored experiences that could generate significant revenue. This is especially true with third-party apps that would be freed from the constraints of the browser.

And I think we'll see even more creative ideas as people begin to understand the power of the API.

But whatever happens, it will be based on facebook's core competence, not on what can happen within the constraints of the www.facebook.com website.

Facebook: How to compete with Twitter? Start with the API

It's no secret that the folks at facebook have gotten increasingly focused on competing with Twitter to become our source for the never-ending stream of news and minutiae without which we clearly can not draw breath. The much-maligned redesign was clearly an attempt to turn the news feed into "twitter on steroids"; unfortunately, like with real steroids, unintended consequences often result. 

So it appears that facebook stepped back and took a closer look at how to win. A few important points likely became obvious:

• facebook has a whole lot richer store of data than twitter does - photos, videos, events, etc. this data is organized in a pretty useful way (think microformats), so if people used it right, they could take the basic concept behind twitter and remix it in such a way as to make a much richer user experience
• for facebook to consider alternatives internally, get consensus on what to do, build them, test them, and then release them to 200,000,000 users would take way longer than they have to fix the user experience 
• it would be hard for facebook to do a lot of experimentation and iteration on alternatives, because every small change they make is subject to such scrutiny, commentary, second-guessing and tea-leaf-reading (not to mention the outpouring of opinions from millions of very passionate users) that figuring out exactly what to do would be difficult 
• and besides, there is no guarantee that the "best" user experience will come from inside facebook - after all, of those 200,000,000 users, there are likely hundreds of thousands of people who have development skills, and all of their users have opinions and ideas. 
• but most importantly, they must have realized that twitter's api has been the key to its growth, a fact that has been reiterated time and again by twitter's founders and by the many journalists and bloggers who have covered twitter's meteoric growth. 

So how do you compete with twitter? You start by emulating the thing that made them huge, and open an API for the news feed. What happens? Well...

• Everyone who has built a twitter app can add facebook to it as well. Tweetdeck, my app of choice, now has a facebook column, and as functionality grows, I expect to interact with facebook more through a third-party app than through facebook's user interface. This makes sense; I rarely visit twitter.com anymore.
• At least one of the hundreds of thousands of people who have clamored for a return to the old user interface will build a third party app that looks just like the old facebook.  
• Thousands of new apps are being developed as we speak, far from the prying eyes of the facebook-watchers. They're being circulated among friends, redesigned, reworked, and refined. Many of them will never get traction, but some inevitably will...and I'll bet that some of the most popular ones will come from people none of us have heard of - and who would never be able to get the attention of facebook execs.  

On a technical note, I also believe that as of today facebook has created the de facto standard for activity streams. Yes, there is an open standard that facebook participated in creating it, and yes, facebook has added extensions that go beyond the standard. That's how it works; new standards are rarely flexible enough to accommodate all needs, so they need to evolve and be extended. That's essentially how AJAX got started, and how many other standards have evolved. No reason to complain about it. We now know the new activity stream standard, and smart providers will embrace it immediately so they can support the same third-party apps being developed for the market leaders. Just as bebo did with FBML and FQL, right before they were acquired.

Outstanding move, facebook - I can't wait to see what develops.

Eric Lewis for Free in SF - Not to be missed

Every once in awhile, an artist comes along who makes you rethink what is possible on his or her medium. On the piano, for me, that artist is Eric Lewis. The first time I saw him was on stage at TED. You can see one of his pieces here, in perfect TED high-def wonderfulness.  

The second time I saw Eric was the following night, when he did an impromptu performance in the lobby of the Westin hotel, Long Beach. A tap dancer appeared at one point; magic happened. 

A lot of people noticed. Eric's been booked pretty solid since. So solid, in fact, that he had to turn down three requests to play at the White House before he could find a slot that worked for him and Barack. So he'll be in DC in a couple weeks playing for the Commander in Chief, but before that, he's here in San Francisco to play for us.

This afternoon (Saturday April 25 2009), Eric will be playing another impromptu free concert. There's a back story, but suffice it to say that Eric had some free time and a desire to play, and Cyan was able to get her friends at DNA Lounge to make a venue available. All we needed was a piano; Cyan put that request out to Twitter, and had it handled in a couple minutes. The logistics were worked out, and Eric's ready to play. Mashery and Zivity are helping out with logistics, and it's all about helping venues like the DNA Lounge bring more and better live music to San Francisco. 

I encourage anyone who has not seen Eric perform to come join us. Anyone who has seen him will need no encouragement; they're already on their way. 

Hope to see you there!

DNA Lounge

375 11th Street

San Francisco

5:30 pm

Saturday, April 25, 2009

Symbiosis and APIs in Twitterland

This morning Douglas MacMillan of Business Week wrote an interesting piece on the developer ecosystem springing up around the Twitter API. As with all ecosystems, this one is a symbiotic relationship, and MacMillan interviewed numerous app developers who are making money off Twitter. And Twitter founder Biz Stone weighs in with an excellent quote - "Because the ecosystem that has grown around Twitter is so integral to our own success, we are sensitive to how we interact with it."

MacMillan details some of the risks inherent in building apps in such an ecosystem:

• The rules can change, as happened with the Facebook platform's de-emphasization of third-party apps
• The API can change, as happened when Twitter abruptly deprecated some of the API methods that developers had come to rely on
• The API provider (symbiotic host) can decide to launch their own feature or app that renders the developer's app obsolete - a risk that is not dissimilar to what happened to Odeo, the company out of which Twitter sprang, when the iTunes music store added podcast support
• The API provider can suffer outages, bugs, or slow performance
• The API provider gets bought, and that can result in any of the above

As I said to MacMillan, "Ultimately, Twitter exists to make money for Twitter." Happily, Twitter recognizes that the fastest path to doing so involves building a symbiotic relationship with a bunch of great developers, and they in turn build apps that result in user growth and more revenue for Twitter.

Twitter's challenge is to manage this balance in a way that benefits both sides, and the developers' challenge is to build apps and business models that are sustainable even as the rules, capability and performance of Twitter's API evolve.

Twitter's growth to date is testament to the success that both sides have achieved to date. Symbiotic relationships are not without risk, but those who are unwilling to take risks cede the rewards to those who are.

API First - or Open Everything

This morning MagicMerl pointed me to a great post by Kas Thomas called API First Design. Clearly, there are benefits to developing your APIs at the same time as you develop your web app. As I commented:

"API First" is spot-on - the way we at Mashery describe it is that a developer should be able to build any or all functionality of your website through your API, and that your web app actually runs on the same APIs (and therefore the same codebase) that you make available to third party developers. 

The advantages of this approach are obvious: 

- a single codebase to maintain

- no additional work to open the API (through Mashery, of course :) - since you will need to create rules around which developers are authorized to use which API methods if all services are built as APIs)

- consistent behavior across the API and the web app. I have seen search APIs that return different results for the same search depending on whether that search comes in through the API or the web page; this makes developing apps difficult, since you can't test and debug different searches on the website.

- by opening the full set of services through APIs, you are providing the broadest possible toolset for third party developers to use in building apps, and you will see way more innovation than if you limit your APIs to a subset of services.  

So even if it is too late to be "API First", we strongly recommend that you "Open Everything" as quickly as you can, even if doing so takes time. The New York Times is setting a great example of how this is done - since opening their first API last October (campaign finance data), they have steadily opened more and more services over the past few months, and will continue doing so until everything is open. They have publicly announced their commitment to opening everything, so developers know that there will be new and exciting building blocks coming down the road.

API First Design also helps in monetizing your API the right way. A successful API is a distribution channel for your core services and makes money as an extension of your core business model. Or, as we like to say, "bake your business model into your API". 

The Guardian's Data Store - Syndication of Syndication

Two weeks ago, I had the pleasure of attending the New York Times's API launch event. Tim O'Reilly spoke about the evolution of newspapers, and said hailed Times Open (their API) as a significant step in the right direction for an important industry facing big challenges.

When Times CTO Marc Frons announced their API plans in May of last year, we at Mashery began fielding a lot of calls from news organizations looking to learn about APIs and figure out how they could build new revenue and distribution from opening their content and, as Marc said, making the NYT programmable. 

One of the more intriguing inquiries we received was from the Guardian in the UK. Not only are they making their content available through their API, but they are also publishing content from other sources in what they call the "Data Store...a collection of important and high quality data sets curated by Guardian journalists. You can find useful data here, download it, and integrate it with other internet applications."

The Data Store is of particular interest because the team at the Guardian recognized that just as they provide a mix of their own and others' content on their website in order to make a more complete and compelling experience for their readers, so should they include as much of their third party data and content as possible in their API. This gives developers a broader range of content to incorporate in their applications, as my very good friends (and Mashery customers) at Zemanta have already demonstrated. But more importantly, it allows smaller content providers who already leverage the Guardian's brand and traffic to reach a broader online audience to enjoy the same benefits from the Guardian's API. And the Guardian is able to build a stronger distribution channel for their own content by broadening the data available to their developer community. Everyone wins.

Today, we're happy to report that the Guardian has launched its API, including the Data Store, using Mashery's services. We're providing all the usual pieces of the API puzzle - rate limiting and business rules enforcement, key issuance, developer management, caching, and so on - but with a twist, since we will need to enable the Data Store to set different rules for different data sets. One of the most critical elements will no doubt be our reporting, which will be used to track who is using which data. 

I expect to see many other news providers - and travel sites, e-etailers, search engines, and everyone else - adopt the Data Store model in coming months. Should be very interesting.

Panic vs. Urgency - only one is useful

Read a a great post from Brad Feld this morning in which he shared a memo one of his portfolio CEOs sent to his team called "The Difference between Panic and Urgency". It should be required reading for every startup employee (and has just become so for the entire Mashery team).

The post contrasts panic - "a sudden overwhelming fear, with or without cause, that produces hysterical or irrational behavior, and that often spreads quickly through a group of persons" - with urgency - "relentlessness, steadiness and the purposeful pursuit of a goal while “continuously purging irrelevant activities to provide time for the important and to prevent burn-out.”

In every startup I've worked at, people who panicked would fail out fairly quickly, and those without a sense of urgency (and the ability to purge irrelevant activities is key to this) would fail out more slowly. There is too much to do, and too many distractions from things we "could" or even "should" do but are not urgent enough to move to the top of the list.

Don't panic!

But bring urgency to everything you do.

API Video from Hoovers

The Mashery support team just passed along a link to the redesigned Hoovers API ("HAPI") developer site. They included a great video that explains what you can do with APIs in general. Great to see a Mashery customer doing such a great job of promoting their new API. For more info on HAPI, check out the Hoovers presentation from the recent Business of APIs conference. The slides from all of the presentations (from an amazing roster of speakers) are now available here.

Hugh MacLeod of GapingVoid helps Mashery explain API monetization

Yesterday I made a presentation to senior management at Best Buy about the API ecosystem and some of the great opportunities they will have with their recently announced, mashery-powered "remix" api.

I've long been a fan of Hugh MacLeod, the cartoonist behind gapingvoid, and am very fortunate to call Hugh a great friend.

So when I was looking for some images to help explain how the "remixed" world works, I borrowed liberally from Hugh's trove of cartoons (which he makes freely available to anyone to use, with attribution). It occurred to me that given Hugh's licensing terms (and his own business model of giving away free cartoons in order to make money as a cartoonist), he of all people understood the value of making content available to others.

So I asked Hugh to think about the API ecosystem and come up with a cartoon that could help explain the why companies would make content available as an open api. He was kind enough to take a break from finishing his book manuscript to draw the cartoon above. I love it - and anyone who sees me speak is likely to see this cartoon in my slides. Thanks, Hugh! (cross-posted at mashery blog - image copyright (c) hugh macleod, www.gapingvoid.com)