The power of a single statistic (to distract)

“I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like “42% of malicious extensions use the Web Request API” when you’re considering what we’re trying to improve here.”

—Justin Schuh, on Twitter. (Also stated in Google’s official post here)

Google is using a large number—42% of malicious extensions—in isolation to justify a decision. This number shows that a large proportion of ‘bad developers’ use this API. But this single data point gives no clue about how big is the total pool of developers using this API.

Are bad developers a large proportion of users of this API, or are they a tiny minority? In the latter case, Google’s action to deprecate/restrict the API may be fairly justified. In the former case, they could have chosen a better, alternative approach in dealing with the bad actors, rather than punishing the mostly good users.

An analogy for case 1:

Bank decides to close all doors leading to the street because 42% of all robbers walk-in through those doors.

Analogy for case 2:

Bank decides to close all waste disposal tunnels because 42% of all robbers sneak-in through those doors.

All we know is that 42% of robbers come in through a point. We don’t know if it’s the main customer entrance, or the waste disposal.

If this statistic was a big argument for this decision’s approval inside Google/Chrome-Dev, then they really need to revisit their decision-making fundamentals.

I seriously doubt this though. Googlers are very smart. They are dealing with mostly smart people on the outside. This number is not for them or us. This number is being published solely to turn the narrative, for the common reader, from ‘Google blocking APIs that stop ads and tracking‘ to ‘Google blocking APIs that stop malicious extensions‘.

Continue reading The power of a single statistic (to distract)

Platform + App + API = Shortcut to Win

As a cyclist, I keep exploring route mapping and live tracking apps. This weekend it was the turn of mapmytracks, thanks to all the attention focussed on rocket2 LEJOG attempt.

But this post is not about a route mapping / tracking website, or about that attempt. It’s about the interesting approach mapmytracks has taken to app development.

They’ve developed official iPhone, Blackberry and Nokia apps. They don’t have an Android app, yet, but openly link to alternative Android apps that work with their API providing both live tracking and route mapping.

I like this approach, coming as it is from a website in a cluttered & competitive space. By providing an API and advertising / linking to compatible apps, they don’t have to compete with the huge number of similar apps in Android marketplace. Yet, they enable people on the most widely used smartphone OS to connect to their platform.

In one move, they’ve reduced their own efforts towards developing an Android app, ensured presence on multiple apps on that platform, and yet given them the option to, some day, buy the app that emerges as most successful on Android.

Wondering:

  • Are there other small firms out there, developing and owning the platform while providing APIs and encouraging outside developers to provide mobile apps for it?
  • Why don’t more startups that are targeting to become a ‘platform’ use this with an app+api strategy?

Continue reading Platform + App + API = Shortcut to Win