Ending Unfair Developer Bait and Switch Practice in the Valley
British MP Damian Collins landed a fair punch on Facebook yesterday (Facebook offered preferential access to data, UK alleges — FT) when he called out private developer whitelisting as anti-competitive.
Developer whitelisting is often part of an insidious tech platform strategy of “developer bait and switch”. This is where developers, independent businesses, are
- baited with free access to platform data, encouraged to build businesses and then;
- switched as the platform clones their business and charges for data access to continue, or closes off access entirely.
Developer bait and switch has long been a dirty growth strategy of Silicon Valley’s tech platforms.
As a long time social media developer, it is one I’ve seen play out time and time again.
For instance:
- Pikini app was locked out by Facebook when data policy changes restricted access to friend feed data. They are not alone, an app I developed — Buzz! The Friend Quiz was caught up by the same tightened data noose;
- Twitter closed Firehose access in order to start charging for a “data API” — (How To Kill Your Ecosystem. Twitter Pulls An Evil Move With Its Firehose — Forbes) a move that famously hurt Kred who sued for continued access.
- LinkedIn cut off previously given API access and restricted access to whitelisted ‘partner’ developers. This cost me revenue, as rise.global had a paying enterprise customer at the time using the API access to provide customised tracking statistics to their staff.
It’s a cruel tactic but one that works well for platforms looking to grow.
What’s becoming clear is that this is an industry wide problem, not an issue isolated to just Facebook.
Let’s understand how a typical scenario plays out.
How the “Developer Bait And Switch“ really works
This is how a platform exploits smaller developers to grow:
- encourage developers — mostly startups and unfunded SMEs — to innovate for your platform’s users, by creating additional features on top of your platform;
- monitor the features created, by leveraging proprietary access to usage data across the whole customer base;
- clone the high value features with traction(those that customers are using and monetising well) into the platform and monetise them directly;
- add new abilities to the cloned features, but don’t make the additional data that drives them available to the original developers — this brings customers to the platform instead and finally;
- lock out the original developers by closing access during an upgrade, cite “data security and privacy”, use any recent media and politics storm as a pretext;
- watch as the original developer business withers and chuckle as you expand your monopoly.
Unfair practice? Really?
“Par for the course”, many will say — “it is their platform, you play by their rules.”
Maybe, but that doesn’t mean it’s fair.
Often developers are forced to integrate with the platform to meet their customer needs. There’s no other option. They have the monopoly.
And, where there’s an unchecked monopoly, there’s potential for abuse.
So what’s fair practice and what’s abuse?
Firstly, we must remember that platforms themselves are often new businesses looking to monetise. After a period they may discover they’ve been giving away valuable data for free. In this case, making developers switch from free to paid access can be ok, as long as those access charges are reasonable.
However, often the new access charges are exorbitant (e.g. Google Maps 1400% price hike, Twitter charging thousands of dollars for previously free access), pricing the developer business out of the market.
Even more damaging though, is when access is closed off altogether. Some platforms then only allow access via a public whitelisting program (e.g. LinkedIn Partner Program).
Totally unfair, is private whitelisting — this is what Facebook is currently accused of — as this gives some privileged developers an unfair, secret market advantage.
Even the public whitelisting programs have grey areas that need reform.
Many programs, like LinkedIn’s for example, don’t disclose who is on them. This allows public programs to provide a whitewashed cover for the unfair practice of private selection. There is no oversight that access rules are being executed fairly for all.
In developer whitelisting, we find (again) a scenario where tech platforms are acting as judge, jury and executioner, and all behind closed doors.
For a platform’s new features, whitelisted access is understandable — many platforms test out a new feature with reliable partners, and then launch with those partners to demonstrate momentum.
However, the nasty version of this is where previously allowed access is rescinded in a non-uniform way.
When it does so, is the platform privileging other valley business friends over foreign competitors? We just don’t know. Is it fair? Certainly not.
This is where Collins’ complaint hit home.
In a data monopoly environment it is market abuse to favour one data reseller over another. And make no doubt about it, these are definitely data monopolies, their strong network effects have locked in their users.
Collins here has done his job well, he is accurately representing the “smaller businesses required to work with the tech giants”:
Ending market abuse
It’s now time for the obnoxious valley practice of “developer bait and switch” to be exposed for what it is — market abuse.
Well done to Collins and the DCMS committee team for a well aimed, much overdue punch.
Deep, long-held strategies like this, will take time to change. They are part of the Valley’s startup culture. They’re in the growth playbook.
But change they must. How they change is up for debate.
By all means bait developers onto your platform, but in the future, if you switch them, be prepared to face the wrath of the digital regulator.
