I supported App.net with $50/year, here’s why

I recently supported App.net in their Kickstarter-like project, and I wanted to elaborate on what I hope it turns into. Here’s the link if you want to learn more: https://join.app.net/

App.net isn’t just a better Twitter
App.net is being incorrectly perceived as “Twitter with less restrictive APIs.” While the consumer application is obviously more relatable, as I imagine it, App.net has the potential to be something more fundamental, like the web (HTTP) or email (SMTP).

(Note that I don’t actually know what it’s going to be, I’m just writing about what I hope it will be!)

The idea that attracts me is that App.net could be a completely open backbone for feeds, from which anyone can publish or consume – this is a big transformative thing, because it turns feeds from something that companies own and manage as closed environments and turns them into an open protocol.

The big question becomes:
Today, feeds are owned by companies, but what if they don’t have to be?

AOL vs the web as an example
Back in the day, you ran AOL software, dialed into AOL-owned modems, and accessed a closed ecosystem of AOL-created content. This is obviously extremely closed.

Eventually, AOL opened up with keywords, so that if you were a publisher, you can work with AOL to set up a property within AOL. This is more open, but still not all the way. (Today, feeds are sort of at this stage)

Contrast that to the open web, where you could pick any number of browsers, any number of ISPs, and browse anything you wanted hosted anywhere in the world. Ultimately, this model would subsume and exceed AOL. See how that’s different?

Closed feeds
Though the feeds that social companies own and operate have been opened up (sorta) but it’s still like the AOL keywords stage. You use Twitter-owned clients to access the Twitter stream. If you want to post content to the Twitter stream, then you need to integrate with a Twitter API. If you want to post to the Facebook stream, then you need to integrate another API.

And so on and so forth with every new feed that emerges – be it Pinterest, Tumblr, Zynga, Instagram, etc.

Here’s how an open backbone for feeds might work:
Imagine a world in which all applications publish and consume off a global feed, and just ask for a filter of this global feed to do everything.

To build a feed within your app, you’d publish every action that any of your users do within your product, and then you ask App.net for the subset of the global feed that was published with your application.
To build an API to let other apps publish on your feed, you don’t have to create your own API. Instead, you would just configure your app’s filter of the global feed to show posts from other applications, and voila, they would show up.
To post to other feeds, you would just write into the global feed, and then ask the other apps to allow posts of your type into their feeds.
To build a reader client for any other app or collection of apps, you would just filter the global feed based on posts from those apps.

Etc, etc.

Integrate once into the feed. Then post, read, like, and comment, from anywhere.

What’s the initial app?
The big question for all of this is, wow maybe this is a big crazy vision, but where do you start?

There’s a lot of places you might go, but I think the very first thing you could do is to make it easier for any developer to build a feed in their web or mobile app. In fact, I would really focus on mobile apps to start, since the developers like to work on Objective C but not the backend, so there’s a clear value prop there.

I’d go to mobile developers and say something like- “Hey, you like to work in ObjC but to build a nice feed, you need a lot of backend stuff. We’ll take care of it for you.” Under this model, you’d let the mobile dev send you all the activity that is happening inside the app, and then when they request a feed, you give them back a nice personalized version. Show that it helps with engagement, and make it easy to integrate.

Next, build out the global feed, consisting of all the app developers on App.net initially. Make it easy for them to work with each other, and to carry each others’ content, if they choose. Make this integration very standardized, to the point where you just go into a configuration page and you say, “yes, I would like to give permission for this other app’s content to show up in my feed.”

Once you have the components in place- both a “Feed as a service” and a “Feed API as a service” then you have at least the two big technology components for them to work. If you get adoption here, then off you go.

On the other hand, if App.net starts out putting everyone’s feeds all in one big bucket, I think the value prop is more ideological than something that solves a real problem (building feeds) for developers. For that reason, even while you had an ideological vision, I would think about starting with a very concrete “make it easier to build feeds” product.

Yes, this sounds crazy hard
It’s obvious that this will all very extraordinarily hard, and there’s a big chance of failure if you don’t get a critical mass of developers or consumers on board.

Yet it’s such a big vision that it’s worth my $50/year pledge to support it. I hope you see the vision too.

Like this post?
Get new updates via newsletter..

http://www.jonmyers.com/ Jon Myers

The messaging didn’t draw me in “real-time feed platform” – it says nothing about what it is, and communicates no benefit, thus I didn’t dig in.

Maybe I’ll have a deeper look.
http://twitter.com/Tinusg Tinus

It just says that it’s a realtime feed API & service. That’s enough for me. Pubsubhubbub is just not it, Twitter is not it, maybe this is.
http://www.windley.com Phil Windley

Andrew, I enjoyed your vision of App.net. Clearly App.net needs to be a protocol more than a place to achieve what you’re talking about.

I want to see the real-time API supporting more than just feeds for apps, however, I want it to support me subscribing to my Withings scale, my thermostat, my car, and so on with the ability to have custom apps running against the data. I want the data under my control in some place.

I’ve been writing about some of that here: http://www.windley.com/liveweb. I’d love your feedback.
http://andrewchenblog.com Andrew Chen

Hi Phil, thanks for the message. I think they can build something that is closer to a protocol, but then be the first to build the hosting platform for it. Think of it as inventing Git and Github at the same time. (This thinking is inspired by something Dalton wrote about app.net earlier)
http://andrewchenblog.com Andrew Chen

Yeah, I think the messaging is more strategic in nature right now, rather than the consumerized value prop-led version. They’ll have to work on that, but I think the vision is compelling.
http://digicraft.com/ daveevans

I’d rather see email fixed. App.net is a addressing a fascinating problem that reminds me of early discussions about RSS feeds and blog readers. Today, most of what they want to do is in Facebook. There are also tons of API aggregators and front-ends and clients of all kinds. Not sure what they are doing here. Plenty to discuss and argue about though, which in itself is a good thing.

Why not just do a $2 billion kickstarter, we all buy Twitter, and open-source it all and make it P2P or whatever to get rid of the middleman (Twitter infrastructure, which is huge and complex).
http://www.lylemckeany.com/ Lyle McKeany

It seems that Dalton’s original vision for app.net came from an ideological point of view due to his frustration with the direction that Twitter decided to head in (ads vs. API). I share your same sentiment, in that I hope there’s more to it than ideology and I look forward to seeing what he and his team come up with.
http://andrewchenblog.com Andrew Chen

Re: ideological POV, totally agree. I think that’s why people are having some trouble grasping, WTF is this product? I tried to put down a few ideas of what a v1 could be, but it’s also cool to start with the big vision and boil that down into an initial product as well.
http://andrewchenblog.com Andrew Chen

The thing with email is that I’m not sure it’s going to be the communication medium of the future- it feels like the younger generation is moving away from it and going straight to texting and short form messaging, first and foremost.

I think the big opportunity here is- should ever new product from this point out build its own feed? And build its own API to all do the same stuff, posting and reading from feeds? Or can we eventually get to a place where this new broadcasting medium can talk each other?
http://twitter.com/JamesTFletcher James T Fletcher

I think some of the comments below are correct, the way they got press was by calling it ‘a new twitter’ confusing all of us, or not attracting us enough to look into it. If they can crack the mobile piece then I’m in.
http://digicraft.com/ daveevans

Yes the writing is on the wall re: kids texting more. The only thing interesting about that besides carriers losing money from texting apps, iOS, Facebook messaging, etc., is when you consider the cultural impact of kids texting and dumbing down communication until we’re digitally grunting at each other.

A protocol is not a business. Making money off them is (see the many companies aggregating API-scoured data and wrapping value around the datasets).

Facebook is basically doing all of this already and using API’s to connect to twitter/pinterest/etc. They pull in the data and monetize tweets for example, in ways that Twitter will never be able to.

Would be nice if there was a common API for social services. Reminds me of the conversations around RSS back in the day when it came to feed readers. Depends on what its used for (consumer-facing stuff vs. developers building services around them.)

Why don’t we all do a kickstarter to buy Twitter and just open-source it all and throw it in the cloud? ;-)
http://andrewchenblog.com Andrew Chen

Yeah, the “new twitter” positioning is confusing.
http://andrewchenblog.com Andrew Chen

The analogy that Dalton’s used is that you can have a decentralized/free standard coupled with a centralized biz around that too. Think Git/Github, Linux/Redhat, Hadoop/Cloudera. You can have an open feed standard combined with a central service that does the heavy lifting in terms of productization.
http://twitter.com/acrookston Andrew Crookston

On one hand I like that they are refusing to go down the ad-supported road but I also have a hard time seeing them reaching critical mass in growth for a big vision like this? Twitter already has a hard time converting the broader mass of people (especially younger people not interested in reading “news”).
Do you have any thoughts/tips as to how app.net will succeed with their growth and not end up becoming another tech-crowd niece product? I have a hard time seeing the broader mass paying $50/y for a realtime feed platform.
http://twitter.com/RishiKhullar Rishi Khullar

I love the concept of charging users vs. an ad-based model, but I can’t relate to the outrage directed at Twitter ads. I never wake up in the morning and say, damn – these Twitter ads are totally ruining my experience. They are so unobtrusive to me. I wonder if I’m a minority in this.
http://www.facebook.com/andrewhchen Andrew Chen

I think there’s a lot more at stake than ads or no ads. As I write above in my article, the real issue is around whether or not the next generation of computing will be defined by a few companies (Twitter, Facebook) who control closed ecosystems. You’ll be forced to use their proprietary clients to access their proprietary feeds, and 3rd party apps that talk to these feeds can be able to be arbitrarily shut down.

“What’s the big deal?” you ask. “I like Twitter how it is!”

Yes, and back in 1994 there were people who preferred the AOL experience and preferred to work with one company where you dialed into AOL modems, used AOL clients to access AOL content. And I’m glad that instead of an AOL controlled ecosystem, instead we got the open internet.

I think the next generation of the web has already been defined by feeds, and I hope we end up with an open feed platform rather than one controlled by AOL and Prodigy. Er, Facebook and Twitter, I mean.
http://mortenblaabjerg.net/ Morten Blaabjerg

I think this misses the point. They don’t need to. What one presumably will pay for and be part of the app.net package/deal is that you get to decide where you’ll syndicate your feeds. You can make your stuff go where your “friends” are – you don’t need them all to sign up to app.net for you to do that. And better, you won’t have to rely on third-party apps relying on big proprietary companies such as FB and Twitter to do it. You can even write your own or hire someone to do it for you.
http://twitter.com/vickks Vivek Nanda

I’ve not really invested in it, but for the simple reason that it is of no use to me at the moment, but as an idea I liked it and I hope they get what it takes to get started… At the moment they need $12,000 in next 39 hours..
http://andrewchenblog.com Andrew Chen

And now they’re done.
http://www.facebook.com/TecnoLord Paul Fijma

i donated 50$ and i don’t twitter. so i really don’t know why i did it … maybe i just like the vision and i really don’t like ads.
Black Kettle

I came to your blog post from the Twitter feed over on the App.net homepage. Since I’m a big fan of not selling my identity/lifestyle to closed proprietary ecosystems, as we are calling them, I had to register a new fake account with Disqus, confirm my fake Mailinator email address, and choose a fake Disqus username before being able to post my comment, which took over 5 minutes. A bit interesting, considering the topic at hand!

Moving forward, you make a good example with AOL vs the open internet. However, the open internet is a collection of clients, servers, and open protocols that all these clients and servers around the world understand. If App.net is the feed version of HTTP or SMTP, let’s call it APPP for kicks, then your vision is hoping that all the current clients and servers of the world will one day understand a sort of open source APPP protocol.

But isn’t this really a poor analogy, as App.net is in fact proposing a centralized company running an open API/infrastructure for clients and servers to plugin in to at will via HTTP or whatever other existing protocol? Wouldn’t App.net in fact be more like Auttomatic, the centralized private company that maintains open sourced WordPress software and infrastructure? At the end of the day, its a centralized company calling the shots in both the App.net and Automattic examples, no matter how open sourced or developer friendly they might aim to be.

The root point that needs to be made is that nothing is possible in the world of electronic communication without standards. And standards are developed by powerful groups – either well-connected and funded private companies or government researchers, or sometimes a combination of both (i.e. HTTP, Blu-Ray discs, SD cards, USB, 3G, etc).

Going back to HTTP as a protocol “standard” example – the US government has always been involved in its development from the beginning, and it is still today maintained by the IETF, a group of volunteers funded in part by VeriSign (company) and the NSA (US government). Obviously, these types of sponsors always have strategic interests. This is the nature of humans, and especially powerful groups of humans, whether governments or private companies. As long as standards serve a purposes that is in high demand, and remain open minded to changes while having dialogues with all parties that demand to be heard, they can remain the standard of choice and continue to evolve.

But even HTTP 2.0 is getting serious heat from Google, who has already put tons of money into a new competing standard called SPDY, athough technically its compatible with HTTP at the moment. But will it always be? Will the IETF evolve fast enough for mega-corporates like Google to be satisfied? Will all of Google’s future services and products be satisfied by the standards and limitations put forth within the HTTP X.X protocol? Hell no.

If in fact we are serious about a new protocol where the world’s clients and servers, the true basic infrastructure of electronic communication, can communication regarding feeds and realtime, wouldn’t it require the cooperation not just of App.net’s team of elite hackers and supporters, but also probably certain elements of the US government and/or huge corporations that control much of the world’s physical clients and servers? Would Samsung, or Apple, or Sony, support this new protocol? What about SaaS companies? And why would the current giants like Twitter, Facebook, or Google have even reason to freeze their billion-dollar development programs in support of an open source feed protocol/API/whatever we are calling this?

Even if a few giants got on board with this based purely on usability reasons, along with tons of elite developers, would all the investment bankers and boards of directors of the world accept it?

Just like Automattic provides a free and genius alternative, WordPress, to the other website platforms out there, its just that – an alternative. Its growing quickly for good reason. But Bank of America will never in a million years build its website on WordPress, or tap into an open source App.net feed system, for the good of the developer community or in support of a more universal user experience.

App.net may be something of a PHP language, or a WordPress, or whatever – free, open source, and invaluable to people or organizations without the time, resources, or concerns needed to warrant an investment in proprietary “closed ecosystems” etc. But there will always be the ASP languages of the world, or the limited Twitter.com APIs of the world.

I don’t believe App.net or copy cats are really a protocol or a standard of the future. They will hopefully create something awesome that empowers cash-strapped startups or companies concerned with usability, but frankly, this may just go the way of OpenID or… Disqus.

Cheers and best of luck to their vision – and for what’s its worth, I don’t know shit about programming.
http://www.facebook.com/eric.alterman Eric Alterman

At Flow we’ve spent the last 2 years building a platform that answers the question, how can developers build streams that share any flavor of real-time data?

To accomplish this our platform had to enable developers to build and share real-time streams, each stream with its own data structure and read/write/modify permission settings. Because different applications need the same data aggregated and organized in different ways, we needed an underlying stream processing capability to make that possible.

In short, sharing real-time data is a multifaceted technology challenge once you move beyond sharing a simple social stream. It’s a many-to-many kind of data sharing problem (i.e. many apps sharing real-time data with many apps), not one-to-many (i.e. many apps sharing data with Facebook or Twitter).

Building the Flow platform was challenging and exciting, but as Andrew points out, what’s the initial app? When lots of apps are sharing every sort of data it’s easy to visualize a sea-change in the way we do business—we call it a “real-time data exchange”, analogous to a stock exchange. But how does it all start?

Our choice was to launch an application at Flow.net that allows enterprise customers to connect their employees, customers and applications in a way that’s just not possible with traditional social enterprise. It’s all about sharing data contextually, not just socially.

But there were many possible starting points for Flow. App.net has a similar data-sharing mission and therefore must ask similar questions.

@andrewchen