Comment by douglasp | Hacker News Reader

Comment by douglasp | Hacker News Reader

I work at Facebook.

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).

I understand Facebook deprecated the REST API, but could you stop cloaking the documentation?

If I visit with my normal useragent I get a log-in form. If I visit with the Googlebot useragent I get content.

http://developers.facebook.com/docs/reference/rest/

I might be a bit naïve thinking this, and I only ask out of curiosity, but, OAuth non-browser implementation issues aside, what drove the decision to support four individual SDKs to access the Graph API as opposed to building the Graph API up into a resource that, like a well implemented REST API, could be used easily by anything that can make an HTTP request?

From that position, the open source community, or any enterprising developer for that matter, has a single, standard, and well supported API they can then write a language specific library for and maintain.

Like I say, I'm not privy to all the details behind this, and I'm being wilfully ignorant, but it intrigues me that the developer of an API feels that it needs to then support its own abstraction of it for a limited number of platforms/languages.

I don't know the details, but to your and latchkey's point, I think the reason they support these SDKs (in addition to their generic Graph API) is that they're consumers of those SDKs. They have an iPhone app, an Android app, use JavaScript and probably the PHP SDK for internal stuff. So they're just making these public since they're good enough for internal use.

They could probably easily hire a Python coder to maintain a Python API (and Ruby, or whatever language), but it would be unrelated to the main work they're doing and probably lag behind since those languages are either little used or not used at all in house.

FriendFeed, acquired by Facebook in 2009, was a Python shop. These guys now maintain their Tornado platform as Facebook (https://github.com/facebook/tornado). Facebook's CTO, Bret Taylor, is a Python guy (https://github.com/finiteloop).

Python is used in house. They have the resources to support Python. They've just made the business decision not to.

Are you at liberty to share the reasons behind supporting these platform-specific SDKs rather than providing a single, robust REST API?

They have that single, robust API in the form of the Graph API. It does everything the old APIs did and more, but it's all in one place now. http://developers.facebook.com/docs/reference/api/

Maybe I'm confused. It seems like Facebook has the ability to hire as many 'resources' as they possibly can. Are you saying that there are no Python developers out there that you could hire that would be willing to work on the SDK?

I think he's saying the cost/benefit of providing the level of support for a Python SDK isn't worth it. Perhaps, once they've gotten everything cleaned up, they'll support Python again.

I like this idea. The FB API is a mess that I've decided to stay away from. If they consolidate their resources, improve the API and provide good docs, I'd be willing to revisit.

Just because a company has the resources to hire doesn't mean it necessarily should. A company culture can only absorb so many new hires in a given period of time, and I think Facebook likes the culture and doesn't want to see it go away.

One recurring point on HN in recent times is that there is a major talent shortage. It is very possible that Facebook is not able to find skilled Python developers to work on the SDK.

From everything that I've read and seen first hand in doing interviews, the reason for the major talent shortage is because FB, Goog, etc have first dibs on the best people. What I suspect is more likely is that their general interest primarily lies in languages other than Python.

Copy-paste from another comment:

FriendFeed, acquired by Facebook in 2009, was a Python shop. These guys now maintain their Tornado platform as Facebook (https://github.com/facebook/tornado). Facebook's CTO, Bret Taylor, is a Python guy (https://github.com/finiteloop). Python is used in house. They have the resources to support Python. They've just made the business decision not to.

"They have the resources to support Python."

Having Python experts on staff is no indication that those people have time to work on additional Python projects. And if there is a real talent shortage, it is quite likely they cannot find anyone else to take on the extra projects.

Ultimately, you are right that it is a business decision. They could hire anyone off the street and train them to be skilled in Python. Though I understand why they might not want to do that.

That's fair. I was more intending to point out that Facebook does indeed have Python developers, and they are not entirely a PHP business.

Unrelated to this issue but I can't find any other way to contact you since you don't respond to email: when are developers' OpenGraph actions going to get approved? Mine have been pending for months. Why release the docs so early if no one's actions will get approved?

Reply on news.ycombinator.com