Your company needs a developer community, but you don't know how to build one? Cloudera's Justin Kestelyn has some answers.
You don't have to be an open-source company to care about developers. From Google to Ford to Wal-Mart, both old school and new school enterprises are actively engaging developers to help extend the value of their platforms.
Your company needs developers, too. The question is how to attract them, make them productive, and retain them.
Cloudera, one of the leading Hadoop vendors, has built an exceptional developer program, one that both educates and engages developers. I reached out to Justin Kestelyn (@kestelyn), senior director of Developer Relations at Cloudera, to find out how they do it. As he tells me, a strong developer outreach program focuses on three things: 1) catering to individual developer needs, 2) a focus on ecosystem growth and 3) an emphasis on the developer experience.
Catering to different developer needs
Before delving into the more advanced side of developer outreach, it's critical to appreciate the basics. Not surprisingly, those basics begin and end with the question, "Why should anyone outside our company care about us, and how will helping us help them?" If you can't answer these questions, no program can save you.
- A way to understand the value of your project
- A way to understand the value they could provide to the project
- A way to understand the value they could receive from contributing to the project
- A way to understand the contribution process, end-to-end
- A contribution mechanism suitable for their existing workflows
Part of providing for these basic needs, to quote Kestelyn, first requires that we understand that "developers are not a monolithic group." Some arrive at your website with deep technical experience. Others are students. The key is to understand these different groups, their respective needs, and cater to them accordingly.
In Kestelyn's world of Hadoop, Cloudera and other Hadoop vendors have to contend with the reality that outside Silicon Valley and maybe New York City and Washington, D.C., the knowledge level of Hadoop is still relatively low. While the uber users like Twitter, LinkedIn, and Yahoo! are important as influencers, the future lies with mainstream enterprise developers working for insurance companies, banks, manufacturers, healthcare companies, etc.
To be successful, Cloudera must engage both classes of developer: on their own terms and at their own pace. No matter your project, you need to embrace developers of all kinds and of varying levels of experience.
Everyone has something worthwhile to contribute. The trick is to discover what it is and facilitate its contribution.
Building the ecosystem
The next pillar of developer outreach is a focus on ecosystem growth. As Kestelyn put it to me, "We recognize that as goes the ecosystem, so goes Cloudera."
This wasn't always the case, of course. For some time, Cloudera tried to go it alone with Hadoop. Over the past year, however, it has actively engaged with external developers, both commercial and hobbyist.
How does this translate into day-to-day, inbound and outbound activity at Cloudera? As Kestelyn notes, his team "actively curates blog posts by third parties that have created interesting add-ons to the Hadoop kernel as, one day their project may well ship inside our platform." That's one of the "inbound" activities Kestelyn and his team handle.
On the "outbound" side of the ledger, Cloudera engineers do nearly 300 tech talks per year at open meet-ups and conferences, not to mention stewarding HBaseCon and Strata + Hadoop World.
One thing I love about both events is that while instigated by Cloudera, they are not constrained by Cloudera. Both events have Cloudera competitors like Hortonworks on the program committees, which allows them to be true community events that help to educate developers, whether they wear Cloudera t-shirts or not.
For your company and project, you need to think carefully about who needs to be a part of your ecosystem. Facebook, for example, reaches out to all sorts of developers, from those focused on hardware to games and more. It's important to think about not so much what you need as what the larger body of users of your products may need.
Emphasizing the developer experience
The last pillar of a strong developer program is an emphasis on the developer experience. While strongly related to the first pillar, this diverges in that it requires the company be "consistent and persistent about advocating a good technical end-user experience, which is distinct and different from the buyer/owner experience."
As examples, Kestelyn calls out a few questions to ask:
- Do developers have the docs/how-to's/and even the books they need for important ramp-up efforts?
- Do they have access to environments (virtual machines, Platform-as-a-Service, etc.) for development and testing?
- Where can they go for help -- be it from Cloudera or the wider community?
- Do they have access to a software development kit (SDK)?
One thing that Kestelyn didn't highlight, but is critical to the developer experience, is the attitude and responsiveness of project leadership. If developers show up and are quickly shunted aside (or, just as bad, ignored), they'll go where they're wanted.
Embracing your community
It's easy to fall into the trap, Kestelyn says, of believing "Developer advocacy and outreach is just about hackathons and t-shirts." But it's not. As he notes, "It requires a lot more thought" than such activities and swag suggest.
But developer outreach becomes easier if you remember the cardinal rule: think first about what your developer community really needs to be productive, and then worry about how they can be productive for you. Obviously, if you're going to spend money on programmatic outreach to developers, you want there to be a return.
But that return comes only as you worry first about the developers' needs. That's the secret.