Live data from Hacker News

The sad story of Facebook Platform

pandodaily.com

81–90 of 105 posts

Re: The sad story of Facebook Platform

#81

Earlier quoted context omitted.

I wonder what this mindset does for the future employability of FB people, do people really want to employ people who are (basically) reckless?

I don't know if you are a developer or not. But the entire industry is moving towards the Facebook model i.e. those people would be highly desired in many places. The "theory" is that developers can't be reckless because all of the automated testing that goes on before anything is put into production.

Not if you're making APIs, which is essentially what the entire platform is.

The "Move Fast and Break Things" attitude is fine when you're releasing a complete product. Look at Twitter or GMail. Google and Twitter change their interfaces pretty much constantly, and outside of a few hours or days of grumbling, pretty much everyone goes back to using the services.

But if you're providing functionality that other people are coding against, it's a cardinal sin to break your API without warning everyone. When making API's, slower and more monolithic releases is often a better approach. It not only gives your teams time to develop and test the features, but it also gives downstream users of your API time to absorb the changes.

Re: The sad story of Facebook Platform

#82
This article fails to consider the (possibly very legitimate) reasons why Facebook backed away from this.

To me, the two biggest ones are:

1. As others have said, spammy apps hugely detracted from the experience of using Facebook.

2. I haven't seen this discussed elsewhere, but I think it's huge: Facebook apps were never allowed to serve dynamic content on people's profile pages. This significantly impaired how rich, useful, and "social" these apps could actually be.

For example, I used to work for BillMonk, which was a way of tracking social, informal debt between friends. It should have been a perfect app for Facebook. But it wasn't possible for us to serve content in our widget that would give you up-to-date information about how much you owed a friend (or they owed you). You had to "push" your updates to this content, as I recall, but it wasn't technically feasible for us to push content updates to Facebook every time there was a change to our database.

I think Facebook imposed this limitation very deliberately for a very good reason: if an app could serve dynamic content, it could also monitor how users were using Facebook. Someone could create a "stalker" app to tell you who was visiting your profile. If such a thing existing it would significantly deter people from using Facebook. You'd have to think before every click about the social implications of visiting the next page.

It's an important part of Facebook's model that you can look at whatever you want without looking like a stalker.

Re: The sad story of Facebook Platform

#83
post #57

Reading this article the one idea that persisted in my head was that this was a case of people not really knowing anything about ecology trying to create an ecosystem. Sure they used the word "Platform" and maybe that was actually the first clue, but what they really wanted was an ecosystem of actors creating increased value for their domain. I think that my favorite piece of writing by Cory Doctorow is his essay "Al…

This is an overly simplistic analogy. No platform developer, when faced with weeds would say "let's torch it". What really happened in my opinion is that they tried a weed killer. However, as in real gardening, it turned out that distinguishing a weed from a non-weed is complex, subtle, and full of value judgments. In some cases, even if a plant has weed-like traits or capabilities, it's not a weed in the eyes of the…

I agree that the analogy is simplistic but I disagree with your weed killer analogy. I use weed killer on my own lawn and when I do I apply it in a targeted spray specifically to the weeds in question. I am still making a judgement and doing the hard work to separate parasites from useful organisms. Based on the article is sound like they sprayed everything ie removed the apis in question, and weed killer will indeed kill the grass surrounding the weed if you are not careful.

So I think that the analogy still stands, in that if you want an ecosystem there isn't really any way to mechanize it yet and you have to be prepared to do some of the work by hand. Creating an ecosystem worth having means offering up interesting capabilities. Offering up interesting capabilities means that parasites will appear. You can remove the parasites either by removing the interesting capabilities, or by doing the hard work to single them out. Doing the former can have grave consequences for your ecosystem even if it appears easier/cheaper in the short term.

Re: The sad story of Facebook Platform

#84
post #75
post #59

Earlier quoted context omitted.

Here here. You can't trust the Facebook docs to be complete. I have numerous comments in our codebase of "Facebook API docs are wrong, it's actually X..."

It's odd that they chose stackoverflow for their support system, because most of the answered questions there are way obsolete by now.

They chose StackOverflow for their support system at one point.

At one point, they've also chosen a web forum, a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site), and probably a half-dozen attempts at official on-site docs.

When I saw they'd offloaded to StackOverflow, I thought that was an idea that had some promise, but the big question in my mind was how long until it reached the critical mass where it would consist of more out-of-date answers than current ones. And what they'd do when it does.

The answer, of course, is likely move fast and break something, and heaven help the people who had the idea of building something on top of their quicksand.

Re: The sad story of Facebook Platform

#85
Admittedly I did not make it through the whole article, but the comparison to iOS early on is laughable. The difference is A) access to a social graph of your friends and their trivial online activities vs B) a powerful touch screen computer in your pocket.

The Facebook API did not have some incredible mishandled potential. Instead, it was a very cool and forward-thinking API that had to constantly be modified to fight spam and keep up with Facebook's rapidly evolving product (which is a couple orders of magnitude more engaging now than it was in 2007 I might add).

Sure the Facebook API could have been better managed. Documentation and stability could have been better for sure. Maybe even the features could have been better. But the Facebook API is not a world changer. The Twitter API is more along the lines of a world changer, but they decided they needed to build the most profitable business possible and being plumbing was not in the cards. The Facebook API is a way to bolster the core Facebook product (which is amazing, probably the most engaging product ever created in human history short of addictive substances). This idea that if they just did right by developers it could have been so much more amazing is just a cyberpunk fantasy. The Facebook API could never be more than a reflection of a product.

Looking back on the mashup era, the future is not going to be from the goodwill of corporations to provide amazing APIs. Rather it will be open source, open protocols and open data that allow for true advancement in the state of the art.

Re: The sad story of Facebook Platform

#87
post #57

Reading this article the one idea that persisted in my head was that this was a case of people not really knowing anything about ecology trying to create an ecosystem. Sure they used the word "Platform" and maybe that was actually the first clue, but what they really wanted was an ecosystem of actors creating increased value for their domain. I think that my favorite piece of writing by Cory Doctorow is his essay "Al…

The cost of parasites was too high for facebook, when weighted against the opportunities: facebook is all about being flat and appealing to the general public, complexities like possible scams are putting off too many potential users. Facebook could not have grown to its present size if it had not killed the platform.

Also they can't share the social graph; the monopoly on the data that they have gathered on us is the whole point/worth/wealth of the company.

If facebook or google run into financial problems (this might happen if tax loopholes are closed, and countries decide that even big companies have to pay real corporate taxes) then these companies will be bailed out as they are 'too big to fail'.

Re: The sad story of Facebook Platform

#88
A very well-written and judicious obituary of Facebook Platform. I started building for it shortly after it launched, in late 2007. I had high hopes for it; I felt I was at the forefront of 'the next big thing,' like others, so I invested a lot of my time into it. I made apps that served millions of people, one of which reached #1 in DAU at one point among all apps (back when they ranked apps by DAU).

As a lone developer keeping up with the changes and additions wasn't easy - I literally ran the gamut - from FBML to FBJS to FQL to xd_receiver.htm to the JS SDK to FB Credits to Graph API. Initially I cut them some slack - it was a new platform, and we all make mistakes.

But things never really got better. I couldn't tell you how many times I came across 4, 5, 6 different ways to do the same (seemingly simple) interaction with the platform, only one of which worked, and of course not the officially documented method. Or inaccurate or nonexistent API docs. Or how many times my app would suddenly break without pushing any changes - I became accustomed to just waiting it out until Facebook would release a patch for whatever they broke, and have to tell my users to just wait it out. This would usually occur Tuesday night/Wednesday if I remember correctly.

Solutions to problems would usually lie in an obscure forum post after about 10 minutes of googling, posted by another friendly developer who probably tore his hair out looking for a solution. Ah, the camaraderie. Here's a recent one I just came across (and they're not hard to find) http://stackoverflow.com/questions/16649634/ios-url-scheme-f... Accepted answers that start with "Facebook seems to have..." and end with "change or remove them completely at will" tend to give developers more than a few gray hairs.

It also doesn't help that Facebook tends to treat developers like sheep. At first this didn't bother me - after all, they weren't forcing me to build apps for them, and I was free to leave at any time. In the early days I'd contact developer support (I don't think there's a published number) to report bugs/issues, suggest improvements, or genuinely ask for help with a problem. I never got a single non-automated response. Not once. So I stopped wasting my time and just became more and more bitter with every breaking change.

The 30% credits tax was the inflection point of the downfall. IMHO, that was a "me too" response to Apple's iOS platform (coincidence that they came up with the same fee structure?) and was, for me, the tell-tale sign that they were no longer interested in their developers' well being. Yes, I understand they need to make money. I am all for ringing the cash register. But Apple and Facebook are different platforms. Apple has a highly trafficked worldwide app store. They let me put my app icon on my users' home screens (that's valuable real estate), and I could push out unlimited notifications to my users' devices to keep them engaged and coming back with one click, among other things. Facebook has no such equivalents. I guess you could argue you're paying for the viral distribution, but after they've heavily curtailed their viral channels and people have become more and more immune to app invites, there's really no way to get free distribution anymore from Facebook. You still need to be buying ads, mostly from them.

If they wanted to make money and curtail spam, all they had to do was charge developers by each notification, invite, or newsfeed post they'd send out. Set a fixed price per message, or use a competitive auctioning system like adwords. The crapplications would never be able to afford their own spam.

I've since migrated my apps away from Facebook, either to mobile or on standalone web sites. Needless to say, my life as a developer has gotten a lot easier, and since I have more time to focus on improving my apps rather than keeping up with breaking changes, I'm doing better than I ever have before.

Re: The sad story of Facebook Platform

#89

It's worth noting that a lot of the apps that Facebook "killed off" (iLike, Social Reader, RockYou, Zynga games, etc.) really did detract from the user experience. Let's take Washington Post's Social Reader as a case study. You had to authorize the app in order to read the articles (that were often loaded with linkbait-y titles), and any time you did read (or click on) an article it automatically shared it with all o…

It sounds like the key benefit is intrinsically problematic... How could they build the platform the right way?

Re: The sad story of Facebook Platform

#90

Facebook’s inconstant behavior on Platform, however, has never been malicious. Rather, it is a result of an engineering-led culture" Seems me and pandodaily have a different definition of "engineer". I'm not an engineer, as I don't have an engineering degree, but I do feel bad for my friends who do, are professionals, and get grouped in with the type of programmers who are just haphazardly winging it to this degree.…

Seems me and pandodaily have a different definition of "engineer"

Hear, hear. That comparison was insulting.

That's like calling a child playing cowboy with a plastic gun a member of the SAS; it really puts down all the hard work and skill of professionals.

Post reply on HN