[douglasp]

I work at Facebook.

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 [e-mail].

[psychotik]

One other option to look at, if you aren't already, is to freeze new feature development and allocate most resources to making the platform solid. You didn't state that in your list above.

You may be correct that you've done a lot to stabilize it during the last year, but how does that compare with the amount of new features you've added over the last year? Maybe Facebook just isn't good at producing bug-free code, and it's time to improve things you do before actually shipping a feature? Continuing to "ship fast, break fast" clearly hasn't worked when it comes to Platform - are you doing anything to fix that?

As an anecdote, Microsoft had a similar problems with Security of their OS - it was a much more severe problem. They took a similar approach to the one you've outlined, for many years - furiously developing new features while scrambling to patch security. However, in the early 2000s (2002?), after a particular severe worm hit computers all over the world, they completely froze all new development on the OS. They did their famous 'security push' where almost every engineer focused on security for many months. They revamped tools and invented technologies to make sure products are more secure out the gate, and the result was a resounding success.

Developer frustration with the Facebook Platform is very real - a competitor with a stable API might actually receive a lot of support from the community. Maybe Facebook needs its own version of Microsoft's 'security push'.

[pyman]

The JavaScript SDK is a complete mess. You broke BC when you introduced OAuth2 support.

Your code speaks volumes to the choices you've made as an organization, as well as your Engineers technical skills.

I know some Facebook Engineers and all of them are average PHP developers.

Code tells a story, and in this case, it's not a good one.

[stickfigure]

The problem is not that the API has bugs, the problem is the way Facebook interacts with the developer community. You have a huge problem and it's not something you will fix by writing code.

I don't know what is going on inside FB, but I can tell you what it looks like from the outside: You hired a bunch of junior developers to "fix bugs" in the platform while the Real Engineers go on to make whatever new bug-ridden feature Zuck wants this week. Except that these new developers don't know how the system works and can't even figure out what is or isn't a legitimate bug.

I mis-linked the second bug in the blog post; please examine it again now. Neither bug has been re-opened yet. The 'auth.logout' event still fires on login. This is obviously broken to anyone who has tried to develop a FB app, and yet the FB engineer looks only as far as some internal documentation before dismissing the claim without explanation.

I'm a 3+ year veteran of the Facebook platform. In all this time I cannot say that support improved one bit. Yes, the Graph API is less janky than the REST API, and the documentation is prettier - but in a lot of ways it has gotten worse:

* There is no way for developers to ask for clarification or add their own observations, like there was in the old Wiki docs.

* The old docs at least tried to document error codes and error results. The new docs make no mention of errors whatsoever. And in the mean time you've added three or four different error result formats because even within Facebook nobody knows what an error result should look like.

Sure, you moved "support" over to stackoverflow, which is at least better organized. But the problem was not the software. Today's problem is the same problem you had before: knowledgeable Facebook engineers are not present answering questions. Combined with the sparse and often wrong documentation, this leaves the community playing ridiculous guessing games.

This is a world of difference from the Google APIs I have experienced: Maps and App Engine. In both cases, there are forums where the actual engineers who work on the features hang out and respond to user questions. These people have names and they're not afraid to talk about the design issues involved. If Google+ inherits this attitude towards developer support, we're going to drop Facebook like an abusive spouse.

TL;DR: Answer questions. Respond to inquiries, even if the answer is "I'm not sure yet". Treat documentation as a first-class citizen. And whatever you do, DON'T CLOSE BUGS UNLESS YOU'RE 100% CERTAIN THEY AREN'T BUGS. Nothing pisses off a developer like spending hours isolating a test case only to be ignored or given the F-U of Won't Fix without an explanation.