Tuesday, April 7, 2009

What FriendFeed, Twitter and Facebook have to do next?

yesterday was the Beta Day for friendfeed , before this facebook too make some change in it UI (user interface).

facebook new change made huge noise inside it own fan and passionate users.

in the new facebook the change where done toward a better public streaming.


mean to open facebook to a third part source of content by aggregating content.

while at friendfeed this was done years before :)

so:

1) facebook
facebook leaders noticed that in order to reach a wider audience they have to open their CONTENT to a wide contribution and here occur the third party content aggregation.

2) friendfeed
friendfeed lead at the same time anticipated such facebook move and introduce a total complete realtime content browsing and aggregation.

in terms of content aggregation and consumption facebook are at mile from friendfeed.

3) twitter
twitter leader understand from the begining that the other way to have a large audience is by opening their service via their API.

friendfeed and facebook are both at miles from twitter in term of third party API-based application.

now who will win the game of sociability?


friendfeed bring real time into an height level. but friendfeed will have to face some problem that I will try to enumerate later.

facebook in walk behind friendfeed will face the same problems or even worst.

a) the problem that may face friendfeed regarding the new change that they operate in their UI.

a-1) the difficulty to translate such change in their API.

friendfeed have to grant to the developer of API based application, the tool to bring the same features that FF are offering in their beta service.

there are change to come in the side of friendfeed API this is clear and simple, but the way to it is a bit longer then supposed.

to transcript the "real time " feature that exist in all the part of FF (list, home, filtering,..) FF-API will expose an advanced use of the Simple Update Protocol.

but then there will be really a new paradigm about the use of SUP couple to REST-API.

this is the new challenge that FF team have to face.

now let ask a question :

are "twitter, friendfeed, facebook" trying to make content more public?more open?

it is delisional to think so becaus, none of those service offer a way to export users data synthesis to others servers rather then by rss feed, witch begin to be obselete in real time communication.

those 3 service are still now offering to users:

1)the ability to read from different source (agregation).
2)to filter the source by author , keyword, like comment etc..
3)to contribute to the stream.

but all the 3 service do one common thing :

users stream retention .

a user in those 3 service can't export his stream elsewhere in a decent format rather then the obsolete rss or atom feed.


those service have to offer a way to export users stream to other service as they offer the way to agregate other service content. at the same rate at the same speed, without latency.without delay.

those services have to offer users at least a way to export their syntheis to their blog at the same rate as they import from their blog.

going public induce a biderectional way.

thinking "bidirectional" is a safe thinking, content retention may lead to crash.

so what those service "twitter, facebook, friendfeed" have to avoid ?

1)users retention.
2)content retention.
3)service retention.

this induce what they have to do next :

1)open authentification (openid, Oauth)
2)real time (third party) content sharing, such export to blog or to twitter of to FF or to FB.
3)better API.

ok I am done.

No comments: