The first thing you hear about is its ridiculous price. You have to pay $50 for a year’s membership in a social network that, as of the moment, has just 17,500 members, and is clearly attempting to topple Twitter, and possibly Facebook, from their perches. Absurd!
But what you need to know about App.net is that most of that, besides the cost and current member numbers, has little to do with the firm’s stated goals, and the cost and user base will change. The company wants to build a network of a reasonable size based on the notion that people who pay for a service can demand responsiveness, and that a modest paid network can provide a consistent and reliable base on which a software ecosystem can be built.
Let’s start with what App.net is before I get too far ahead of myself.
What Is App.net? -- App.net is Yet Another Social Media Startup Company. Too bad that doesn’t turn into a pronounceable abbreviation. But it has a twist. The company management comes from a background of building systems to support large numbers of regular users (not techies), such as. The firm spent over two years building picplz, a social photo-sharing service that had elements in common with Instagram, but never caught on. It was shut down in July 2012.
The code developed for picplz (and) has been repurposed for App.net, which isn’t a Facebook, Twitter, or Foursquare clone in that the system wasn’t designed and isn’t being developed to showcase advertisers and media. Rather, App.net says it will stick to the ugly plumbing, and charge users a subscription fee to cover costs. In short, App.net aims to offer pipes, not a media platform.
Architecturally, App.net most resembles Twitter in that the system is optimized around managing the sending of short messages (currently 256 characters) with various properties in those messages, as well as maintaining a user-defined set of relationships (the “social graph”). Third-party software, including Web apps, will be able to access messages through different means. That can include reading and posting client software, or tools that analyze streams of public messages.
App.net’s timing for launch of its alpha phase couldn’t be better, coming as it does on the heels of that essentially spells the slow end to existing third-party Twitter clients — and a blockage against new ones — that primarily offer features for reading and posting similar to that of the Web site and its own client software derived from Tweetie, purchased in 2010. Twitter also owns TweetDeck, bought in 2011.
Twitter was once more like what App.net aims to be, but has opted to shift into a media and broadcast model. In such a model, the most important goals are a high flow of traffic and a high number of users against which Twitter can sell targeted advertising. Advertisers are Twitter’s customers; users are the product that it sells. That may sound harsh, but it’s the literal truth. In that world, Twitter needs to control the entire experience of all its users to deliver ads and other messages the way it wants.
That explains the changes to Twitter’s API, since third-party software can’t be controlled sufficiently, and can easily be designed to display ads in a format other than the one that Twitter is offering to advertisers, suppress Twitter’s ads, or even replace them with other ads. Third parties also charge fees for their software, a revenue stream to which Twitter lacks access.
But once you move from the idea of creating an ad-driven platform to user-driven plumbing, you can easily throw out the idea that to succeed, App.net must acquire a vast user base quickly and become a “Twitter killer.” Despite Twitter’s 150 million registered users, studies show that most users rarely or never tweet and follow just a small number of people. Twitter, as befits a media company, has become a form of entertainment, with most users quietly following a few celebrities or other interesting people, so much so that it’s no longer unusual for celebrities to have several million followers.
Instead, try to wrap your mind around the potential of a messaging network in which most users will engage with one another and with other entities on the network regularly, because the network will have utility, whether for entertainment or business pursuits. Think amateur ham radio instead of commercial broadcast radio. Think participation instead of passivity.
If the most interactive users on Twitter, the ones who spend most of their time talking among their social set (as opposed to lurking or bloviating), left Twitter, the Twitter universe would likely hardly notice their absence. But it would represent an enormous amount of conversation on App.net.
To prevent itself from becoming a media company, App.net swears it will never build its own client software or sell advertising that it has to deliver to its users, and will exist entirely to move messages between paid users. It wants to be dumb, as I’ll explain next.
Dare To Be Dumb! -- App.net wants to be a dumb network (also called a stupid network), a concept I should explain first if you’re unfamiliar with it. (You can also read by David Isenberg, the coiner of the phrase “stupid network,” written in 1998, and still absolutely relevant.)
Whether you’re talking about physical networks like broadband systems, or logical networks (which move data over existing physical networks), such as Twitter, networks can be smart or dumb. Don’t read too much into those words — a network can easily be too smart for its own good, and networks have been getting dumber. For instance, the public switched telephone network (PSTN) is a smart network, and the Internet is a dumb network. The difference comes in how the network defines the messages that move across it, and how it manages the endpoints that send and receive those messages.
Smart networks are made up of both the plumbing that moves messages around and the endpoints where activity takes place. For the PSTN, the endpoints are telephone handsets; for Twitter, client software occupies the endpoints. In the past, when resources were significantly more limited, everything had to be purpose-built and tightly controlled, so smart networks were required.
For instance, until the 1990s, the PSTN had operated essentially unchanged for several decades. AT&T in the United States and PTT (postal, telegraph, and telephone) services in many countries owned and operated all the infrastructure in a monopoly model that was required because of the vast cost to build out the network, and the impracticality of having two or more competing physical wires entering a home to offer the same service.
Telecom firms wrote specs, built network components like switches, owned the telephone handsets, and dictated precisely what could be done with the wire that came into our houses. The only thing they didn’t control, at least in America, was what you could say over a telephone, as that would have provided too much liability. (Common-carrier exemptions protected them from what you did on the data side, in this case a voice conversation, and those sorts of exemptions persist into the Internet age.)
In essence, whenever a network was built for a single purpose, like the PSTN, it made sense for it to be a smart network, rather than an abstracted dumb network that could be put to many different uses. If that sounds like the Internet, you’re getting the picture — the Internet wasn’t designed for just email, for instance. Instead, the Internet was designed as a general-purpose dumb network where the smarts are at the endpoints — mainframes at first and now our personal computers. When you use Apple Mail to send and receive mail, it’s doing all the hard work of dealing with all the different parts of a message; all the Internet sees are packets of data that could contain anything.
Somewhat oddly, since this goes against the smart-to-dumb trend in networking systems, Twitter is transitioning from being a dumb network to a smart network. The reason is because smart networks often make more sense from a business standpoint. Twitter doesn’t want legions of outside software developers to come up with new uses for its network because it doesn’t derive any revenue from increased use — only from advertising sold against the eyeballs that read tweets. Twitter will tolerate independent Twitter clients for a while, but will eventually make them all obsolete in favor of its own clients, endpoints it can control completely.
Can Stupid Survive? -- How can App.net launch, grow, and survive in the face of a behemoth like Twitter? By attracting early adopters interested in alternative social networks in which they are not the product, and by bringing in developers who will create such interesting offerings that themselves attract new users to App.net.
App.net will charge subscribers and developers ($100 per year for the latter, just like Apple), build the necessary server and network infrastructure, and maintain an API (application programming interface) to give developers access. As long as developers are well-behaved citizens (a definition that I’m sure will generate an enormous amount of debate), they can build whatever they want on App.net’s infrastructure and keep the proceeds of what they sell. Because software that uses App.net requires members to pay subscription fees, both App.net and developers benefit from recruiting subscribers.
While App.net currently charges members $50 a year in this early phase, I spoke to Dalton Caldwell, the company’s head, and he made it clear that the current rate isn’t written in stone. That number is meant both to discourage too many people signing up all at once, and to be a conservative starting point to cover estimated costs for scaling up. Caldwell is using price sensitivity to prevent a rush to sign up all at once, which could destroy the immature system through overuse.
The subscription price can come down as the network scales, and I wouldn’t be surprised to see it drop to $15 to $25 per year. Developers could conceivably be offered wholesale pricing and sign up subscribers directly as part of the cost of their software, or pay for users’ subscriptions by displaying ads in the software.
App.net also isn’t restricting itself to being just like Twitter in terms of features. There’s a lot of room to grow, including messages longer than 256 characters and more interesting relationships among those messages. Feedback from paying users and early developers will certainly shape the kind of features App.net offers as well. Here are a few early ideas for systems that could use App.net’s infrastructure:
Build a private text-messaging system like iMessage that uses standard Jabber (XMPP) protocols to create a gateway to work with the Messages app and other chat systems.
Provide a kind of spam-free verified short email system among one’s social graph through email plug-ins that would show incoming messages and allow messages to be interleaved with regular email.
Offer RSS feeds of all the URLs noted by those you follow, those who follow you, public lists, and other groups.
Provide ebook annotation, in which notes could be added to books and automatically synced using EPUB and PDF software that relied on App.net for social relationships, message storage, and message notification.
For computer-to-computer interaction, offer an alternative to HTTP, proprietary software, or email. Lightweight “listening” modules and libraries could use App.net as the backbone for sending automated messages, keeping them persistent for later review, queuing them in the event of network or server outages on the ends, and notifying humans of problems or status.
These are just a few ideas that have occurred to me, and we’ll see hundreds more. In the first few days after App.net released its API and then provided access to developers, dozens of desktop, mobile, and Web apps appeared in testing form. wasn’t even set up by App.net; it was self-organized by developers.
Developers may be wary of the effort in supporting a new and unproven system, but they appreciate the predictability of controlling most of their own destiny. This is where App.net will differentiate itself from both Twitter and — if you extend your thinking a bit — Apple’s iOS App Store. iOS is a combination of dumb and smart networks. Apple claims it allows nearly all endpoint uses (in the form of apps), but becomes “smart” whenever it denies perfectly valid software for reasons that range from the competitive to the capricious.
Making Spam Too Expensive to Send -- One of the most consistent complaints I hear (and want to make myself) about Twitter is the persistence of spam, which takes the form of @messages directed at you from people you don’t know, each one generally including just a single short URL. Click one of those URLs, and you’ll be presented with some sort of scam offer. (Facebook, which requires you add people to your social circle, doesn’t have this particular problem.)
Twitter has many protections in place to prevent spammers from registering, but they clearly don’t stop enough of the fake accounts that spammers use to make the reading experience unpleasant.
App.net may be less vulnerable to such spam because of its membership fee. True, spammers often use fraudulently obtained credit card numbers for purposes like this. But once they use a particular credit card number, the clock starts ticking on eventual discovery. At $50, the threshold charge is high enough that it will trigger some credit card companies’ higher-level fraud monitoring. And it seems unlikely that App.net will allow the same card to be used to register many accounts at once, or that such behavior would elude credit-card fraud protection. I also just don’t see spammers “burning” a card for a $50 charge in order to send out spam that has a extremely low yield.
In addition, it’s possible that App.net’s user base will be more sophisticated than the average Twitter user, and will thus be less likely to fall for spam and more likely to report it. And App.net may set the spam reporting threshold far lower than Twitter under the assumption that those reporting spam are less likely to abuse the option because they are fully traceable and accountable through a credit-card backed identity. That should prevent harassment.
Pipe Dream or Alternate Universe -- App.net doesn’t need to get everyone to move away from Twitter. It only needs to get everyone you know to move. I’m being facetious, but it’s true. If you have even a relatively large group of people with whom you interact on Twitter, and they start turning their attention to App.net interaction, you may find yourself there as well. For now, I run Twitter and App.net clients side by side, since App.net is still in alpha, and only a small number of people I know are early adopters like myself.
Because the most active Twitter users are also the most likely to be persnickety enough to not want to use the Twitter-brand client software or Web app, it’s more like that they (or we, I should say) would drift to test out a service that lets us use whatever client we want. Heck, I could even program my own, if I so chose and paid the extra yearly developer fee. And my head is already swimming with possible uses of App.net’s infrastructure for interactions that go beyond trading of short text messages back and forth.
No, the measure of App.net’s success won’t be the death of Twitter. Rather, it will be providing a reason for enough people to use an alternative in which the pipes are dumb and the software is as smart as hell.