The Dangers of Relying on Facebook | Hacker News Reader

The Dangers of Relying on Facebook

blog.pixamid.com

78 pointsbbd3741 comments

As a business, it will always be a bad idea to completely rely on another entity outside your control, whose interests are very likely to be misaligned to yours.

By all means leverage, Facebook (and Twitter and others) sign on and APIs, but if you are building a business on a single one of those, you are completely at the mercy of their whims, any incompetency, and changes in business practices.

This seems like a really valid and important point. Yet companies who do build their entire business on other companies' info / APIS (Think Greplin, Trendrr, Tweetdeck, etc.) still get tons of interest from investors. While it is easy to realize the importance of developing an independent business when commenting on HN, I think the startup community as a whole needs to start displaying this in its actions.

Once more large internet companies realize that their users (both of their services and API) are not necessarily their customers (Think Twitter's denial of new 3rd party clients), the API free-for-all which we're experiencing right now will dry up, and we'll see at least one of the companies-who-are-built-on-other-companies fail. This might be the kick in the pants that the startup community needs to realize the importance of building unique, independent businesses.

While not the perfect situation, I think companies like Greplin, that use multiple APIs across multiple third parties, are at least able to offer a service should one (or a few) of those APIs become inaccessible for any reason.

Much better than your business relying on a single third Party (as in the featured article), where should you cease to have access you are completely screwed.

Greplin et al always have the exit scenario where their product is so much better than whatever (say) Facebook has in-house that Facebook buys them as a social-search talent-acquisition play.

This sort of scenario might be easier to identify and invest in than "the next Facebook".

Wouldn't it be a bit worrisome for a company to bargain to be purchased by Facebook when that company is in the position that Facebook could put them out of business at any point by cloning their stuff?

Creating an app as a "talent-acquisition play" seems reasonable but wouldn't you want to position yourself for multiple offers? If Facebook buying for talent, it doesn't have to restrict itself to the creators of Facebook apps.

There are always risks in business.

Are all the people who have built successful companies that rely on facebook, apple, twitter, google, or other platforms wrong?

The important thing is to understand the risks and account for them. Don't overreact just because having your app suddenly pulled seems more traumatic or less under your control than other failure modes.

A business built on a platform involves risks.

And a game of three-card-Monte involves risks(http://en.wikipedia.org/wiki/Three-card_Monte).

How do you distinguish the risks involved in one from the risks involved in the other? I'd say one important question is whether the "house" has more incentive to take your stuff or more incentive to benefit along with your success. Considering that Facebook's business model is essentially still up in the air, the question of what Facebook in particular cares most about is also up in the air.

You do not rely on other companies only when you rely on open standards. Web development is an example (although you indirectly rely on Google for example). All kinds of apps usually rely on an underlying commercial technology ( windows development, osx development, ios development) whose actions are outside your control.

The Facebook app and Windows app scenarios are not comparable. Microsoft knows that the only reason Windows has succeeded as much as it has is because of its vast and deep pool of applications. As such, there is an incentive for Microsoft to allow a relative amount of freedom when developing Windows applications. Indeed, a bare operating system is quite useless without applications to run on it.

Facebook, on the other hand, became successful without any of the additional third party applications that use it as a platform today. A "bare" Facebook, without any third party apps, retains quite a lot in the way of functionality. This means that Facebook's interests are much less aligned with yours than Microsoft's.

Facebook became popular without apps, true, but they have yet to prove how successful they are. Zynga is more profitable than facebook itself, that must mean something. It's just speculation, but i believe things will change as growth starts to plateau and everyone has caught up with their old schoolmates. As for microsoft, well, remember netscape.

Zynga is more profitable than Facebook itself, that must mean something.

Yes, it means something. The question is what.

It might mean that Facebook has strong incentive to steal Zynga's business.

Considering there are rumblings that Zynga is casting about for other platforms, Zynga might think so.

If Facebook could be the home of many profitable apps that it had fair and transparent way of taking a cut from, then you could feel like Facebook was likely to keep its ecosystem working. Until then, it seems like anyone building on Facebook is subject to continuous risk of, as you imply, a sea-change in Facebook's operations.

But that s what fb is already doing. They have a long term agreement with zynga to use fb credits exclusively, and they are extending that exclusivity to all developers starting this July

>> although you indirectly rely on Google for example

huh? how do you figure that?

Thats why it says indirectly. Google can harm your traffic if they want to

I would honestly never rely solely on one system, unless that system was my own. You never know what might happen in a years time. Everyone might realise that Facebook is actually worth £10 and it just drops out the sky altogehter.

One of the developers here was building a newsletter system recently and they wanted to use just one 3rd party mail system to manage the user lists and groups etc. I stressed that we must make the system independent and to store the lists of users and groups ourselves and only replicate to the email marketing system. That way, if we ever fell out with the email marketing software we could just open a relationship with another company and replicate the same information there.

As a company, we never implement something without sitting down and talking about the pro's and con's first. Don't get me wrong, we don't have meetings for the sake of meetings but important matters we take the time to discuss.

When we planned our CMS, we took 2 weeks to plan the system and how it would work. We are 18 months into the development cycle and the only thing we can think of that we would do differently is to use url routing over our own url engine. It's not even a massive change to implemement so we are lucky. The 2 weeks planning has saved months of re-factoring for future.

We now have news, galleries, ecommerce, content driven pages, personalised url campaigns, newsletters, e-newsletters. The list goes on. All with no regrets!

It's unfortunate that a company has to suffer bad planning and bad decisions, the main thing is learning from them

You have to trust someone. Unless you're using multiple datacentres, you are trusting your datacentre/hosting provider. All it takes is one billing dispute before they turn you off.

Re: mailing list, the great thing about email (unlike facebook), is you can change how you send you emails and your end user can still get your emails, and they don't know you've changed. Whereas with Facebook, you can't just change to (say) Diaspora without affecting your users.

I appreciate what you are saying but I know that if I pay my bills and I handle my own redundancy I am only responsible for myself. The level of dependency you are referring to would get you stuck in a recursive loop of never trusting anyone!

What I am saying is, if this company had stored the pics on their own server then they could still retrieve the pictures. You would then push the pictures to Facebook, Diaspora, Twitter etc. The company were using the data storing capabilities in Facebook to store the pictures, hence the high dependency on Facebook.

If in the instance I mentioned, Facebook cancel the app, you would still have the pics on your server and the user could see them and post them elsewhere

We knew well the risks going in, but still sucks when you run into the worst-case scenario. It certainly moved forwards our plans to get in alternatives.

What was the developement time on the app compared to if you had implemented a full system with photo upload etc?

Was time a factor?

Sure, it was a factor. The whole backend was built in 3 months, photo upload would have added another few weeks. But again, we aimed not to do that at all, wanted to be more virtual. At least until we heard form enough users that they wanted that option.

It's good you managed to find out what the issue with Facebook was and that they allowed the re-submitted application.

I not had the chance to work with any of the social networks or app stores yet. I am currently in the process of being commissioned to do an Android app, I'm a little concerned myself about running into red tape.

Facebook API client author here (http://restfb.com). In my experience, you've got to be extremely careful/defensive when relying on anything from FB. Undocumented breaking changes are commonplace and no one on the FB side seems to care very much, possibly because they've got a de facto monopoly for the time being, or possibly because community notifications/documentation/etc. are boring next to sexy engineering problems.

Parroting the article, I know: unless your entire app is Facebook-centric, be careful of tightly locking it to FB. If you must tie yourself to FB, think long and hard about doing so first and if you proceed make sure you've got a mitigation plan in place if things go south.

possibly because they've got a de facto monopoly for the time being

On what?

On "social networking", I guess. Just like with instant messaging, Facebook has a monopoly on social networking thanks to network effects. User join Facebook because all of their friends are already on Facebook, which leads to even more users joining Facebook.

Its the same scenario we saw with AIM in the instant messaging space. Lots of people were already on AIM (thanks to having AOL accounts), making AIM an attractive choice for new users. The trend was only broken when the AIM protocol (as well as those of other proprietary chat networks) was broken, allowing multi-protocol chat clients to bridge the gap between networks.

We're already seeing the same thing with social networks. Many clients support both Facebook and Twitter, allowing users to transparently bridge the gap between the two largest social media networks on the Internet.

Like quanticle said, social networking. You can't say, "fuck this, I'll just integrate with myspace instead" without getting laughed out of the room. Like it or not, Facebook's the only game in town.

Like quanticle said, social networking.

My problem is that is not a real thing which can be monopolized. I promise I'm not being (intentionally) obtuse here. I don't understand which piece of an online offering requires Facebook. Maybe an example would help me.

Specifically with respect to the OP, they have a gigantic datastore of their users' social graphs. That's a "real thing" that can be monopolized: their users' data.

I agree, there's nothing that requires facebook yet, and I hope developers realize the importance of keeping things that way, and stop integrating FB's services while there is still a choice.

It seems that neither Apple nor Facebook is particularly attentive to the developers who build on their platforms once the app is released. Curious models for companies whose success is largely due to the developer community.

I don't know about Apple, but I don't think that Facebook's success is due to the developer community. I would argue that the arrow of causation is reversed in Facebook's case - developers are interested in Facebook because of its market share, rather than the reverse.

Apple and Facebook don't get success from having lots of developers, they get success cause their users get access to some cool apps. If they burn X% of developers, then that's OK. Lots of their users don't complain about apps they never saw.

It is a matter of scale to a large degree - supporting so many developers efficiently, while still preventing harmful abuse. They both could improve in many ways, for sure, and given the contributions developers are making.

I'm working on a side project which needs to access a large sample of images to do some magic with the provided target image. Since Facebook has a good store of images, I'd chosen to use Facebook login (and to access user photos and profile pictures of his friends).

With the increasing reports of Facebook horror stories, I'm redoing the backend to be generic so that I could easily integrate a new login system (twitter or my own) if something goes wrong.

As per my project requirements, Facebook is the best option. So, the only care I'm taking to avoid get flagged by Facebook spam detection algos is to ask for as less permissions as possible from the user and avoid posting on walls without user confirmation.

This is pretty much my experience of basing a business on another company in such a way. Besides having learned my lesson about that, it's left me leary of everything from using cloud-style servers to outsourcing features such as comments.

You can get a big boost up from leveraging another company's assets, but you're left in a very vulnerable position - at their mercy in several ways. I'm striving to make all future endeavors as independent as possible.

One way to think of this is that if you are a regular employee of a company, you are 100% dependent on them for your work, but you also have a lot of things taken care of for you (one hopes). If you have a startup, but it's heavily dependent on some platform, you are maybe not completely dependent on them in the same way, but less independent than if you had your own infrastructure. There's sort of a continuum here.

What does Pixamid do that the iphone/facebook android app with integrated camera doesn't do? From what I've deduced Pixamid is a feature of current Facebook clients, not an independent venture in its own right.

This puts them in a similar position as Foursquare or Gowalla - once Facebook introduced places, you saw the stickers on the outside of businesses become "Check-In with Facebook".

Pixamid is similar to Color, in that we instantly share photos with those around you. But Pixamid gives the user more control, allowing them to limit sharing to just friends at the same place.

We also focus on aggregating photos from whatever source we can. Today, when people are together socially and taking photos, those photos end up spread out all over. If a Pixamid user is at a particular place, Pixamid will collect any photos taken at the same place from Pixamid, Foursquare, Facebook and Instagram.

The more nuanced sharing model and the aggregation are not currently features of Facebook clients. From what we have learned, a lot of people are not happy with any existing photo sharing solution, and we hope to provide some of them with a better service.

Can anyone reference some community that was destroyed or is being destroyed by the quote

"Deactivating apps without warning, and with no recourse, will seriously hinder Facebook’s ecosystem growth amongst “real developers,” leaving just the scammers and spammers. " Is adwords and adsense in this same trend? Does the need for spam and scam control outway the cost?

The pixamid situation is similar to the reason the breakup notifier got banned by Facebook originally. A large amount of users were deleting wall posts made by the app, causing the app to get flagged and automatically shutdown temporarily.

Well, it is increasingly becoming a world where we rely on 3rd party servers like Facebook, app approval process from Apple, etc. I wonder how much more complex things are going to get in future

Yep, you should just read the TOS and be prepared for the worst ;)

I'm trying to reduce my dependencies to a bare minimum. I implement most of the features I need by myself. I need the users, just it.

Reply on news.ycombinator.com