I should have seen the writing on the wall. Back in February 2008, when I first joined Twitter (admittedly, slightly late to the game), I was excited about the service. Its premise was intriguing, and it completely sucked me in. Twitter was a simple concept: micro-blogging in the guise of pithy 140-character posts.
Compared to Facebook, or if I go back further, MySpace, Twitter was more interesting and fun to use. Twitter eschewed most of what other social-networking services considered features in favour of its dead-simple concept. While I enjoyed using Facebook back then, and still do, Twitter was bereft of advertisements, copious images, videos, and animated gifs. Moreover, I jumped on board before the trending-topics days. It was a better experience by far.
In its infancy, when Twitter’s userbase started to explode, third-party app developers flocked to the service. With a reasonable API to hook into, developers were champing at the bit to make innovative apps like Loren Brichter’s Tweetie for iOS, and then later, of course, its Mac cousin. Geeks heralded the arrival of Brichter’s native iOS and Mac apps. It’s not that Twitter itself was a poor experience pre-Tweetie days — it was a matter of executing on a brilliant user interface and user experience that absolutely set the gold standard for years to come. In 2009, Tweetie deservedly won an Apple Design Award. During that time, Tweetie and The Iconfactory’s Twitterrific were the main two excellent choices for third-party Twitter clients. (Later on, this would become a saturated marketplace.) Back then, third-party clients didn’t just bring the web experience to iOS, they added to and enhanced the service in numerous ways. Polished third-party clients had cemented themselves as the premier Twitter experience on iOS.
What we find now as commonplace, the infamous “retweet,” was a convention that came from the userbase. Retweeting started picking up steam as a method of reposting someone else’s content to your own followers. The merits of retweeting were well-meaning, but because they weren’t initially part of the API, third-party apps started implementing it differently. Twitter took notice in 2009 and later decided to implement their own version. They went on to expose their implementation in the API for third-party developers soon after.
When you build a company from day one without a clear business model, you’re destined for two likely outcomes:
- By leaving your service free and open to anyone who wants to sign up, you foster massive growth, but eventually have to find some way of making money. This usually means advertisements.
- You take venture capital and/or potentially get acquired, which may then force you to shut down that much-beloved service that you worked so hard to grow.
Twitter clearly went the route of advertisements, which they colloquially call “Promoted Tweets.” Promoted Tweets currently will show in your timeline if you use the web app, or Twitter’s official iOS or Android clients. Although the company won’t disclose how much revenue they’re bringing in from Promoted Tweets, profitability can be inferred from publicly available information.
At the moment, people who are using third-party clients do not see Promoted Tweets, potentially leaving money on the table that Twitter can’t collect. This of course is something that is being debated frequently by not only end users, but by many developers who bring in a healthy income from the sales of their Twitter clients. I completely agree with the uproar happening right now among the developer community. Each iron-fisted decision Twitter makes to further restrict their API only stands to instigate fervour in the eyes of their development community.
Today, they aren’t shoving Promoted Tweets down our throats in third-party apps, but doesn’t that seem inevitable? Certainly, Twitter has the right to take control of what they feel should be the ideal experience in their eyes. Given the direction in which they have taken their business, they have no choice but to exert more control over their APIs. Since the launch of the service, Twitter has deprecated consuming Tweets via RSS, and recently they cut off services like Tumblr and Instagram from being able to find people you follow. The notion that Twitter needs to control how people access and use the service seems reasonable on the surface, but I doubt that preventing existing customers from being able to find people they follow on third-party services like Tumblr somehow devalues the service. All of these changes greatly trouble me, and I can’t help but feel saddened by each incomprehensible blog post of theirs I read.
Creating a platform that enables millions of people all over the world to communicate and disseminate information is inarguably valuable. Without Twitter, I can firmly say I would not have the opportunity to converse with many like-minded souls who I may otherwise never meet in person. Tools such as these need to exist, but I am concerned that the experience may degrade over time with the direction Twitter seems to be taking the service.
From day one, I should have taken into account that Twitter had zero interest in building a platform that didn’t lock in your data. In addition to data lock-in, Twitter also never gave people an option to pay and help support the service. I realize that the majority of people would never pay for a service like this, but even if a small enough percentage of its userbase were willing to pay (let’s say 2% to be conservative), they could have a profitable enough business to avoid ruining the experience by including advertisements in peoples’ timelines.
Some may argue that a service like App.net is a direct competitor to Twitter. After all, its very idea was sparked by and virtually copied from Twitter. Given that, I posit that App.net isn’t intending to be a direct competitor to Twitter — in fact, I would say it’s trying to stand on its own as something else.
Let’s put aside feature comparisons to Twitter for a few moments. After closely following Dalton Caldwell’s blog posts, and his general philosophy and goals for the project, I think what he’s trying to build is what I initially always craved from a social networking service: a platform to communicate that would respect its users and development community. By building in a monetizing strategy from the start, App.net can slowly build its userbase while generating an income to pay for staff, expenses, and the continued development of the product. Call me old-fashioned, but I remember a day when you had to exchange money for a service you valued.
App.net is still in its very early days. The service is still missing some important features, and I’m sure there are many things that have not even been defined yet. But one of the most positive discoveries I made when joining was learning that they offer a data-export option. Unlike Twitter, where you are limited to retrieving your last 3500 Tweets, App.net has decided to give users a way to fully export their data in case they want to leave the service or just keep an archived copy.
I remain cautiously optimistic for App.net. I believe they have a great team with an incredibly smart founder. They seem to have a clear vision in terms of what they want to achieve from the product, even though some of the details may seem fuzzy right now.
Thus far, we’ve seen some preliminary promises made by Dalton Caldwell regarding what they plan on committing to. Caldwell states:
I am publicly stating that, if backing is successful, App.net will support the following things:
- Activitystrea.ms Atom & JSON feeds, as well as RSS feeds, of public posts for individual users, hashtags, etc. (Note that this is different from making them the foundation of our read/write API, which we have decided not to do)
- Pubsubhubbub (PuSH) support (as a publisher, initially)
- Exposing user identities with Webfinger
- Commitment to coordinate between internal and external parties to create and support open-source “lightweight” clients in as many flavours as we can, a la Stripe
- Commit to enabling and supporting users in building inbound and outbound syndication to and from App.net
A cynical interpretation would be that anyone can make promises, but executing and delivering on those promises is what matters. I have an optimistic take: Dalton is a smart guy. He doesn’t strike me as someone who would make such clear and bold promises without committing to them. The potential PR nightmare that would ensue if App.net didn’t deliver on any of these items would be catastrophic. Considering the current state of App.net’s alpha product, I imagine we’ll see a ton of iteration over a very short time period of, say, 6–12 months.
Most companies tend to provide confusing “terms of service” and “privacy policies” that are full of legalese that most people won’t understand (or even want to read). Have a look and read App.net’s terms of service and privacy policy — you will find that they are not only clear and easy to understand, but they are living documents subject to user feedback. Caldwell is interested in making sure users of the service have actual input on these documents. I can’t recall any other company doing this.
Twitter may seem far too big to fail anytime soon. I plan on continuing to use my accounts there, although I’m going to place my time and attention to using and providing feedback to help improve App.net. There is an ever-growing list of web and native third-party apps, and it keeps improving weekly. In App.net’s development community, I see unbridled enthusiasm like I haven’t seen in years.
Since App.net currently charges $36 per year for a user account, I don’t think anyone expects the service to grow anywhere near the size of Twitter. The barrier to entry for the average person, after all, is the price tag associated with membership. But I don’t believe that they need to grow to the monolithic size of Twitter — perhaps the service would remain more interesting with a much smaller, tight-knit group of people.
With a strong team and a leader who has a clear focus on building a service that we want to use, App.net will probably grow strongly over the coming months. I don’t know if they have had any internal discussion over what their mobile app strategy will be — I’m not entirely sure that producing their own apps would be a good use of their resources. I’d rather see them provide clear guidelines on how interacting with the service should work via their APIs, and let great third-party developers bring beautiful apps to the table. Remember, before Twitter became heavy handed with their policies and tactics, it was the developer community that brought innovation in the client space. I’d love to see the same thing happen to App.net.
You can find me on App.net as @zero.