How to (accidentally) sabotage a developer program

A strong developer ecosystem is a valuable asset, but for vendors, balancing developer needs and business objectives can be a challenge

Developers can be an ornery bunch. When a vendor does something they don't like or when they're not getting the attention or respect they feel they deserve, they tend to be very vocal about it, often publicly. But spare some sympathy for the managers in charge of vendors' independent developer programs, to whom fall the difficult task of responding when developers attack.

A perfect example is the situation Research in Motion (RIM) faced last week. Jamie Murai had already written apps for the iPhone and iPad, so he figured RIM's upcoming PlayBook tablet looked like a promising target. Once he signed up for RIM's Playbook developer program, however, he met with frustration after frustration. The eventual result was a long and sarcastic self-described rant he posted to his blog, in which he railed against everything from RIM's program fees to the awkward process of downloading the tools, from the inadequate installers to the poor quality of the SDK (he judged it "complete crap").

[ See why InfoWorld's Galen Gruman thinks the RIM PlayBook's self-contradictions could hurt its chances. | Stay up to date on the key programming news and issues with InfoWorld's Developer World newsletter. Sign up today! ]

Murai reserved particular ire for the sign-up process itself, a procedure that required him to not merely fill out several pages' worth of personal information, but to actually print out a form, sign it in the presence of a notary public, and send it back to RIM via postal mail. It was the last straw. "I concede defeat," Murai wrote. "I no longer want to attempt developing an app for the PlayBook."

What Murai didn't expect was how quickly his rant would spread across the Web. Links from such developer-friendly social networking sites as Slashdot and Reddit drove traffic to his blog sky-high. Even worse for RIM, many of the comments came from other PlayBook developers, whose own experiences largely echoed Murai's. In short order, Tyler Lessard, RIM's head of developer relations, posted a response thanking Murai and others for their feedback and assuring them that everything was being taken into consideration. Unfortunately for RIM, however, even Lessard had to admit that most of Murai's descriptions of the developer program were accurate -- including the requirement of a notarized form.

Opening up while retaining control
Since long before Microsoft CEO Steve Ballmer's famous onstage outburst (video), IT vendors have recognized that maintaining good relations with independent developers is one of the best ways to grow and strengthen a hardware or software platform. But as RIM found out last week, managing a developer program often means striking a delicate balance between providing the resources developers want and maintaining the control over a product's ecosystem that its business demands.

Establishing a developer program requires vendors to make careful decisions. For starters, what form should the program take? Should it be a licensed, subscription-based program, such as what Apple and RIM offer? Maybe the vendor could attract more developers if it took a portion of its product's code base and made it available as open source software? What tools and resources will developers need? How much documentation should be made available, and what should remain proprietary information? How much access should outside programmers have to in-house product development staff?

Marketing and product strategy are important considerations, too. While one main benefit of a developer program is to open a product to a broad range of opinions and ideas, vendors also need to control the overall direction of their products. RIM, for example, wants to maintain its image as a mobile platform for serious business users, so it discourages frivolous apps, much to the chagrin of some developers. Similarly, Apple has repeatedly come under fire for the restrictive policies of its iOS App Store, which limit everything from content to the tools developers can use to build their apps.

Developers and providers: Can we talk?
Perhaps the most difficult aspect of this balancing act is keeping the lines of communication open. Marketers are the usual company mouthpieces where customers are concerned, but programmers and marketers hardly speak the same language. Indeed, while some commenters appreciated RIM's response to Murai's blog post, for example, others seemed to take it as further proof that RIM was out of touch and indifferent to their needs.

Believe it or not, maintaining a successful developer program is such a dicey and unique challenge that there's actually a conference devoted to it. Evans Data, a market research consultancy, will host its seventh annual Developer Relations Conference in San Jose, Calif., later this month. For any other industry, partner relations would be considered a niche topic. But each year, the list of speakers at the Developer Relations Conference reads like a veritable who's-who of the IT industry's largest companies. This year's conference will feature presentations by representatives of Adobe Systems, Cisco Systems, eBay, Hewlett-Packard, IBM, Intel, Microsoft, Oracle, and SAP, among others.

A glance at the conference schedule reveals a few of the topics on offer. Recruiting developers seems to be a primary concern -- meaning not just grabbing their attention, but keeping them engaged (rather than repelling them, as Murai was by the PlayBook developer program). One session purports to explain the "cultural norms of the modern developer" for business managers. A keynote presentation will discuss how to engage a developer audience by bridging marketing jargon and "geek speak."

Developer relations: A work in progress
So far, the BlackBerry developer community's reaction to RIM's response to Murai's blog post seems divided. While some commenters appreciated Lessard's acknowledgement of the issues Murai raised, others said they would reserve judgment until RIM actually took any action (and they didn't seem to be holding their breaths). Murai himself posted a follow-up in which he commended Lessard for his attention and speedy response, and said it had actually changed his mind: He now plans to give the PlayBook SDK another try.

But buried within Murai's second post is perhaps the most damning criticism of all -- that RIM paid attention to one frustrated developer's angry, sarcastic blog post, when comments and pleas for help posted on RIM's own developer forums usually went completely ignored. It seems even companies that are willing to engage their developers directly don't always have their lines of communication sorted out.

That's the thing about Evans Data's Developer Relations Conference, too. The sessions on this year's schedule sound remarkably like last year's session, and the year before that. The overarching theme seems to be what do developers want from a developer program, and how do we give it to him. Sadly, for all the theorizing, it remains an open question. If you think you have the answer, be sure to let the rest of us know.

This article, "How to (accidentally) sabotage a developer program," was originally published at InfoWorld.com. Track the latest developments in programming at InfoWorld.com, and for the latest business technology news, follow InfoWorld.com on Twitter.

Join the discussion
Be the first to comment on this article. Our Commenting Policies