Lip service to so-called ‘developer engagement’ is running rampant. But few companies grasp the business impact developer communities can have, or even if they do, they are struggling to make it so. Given that apps are supposedly eating the world, this is an odd state of affairs. To get a better handle, I tracked down Narinder Singh of topcoder.
My timing was good – when Singh and I spoke, topcoder had just announced the acquisition of Coderbits, a profiling system for developers that is another step in Singh’s vision of a crowdsourced developer community that spans multiple platforms. Topcoder supports more than 600,000 developers who compete to solve challenges posted by a host of enterprise software companies.
I boiled my conversation with Singh down to ten ‘rules’ of developer engagement. These rules are my interpretations, so Singh might have a few he would add or consolidate. As we go through them, we’ll cite where companies are going wrong, and the best ways forward.
Ten rules of developer engagement
1. Rules of governance must be fair and transparent. Communities fail quickly when decisions are made without transparency. Singh:
The TopCoder community chooses to be here. We don’t own them, and they’re more important to me than any single customer that we have – they are the product. I don’t think we always get it right, but you’ve really got to engage with that community. The rules and governance you set up is so important – it has to be fair. The system can’t do a bunch of one offs with 600,000 people.
2. Go where the developers are. Building your own developer space must be accompanied by effective outreach to established players. That outreach will also give a continual gut check on how open and easy your solutions are to work with. Singh:
Our ability to actually do crowdsourcing is significantly higher because of sites like GitHub. We use GitHub all the time for source code control across multiple platforms, because many of the competitions we run are not tied to a platform. Sometimes we say: ‘Here’s a problem, build it wherever you want to.’ It’s fascinating to see who built it on what stack, who built it on Heroku, who went to AWS.’ Now with coderbits, we bring together information about what developers and designers are doing from over 60 sites into the mix.
3. Open up your APIs or go home. Without accessible APIs, developer communities are basically dead on arrival. Needless to say, the journey to open APIs can be fraught with cultural and technical obstacles – but that’s the price of this particular ticket. Singh:
We have companies who want to reach our developers, but not all of them are ready. You’ve got to be willing to put up an API for free, and then we can run challenges around it. My response to the API situation is, ‘Look, if you want to work with us, if the developer cannot get access to your system and your APIs in a minute or less, that’s what you should work on before you come talk to us – or let us help you do that first.’ People want to talk about building ecosystems and doing all these cool things, but they have to be willing ot make that upfront investment.
4. Every company needs a developer community. OK, slight exaggeration, but the so-called Internet of Everything means that developers could be ‘applifying’ your product – if you give them the chance. Singh:
What happens in a world where there’s 3D printers disrupting every manufacturing company and logistics firm? With robotics, the programmer is able to engage with the physical world. All of a sudden, you go from ‘software is disrupting the world’ to ‘software is everywhere’. We think the skills shortage is going to get a lot worse, because it’s not just a software problem, it’s a problem hitting every industry. The world is programmable, and there is a massive amounts of consumable data out there.
As an example, If you’re a company that makes electronics equipment today of any kind, whether it’s TVs or electric guitars, I would make the argument that there probably should be a developer site on your physical product web page.
5. Crowdsource your developer needs. In-house developers may not have the skills to build the killer apps you need. Singh cited the example of topcoder’s HP IDOL OnDemand developer competitions:
With a crowdsourced community, you present a significant option for a company that might not be able to cultivate a huge developer community right away, so they can essentially sort of leverage yours. With HP IDOL OnDemand, we are running challenges and saying, ‘Use the Idol OnDemand API, but for most of the stuff, build it wherever you want.
6. Get unfiltered reality checks from outside communities. The feedback loop from developers outside your proprietary products can be harsh, but it is invaluable. Singh:
Real developers are seldom emotionally tied to one company. They’re more likely to be tied to the technology than to the company. What’s an HP partner or a Salesforce partner or an SAP partner going to say about the new SAP or Salesforce or HP technology? They’re likely to say, ‘It’s great.’ Or there will be silence. Whereas if you put it into an independent community, you know you’re getting real feedback. It helps to be able to say, ‘Hey, our technology is standing up to the test.’ They will also submit use cases you hadn’t considered.
7. Developers don’t like marketing very much. Singh has stories-a-plenty of developer marketing fails. It turns out the community is better at marketing itself.
You have to be willing to let the markets speak. The biggest thing to do is build a great product, make it easy to get to and then support people around that. Then you can maybe put an incentive or two out there, to get people to try your stuff on for size. That’s 100 times more impactful than the same old marketing pitches we see from companies trying to get developers to use their technology.
8. Treat developers as your most important partner. For most companies, catering to individual developers is an afterthought compared with the red carpet treatment of premium partners. For Singh, that’s a fail:
People think about the developer at the end of the cycle. They don’t think about the developer or the designer as a partner. That’s a key mistake. If you said, ‘We have a partner, which is the individual developer,’ you would of course have put up an API because you’would say, ‘Hey, how can I partner with somebody without giving them a way of connecting with me.’
9. Even cool SaaS companies need developers. Singh is surprised by how many of the sexy SaaS companies that dominate enterprise headlines are sluggish on developer engagement:
If I went to the top 30 SaaS applications – not platform providers – but SaaS applications across enterprise categories like ERP, HR, and product configuration and went looking for their developer home page, it probably wouldn’t be prominent on their web site. A lot of times, the APIs aren’t public. There’s certainly no way for a developer to get access. If we did an inventory of the top 30 SaaS applications that were not themselves platforms, I’ll bet that less than 10 have a strong developer presence online.
10. Learn from open source communities. Singh is quick to credit open source as the inspiration for topcoder’s crowdsourcing model:
With Appirio (topcoder’s parent company), we wanted to disrupt services the way cloud software disrupted that ecosystem. We knew we’d never be able to scale by doing it the official way. We said, ‘Where has that happened before?’ The answer was open source. We as enterprises have used the output of open source for the last 15 years but we’ve never really been able to tap into the process that allows for lots of people to contribute and bring things together. That’s what we’re trying to do with crowdsourcing and communities.
Image credit: smiling team with laptop computers in office © Syda Productions – Fotolia.com.
Disclosure: Appirio does not have a financial relationship with diginomica. SAP and Salesforce are diginomica partners.