FB seems to have a two tiered developer program. There are the peons, the guys forced to toil away trying to figure out how to make the stuff work by doing exactly what is described in the blog. And then there are the anointed: the big companies or YC-related startups that enjoy special access to FB employees to get the answers they need.
For now it doesn't seem to really be harming FB. They enjoy extreme growth and developers are pulled to their platform because of their enormous gravity. Over time, however, it is really not sustainable. If they want to be a platform they should start acting like a platform and that means making sure their APIs are documented properly and developers have a way to seek out information they need. Microsoft, whether you like them or not, does a great job of this.
We’ll provide product, technical and design resources to support new Y Combinator companies interested in working with us to build deeply social products, whether a website or an application on Facebook.com. These companies will have priority access to our technologies and programs such as Facebook Credits, Instant Personalization and upcoming beta features.
Sadly, this is not the case. I am currently working for a large media company that had/has relatively close ties with members of the FB dev team. The position I hold now was previously occupied by a fellow who went to work for FB and was a key interface with them over the last year and a half for things like FB Connect. I can tell you now that we got no privileged documentation that anyone else didn't. The only thing we really got was a poor guy who heard our complaints a little too often and wasn't really able to do much to help out.
We are probably in a similar program, but our developer contact was basically of no use whatsoever. Probably not his fault - it seems to be a cultural thing as observed above.
Even after last week's developer meeting and subsequent rollout of changes, my request for documentation was met with - not paraphrasing - "We'll get back to you."
You're overstating this quite a bit. I work for a startup that was an early launch partner for Pages back in mid 2007, and have built and maintained our Facebook application from that time. We have numerous contacts inside Facebook, and they can be of help occasionally, but they can just as easily turn around and screw us. They stole hundreds of extremely popular pages from us that we built up over years, and they did it basically on the same freakin day that our CEO was having high level meetings on unrelated partnership deals with Facebook brass.
The reason is very closely tied to Facebook's engineering success: there is no top-down control over anything. All the engineers are encouraged to break things and to keep the pace of progress rapid. For developers on their API this is a nightmare scenario. However your claim that this is not sustainable may just be wishful thinking. Facebook craps all over its developers, but it's not clear at all that that price is too high to pay for the continued agility that Facebook exhibits. It's hard to argue with that kind of market dominance. Plus, Facebook is so nimble that if API stability does become a problem they can easily switch gears and focus on it.
In other words, I wouldn't hold your breath for any change at Facebook.
An engineering culture that breaks APIs is bullshit. Taking 48+ hours to fix show-stopper platform errors is bullshit. Their 'innovative approach' is not working and the proof is in the pudding. They have not reached 500 million users solely on the success of this engineering approach, and I would vehemently argue they have reached 500 million users in spite of it.
The price will become too high to pay, if the future they envision involves third party developers at all. 500 million users is a hell of a lot of momentum, but it won't carry them as far as they want to go.
Of course it's a problem. It's a terribly onerous problem for developers. But the thing is that they don't have any problem getting developers to deal with it because there's really no alternative. And businesses hiring web developers are demanding Facebook integration as much as ever. Sure, if they fixed the problems then developers might be more enthusiastic, but you haven't shown that that will improve Facebook's bottom line. They have no shortage of apps, users, or growth, so the onus is on you to support your argument.
Saying that you think they have reached 500 million users inspite of their engineering approach is far from a common-sense argument. It's clear that Facebook ran technical circles around MySpace. And it's clear that they have launched new features at a breakneck pace throughout their history that have fueled growth at every turn.
I personally will avoid working with Facebook as much as I can, but will that hurt them? Not in the current business climate.
I've just been playing with the Facebook API for a toy project (submitted here: http://news.ycombinator.net/item?id=1743486), and utterly agree - the documentation is not even barely adequate.
The other irritating thing is when you eventually discover that there's a bug, the best response you see is "Hi, sorry this is a known issue" with no resolution date or even rough idea of whether it'll be fixed in the next year or not.
If they can't provide the support we need with their limited resources (someone mentioned on Reddit they had only 6 people on their platform team), they should at least let us pay $250/yr for a "premium developer" account, and have that enable us access to a developer helpline or something.
This is so, so correct. I've been doing Facebook stuff for a few years now, and this rant is just the tip of the iceberg.
Other favorites:
* They accidentally flipped the switch to a new authentication mechanism overnight to a beta with no documentation. It took them over 48 hours to realize and fix this mistake.
* At one point I was asking for JSON and intermittently getting back XML instead. Apparently JSON parsers can't parse XML. Who knew?
I have to agree. Just about every bit of this article is correct, it's part why I hate developing for Facebook so, so much. For an API whose stated goal was to power the social fabric of the interwebs, Facebook is doing a terrible job of letting those of us who create the interwebs work with it. The only response I've gotten from FB engineers was either "Sorry." or "I don't know what your talking about," both in person at F8 or via IRC.
On the contrary. I think Facebook cares very much about developers. They do not want to give developers enough tools to create enduring products, because this would kill their walled garden, in a variety of ways.
The biggest way is they don't want to make it easy for you to get your data out of Facebook. Any robust, well-documented API would have to enable that.
In some ways this is even a good thing. A small number of compromised accounts can give access to most of the data on Facebook.
I really don't believe that Facebook's developers are incompetent. And it's quite easy to neglect work when there's a business case for leaving that work undone.
I suspect that as with any large enough organisation there is a spectrum of competence across their workers, raging from high to low. I obviously have no proof that there isn't some big conspiracy afoot, but given the choice to bet on conspiracy or incompetence as the primary factor for the issues we're seeing, I know what I'd put my money on.
I'm more of a season fb dev, since I only play with the API from time to time, yet I've managed to suffer with their docs every time I try to do something.
While I need it mostly for side projects, I pity the ones whose FB app is core for their business, f.ex. this comment:
Do we have a fix for this solution?
In spite of so many people facing the problem why is this issue not addressed
till now?
Can someone answer these questions? Our application is totally based on the way
Facebook gives the location info and most of the time we get the location info
as NULL.
The poor documentation is an inconvenience, but the real problem is how often the functionality of the API changes (ie: breaks) without anyone at Facebook noticing (or perhaps just not caring).
I remember constant problems with authentication and sharing APIs. How do you not have tests for those?
I'm utterly astonished that there is no way of getting a full list of fans of my own page. FQL? No. Graph API? No. REST API? No. Screen scraping? No! If you have more than 10000 fans, then not even the web displays them (page 100 = page 101 = page 102...)
Just about the only thing you can use at all is the javascript api. And only because you can use firebug to throw a million things at the wall and see what sticks.
...and for the love of god don't use facebook for user auth. The API will mysteriously go down without warning for hours at a time.
This is one of the reasons I left my last job. Facebook was crucial to the business strategy, but it's miserable to work with.
I have a humble request for all of you developers who are building facebook apps. Please create an open source project (or a forum with all the tricks you are discovering) so that everyone doesn't have to reinvent the wheel. Basically, please collaborate your efforts to create a more reliable unofficial API documentation for FB.
Ryan Waggoner wrote a similar post like this a few days back (http://news.ycombinator.com/item?id=1731427), so this is clearly bugging a lot of people. Please collaborate your efforts if possible.
The problem is, with every iteration of API changes that FB makes, existing entries in such a forum would go obsolete. This could just increase confusion.
There was definitely a cultural problem at facebook in terms of how they were treating the developer community. The copious unanswered critical issues in the forums among other things sent a very clear message that FB has other priorities.
Judging by the comments left by newly hired FB staff on http://news.ycombinator.com/item?id=1731427 and on this post, maybe that attitude is finally turning around. But I personally really feel burned by my experience working with the facebook platform. Their deficiencies cost me a lot of money, and caused a lot of stress due to blame and doubt applied upon my team by skeptical clients. When it comes to Facebook, I'm going to have trust issues for a long time...
A co-worker who had to work with the Facebook API in a previous job had this to say about it. Working with the Facebook API is like poking yourself in the eye with a fork, repeatedly. It is interesting to see the problems he described confirmed and explained in more detail.
35 comments
[ 3.0 ms ] story [ 82.0 ms ] threadFor now it doesn't seem to really be harming FB. They enjoy extreme growth and developers are pulled to their platform because of their enormous gravity. Over time, however, it is really not sustainable. If they want to be a platform they should start acting like a platform and that means making sure their APIs are documented properly and developers have a way to seek out information they need. Microsoft, whether you like them or not, does a great job of this.
I don't think a startup would enjoy special access to FB technology just by being related to YC
We’ll provide product, technical and design resources to support new Y Combinator companies interested in working with us to build deeply social products, whether a website or an application on Facebook.com. These companies will have priority access to our technologies and programs such as Facebook Credits, Instant Personalization and upcoming beta features.
When I browsed the API on my own it was an utter disaster on par with the article's description.
Even after last week's developer meeting and subsequent rollout of changes, my request for documentation was met with - not paraphrasing - "We'll get back to you."
The reason is very closely tied to Facebook's engineering success: there is no top-down control over anything. All the engineers are encouraged to break things and to keep the pace of progress rapid. For developers on their API this is a nightmare scenario. However your claim that this is not sustainable may just be wishful thinking. Facebook craps all over its developers, but it's not clear at all that that price is too high to pay for the continued agility that Facebook exhibits. It's hard to argue with that kind of market dominance. Plus, Facebook is so nimble that if API stability does become a problem they can easily switch gears and focus on it.
In other words, I wouldn't hold your breath for any change at Facebook.
An engineering culture that breaks APIs is bullshit. Taking 48+ hours to fix show-stopper platform errors is bullshit. Their 'innovative approach' is not working and the proof is in the pudding. They have not reached 500 million users solely on the success of this engineering approach, and I would vehemently argue they have reached 500 million users in spite of it.
The price will become too high to pay, if the future they envision involves third party developers at all. 500 million users is a hell of a lot of momentum, but it won't carry them as far as they want to go.
Saying that you think they have reached 500 million users inspite of their engineering approach is far from a common-sense argument. It's clear that Facebook ran technical circles around MySpace. And it's clear that they have launched new features at a breakneck pace throughout their history that have fueled growth at every turn.
I personally will avoid working with Facebook as much as I can, but will that hurt them? Not in the current business climate.
The other irritating thing is when you eventually discover that there's a bug, the best response you see is "Hi, sorry this is a known issue" with no resolution date or even rough idea of whether it'll be fixed in the next year or not.
I had three more sections planned out, but said the heck with it, they've already taken so much of my time.
You are totally right, though.
Other favorites:
* They accidentally flipped the switch to a new authentication mechanism overnight to a beta with no documentation. It took them over 48 hours to realize and fix this mistake.
* At one point I was asking for JSON and intermittently getting back XML instead. Apparently JSON parsers can't parse XML. Who knew?
The biggest way is they don't want to make it easy for you to get your data out of Facebook. Any robust, well-documented API would have to enable that.
In some ways this is even a good thing. A small number of compromised accounts can give access to most of the data on Facebook.
Recently I've found another problem - public user data being visible to users, such as birthday, hometown and current location is not available through te Graph API as well as REST old one. Of course they're documented as available http://developers.facebook.com/docs/reference/api/user and accessible by visitors, but not by API. I've found this case in lots of posts on the forums and bugtrack, f.ex. http://bugs.developers.facebook.net/show_bug.cgi?id=8376 marks this bug as fixed, yet there's a new one http://bugs.developers.facebook.net/show_bug.cgi?id=12090 with the same case.
While I need it mostly for side projects, I pity the ones whose FB app is core for their business, f.ex. this comment:
Do we have a fix for this solution? In spite of so many people facing the problem why is this issue not addressed till now?
Can someone answer these questions? Our application is totally based on the way Facebook gives the location info and most of the time we get the location info as NULL.
I remember constant problems with authentication and sharing APIs. How do you not have tests for those?
Facebook is still way too cowboy.
...and for the love of god don't use facebook for user auth. The API will mysteriously go down without warning for hours at a time.
This is one of the reasons I left my last job. Facebook was crucial to the business strategy, but it's miserable to work with.
At least twitter's api is easy to use.
http://www.sethcall.com/blog/2010/09/30/facebook-api-does-no...
I am really quite pleased he took the time to address the post. Let's hope he can succeed.
Ryan Waggoner wrote a similar post like this a few days back (http://news.ycombinator.com/item?id=1731427), so this is clearly bugging a lot of people. Please collaborate your efforts if possible.
http://area51.stackexchange.com/proposals/7285/facebook-deve...
Personally, I think the StackOverflow engine would be a great way to build up a crowdsourced wiki of FBAPI knowledge.
Judging by the comments left by newly hired FB staff on http://news.ycombinator.com/item?id=1731427 and on this post, maybe that attitude is finally turning around. But I personally really feel burned by my experience working with the facebook platform. Their deficiencies cost me a lot of money, and caused a lot of stress due to blame and doubt applied upon my team by skeptical clients. When it comes to Facebook, I'm going to have trust issues for a long time...