Hi, I'm Doug Purdy, Director of Developer Products at Facebook. I wanted to weigh in here to explain how we think about some of these things.
Successful iOS and Android developers are integrating Facebook into their mobile apps. It's not an either/or equation. In fact, as of this month, more than 81% of the top 100 grossing iOS apps and 70% of the top 100 grossing Android apps integrate with Facebook.
All categories of developers continue to build with Facebook (fitness, books, music, games, etc.) with over 10 million apps and websites integrated with Facebook. Notably, games continues to be an extremely popular category – more than 250 million people play games on Facebook each month, and canvas installs have gone up 75% in the past year. Most of our games developers had record years in 2012, and over 100 of these developers made more than $1M in 2012 (in total, we paid out more than $2B to games developers in 2012).
With regard to Platform policies, for the small number of apps that violate our policies (replicate our functionality, fuel their app's growth at the expense of people's experience or expectations) we take action as needed. But for the vast majority of developers building great social apps, keep doing what you're doing.
Our goal is – and has always been – to give people a convenient way to login to apps, create personalized and social experiences, and let people share the things they care about through the apps they use.
I replied on the site, but I'll share my comment here as well.
I work on Facebook Platform. We never "turned off the Requests functionality for apps that are not labelled as games, breaking many live apps." We never turned off requests. We never broke a single app.
What we did do was test the impact of issuing a notification for a new app request for several categories of apps. The sending and delivering of requests still worked through this test and nothing broke. Users could still send requests and they could receive them on Facebook.
The key thing to bear in mind is that our APIs often express "intent", not specific UX actions on Facebook.com or our mobile apps. We are always testing new user experiences to see what the best experience is for a given intent from an app. Such was the case with this test.
Again, no apps were broken, we were simply testing if/when/how we should surface notifications for app requests to users.
We have concluded this particular set of tests and if we are going to make some permanent changes, we will make sure to inform our developer community.
We are working as hard as we can to make our API less buggy and more stable.
Over the course of the past year, we have added more tests, more resources and more tools to this problem than we have throughout the lifetime of Facebook Platform.
Ironically, it is the OAuth migration that is responsible for the JavaScript SDK bug reported in the post. We introduced this bug went we added the OAuth code path. This bug is on deck to be fixed soon, however (there is a straightforward workaround in the meantime).
In terms of the source of JavaScript SDK, we are working through the right approach to ensure that developers get access to the non-minified source (which I agree we need to do for debugging). It is unlikely that we will do this via GitHub, but we are looking at just having it off our CDN with the minified version as an option.
As for the bug process, I'll say two things. First, we now have a dedicated team of engineers devoted to supporting developers. If you have been developing on Facebook Platform for a while, the fact that bugs are getting daily responses is a vast improvement. We have a _long_ way to go, but we are listening and fixing. I will note that we are still working through the process on how we respond to various issues and how the bug tool (something we launched this year) works -- this seems to be evidenced from the post and something I am following up on. Second, just because the reporter can repro it, it doesn't mean we can, even with the steps that you provide. Our team of support engineers tries to repro every single issue that gets reported. Often, they simply can't and need more information.
I'll close by saying the following:
1. We care about our developers and the API.
2. We have done more this year than we have ever done to help developers and keep the platform stable.
3. That said, we still have a long way to go and these things do not change overnight.
4. If anyone has issue with how a bug is getting handled or any other issue with Facebook Platform, you can always ping me on Facebook (www.facebook.com/dmp) or [email protected].
My short response is that the repository is public once again, with a notice that it is deprecated. I personally apology for the churn.
My long response is that we haven't supported this SDK for some time and with our recent move to OAuth 2.0 across the board, the SDK does not support the latest cookie format. The reason we made the repository private was to avoid confusing developers with a public SDK that just didn't work and that we already said we didn't support.
Based on this, we are going to do two things. First, we have made the repository public again, with messages that it is now deprecated. Feel free to clone and mod to taste/work. We really want to support a Python SDK, but we need to get all our resources focused on the SDKs we can actually support well. I have no doubt that the developer community can and will provide an SDK to fill this need in the interim. Second, we are going to post something on our developer blog to make sure everyone is clear about what SDKs we support (at this time we are only supporting the PHP SDK, the Javascript SDK, the iOS SDK and the Android SDK).
I am not going to go into specific details of what our system does, but we require that the developer verify their identity when we take a policy action on an app.
We do this to ensure that the account wasn't compromised (which could have led to the behavior our system detected).
If you have ever forgotten your Facebook password, it is a similar flow.
We communicate with the developer over their alternative email in these cases.
I work on the Platform team at Facebook and wanted to respond to some of the comments on this post.
Breakup Notifier is an interesting idea and an example of the sort of engagement that developers can get on Facebook Platform (according to our stats this app had ~13k monthly Facebook users).
That said, we've built a number of automated systems that track people’s response to News Feed stories generated by apps to ensure they have a positive experience and to determine if a given app is violating our policies. These systems have worked well, cutting spam by 95% last year alone.
In this particular case, Breakup Notifier triggered one of our automated systems due to an excessive number of negative user reports. The system automatically shuts down access to the app while immediately notifying the developer via email; which is exactly what happened for Breakup Notifier. We take this action to preserve the user experience while giving our developer relations team time to work with the developer to correct the issue. We have been in contact with the developer since he followed back up with us. We hope to get the underlying issues resolved and get Breakup Notifier running again.
We want Facebook to be a great place for both people and developers — and we work very hard to ensure that we are balancing all the factors at play. We think our systems do a reasonable job helping us strike this balance, but we are open to feedback and constantly look to tune how we react to these situations.
Successful iOS and Android developers are integrating Facebook into their mobile apps. It's not an either/or equation. In fact, as of this month, more than 81% of the top 100 grossing iOS apps and 70% of the top 100 grossing Android apps integrate with Facebook.
All categories of developers continue to build with Facebook (fitness, books, music, games, etc.) with over 10 million apps and websites integrated with Facebook. Notably, games continues to be an extremely popular category – more than 250 million people play games on Facebook each month, and canvas installs have gone up 75% in the past year. Most of our games developers had record years in 2012, and over 100 of these developers made more than $1M in 2012 (in total, we paid out more than $2B to games developers in 2012).
With regard to Platform policies, for the small number of apps that violate our policies (replicate our functionality, fuel their app's growth at the expense of people's experience or expectations) we take action as needed. But for the vast majority of developers building great social apps, keep doing what you're doing.
Our goal is – and has always been – to give people a convenient way to login to apps, create personalized and social experiences, and let people share the things they care about through the apps they use.