Appirio's CloudSpokes acquires TopCoder, blows up developer model

Den Howlett Profile picture for user gonzodaddy September 17, 2013
CloudSpokes' acquisition of TopCoder sets a new bar for commercialized developer community and engagement. Here we dig into alternative models to discover the trends going forward.

The last 30 months, Appirio has been quietly building its CloudSpokes community of developers. This is aimed at building new and custom applications for cloud landscapes. The model centers around the creation of competitions which anyone can enter. When CloudSpokes launched in February 2011, I said:

I wonder whether this will work because as I pointed out to Narinder [Singh, co-founder], developers may be great at providing elegant code but that doesn't always translate into the best user experience. Narinder answered by saying that in creating competitions the company hopes to be in a position to offer its customers a range of options rather than THE one thing that is going to solve their problem.

The market has spoken. Yesterday, CloudSpokes announced the acquisition of TopCoder, another crowdsourcing development community.

The SCN comparison

Earlier in the month, I met with Narinder Singh to talk about developer communities. It is something in which I have had an ongoing interest for some six years, largely because of my following how the SAP community network (SCN) is evolving. Comparisons are inevitable given both TopCoder and SCN have been around for 10 years. . Where TopCoder and  CloudSpokes (CS/TC) claim (roughly) 600,000 sign ups, SCN claims north of 2 million. Where Singh claims roughly 10-15 percent active engagement, defined as those entering competitions, it is almost impossible to tell what is 'active' inside SCN other than perusing the badges and point scores earned by contributors. Even then, there is no objective measure of quality, rather recognition has been quantity driven. SC/TC is outcome driven while SCN is input focused. Much of SCN content is driven by problem solving for the SAP community rather than direct code sharing. It does not have the CS/TC competitive element. The ongoing question is whether one model trumps another. Singh is adamant that cost effective outcomes will always win. That fits well in the lower cost world of cloud. I can equally argue that a solution which has historically attracted premium pricing will naturally appeal to those wanting to earn top dollar. But inside both arguments lies a world of complexity.

Employee v entrepreneur

One of the key arguments for crowdsourced competition is that there is a more natural alignment between what the developer wants to get out of the 'game' and what customers want. Singh argues that talent sourcing in this way gives customers a better sense of choice rather than being stuck with a contracted engagement that may (or may not) deliver the best outcome. He also says that the key to the success of the crowdsourcing model lies in treating the developer like a valued customer. More starkly, Thorsten Franz, who recently gave up a long term career as a developer inside an SAP shop to set up his own business said on Facebook:

Big difference between holding a job and being an entrepreneur: As an employee, you have to work. As an entrepreneur, you have to finish.

On the CloudSpokes community website, Sal Partovi puts it another way:

When you hire a contractor for development you're hiring a soldier. When you contract someone for a task, assuming they're competent in that field, you're going to get that task completed.

The question comes - who wins? Partovi is clear:

Crowdsourcing applies all those juicy "community engagement benefits" of hackathons to day-to-day work. Public challenges? Check. Prizes? Check. Competition? Check. Enthusiastic self-selected experts showing up to participate? Check. It probably sounds a little counter-intuitive at first, but crowdsourcing is a better method for building long-term relationships than contracting. Ignoring data that shows that crowdsourcing is 62% more effective than methods like contracting, the basic logic is as follows: (A) Crowdsource it, get work done, and engage and build your community of fans -- or -- (B) Contract it, get work done, and that's about it Contractors don't create communities.

Does community matter?

You can equally argue, does community matter when viewed from the customer's standpoint? I think the answer is 'yes.' A crowdsourced community encourages the building of balanced relationships that are independent of the code that's being developed. On the evidence I have seen among customers, that leads to superior outcomes across the board. The vendor based version of community is solely driven by vendor objectives and their proprietary code line. That is limiting because developers rarely get the chance to bring their own choice of coding skills. Instead they are driven by what the vendor says they can use and how they can use their own code. Why should that matter to a customer? In the traditional world of enterprise applications, developers (largely) fell into two camps: those who worked with Windows based languages and those who worked with Java. In the SAP world that was augmented by ABAP, a language specific to SAP technology. In today's world, we see demand for many languages that don't easily fit into the two or three camps outlined above. The emergence of the newer languages are a direct response to web scale requirements and rapid innovation. That automatically places restrictions on finding the best solutions in the vendor specific world unless the vendor play morphs to a platform capable of supporting the 'new' and rapidly evolving multi-lingual world.

What of breakthrough innovation?

Vendors will argue that new platforms need to support the old, largely because you cannot simply jump from one place to another in complex landscapes. That is especially true for systems of record. But it doesn't seem to prevent businesses from finding solutions to the problems they have today, independent of the systems they employ to run their businesses. Jon Reed dug deeper into my conversation with Vinnie Mirchandani on this topic. He says:

Vinnie thinks the tech media is sleeping on a very big story: customers are now the innovators. They aren’t waiting for ‘vendor release′ to get cooking:

Every one of these areas in their industries, they’re pushing the envelope. They’re using technologies that are generally available., but they’re the innovators. They’re not waiting for a big vendor to come along and say, ‘Here is a solution’ That’s a massive shift that’s going on … So just in the last few years, we’ve seen a revolution happen. I think the media and the analysts have missed this transition.

That’s not to say there aren’t vendors Vinnie respects and follows closely. He likes where some are headed more than others. Ergo, Vinnie and I have jousted about SAP HANA before and probably will again. For me, the takeaway is not to march in lockstep with Vinnie’s views but to push away from the social stream and dig – for the unrecorded conversation. And if you can’t find the innovation you seek, build it.


We see three distinct worlds.

  1. The crowdsourced community of which SC/TC is rapidly emerging as the leading commercial version for cloud and mobile plays.
  2. The established vendor community that depends upon the vendor's pre-eminence in a captive market.
  3. The fragmented world of the business or industry specific market that is focused on self interested innovation.

I could add a fourth - the secret world of the national and international security establishments inside government. Let's not go there!! Your perspective on each will depend on what you are trying to achieve as a buyer and where your strategic application buying decisions are leading you. What is clear however is that this is not a winner takes all game. At least not yet. Bomus points: FinancialForce looks at another type of community - the AppExchange which is closing in on 2 million installs with a tad under 2,000 apps. Disclosure: SAP is a premier partner Featured image credit: © kbuntu -

A grey colored placeholder image