Stevie Graham. Hacker at large. Working on Zap.

6th September 2013

Post with 4 notes

Why Facebook really bought Parse (YC S11)

I read a quote from Mike Vernal, VP of Platform at Facebook on the Y Combinator blog re Facebook’s motive for acquiring Parse earlier this year:

I think about Facebook’s mission as helping people connect, wiring up the world. For our developer mission, we want to extend the same thing to them. We want them to be able to build apps and reach everyone in the world. On the build side, we know from our own experience how painful it is to have to maintain five or six apps. One of the things we want to do is make it easy to build for all platforms and reach all people on Earth. The biggest challenge today is supporting all the different platforms that exist, and Parse makes that really easy.

Of course this is probably not the reason that drove the acquisition, it was more likely to be about data. Earlier this year Parse crossed the 100,000 app mark. Parse is a PaaS, not a consumer app, so that’s great growth for less than two years out of the trap. Imagine how many users those apps have and extrapolate out to five years from now. That’s a shit ton of apps and even more users using them. All that transactional user data being beamed straight into Facebook. How many times a user opens an app, when, what they do, and for how long. Parse user objects have an email field, so Facebook could trivially reconcile Parse user data with that of its own. My inner Zuckerberg is salivating at the possibilities. Is this cool? I don’t know. Is it allowed? I suspect right now the answer is no, but what is stopping Facebook changing the Parse ToS tomorrow and make it completely free at the same time, or simply rolling Parse into the Facebook platform where this is already de facto expected?

Another use I can see for Parse data is giving Facebook the jump on fast growing apps they can acquire before anyone else even knows what has happened. Facebook will know the metrics of any app using Parse, so when they see they have the next Instagram on their hands they can swoop in early and get it for a knockdown price before breakfast. If Facebook could acquire the next Instagram for half off by being early to the party, the Parse acquisition will have paid for itself many times over. This is genius, diabolical genius but genius nonetheless. Similarly they could use the data to reveal distressed teams to acqui-hire. Developers should expect the data to be used, and not to their advantage.

I’m not making any judgment as to whether the aforementioned is legal or ethical, but I don’t expect that to stop it from happening now or later. Even though those are my thoughts I will probably continue to use Parse, it’s such a great platform. However, I have been working on a way to avoid being locked in to Parse, i.e. still use the Parse SDK (ViewControllers, PFObject, etc) but build in a kill switch to have the Parse SDK suddenly communicate with one’s own servers instead of Parse’s. Then to migrate out of Parse all one would need to do would be to build an API server endpoint that quacks like Parse. This would be a much less daunting task than getting every user to upgrade to a new app binary that didn’t use Parse. I thought of the name Parseport, i.e. leave when you want. A proof of concept is here. I class dumped the Parse SDK private headers and used Objective-C categories and method swizzling to decorate the HTTP client class the Parse SDK uses to talk to foreign hosts without changing the SDK’s public API. I’d like to tidy this up a lot, and provide a simple API to do achieve the same result, and then it would be simple to use GroundControl to remotely flip the switch.

If you know a lot about Objective-C, its runtime and would like to help me please find me on the twitters.


  1. d43pan reblogged this from stevegraham
  2. steoreilly reblogged this from stevegraham
  3. stevegraham posted this