Attracting Developers to Your Platform

Following up on Nat's great piece on rolling out an open API, I thought I'd add some guidelines I wrote up last year for a company looking to attract developers to their platform. They were specifically hoping to have developers sell components and applications on the platform (like the "Palm Economy," for instance), so some of this advice is specific to that model -- but it applies just as well to open APIs as otherwise. There's overlap with Nat's suggestions, too.

This is the advice I gave this company (edited to remove their name and update a few examples):

1. Make it completely easy for a developer to play with your tools. One-Click Playtime should be the goal. If you absolutely have to send them through a click-through license, okay, but if not, so much the better. Could you set up a sandbox that would allow anyone to experiment with your product (for their own use only, maybe) with absolutely no download, no license, and no registration? That would be fantastic.
2. Deployment should require a developer to agree to the rules of the market, but it should not require the developer to seek approval for their creation. If you want to make a general rule saying, "No porn" or "Don't compete with us directly," that's fine -- but if they have to have each upload reviewed before it is live, that's terrible. Maybe another way to say this is, deployment must not involve a person on your side.
3. They make it, they own it. Any code they write is theirs, and they can take it away, back it up, sell it, and modify it to their hearts' content and without your approval. Don't try to force them to stay in your market by contract or capability restrictions, because that will cause them to shop for a less-regulated market. Make them hungry to stay in your market because that's where they get the best value from their creation.
4. Try, try, try to resist the urge to compete with your developers. Apple is terrible at this -- a great MacOS X shareware app is likely to be in the next major release of the OS (e.g.: Audion/iTunes, Watson/Sherlock, Konfabulator/Dashboard,). Even if it isn't really "likely," the perception that Apple does this too much is discouraging for Mac developers and bad for the Mac market. If you have to own something a developer has made, acquire it from them and give them a nice payout. Better yet, you go after one pile of money and get the developers to go after some other pile of money so that you are not tempted to compete with them.
5. Let them compete with each other. It's great to promote an individual developer and make their work known (see #7), but if your model is to choose the one anointed FooWidget and freeze out other FooWidget authors, they'll go looking for another market or just give up on your model altogether.
6. Don't put an upper limit on developers' success. (This is sort of a superset of #4.) People support themselves through eBay, create thriving, enormous derivative businesses through eBay, and they are limited only by the size of the market and their ability to provide value to it. That's fantastic for eBay. The best incentive for a developer to contribute code to your market is the possibility of supporting themselves through it -- the dream of the self-employed coder working whenever and from wherever and doing well at it.
7. Love the best developers. A great coder who's terrible at self-promotion should get a leg up from your marketing group. A developer's work that is catching on should have a big bucket of gasoline dumped on top of it. This is just like management in a team -- if you very publicly acknowledge the work of the best performers, everyone will see that and try to get some of it for themselves.

Such simple ideas. It's amazing how many supposed "platform plays" get every single one of these wrong.