The document provides strategies for companies to reach out to third party developers to build on their products and services. It suggests being open with data and services, making APIs platform independent and RESTful, providing documentation, code examples, sandboxes, and collaborating with other API providers to invite external development.

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. 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. Building for
web use
* Be Platform independent
* Be RESTful
* Release all documentation and code examples in a portable format

4. Thinking of
* Good URL structures
endpoints
* Easy to understand method names and parameters
* Versioning of APIs

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. 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. 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. 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. Be responsive
* Have a mailing list / forum that is monitored
* Keep your eyes out for things people do with your code (blogsearch, twitter)

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. 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. T H A N K S !
Keep in touch:
Christian Heilmann
http://wait-till-i.com
http://scriptingenabled.org
http://twitter.com/codepo8