If I visit with my normal useragent I get a log-in form. If I visit with the Googlebot useragent I get content.
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.
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.
Python is used in house. They have the resources to support Python. They've just made the business decision not to.
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.
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.
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.
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).