

Why Facebook really bought Parse - sjtgraham
http://swaggadocio.com/post/60416244109/why-facebook-really-bought-parse-yc-s11

======
jng
This doesn't add up at all. If it's about usage data, they would be buying
Flurry in a heartbeat.

I'd bet the acquisition is more about a huge challenge Facebook faces, which
hasn't had a good engineering solution for years, and for which the solution
is still not clear: the chasm between the web as a platform and the native
mobile platorms. A lot of FB's value has not survived trying to jump that
enormous gap, and the major casualty has been the concept of "FB-as-a-
platform". There is nothing equivalent to Flash in mobile through which they
could control social games like they did back in the early Zynga days. Apple
and Android are the ones who really control the platform, including payments,
for social games and other apps on mobile. FB would _love_ to have a platform
they could control as tightly as Apple controls the app store, but they are
simply closed down behind a technical barrier. Parse is probably the only
successful initiative of a mobile platform that smartly sidesteps the control
of the walled-garden-guards. It takes control of the back-end and its access
code, and trying to leave the native client part to become just a UI skin,
which is under the control of Apple/Google, but which in FB's dream scenario
would become a minor part. I think FB's wet dream about Parse would be to find
a set of calls that can be abstracted, which define the actual app logic,
which can be implemented equally on Android/iOS/HTML5+JS and through which iOS
and Android can become just skins to the real app... and offer that platform
for developers to develop FB apps, which would run in iOS/Android/the web and
for which the gatekeeper could be FB itself.

~~~
sjtgraham
> This doesn't add up at all. If it's about usage data, they would be buying
> Flurry in a heartbeat.

\- Flurry has $50MM in VC funding. Parse had $7.7MM. Something tells me Parse
would have been a lot less expensive to acquire.

\- Acquiring Parse also allows FB to pass off the acquisition as some sort of
pro bono play as Mike Vernal did. Buying an app analytics company would be
obvious and deprive FB of this +ve good will they got for free here.

\- Parse has 100,000+ "apps", Flurry has 115,000+ "customers". Assuming these
are pretty much equivalent as I do, Flurry is 8 years old, Parse is 2. Tell me
which looks like the better deal?

------
johnwards
I think this is the important bit from this article.

 _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[1]._

[1]
[https://gist.github.com/stevegraham/6067333](https://gist.github.com/stevegraham/6067333)

------
yamill
Genius.

Parse is the most amazing app building service I've used thus far.

~~~
MasterScrat
I just wish they'd implement real-time data sync as Firebase does, then I'm
totally sold.

------
jolie
FYI, this quote was swiped from my article/interview on VentureBeat. You can
read the whole thing (with a lot more context) here:
[http://venturebeat.com/2013/09/05/why-parse-was-the-
missing-...](http://venturebeat.com/2013/09/05/why-parse-was-the-missing-
piece-in-facebooks-puzzle-interview/)

------
apphrase
It is very unlikely that the next Instagram would be using Parse

~~~
fnayr
Why? The next Instagram with an Instagram number of users would definitely not
be using Parse, but the whole point of the text you are disagreeing with was
that Facebook could use the data before the next Instagram fully exploded with
users.

