I recently stumbled across this quote somewhere on the AppleInsider website. I’ve got nothing to add, so here we go:

“Google only wants to give phone makers and providers enough code to allow them to deliver their own customized, distinguished products so that it can continue its core business of selling ads and paid search to mobile users. Those partners actually want to have control over differentiated, compelling features that they can use to sell their Android phones in competition with other Android makers.

So rather than Android being a platform being pushed forward by Google, it will largely be advanced by Motorola, HTC, Sony Ericsson, and other makers who all have a history of making dozens of phones with terrible user interfaces and bizarre bundled apps and hardware features that are poorly implemented.

The commonality between these devices will be that they all run Dalvik bytecode and have an open source kernel, something that few Android users will care anything about.

Essentially, Android isn’t Google’s phone platform, it’s an open alternative for failing hardware makers to use in place of Symbian, Windows Mobile, and Linux to create the same type of convoluted, fractionalized, and poorly integrated products they’re already making. This is also why Symbian, Windows Mobile, Motorola, and Sony Ericsson are all failing commercially.

Google’s primary and most significant contribution won’t be any major innovation in the core Android platform but rather in its own bundled apps, where Google plans to earn its revenues from via, to put it bluntly, adware and spyware. It should not be a surprise to see that Google is motivated to do things that advance the company’s profitability rather than create free value for other companies at monumental expense to itself.

Google has no interest in making Android phones work well with a media app like iTunes because it doesn’t have one; it has no motive to develop hardware integration with home theater or WiFi products because it doesn’t sell them; it has no need to line up major software vendors or games developers for Android because it doesn’t make any money selling hardware, and there’s really very little money involved in creating and maintaining a third party software store.“

Period.

Today marks an important day in the short history of social networks or – as you might prefer to call it – the real-time web: Facebook announced the definitive agreement to acquire FriendFeed. As the FriendFeed founders have put it, they’ve accepted Facebook’s friend request.

While the internet is a buzz about these breaking news, it’s sad news for me.

A quick glimpse at FriendFeed right after the announcement it appears to me, that the majority of FriendFeeders seem to dislike the idea of being forced to become Facebook users for what FriendFeed delivered to them, as well; some have even started to cancel their accounts.

It’s very likely only a matter of time until Facebook kills FriendFeed as a product, slightly “adjusts” content ownership policies and starts using the FriendFeed history for behavioral analysis and “targeted” ads. We’ve all seen this before.

To me it reemphasizes the need for a community owned, community driven, non-commercial platform. This might sound stupid, but it has worked before with programming and scripting languages, version control solutions and even entire operating systems. There’s no obvious reason why it shouldn’t work for stuff that forms the real-time web.

Having sold my own company, which did enterprise communication solutions, to Alcatel in 2008, I can very much understand the founders motivation to agree to the deal. But this only strengthens my point: At a certain time any founder will be offered enough money, to agree to the deal of his lifetime. And even if they claim not to, we might see Twitter being acquired in the near future, too.

Ultimately the only solution might be, to ask Linus Torvalds to do us one more favor and kick off a real-time web platform, that let’s us build a social network that can stand commercial interests and ask the Gates Foundation to fund it. If Linda and Bill don’t come to our rescue, we might ask users to voluntarily donate in favor of guaranteed privacy.

I’d love to see how that “business model” would work out.

OAuth has rightly gained lots of popularity these days and even given the current session fixation issues, I’m a strong fan of the delegated access control it promotes and helps implementing.

One of the prominent service providers offering OAuth based authentication is… Twitter. As more and more people are using Twitter as a personal and professional communication tool, I’m wondering why many of the additional third party services have not yet implemented OAuth based authentication. I don’t know about you but I’m getting slightly annoyed when an independent (often poorly designed) web site asks me to enter my full Twitter credentials. They all promise to not cache or store my username and password but still, it’s does not feel right. Some don’t even use an SSL encrypted HTTP connection for retrieving my secret user information.

Today I’d like to encourage all third party Twitter services to jump onto the OAuth bandwagon and offer their users with a secure and trusted way to delegate access control.

And here is my list of services that do not currently offer OAuth (and that I’m no longer going to use unless they do):

• Twellow: Asks for username and password. No secure HTTP POST.
• TweetLater: Asks for username and password. No secure HTTP POST.
• MrTweet: Asks for username and password. No secure HTTP POST.
• GroupTweet: Asks for username and password. No secure HTTP POST.
• Twitter Scheduler: Asks for username and password. No secure HTTP POST.

I don’t want to finish this post without giving outstanding, positive examples of doing it right: Check out WeFollow and TwitterCounter.

I’ll update this list accordingly and will add service providers, that don’t do it right and move those that switch to OAuth off from this hall of shame.

Which 3rd party Twitter services are you using? Please submit via the comments!

Update: We have decided to publish the post over at The Next Web. You might want to follow the discussion there, too!

I’ve recently had the pleasure to get interviewed by Laurent Francois (LinkedIn link), Head of 360° Digital Influence Hub at Ogilvy Public Relations Worldwide. The interview has been published in English and French.

Thank you Laurent and keep up the good work!

Tweetie for the iPhone (direct iTunes Link) and for the Mac are by far my two most favorite twitter clients. The Mac version that has been release just two weeks ago has replaced the Adobe AIR powered TweetDeck and besides some version 1.0 quirks I’m pretty happy with it.

As atebits – the maker of both – does not seem to listen nor respond to their two twitter accounts (@atebits and @tweetie), I thought I might start a list of enhancement ideas here. A blog post is also a bit more sticky as compared to the flow of tweets on the @atebits timeline.

I understand that some of these requests might not be ideally suited for the less-than-ideal twitter API but maybe the great folks at atebits find a way to work around it.

Tweetie for the iPhone

• Grey out the “Direct Message” button if the user is not following me. Letting me type in a message and telling me that it cannot be send afterwards is just not the right way of doing it. Maybe it’s been done this way because of the way the twitter API is structured, but it still needs to be fixed.
   
• Add a “Resend on reconnect” option if the user tries to send a message but the iPhone lost the data connect.
   
• Add the typical iPhone “new message badge” to the “Mentions” and “Messages” tabs and maybe also to the Tweetie home screen icon itself. Upcoming Push Notifications might be of great help here and open up a whole new world of possibilities.
   
• Think about introducing the option to auto-add a language hash tag (#en, #de) to tweets and allow client-side filtering by language.
   
• You might even go further: Have the client automagically find out the language of tweets and allow filtering. (For as long, as twitter does not introduce language as a first class citizen to their entity model.)
• Register a custom URL scheme (think tw://…) to allow other iPhone apps to invoke Tweetie and submit tweets. I’d love to see integration in e.g. Byline and other RSS readers that would allow direct tweet of links to articles of interest. 

Tweetie for the Mac

• Integrate the followers/following list into the native interface instead of launching the twitter.com website. If users run multiple twitter accounts, it currently gets confusing. You might have that on your list anyway but wanted to rush with releasing the initial version. That’s ok. Now simply fix it, please.
   
• Add an option to have the dock icon indicating activity and unread tweets (take a look at Adium and simply copy the implementation).

That’s it so far. I’ll keep expanding this list as more ideas will come to my mind. Feel free to add yours to the comments.