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..)

One size doesn’t fit all: API Versioning and Mediation »

(continuing our series on API roadmap considerations)

TrueCredit.com tells a story of calculating they would need thousands of IP addresses for all the different versions and flavors of their open API - to account for different variations and versions needed by partners.  

Even if you have a ‘one sized fits all’ API - you might need to be able to transform data, mediate terms or customize SLAs without coding each change or a creating a new version of the API. Reasons could include:

•    Protocol needs - A SaaS customer with a REST API had an important deal on the table with a bank, but the Bank insisted on a SOAP API with WS-Security.  Some SOAP shops want to offer a RESTful API because it’s easier for developers to work with. And you might need to transform between different syntaxes of SOAP, REST, or REST/JSON, etc...
•    Monetization – You might want to sell a premium version of your ‘one size fits all’ free API.   For example, a search API provider wanted to do a BD deal with it’s free API and needed to insert extra data ('enrich the API' as they called it) the partner wanted to pay for.
•    Standardization –  A customer of ours grew from offering 1 API to 40, and needed to add some standard fields to each API - enforcing some consistency without needing to coordinate a bunch of teams to write code.
•    Versioning - Ever used an API where you get an email every month asking you to upgrade to a new version?   TrueCredit wanted to provide API upgrades to customers that needed it while holding the API fixed for everybody else longer, to reduce versioning headaches.

So you may need to figure out how you to provide and manage different flavors or versions of the same API – or ‘mediate’ (or transform) API content and syntax.

Alternatives might be to support multiple APIs (painful), hold off as long as possible and push back on customers to snap to a ‘one size fits all’ model (more painful), or create a ‘mediation’ capability or layer that can transform between different ‘shapes of the API – protocol, data, version, credentials, etc.

(And going back to TrueCredit’s story at the top, this is what led them to think about an API gateway for mediation, caching, load balancing, and more.)

So ask if and when any of these issues might apply to your roadmap:

Will you need to mediate protocols?

• Will you need to offer more than one protocol or a different protocol?  (SOAP for enterprise customers? REST or JSON for developer adoption? )
• Would you ever need to map across different security or credential schemes?  (ex: from simple HTTP auth to WS-Security)
• Will you need to handle syntax issues across a particular protocol (SOAP 1.1 vs. 1.2, etc.)
• How important will it be to minimize API versions?

How important is version management?

• How often will you need to release upgrades to the API?  What is your process for asking customers to upgrade and how long will it take to sunset a version?
• If you offer more than one API, any need to standardize elements of the API (header or payload)?  Do different teams need to do this or does it make sense to put this capability at one point?

Will there be a need for payload transformations?

• Will you ever need to enrich an API for a particular customer or class of service?  (such as a big customer that licenses more data..)
• Will you need to remove or clip certain fields for certain customers or classes of service?
• How fast will you need to turnaround these requests for the business vs. your dev or product cycle?

A mediation layer (see more flavors here) can be important to handle complexity so you can focus development on business specific API capabilities.

(and thanks to collinanderson for the photo)