App.net: the smell of inevitability
After nearly 3 years as a zombie company - the lights were on but no one was home - App.net finally shut down last week. I don't mean to be negative but can't help feel that it was always destined to fail.
After recording a microcast episode about Twitter's identity crisis it's ironic that the service often referred to as "what Twitter should have been" suffered a similar existential problem.
But what was it?
App.net began life as "a paid service for mobile application developers" allowing them access to tools and to showcase their work.
As mentioned before, what most knew it as began in response to a growing frustration with Twitter and how it treated those looking to build applications using its API.
This new incarnation was intended as a "financially sustainable realtime feed API & service" - a standardised, open, backbone for the social web and beyond.
Its open API meant anyone could build an application and, subject to permission, exchange data with any other app due to the shared infrastructure.
Being a pivot from App.net's original purpose, combined with the backlash against Twitter, it was always more attractive to developers and this was really the point: App.net itself was never a consumer product; the apps built on top of the API and backbone would be the consumer facing aspect.
Mistakes
Some have argued in the past that the service's mistake was in the name being too similar to Microsoft's .NET framework leading to confusion and a lack of discovery.
Not so.
App.net's biggest failing was in its approach at launch (or, rather, at pivot) but there was almost no choice.
Most people, even many that used it, viewed the example application, Alpha, as App.net despite founder Dalton Caldwell emphasising it was just a proof of concept. The name Alpha was almost never used.
I say there was almost no choice at launch because they had to demonstrate the service and APIs in action. The best way to do this was with something familiar. When you also consider the reason for App.net's very existence it was inevitable that Alpha would be synonymous with App.net.
It became seen as a paid "Twitter clone" but you weren't paying to use Alpha the social network. Users were actually paying for a personal cloud, the only place you would ever need to hold your data and to which you would give applications access.
True data portability!
Developers were also paying for access to the API.
Later we got a free account tier allowing you to follow up to 40 people and store 500MB of data but then it was already too late.
Trapped
App.net was not Alpha was not App.net but people could never separate the two.
Rather than designing new experiences for posting, using and sharing social data developers immediately went back to doing what they knew best: creating third party Twitter - sorry - Alpha clients with minimally varying functionality.
Where were the new innovative services and uses of the social backbone that developers had been begging Twitter to let them build?
Launching Alpha as the proof of concept application immediately, and irrevocably, trapped both users and developers alike in a Twitter mindset. A mindset from which they would never escape.
While other apps (photo and video sharing tools, a chat client built upon direct message functionality, and others) may have demonstrated that data was truly "cross-app" and could be easily shared they all still rode on the back of, and were designed to share to, Alpha.
But how else could the capabilities of the service and API be shown off?
Writing on the wall
You can't help but feel that no matter what demonstration was given it would be seen as the default App.net position and everything else built for it or on top of it.
Without original, innovative applications the smell of inevitability sadly pervaded the experiment from its inception.
It was only ever a matter of time.
