If your business model is reliant on annoying the users of a proprietary 3rd party platform, you shouldn't be surprised when the rug gets yanked out from underneath you.
The point was that if Facebook are providing the APIs and encouraging developers to use them then it's a crappy thing to yank the rug away.
I don't think that it's a great idea to build a business model that relies on Facebook - but at some stages of developing an app it is very useful to use Facebook facilities to implement a social graph and notifications, so that you don't have to.
> "I don't think that it's a great idea to build a business model that relies on Facebook"
Correction: it's a bad idea to build a business model that relies on screwing Facebook, on Facebook's platform.
One of Facebook's priorities is keeping its users engaged and happy - invite-heavy, spammy apps run directly contrary to that goal (in a very egregious, very serious way). It is no surprise that Facebook slammed that door shut.
This is generalizable to: if you are reliant on a third party platform and your interests are aligned against the interests of the platform, you will fail.
> One of Facebook's priorities is keeping its users engaged and happy
Engaged, yes. Happy, bullshit. Facebook ignores its users and abuses them far more regularly than most other companies. Anecdotally, everyone I know hates facebook and wants an alternative that has active users. By numbers, Facebook was the last in brand satisfaction for its market in 2011[1], although ACSI appears to have died since then. I strongly suspect the reason facebook restricted notifications was because they weren't making enough money to offset e.g. disabling of notifications.
They're willing (and smart) to leverage independent efforts where they assist this. But... only so long as they do.
Look at it from this perspective: If a functionality becomes important, would they not be "derelict" in their duty not to attempt to bring it under their control? In-house, acquisition, whatever.
If you choose to help them out, they're not going to say no. But you should keep the balance of power in such a relationship in mind.
As a facebook user, I'm happy I'm not longer gonna get "your friend has invited you to this app..." notifications. As a developer, though, I can see why this would be frustrating.
The main frustration here is that the Requests are those that are actively initiated by a user. A friend is actively trying to invite you to the app, rather than just an app spamming those who have once installed it.
That logic melts down when it meets the ecosystem that churns out 5 Farmvilles or Slot Manias a day. Suddenly a rotating set of 1% of your friends list can make using Facebook so painful you'll stop, permanently.
So many new apps launch that banning notifications by app gets tedious. They all suck in different groups of your friends, so banning notifications by friends is tedious. Not forever, perhaps, but long enough to make you think ill of Facebook.
We've been there before, and even though as a developer I miss it, it was the right thing of Facebook to do.
This is what I was trying to achieve with my app. The Request notifications were for individual users - not pre-ticked.
The problem is that creating something that people actually want, working via the channels that Facebook provides for people to access the Social Graph is very risky, as they can move the goalposts at any point.
The fb policy is that you aren't allowed to incentivize the sending of requests, but you can give a reward for someone accepting a request. A subtle distinction, but a distinction nonetheless.
I replied on the site, but I'll share my comment here as well.
I work on Facebook Platform. We never "turned off the Requests functionality for apps that are not labelled as games, breaking many live apps." We never turned off requests. We never broke a single app.
What we did do was test the impact of issuing a notification for a new app request for several categories of apps. The sending and delivering of requests still worked through this test and nothing broke. Users could still send requests and they could receive them on Facebook.
The key thing to bear in mind is that our APIs often express "intent", not specific UX actions on Facebook.com or our mobile apps. We are always testing new user experiences to see what the best experience is for a given intent from an app. Such was the case with this test.
Again, no apps were broken, we were simply testing if/when/how we should surface notifications for app requests to users.
We have concluded this particular set of tests and if we are going to make some permanent changes, we will make sure to inform our developer community.
Thanks for the reply Douglas, I'd dropped you a note via FB asking for advice on how to proceed.
It's a very frustrating position to be in. I can understand why you need to test, and the arguments in favour of preventing spam.
It does seem that when you play by (what you think are) the rules you can get screwed, as others take advantage of the system. It's been a very frustrating few days!
This story is about 3 years late. Facebook long, long ago made notifications unreliable. They just took them from near-worthless to totally worthless for some apps.
Nobody who has any clue what they're doing is relying on those notifications getting through en masse now, at least not without a contract with Facebook.
Agreed; app requests' visibility and acceptance rates tend to be so abysmal in general that I'd bet that it makes very little difference to most developers that they've been yanked.
Meanwhile, Dr. Oz has a diet he'd like you to go on...click here to change your life.
I don't know if this has changed recently, but when the FB Platform launched, Facebook was notorious for constantly breaking publicly documented APIs. In fact, an unmaintained wiki was their official documentation.
I'm surprised anybody is still surprised when Facebook changes its rules without warning.
"So this is a warning - develop for the Facebook platform and run the risk of your business losing its whole value over-night."
This goes for using any platform. Look at the apps developed using the Twitter platform. This is one reason I've been trying to work on other ideas for a business, or to do my own crawling, for unscatter.com. Using API's from another company is always going to be a product risk.
Not only does it apply to any platform, this particular lesson keeps getting re-learned and re-ranted regarding FB, Twitter, and LinkedIn.
They all present massive opportunities to reach and interact with users/customers/clients... but unless you've been living under a rock for the last few years, you should know this kind of thing can and DOES happen.
This shouldn't and won't stop most people from building services on top of these platforms, but at this point you either know this is a risk and accept/plan for it, or you don't know this, which means you do not have an adequate understanding of the infrastructure you are depending on.
The problem that I had, and why I wrote about it, is that Facebook didn't follow their own policy on breaking changes.
We had planned to use Facebook-only for the first phase of the app - as it has a prebuilt social graph, friend model, and notifications system. Easy to use, and with a large base of users.
I guess my point is that even if you think you have taken a calculated risk (90 days breaking changes), the companies can find a way to mess up your plans anyway!
Whats annoying about all these new fandangeled web platforms is that they really screw third party developers over with drastic API changes which only benefit their own interests.
This is totally different to how things used to be done back in the desktop software era.... oh wait... oops.
P.s it sucks to be small and at the mercy of big boys
