Devil’s Advocate: Why you shouldn’t be worried about App.net’s culture

After I wrote about App.net’s apparent culture problem today in this post, I read some more about it. Specifically, I went ahead and read the API Spec. Then, I came upon this article by Matthew Ingram on GigaOm that talked about how App.net is not really a twitter clone but a lot more than that. The article makes a pretty important point. So, going with the flow, here’s my two cents about how the article I wrote earlier might just be wrong –

When we look at App.net as common users, we see a stream of posts, a lot of apps that are being built on top of it and the customary box asking us our thoughts. That’s the face of the App.net Alpha as we see it right now. But let’s step back and look at what Dalton had promised us. Dalton talked about a realtime feed, a financially sustainable API and a viable solution to today’s ad-supported social network conundrum. But enough of the lengthy words. In essence, Dalton promised us a platform and an API. That’s it. Above and beyond that, he pretty much said, go, do whatever you want to.

So, as a developer, if I read about the problem of “who is building the culture” in the Alpha, I think, “Why are they even worried about the alpha?” The alpha is not the end goal. The alpha is not the product. The product is the ability to have a scalable, real-time feed without the need to raise rounds from VCs or to inject advertisements from promoters in order to maintain the servers needed to do this. Who pays for the servers? The users who want the feed.

Let’s look at it this way. The GigaOm article talks about how App.net wants to be a platform, not just an App. So, in essence, I could take the API and the platform and build my own social network on top of it. I don’t care what’s going on underneath. I have a scalable solution without the hassle of having to support apps that want to access my social feed. They simply access the App.net feed and ask for specifically my social network’s data based on the metadata the app provides. Think about Instagram. Right now, Instagram has it’s own network and it’s own APIs and it also allows users to cross-post to twitter. Why? Because twitter and facebook have more visibility. Instagram is just an app to those social networks but if someone want’s Instagram’s data to make an app, they have to come to Instagram and use their API. They can’t go to Facebook and say – “Hey, gimme all the Instagram posts this user made and also all the comments that his friends on Instagram AND Facebook made on that photo”. With App.net, this is about to change. I can make a social network like Instagram and essentially outsource the task of handling the API to App.net. Other apps that want to get my data go directly to App.net and use their massive infrastructure. I worry about the code, not the scale. This means I can have as many social networks on top of app.net, each with it’s own purpose, it’s own lingo, it’s own set of supporting apps and followers.

Now, coming to the issue of culture on App.net. Yes, there is a stream of data and yes, there will be issues such as reposts and the question that who will decide the standard. But once you’ve gone beyond that initial Alpha, you’ll realize that everything that builds on top of it can have it’s own standard, or it can follow the standard that the users are using the most. Instagram uses the ‘@’ symbol because so does Twitter and it is just easy for cross-posting. That means that when the time comes for social networks like Friendle to sprout, they will either be following the current App.net standards or just making their own. The end-user of that high-level social network never needs to come down to the App.net site to see their data in it’s original form, they just see the version that their social network shows them. Once again, one mustn’t confuse these social networks to be groups or pages built into App.net. They can be of varying functionality. One social network might be an image sharing service while another would be all about sharing your favorite links. They all will be bound by the same API but will be able to do so much more than what the underlying platform can, without sacrificing the underlying comment and re-posting system that App.net has built.

As an example, imagine an image sharing service. The 256 characters that App.net gives to each individual post can just be a link to where the original image is stored on the high-level social network’s servers, with all the supporting apps just getting that post from App.net and using it in a way as specified by the social network. Another social network, one which is used for link sharing, can simply have the link and tags as part of the 256 character post. Both these social networks get the benefit of the comments system and the amazingly robust API.

When you’re looking at App.net right now, you’re looking at that Alpha and thinking, “Well, here’s another Twitter Clone”. Wait for some time. You’ll see independent social networks that bear no or total resemblance to App.net sprout up, changing the face of the game and perhaps even obviating the need to ever visit the original site, all the while accessing their API. App.net should not be worried about their culture because it’s not a social network, it’s a platform to build other social networks.