Facebook tries to appease frustrated developers
In both cases, I wanted to write up the issue brought forward, but I wanted to get Facebook's side of the story as well. I contacted the company and was pointed to lengthy responses from Douglas Purdy, Facebook's director of developer relations. In short, he offered his apologies, cleared up some confusion, and promised Facebook still cares about developers. Is that true? You be the judge.
The first issue (Javascript SDK) is about how painful it is to work with the Facebook API: not only is it buggy and inconsistent, but Facebook apparently doesn't care that it is. The author, Jeff Schnitzer, says there are hundreds of examples of this, but he goes into detail describing a recent one he experienced, explaining how he lost a couple of valuable hours.
The Javascript SDK lets you subscribe to events "auth.login" (described as "fired when the user logs in") and "auth.logout (described as "fired when the user logs out"). Schnitzer discovered that auth.logout fires when you log out and when you log in. He then found two other people that had filed this as a bug on Facebook Developers. Facebook told them this bug is By Design.
In frustration, Schnitzer defined Facebook's typical issue response flow as follows:
- Close as Won't Fix without comment.
- Ignore developer comments asking for clarification.
- Developer posts a duplicate bug asking for clarification.
- Close as By Design with a cryptic explanation.
- Ignore developer comments asking for clarification.
"I wish this was an isolated incident, but nearly every experience I've had with the Facebook platform is equally unsatisfying," Schnizter wrote. "Bugs are closed or simply ignored. Of the issues which get a response, nearly always the first round is 'need a repro case' even though the bug is *clearly* spelled out in the description. Do I need to drive down to Palo Alto and type it in on your keyboard?"
Here's how Purdy responded to Schnitzer's complaints:
We absolutely do care about our API. 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. In addition, we are in the process of reducing the surface area of our platform to a level that allows us to provide a good level of support. Specifically, we are removing FBML (https://developers.facebook.com/blog/post/568/), deprecating the REST API (https://developers.facebook.com/blog/post/616/), moving to support OAuth 2.0/HTTPs (https://developers.facebook.com/docs/oauth2-https-migration/) across the board and deciding what SDKs we are really going to support. These changes are painful for us and developers, but necessary to provide the level of support developers expect. 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 dmp@fb.com.
The second issue (Python SDK) is about how Facebook previously maintained the python-sdk project on GitHub, but then suddenly deleted the public repository. The author, Lincoln Quirk, notes that the problem with deleting a repository off GitHub is that it affects lots of people who specify GitHub repositories in their requirements.txt files, a Python Pip feature which lets you list dependencies for your code, to be auto-installed from the Internet when needed. Quirk had Facebook's python-sdk repository in his requirements file, but since it's now gone, he can't install its dependencies.
The bug report on Facebook Developers refers to the company's "90-day Breaking Change policy" but the Facebook employee who classified it as "By Design" seems to ignore this fact. Quirk did, however, find that someone is maintaining the code at github.com/pythonforfacebook/facebook-sdk. He then also discovered that Facebook did announce they were discontinuing it, but that the note was buried in a different bug report on Facebook Developers.
Here's how Purdy responded to Quirk's complaints:
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. You may be wondering why we don't support this SDK. The answer is very simple, resources. What we have been doing all year is reduce the surface area of our platform to a place that we can actual provide good support. This is the reason that we are removing FBML (https://developers.facebook.com/blog/post/568/), deprecating the REST API (https://developers.facebook.com/blog/post/616/), moving to support OAuth 2.0/HTTPs (https://developers.facebook.com/docs/oauth2-https-migration/) across the board and deciding what SDKs we are really going to 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).
It seems Facebook is not so much throwing unnecessary obstacles at developers as it has a serious communication problem. The company is still young, so it is understandably making tons of changes on a frequent basis. Facebook's developers should definitely be the ones posting about these events, but they need some better training, in my opinion.
See also: