In part 1 of this series, we made the case for creating and fostering a developer community, and it boils down to something like this: if you want to enable development with your API, extend your platform, and encourage exponential use of your applications, you’ll need an enthusiastic (and ever-growing) community of developers to help make this happen.
The idea is that if you want applications to access and transact with your application, you’ll need developers to be able to easily work with the API and quickly enable communication among apps. This isn’t a terribly difficult thing to do – you provide the right code access and maybe some documentation, and the developers get busy and work their magic. If all goes well, you’re benefitting from the network effect and have all kinds of apps doing transactions with your app, all because of a well-constructed API. And if all goes REALLY well, then you’re seeing a lot more users, who are paying your company money, and you realize that your huge success is because you made a lot of developers happy.
OK, that’s what happens if all goes well – REALLY well. And there’s a slim chance that it will all go like this without a plan for you to make developers happy and like your API. It won’t happen by itself, regardless of how easy-to-use your tools are. So when you create your strategy for your developer community (get the word out, have a simple registration system, provide regular and relevant communication, etc), the first decision you need to make is a political one: will your community be of, by, and for the people, or will it be a dictatorship?
OK, let’s not get dramatic – we’re not really talking about targeting either the 1%, nor the 99%. But a developer community can be one of two things: it can operate for the benefit of the community owner (in this case, that’s probably you and your company), or it can truly be there for the community members. And this is a big decision, because it will likely dictate what kind of developer you attract and may impact their motivation to work with you. So, what kind of community do you want?:
TOP-DOWN: In this type of community, you’ll produce the content, you’ll respond to the questions, and you’ll set the tone. This isn’t a bad thing – if all you want is to provide a basic API with some basic documentation, and if your solution is narrowly targeted, then maybe this will work. If what you’re doing truly helps your developers get on with their tasks and do them more efficiently, then you’ll be doing it right. But you need to be cautious – if your community is all about you and what you want, that will leave very little room for the developer to express what they want and customize a solution that works best for them. If you populate your community with content and tools that were created by marketing interns and read like brochures, you will be suspect in the eyes of developers. Why would anyone want to make YOUR life easier?
BOTTOM-UP: Maybe it’s “bottom-up” and maybe it’s just “of the community”, but no matter what you call it, this type of community is where your developers really run the show. They support one another, they provide feedback, they write content when they think it’s necessary, and in general, they have a sense of ownership. That engenders pride, but it can only be done with trust. If you really want your community to be bottom-up, then you’ll need to provide the right tools and functionality. These should allow your developers to learn and collaborate with one another, and to do so in a way that’s easy (using communication tools, social media channels, easily navigable dashboards). If you’ve really made it about them, then they will WANT to spend time in the community and by virtue of their involvement, help make it a success.
Now, at the end of the day, of course the community is for the benefit of you and your company and your bottom line. A company spending money and time on an online playground for coders is an unlikely scenario, and even developers know and understand this. They won’t begrudge you trying to make money, but they aren’t pawns. They’re partners, and if you want them to use your API, you’ll need to have that spirit of partnership as a visible and functional aspect of your community. You’ll need the community to know that you trust them and that you’ll be an advocate for them.
How best to do this? Top-down, or bottom-up…you’ll have to decide, but you should do it with thought given to what will make the lives of your developers easier. Because that, in turn, will probably benefit you the most.
To learn more about the tools we provide to enable API developer communities, check out our Community Manager product, which offers an extensive set of social capabilities to promote the creation of a community of developers either inside or outside the enterprise, or a combination of both.