Several people have asked me what I am going to use instead of Google #Reader . I know what I definitely won't use - the majority of the alternatives out there, because they are obsessed with with showing items as rectangles with as much of the rectangle taken up with pictures as possible. (That is also why I gave up on G+ on Android.) My RSS feeds do not constitute a pretty magazine. For example look at http://feedly.com and notice how the screenshot of the mac is showing 6 articles - all that space for 6 articles! Pulse's home page has way more articles but all as images. 99% of my RSS articles have no images.
Reader has three important parts. One is the backend which means you can read from any number of computers and devices and a centralised location keeps track of your feeds and which articles have been read. There is no open standard protocol for this and I'm hoping that in the next few months one is born. (Reader was used by many but as far as I can tell the API was not official, arbitrary and reverse engineered.)
The second was updating the feeds (a background task). Having worked on consuming RSS feeds before, it turns out that many only have the most recent few articles which could turn out to be a few hours worth or at most a day. If you don't regularly poll the feeds then you will miss out on articles. This rules out pure clients like Liferea.
The final part is the presentation which worked well with a hierarchy of folders, feeds, articles and article, making it very easy to jump around hierarchy. UI that blends it all together into a single stream does not work (eg G+) because that only works with a low volume of articles. (I do not follow many people on G+ due to their posting volume. I would happily follow them via RSS feed but G+ doesn't export the data so I don't. Google loses by being a closed island.) So far only http://tt-rss.org shows that hierarchical context and navigation UI. Others like http://theoldreader.com/pages/tour seem obsessed with the whole social side, and note there is no screenshot showing the actual reading experience!
Oh, and the presentation part needs to work in disconnected mode on mobile too.
My plan is to punt for a few months hoping that someone comes up with the sweet spot of openness and readability. If not I'll just write my own. The database side of things can be solved in a home grown manner, but a toolkit like https://www.parse.com could be used instead to solve the data problem keeping web (Javascript) and mobile clients all synced up with state.
However I realised that it would be even easier to use +Dropbox as the state and synchronization mechanism. Each article becomes a file, and gets deleted by a reader when done. The poller just keeps adding the files from feeds. (Yes, that is the same principle as Maildir.) Dropbox released https://www.dropbox.com/developers/sync recently so that solves the offline mobile clients sync problem. I just wonder how well they will cope with hundreds of little files being created and deleted every hour.