Now is the age of developer programs or “developer communities” as they like to style themselves. Five years ago there was barely a handful of such programs in existence. Microsoft led the way for platform vendors, and if you add Java, IBM, Adobe, and Apple to the mix you’re close to the complete list. Now there are literally hundreds of developer programs; from Paypal to Vodafone hundreds of technology companies offer a developer program.
All these developer programs are created for the same reason:
- More developers –> more applications for the platform
- More applications –> more consumer adoption
This is the formula that gave MS Windows such success in the mid-90s and Apple’s iPhone in the past couple of years.
But as all these companies scramble to build a developer community I see a general misunderstanding of the key success factors; leading to most companies focusing their efforts ineffectively. So I wanted to write-up my view of the key success factors for building a “developer program”. Note that I’m talking here about developer programs offered by platform vendors to the developers creating software around their platforms. In particular I’m not talking about open source projects and their contributor developer communities which is a different kettle of fish entirely.
.
Developer Community
Before describing the key success factors, it’s useful to demystify the term “developer community” as it applies to software platforms:
- Primarily it is simply the set of developers creating software for the platform.
- A more genuine ‘community’ exists when these developers support and inspire each other to great better software.
Regardless of what you think “developer community” should mean, 99% of the time this term is used by software platforms, it means (1). They like to imply it means (2), but it doesn’t. Very few platforms have genuine communities.
.
Key Factors
I believe that the key factors for building a successful developer program (in order) are:
(1) Awesome platform. You need a platform that lets developers do things that they can’t do anywhere else. The first platform that enables developers to do really effective Augmented Reality applications will benefit greatly from this.
(2) Channel to users. A simple, low barrier, channel to a large number of users.
(3) Support. The support offering has now been almost standardised with SDK, IDE, example code, reference library, guides, FAQs, and support forums being the main elements.
(4) Promotion. Tell developers about your technology, what they can do with it, and how to access it.
(5) Collaboration infrastructure. Provide infrastructure to encourage and help developers to interact on-line and off-line; discussion forums, events, ideagoras, etc.
Note that while list is primarily focused on application developers; it essentially holds for OEM-style developer programs too.
.
Comments
MS showed us how to do developer support properly, Apple showed us how to provide a channel to users properly (at least in the mobile world), and the social networking craze has given some reasonably good hints on collaboration infrastructure. So most companies seem to get these bits (or at least get that they don’t get them but really should).
But very few companies seem to understand that everything else is meaningless and will come to nothing if there isn’t an awesome platform underneath everything. The channel won’t succeed if there isn’t great unique content. Promotion will become despised if it’s empty. Collaboration simply won’t happen if there’s nothing interesting to talk about.
Why does this happen? Typically companies create a “developer marketing” team to create a “developer community”. This team almost never has any real influence on product requirements. They are a downstream team that take what they are given and do what they can. If they are mainly technical guys then they will focus on providing good support and maybe some on-line collaboration. If they are mainly marketing guys then they’ll focus on channel to users, promotion, and trying to build a social networking website.
Whilst a little subtle, there is a pervasive difference in how you work when creating a product vs creating a platform. This makes it a difficult change and like all change it is generally done badly.