Why Facebook really bought Parse
swaggadocio.com
swaggadocio.com
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.
- 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?
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].
Parse is the most amazing app building service I've used thus far.