Video and Slides: Developers Hate Marketing! Launching Your API and Attracting Developers »

Thanks to all that attended last week's API Best Practices Webinar #7 "Developers Hate Marketing! Launching Your API and Attracting Developers." Here are the slides and video! 

In this webinar we share our experience, best practices and toolkit for API and platform adoption. We cover creating a beautiful developer experience, audience segmentation, offline and online community, the top 10 things you need to launch your API and more.

Join us next week for the next webinar, OAuth for Your API: The Big Picture with our CTO Gregory Brail and Senior Architect Brian Pagano. We'll discuss business and operational benefits, the different versions of the spec, and answer your questions.  

Developers Hate Marketing from Apigee on Vimeo.

Video and Slides: Your API Sucks!  Why Developers Hang Up and How to Avoid That »

Thanks to all that attended last week's API Best Practices Webinar #6 "Your API Sucks!: Why Developers Hang Up and How to Avoid That" (and thanks to our presenters @earth2marsh and @landlessness).

We apologize for the audio problems during the actual webinar - but Henry - our amazing filmaker - did a great job of cleaning it all up for the video below. 

Need to transact credit card information with your API?  Then check out our next API webinar, "Does your API to be PCI Compliant" with @brianpagano, our Sr. Architect, and @scottmetzger, our VP of engineering,  is July 14th at 11am PST (sign up here!)

(for our entire video series, check out the rest of our API best practices webinars)

Social Commerce as part of ‘Distributed Commerce’ through APIs »

There’s been some buzz about ‘social commerce’ this year, with a great WSJ article a couple weeks back: Retailers Embrace Social Commerce.

However, there’s not really such a thing as ‘social commerce’.

What these companies are doing is executing a ‘distributed commerce’ strategy.To really understand this profound shifft, it's worth watchign Sam Ramji's talk on  evolving business models in his Web 2.0 Strategy presentation: Darwin’s Finches, 20th Century Business and APIs.
 
A key point in this talk is how business is migrating from a direct to indirect model. 

The web revolution that gave birth to Amazon and eBay was based on a shift to a direct business model… retailers selling directly via their websites. 

Today businesses are figuring out how to execute an indirect model.  They are trying to put their product/service/content where their customers are. 

To use some retail-speak, the nuance is that commerce is now about more than about 'selling in' a channel, it is about selling ‘through’ a channel.

So where are customers?

Increasingly, consumers are on the move and on their smart phones.  They are on tablet computers like the iPad and on game consoles (xbox, ps3) and set-top boxes (roku, etc), and filling their car at gas stations. 

Consumers are also spending time on social networks… which brings us back to ‘social commerce’.

Borrowing Sam’s Finches metaphor, retailers are exploring their ‘niches’… reaching out into the places where customers are, and selling in that context.

So a Facebook store is just one niche, one place to reach customers where they are.   Gamestop is another retailer with a Facebook store.  However, Gamestop is also on mobile device apps and other social networks.  They are executing a distributed commerce strategy well.  In the same issue as the social commerce article, WSJ reported that Gamestop’s profit rose 6.9% on higher sales.

Another example of distributed commerce is Shopsavvy, a mobile app that searches for products based on location and brings back pricing, availability and product attributes.  Retailers want to be included in the shopsavvy app to have their products discovered by consumers in that venue.  Shopsavvy itself is exposing its engine to developers who are finding niches of consumers via wine-specific apps, “Lego apps”, etc

In the post-web world, forward-thinking retailers are executing distributed commerce strategies to reach consumers where they are, including on social networks. Where are your customers?  And what is your distributed commerce strategy to reach them?

Globalization, Black Swans, and APIs »

Sam Ramji gave this talk at GlueCon on delivering APIs globally.  Considerations include:

• distribute locally
• serve elastically
• specialize universally

To see what Sam is talking about (and how Black Swans play into it) check out the slides below.  To deliver APIs globally, also check out our API Delivery Network - a CDN for APIs. 

Globalization, Black Swans, and APIs »

Last week Sam Ramji gave this talk at GlueCon's "What's next for APIs" panel.    Sam talks about considerations for delivering APIs globally - including:

• distribute locally
• serve elastically
• specialize universally

To see what Sam is talking about (and how Black Swans play into it) check out the slides below.  To deliver APIs globally, also check out our API Delivery Network - a CDN for APIs. 

How APIs encourage the separation of content and presentation »

From the dawn of the web, we've been entangling presentation with content. Which is, overall, a big suck. Why? Well, on one hand, it's fine for people to consume. But it's really rude to computers. And computers, after all, are doing all the work to keep the Internet running.

If computers can't easily parse data, they can't do anything meaningful with it. However, once computers can easily disentangle the layers of data, watch out: innovation happens like crazy.

In a series of blog posts I'm going to talk about all the beauty of separating content from presentation. And how that simple idea when amplified with proven, existing design patterns makes things really interesting. Let's start with Twitter as an example...

When you view tweets on twitter.com, you see shared links, hashtags, and @mentions, all of which are clickable. But if you query the Twitter API you get back plain text. Why?

Because Twitter understands the importance of separating the content layer from the presentation layer. Imagine seeing this on a phone:

Ran into <a href="http://twitter.com/shanley">@shanley</a> at <a href="http://twitter.com/#!/search?q=%23sxsw">#sxsw</a>!

… because the SMS app on that old phone didn't understand HTML! Furthermore, when every character counts, like in a 160 character SMS message, markup would end up dominating the content. You shouldn't even assume that the consumer device will even know what to do with it.

So instead, Twitter keeps statuses as simple as possible—text only. This is plain, vanilla content. No markup, just data (well, unless you count the "organic" markup conventions like hashtags and @mentions).

Everything else, all the rest of the CSS and HTML that make up the twitter.com experience—that's the presentation layer. It takes all that content and makes it look good.

APIs, at their most basic, are carriers of content. They are perfectly evolved for getting data from one place to another.

And this is super-important in today's world, where we consume content on multiple devices. One size no longer fits all. There is no single form-factor. Each device offers a different experience of the same content.

This is just one example why APIs are changing the way we develop, by demanding the best-practice approach of separating the content and presentation layers. Modern web applications use the same APIs that their official mobile apps do. And those are the same APIs that get exposed to 3rd party developers who innovate around the edges.

How to learn and explore PayPal’s Adaptive Payments APIs with Apigee Tools »

At PayPal's Innovate 2010 event yesterday, we launched our API Explorer for the PayPal Adaptive Payments APIs, including their new ones. Our own Sam Ramji gave a great demo on stage, but in case you couldn't be there, here's a quick overview of how to get started:

Welcome to Apigee! »

Today we've changed the name of our company - from Sonoa Systems to Apigee Corporation. Sonoa Systems' API infrastructure platform is now Apigee Enterprise and the Apigee tools platform you know will remain free.

This company was started with the vision that the web would be mostly driven by web services. And this would bring new opportunities and challenges - business and technical.

It's happening with APIs - driven by an explosion in mobile, social, and cloud. What started on the web has become part of enterprises. Companies of all size are opening APIs to reach customers beyond the browser.

One year ago we launched our free Apigee service for developers using APIs. Today we are putting all our strength behind one brand and product line-up - Apigee Free, Premium, and Enterprise. Premium is in private preview today, and you can sign up for an invite to check out new features for providers like OAuth, caching, unlimited requests, developer key provisioning and more.

Apigee is for people for want to provide and use API's - made by people who love APIs.

Try it now for FREE, or find out why EVERYONE is doing it.

Check Out Facebook’s New Places API »

How to explore Facebook's new Places APIs in the Apigee Test Console:

Don't have a minute to watch the video? Start by viewing the checkins at the Cookie Jar.

Connected Devices, APIs and the New Web - Can You Make the Shift to a Post-Browser World? »

Two weeks ago the Wall Street Journal ran the story ‘Sam's Club to Use Wi-Fi to Push TVs,’ highlighting internet-connected TVs which run popular social media or video applications. Last week WSJ highlighted how cable companies are getting their content on the iPad in response to excellent execution by Netflix and Hulu. This week, WSJ reports how businesses like law firm Sonnenschein Nath & Rosenthal, Bausch & Lomb, and Mercedes-Benz Financial are adopting the iPad as a business tool. APIs are all over the business press as early leaders emerge and competitive pressure to succeed in the multi-device web heats up. 

Chris Anderson sees the trend. From his excellent feature article in this month’s Wired:

Over the past few years, one of the most important shifts in the digital world has been the move from the wide-open Web to semi-closed platforms that use the Internet for transport but not the browser for display. It’s driven primarily by the rise of the iPhone model of mobile computing, and it’s a world Google can’t crawl, one where HTML doesn’t rule. And it’s the world that consumers are increasingly choosing….

We’ve seen a shift like this before. In the late 90s, consumers adopted the web to search, shop, and socialize. Companies who recognized the shift capitalized (think Google, Amazon, or eBay), and those who couldn't innovate fast enough suffered. 

How can consumers reach your service or interact with you on their device (phone/set top/tablet/car/other) of choice? Can your service or data be included or embedded in applications consumers love? What would be the impact if your main competitor’s service was available everywhere and embedded in popular applications and devices?

An open API strategy allows you to engage and capitalize in the multi-device world - and just like we saw in the 90s with websites, companies need to adapt to succeed. 

A Preview of Sam’s Web 2.0 Expo Talk: Evolve your Business Model with Open APIs »

What do Darwin's finches, the old garment district, and open APIs have in common?

Check out this short preview screencast of Sam Ramji's 2010 Web 2.0 Expo San Francisco talk tomorrow (and here's the full abstract).

Hope to see you there!

Paid vs. Free APIs »

Last time I wrote about the difference between'open' vs. 'free' APIs.  

Another interesting dimension is free vs. paid.

Free vs. Paid has to do with the business model of your service.  If you have a service that’s valuable/revenue-generating to the user (unlike advertising/reach, which is valuable to *you*) then you might choose to ask to be paid - through a credit card, licensing or BD deal.  (we've written before on the many API monetization models and resulting API roadmap and technology implications.)

While I hate the term "freemium" (more on that later) .. You might also choose to offer your free service up to some limit (100 API messages/hour) and then charge for larger volumes (100-999 calls cost X, 1000-4999 calls cost Y, etc.).  The lowest rung on the pricing waterfall is often 'free'.

Twitter's API has both free and paid access.  For typical end-users, the API is free and provides a limit of 150 messages per hour.  For larger usages – such as those from media and news companies who want to harvest Twitter data – there is paid access to enable message volumes in the thousands and higher per hour.

No doubt if the volume of API calls in the Tweetdeck case to Facebook goes up, there could be a charge; or if Twitter starts selling licenses to consumers for larger API bandwidth as they do today for enterprises (media companies), Tweetdeck could be a place where those licenses are sold.  Personally I would happily pay $2-5/month to get 500-1000 messages per hour on Twitter due to the incredible utility of Tweetdeck.  Otherwise I’d be confined to the Twitter web interface which is just not that useful to me.

We are really in a very dynamic part of the API market right now where many business models are being tested out.  We should have a longer conversation about the different business models that seem to be working.  A good example - Fred Wilson had some great and different thinking that can open up new profit models through APIs.

Next - is there a business model in *paying* people to use your API?

Sonoa welcomes Sam Ramji »

We're delighted to welcome Sam Ramji to the Sonoa team as VP of Strategy.    

Sam joins us from Microsoft, where he drove many of Microsoft's contributions to open source and the company's shift to embrace open source technologies like PHP.  

In honor of Sam's first day - Sam and Chet Kapoor, CEO of Sonoa, spent some time discussing the API economy, remixing services, and why the time is now to transform your business with Cloud APIs.

If you build it will they come? Developer Community and Audience »

(The 10th installment in our API Roadmap Considerations series)

You've built a great API and have the operational bases covered.  Now the fun part - buiiding awareness, adoption, and community.

Think about it like throwing a party - you need to get the word out, have food and drinks covered, and help people mingle.

That is - 3 things need to work together  - audience, tools, and community.

(But first you must have a cool product.)

Always loved this talk by Dave McClure.  First – your product better be cool. Or..start with a great, differentiated API.

Developers will make or break your API strategy. If you focus on making developers successful you are building on a very strong foundation.

It's important understand different developer segments, what's important to each, and key contributors. And there are thousands of APIs now - maybe dozens in your vertical.  Is yours differentiated by features?  Better terms?  A SLA?  More data?

Get the word out: Audience

We often see API developer community plans that focus heavily on tools and building a 'destination portal'. 

But first - plug into existing destinations and communities.  You can sign up for most of these now, for free.  They reach thousands or millions of developers and they rely on your content and participation.  Examples include:

• API listings and resource communities like ProgrammableWeb.
• Vendor communities, like Microsoft's MSDN, Google code.   If these developers might use your API, you should be there.
• Platform communities like RubyOnRails or iPhone.
• Independent communities like Stackoverflow.

This also helps your search engine discoverability on anything related to "API + your business."  You want to rank well aginst similar APIs in Google searches.

All the fixin's:  Tools and processes

Just like a decent party needs catering and comfy chairs, you need tools and processes dialed in before your API launches.  Things like developer onboarding , developer key management, and integrations with the business (billing, compliance, etc.).   Dress rehearse these during the private alpha period so you can handle demand when it comes.   We often see teams that have licensed all the tools but haven't run the processes end to end - it's just as important as testing your API.

You'll need to make it easy for developers to find and help each other when working with your APIs. Blogs, documentation in wikis, code samples and app galleries are critical and easy to create. (most are free).   And again, not just the tools but dress rehearse the processes. (i.e. who's on duty for monitoring and responding to tweets and blog posts.).  For example, we love GetSatisfaction for Apigee.

For content and resources, code samples are consistently ranked at the top by developers.   You can use your own QA stuff for starters -  that they can incorporate in their own apps.

Take jackets and get drinks:  Community

If your API is easy to find and you have tools in place, you can tackle 'community'.   A book could be written about this, but successful communities have a hardcore group of developers that help each other be successful, an open dialogue with the API provider, show up at both online and offline events, and have at least one rabid, hardcore evangelist ringleader at the core that writes code with the API and seems to be everywhere.

The best community managers make it all about the developers – welcoming them, showcasing their work, and making them stars.  (more ideas at the end)

Should you outsource community management?  It's all about the passion - we usually see the best being full-time employees that actively seek out the position.  

Your Roadmap: Audience and Community

So if you are opening and API, think about the following for your roadmap.

Audience and distribution

• Can you get awareness and distribution through existing developer communities, such as any vendor (MS, Google IBM), Platform (Ruby, iPhone), Independent, Directories (programmableweb)
• What Web marketing - Search Engine Optimization or Adwords - can you do to make sure developers find you

 Tools and processes

• Do you have formal documentation? Can you put it on a wiki?
• Do you have code samples on how to use the API?
• Do you have a place for developers to put their own code samples and showcase their own work and sample apps? (widgets, mobile apps, etc.)
• Are code libraries needed for important platforms? Should these be open source?
• Do you have a blog for best practices and a way to get in touch with developers on important changes (such as API version updates?)
• What about adding and managing developers?  More on that in User Onboarding and Management

Community management

• Should you have a dedicated full-time employee to drive community and evangelize your product and best developers?
• Are there any offline events or meetups you should be at?
• How can you recognize and promote your hardcore community members? Do you have an evangelist that knows these folks personally?

Good resources and other ideas

Create discussions & docs on Google Groups.  Check out how some of the great developer communities use Google Groups, like:

• twitter - http://groups.google.com/group/twitter-development-talk
• iphone - http://groups.google.com/group/iphonewebdev
• ruby on rails - http://groups.google.com/group/rubyonrails-talk
• get started with your own group here:  http://groups.google.com

Make your API sample code available on a social version control system like:

• github - http://github.com/ - uses git
• beanstalk - http://beanstalkapp.com/ - uses subversion

Promote Yourself on facebook, twitter & a blog

• facebook.com - create a fan page
• twitter - look for people doing the stuff with your API and call it out
• blogger, typepad, etc all provide a great way to respond to and showcase developers

(and thanks to Richard0 for the photo..)