Successfully reported this slideshow.
Your SlideShare is downloading. ×

Reaching Out To Developers

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
How to become an awesome oss
How to become an awesome oss
Loading in …3
×

Check these out next

1 of 12 Ad

Reaching Out To Developers

Download to read offline

A brown bag presentation given at Sky in London about strategies and ideas to keep in mind when releasing APIs and talking to developers.

A brown bag presentation given at Sky in London about strategies and ideas to keep in mind when releasing APIs and talking to developers.

Advertisement
Advertisement

More Related Content

Similar to Reaching Out To Developers (20)

Advertisement

More from Christian Heilmann (20)

Recently uploaded (20)

Advertisement

Reaching Out To Developers

  1. 1. Reaching Out Strategies and ideas Christian Heilmann | http://wait-till-i.com | http://twitter.com/codepo8 Brown Bag @ Sky – June 2009, London, England These notes are *very* brief - for a full transcript go to http://www.wait-till-i.com/2009/06/15/ reaching-out-to-developers/ * Third party developers make your product better * Reaching them can be tough * Here are some ideas and strategies that worked in the past
  2. 2. The importance of being open * Opening your data and services multiplies your reach * Developers are happy to use your products and test them at the same time * You can not test for all environments, other people can
  3. 3. Building for web use * Be Platform independent * Be RESTful * Release all documentation and code examples in a portable format
  4. 4. Thinking of * Good URL structures endpoints * Easy to understand method names and parameters * Versioning of APIs
  5. 5. Thinking of output * Provide data that people need - a lot of data is good but don't add information that only makes sense internally. * Provide data formats that people can use: xml, rss, json * Allow for callback parameters for json to use as JSON-P * Maybe allow for object transportation / ID for JSON-P calls * Allow people to turn off diagnostics and filter down to specific needs
  6. 6. Providing easy access * For data APIs that are read only, don't bother with authentication - just use a developer key * Have sandboxes where developers can play without having to sign up
  7. 7. Documentation * Provide proper documentation that is quick to read and easy to navigate * Offer cheatsheets and quick introductions * Have a documentation team - developers are not writers and are too close to the product to actually write readable docs
  8. 8. Demo Code * Provide demo code and SDKs (if you really must) * Have excellent demo code - *not* 'look, just two lines of code' * Offer different language demos
  9. 9. Be responsive * Have a mailing list / forum that is monitored * Keep your eyes out for things people do with your code (blogsearch, twitter)
  10. 10. Invite people to play * Invite selected people for a private beta - this is amazingly powerful as people's integrity will work for you - or you get great feedback what to change * Give people a chance to build "official mashups" before release to show on the site and in the press conference. * Maybe launch with a developer day
  11. 11. Collaborate with other API providers. http://www.flickr.com/photos/15622795@N05/3587077659 * Reach out to other API providers * Take part in groups dealing with the same topic * Create an open YQL table, add your data to gnip
  12. 12. T H A N K S ! Keep in touch: Christian Heilmann http://wait-till-i.com http://scriptingenabled.org http://twitter.com/codepo8

×