2012/Building Developer Platforms

From Open Source Bridge Wiki
Jump to: navigation, search

How do you transform your site or service into a platform others build on top of? How do you clear the path, lower the barriers, and make it easy for new developers to get started?

Speaker: Scott Becker

Return to this session's details

Contributed notes

(Add your notes here!)

Background and definitions

Developer Platform: the ability to run additional applications on top of or within an existing application. Typically include an SDK.

Components of a platform:

  • A useful App
    • the desire to extend it
    • an API
    • a business model

What is the monetary motivation for a developer to build on top of your platform? What is your monetary motivation?

. How to get developers on board:

  • Make it free
  • quick, painless sign up
  • instant gratification

There are exceptions, for example if you're in beta and want to

Making it easy

  • Keep it simple
  • spoon-feed tutorials
  • not too much at once

Going further

  • automate the pain away
  • app templates/ dev structures
  • live API docs
  • IDEs
  • Source control hosting
  • Web hosting

Examples - Jive software

Enterprise Social

  • Used by Fortune 500
  • Extensible
  • Custom Java Plugins == Painful Upgrades

Goal was to make it easier to upgrade people, not hamstringing Jive to existing implementation. Hence:

  • Open Standards

Based on Open Social.

Friction

Many steps

  • well-formed app XML file
  • maintainable project structure
  • single file examples == easy, not simple
  • web hosting
  • source control
  • register with jive apps developer community
  • register app with jive apps market
  • request oauth credentials
  • register developer sandbox

Made it easier with developer tools

  • inspired by rails & heroku
  • automates all of the above
  • create, register, host, and install in one step.

Single command-line call creates, registers, installs a template app.

Git is the deployment mechanism. Only problem is that you have to commit and push whenever you make changes, which is not ideal when you're just trying things out. Added an extension to auto-commit changes.

Components

  • Command-line tool is a ruby gem. (under jivesoftware on github)
  • backend API
  • glue between other jive services
  • Git repo hosting
  • static web asset hosting (via git post-commit hooks)

Ingredients

  • Ruby
  • Rails
  • mySQL
  • git
  • gitolite (runs on server side, handles git repo hosting)

building it

  • RESTful JSON web services (can add ssh keys to manage apps, can share apps, let other devs commit)
  • API client
  • code generation
  • git automation (auto-commit)
  • gitolite automation (simple git repo hosting is really easy; it's more complicated with a lot of repos, a lot of users, and access rules. gitolite lets you build your own github-like service)

If I started over

...

Q&A

Q: How important was it to host the git repos, vs. having the dev host it themselves? A: Probably wasn't important for adoption as an SCM, but is important to release process.