Bummer. Can I ask why this changed your mind? At FB, we're quite serious about finding ways to gift third party developers with APIs, tools, open source, platforms, whatever we can do to help. I think Parse is pretty awesome and is likely to become more so at Facebook. That's a useless opinion if it's not shared by the wider community, though.
So: feedback taken seriously - we're listening. Fire away.
- I don't trust Facebook to not convert the user system into a Facebook connect monster and force it on me
- I don't trust Facebook to not data mine my data and violate me and my user's privacy
- I don't trust Facebook to let me export my data once I want to move on
- I don't trust Facebook to actually delete data once I tell them to do so
- I don't trust Facebook to not to attempt to monetize my users beyond the account fee that I pay
I am in a similar position. Was about a week away from pulling the trigger on parse after a lot of research into the backend service providers. Now I will definitely look elsewhere. One problem is that FB APIs have a tendency to be constantly changing, and the documentation is not good. This shifting sands is not a good place to build a service.
However, the biggest reason is that FB is NOT a back end service provider. Facebook's customer is the advertisers. Before getting bought, Parse's customer were the companies that used their service. Now Parse is part of FB so future directions will all be in service of FB's main customer, the advertisers. I have no problem with this from a business standpoint, I am sure it is a good move for FB, but as a customer of back end cloud services I want to be purchasing that service from a company that puts me first. FB will not do that.
TL;DR: I was Parse's customer, I am not Facebook's customer.
So the Parse platform allowed me to get and implement my iOS app in under a month, getting my MVP out there. If you want to really assure users that they can be comfortable, and to not flee, make it so we have access to our user's password hashes.
Before, the Parse team said they were thinking of implementing it, but now there's no contest. Either you guys allow me to take my user data, or we're done, and I'm completely separating from you guys, and wouldn't recommend anyone building on the platform.
So, let me have ALL access to my user's data, and we can keep hanging. Otherwise, we're done.
As it is, I'm making plans already to move, on the assumption you guys won't let me get my user's data.
Nope, not from the last export I did a few weeks ago. Please check and make sure, because this is a crucial link to the level of trust with the continue support of Parse and FB
Our team uses Pieceable, which Facebook also purchased, and which I would also consider a tool for third party mobile developers.
The acquisition announcement [1] states that Pieceable is/was going to be killed 12/31/12, but prior to that date they'd open source it. And, as far as I can tell, that's the last time anything has been said about the product. I don't even know if you're still taking our money, but it's going to suck when you turn it off or it breaks due to obsolescence.
So, my answer is that your prior behavior does not instill confidence.
As someone in a similar situation: I don't like tie ins with huge companies. My experience with the Facebook API has been horrible in the past (constantly changing, poor documentation).
In short, I don't want FB/Goog/Apple/etc. to keep buying up the independent operators that I know and love. In a similar way, I prefer to frequent my local coffee shack over a Starbucks. Nothing Starbucks could do would really change my mind.
There's not really anything facebook could do other than not being facebook. Sorry.
I'm really sorry you've had bad experiences with the API. :/ I'm not sure how much consolation it will be to you, but we've gotten a lot better about this, even in the last year, increasing platform stability, improving our documentation, adding guides and Developers Live, giving 90+ day heads ups for breaking changes that you can opt-in to.
Facebook's definitely not going to stop changing and sit on its laurels; our Platform is going to evolve as well. I know this means work for developers but we'd like to do so hand-in-hand with our community, working together to build a better future. We're learning how to do that. We've made mistakes. But we're here for you and are trying every day to give you more.
Email me at dew@fb.com if you prefer to rant in a private forum, or here and I'll respond.
Phrasing like this concerns me. When making platform decisions, I would very much like greater assurance that there is an expectation of how a relationship matures than you would find in a "gifting" scenario. I feel like sometimes the attitude from Facebook has been "We're giving all of this stuff away for free! What is there to complain about?" Free means no expectation of warranty and zero assumed reliability.
I don't really even care about free. If you're running a real startup, you pay for things, and I would gladly pay for Facebook API usage if it meant that Facebook took their APIs a little more seriously (I could talk at great length about all the subtleties in Facebook's APIs that require us to duplicate insane amounts of work that Facebook could _easily_ take care of). Amazon is clearly the best at this with AWS (especially in preemptively coming up with new services it turns out everyone was building piecemeal anyway), I would look at Amazon's APIs and try to port the some good insights to the Graph API.
I think the word gift and give in this context are interchangeable. Sounds like you found a word to pick at and are now just hating Facebook for the sake of it. (You managed to extrapolate that Facebook has 0 assumed reliability because he used the word gift.)
Quite the contrary, I think Facebook is great and is only getting better. But as someone who builds a lot of stuff on their APIs I can say it's easily the shakiest component of our architecture.
[nod] I think it's absolutely true that in the most stable relationships, both sides stand to gain. There is definitely much to learn from the pioneering work Amazon has done in this space.
For what it's worth, I'd be very interested to hear your at-length talk about the things Facebook could easily take care of that would make your life easier. Fire away. :) dew@fb.com.
Users of apps based on Parse used to just be users, now they're Facebook users. Combine the fact that a core part of Parse is storing user data, and Facebook's track record of treating such data, I think you should be able to figure the rest out yourself.
If I'm going to pay a firm to store data for me, I need to completely trust that that firm is going to treat said data with silk gloves. I choose what's done with it, not my backend storage partner.
I'm going to be very surprised if the Facebook make-a-detailed-profile-of-every-person-on-the-planet department is going to keep their hands off of Parse data for the next 3 years.
I've been using Parse with great pleasure as well for a couple of months and I really want to keep using it because their API is really beautiful and their design is absolutely gorgeous. But the past event that worries me is the acquisition of face.com. Right after the acquisition, they assured everyone it would stay up and they would continue to support it for all the developers who integrated its facial recognition API into their apps. And just a couple of months later, they announced they would fully absorb and kill it as an independent service. Today, the domain doesn't even lead anywhere. Now I know that the scope and impact of Face.com were way less than those of Parse, but still, you can't blame us for worrying.
One thing that would personally reassure me would be for Facebook to add a "non-hosted" offering to Parse, which means the ability to download Parse's application and install it on my own server. If this was available I would keep using Parse as a hosted service knowing that in the event that Facebook decides to shut it down at some point, I can export all my data and have it running on my own infrastructure.
Parse is a distraction for FB. You are not even in the same business. Regardless of what you say, you are unable to override the CEO if or when he decides that Parse is to be shut down. The alternatives are more appealing because their business model solely depends on customers paying for the back end service.
The best thing FB can do is to bind itself legally to continue to run Parse for the next x number of years.
If FB wants to dabble with PaaS, businesses are going to assess Parse on the basis that it is only an experiment. Tying oneself to a back end is like marriage. No one will invest in a relationship if the other side is only half serious.
What would worry me is that I don't understand what Facebook really wants out of this acquisition, and why this will motivate it to do right by Parse users. It looks to me like a number of other people in this thread don't understand either and are coming up with their own theories, few of which are good news for the developer.
Long story short is that Facebook needed a way to be a platform for other mobile app companies' products without building a new os.
Developer mindshare is a big deal for technology companies. It has been argued that Microsoft's dominance in the 90s was fueled by its ownership of the windows api. Because the windows api had the most users, Microsoft owned the main platform where software developers and consumers would meet. While there was often friction between MS and the rest of the software community, they had a beneficial relationship.
Microsoft got paid rent and could leverage other people's work in making their value proposition to customers (ie if you want to game seriously you'll need to run Windows). And all of those developers did not have to write their own operating system or deal with all of the different computer companies.
Because Facebook apps have turned out to be more attractive as a way to access their social media users (ie for dating services etc) than it is for general purpose software products, they need a new way to grab developer mindshare.
Amazon didn't care about making their own mobile operating system because they have AWS. That's why they just forked android. Facebook doesn't want to buy a whole new mobile operating system in 2013 because blackberry and windows phone have shown how expensive it is to try and convince customers that they are a viable competitor to android and iPhone.
Being a mobile backend as a service allows Facebook to take rents and work with developers and avoid that big marketing effort. On the other hand, they will take on similar risks to Netflix. They need to prove themselves to be as valuable to android and iPhone as Netflix is to Verizon and Comcast or they will get jerked around.
I have the same concerns (although I already have apps using Parse in the wild!):
• Will FB kill off Parse? Seems quite unlikely in the short term, but in the long term?
• Are they going to try and force any integrations with FB?
• Will Parse continue to improve (they've done a lot of this recently!) or will it dwindle as others move faster?
• Data / Privacy - what's going to happen with those going forward? These always are a concern in people's minds when FB comes up.
• Facebook's APIs / Developer Support is SHIT... will this happen to Parse too?
Totally agreed that Parse kicks ass, which is why we bought them; we're looking forward to working with the team to continue to improve it!
As a brand new member of the team, I'm really keen to hear more about how we've failed at our APIs and developer support and what we could do to be way better.
Late last year, I've tried to integrate Facebook into two tiny iOS apps. It sucked, and I'm not going to touch Parse in the future.
One of the few things I needed was an app request dialog. It didn't seem possible from the SDK docs (at least not clearly so), the only way was to use the deprecated global Facebook object:
There was no definitive list of possible values for the dialog name or parameters either. Apparently "message" was being ignored, but only for "feed" dialogs...? Apparently there is a replacement now, but it's still in beta. How am I supposed to tell my clients what is possible (and sustainable) and what isn't?
I'm in the same boat - was planning on using Parse and no longer think I will. Core issue: complete lack of trust that Facebook won't screw things up as they have so many times in the past (frequent breaking changes to their API, etc.).
Also, complete lack of trust in Facebook due to their lack of understanding of the need for privacy as opposed to pseudo-social ... "stuff".
What's sad to me is I have a HUGELY high view of "you" (i.e. Parse) - your documentation & examples are the best I have seen for any developer services, bar none. I'm just afraid what will happen as you get assimilated into the giant blue monster.
But still - genuine congratulations! You guys have definitely earned it, I'm sure this was the right step financially.
But what exactly did you buy them for? It can't be infrastructure, you already have that. It can't be app development libraries because you already have your own. Seems plausible you want to become a storage platform for their user data, which will ultimately mean tight FB integration. I don't think Parse can survive that. You might not intend to kill it, but how are you going to use it and prevent that from happening?
I'm sure not, and that's easy to say, but you never know how things go and you can't promise with absolution that nothing will change. To a lot of devs (me included), that's scary.
His issue seems to be a fear that Parse will be "integrated" into Facebook and its walled-garden-philosophy, rather than presented as a serious B2B offering. That wouldn't be as much as a problem with Microsoft.
The difference is Microsoft isn't buying anyone, it's their own service. The guy is turned off by the notion of what's about to happen to Parse, not just that they're being bought. The context matters.
It is still in beta but just for a couple of weeks. In general it is similar to parse.com but it has also heavy support for developing web applications hosted on backbeam (optinally with custom domain). It also has a more powerful query language, a real-time API and great support to manipulate files (you can escale images in different ways just by changing parameters in a URL).
Each project has two environments and you can browse the databases visually taking special care of relationships between entities.
The website is being redesigned and the documentation is work in progress.
This is an example of a complex query to the database:
select('news').query('join author join last 5 comments having score > ? fetch author', min_score)
It's not even close to being accurate. StackMob has multiple official partnerships with companies on that list that include full integrations, not just compatibility, but you only see one line of integration to Heroku. It would take 30 seconds worth of research to show how inaccurate that chart is.
If you're an enterprise developer, AnyPresence is a great option. Hands down the best MBaaS for enterprise, and the ONLY solution that won't lock you in (i.e., you own not just the data, but also the run-time components (code, server, etc). Check them out - http://www.anypresence.com.
There's a bunch out there. Buddy has advanced analytics, Kinvey charges by the user (vs. by APIs), StackMob basically runs an affiliate model upselling companion services.
