Get the newsletter · Featured · Recent
Hi readers,
I'm on writing vacation for the rest of 2015, as I start my new role at Uber.
Please subscribe via email to get an update once I start back up. -A

PS. If you're interested in opportunities at Uber, drop me a note and I'll be in touch.

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.

PS. Get new updates/analysis on tech and startups

I write a high-quality, weekly newsletter covering what's happening in Silicon Valley, focused on startups, marketing, and mobile.