I don't really want a reader, I want a service that syncs state accross readers, and aggregates my feeds into one feed for easy downloads by devices.
Google reader was perfect for that, and it was only on occasion that I used their web interface. Most of the time I was on my iPad/iPhone/Android (using Reeder/Byline/Flipboard and the official android client)
That's one part, but it doesn't solve the central state control. Perhaps someone could extract the Google reader API and turn it into a standard for other products to implement?
By rename feeds do you mean the title? For example, Craig Mod's feed (https://feedreader.co/feeds/http://craigmod.com/rss/) has a rather ungainly title ("...considering the future of ...") which would make sense to rename.
It seems like the obvious thing to do is to create a standard, perhaps based on however Reader currently syncs, and then build against it. That way, people like me who aren't interested in e.g. "social" features or "sharing" could implement a simple backend, point our preferred clients at it, and call it a day. Let the client developers war it out over front-end features, and let clever people like the Newsblur fellow add cool new backend stuff.
The death of Google Reader might actually be a good thing, in the long run.
Google giving away their product for free effectively prevented a working market - nobody could make money selling a feed-aggregator.
With Google out of the way, there will hopefully be money sloshing around, and users who now realise how much they want this kind of service (and are prepared to pay for it).
But how much were these services really offering? It is one thing to attempt to charge for a superior service, but for the most basic of services? That's a whole different story.
IMHO, feed reading should be integrated into the browser as a tab, not in the hands of commercial interests. But that's an aside.
>IMHO, feed reading should be integrated into the browser as a tab, not in the hands of commercial interests.
This is a really interesting idea. Has there been any talk in Chrome development about building a browser-side RSS reader? Google would still get all the information they get from Reader now but they'd be making the 'feature' exclusive to their browser. This coming not long after Apple removed their feed managing ability in the web browser, meaning they could get a load of Chrome converts on OS X just from that.
It'd be really interesting to see what happened if browser-side RSS became "the thing" again. Although, as julien pointed out, doing it browser-side doesn't necessarily mean your RSS isn't in the hands of a commercial interest.
It is foregone conclusion that G+ will add the subscriptions in some manner?
Agree Reader exit still creates a nice niche for others to fill since even if G+ is the goal not all folks will go G+ if there are more focused alternatives.
It's not a GUI app or web-based, which are both plusses to me. It's also neither closed-source, nor spyware (like way too many web-based readers are).
Newsbeuter is relatively feature rich and has a decent enough interface. I'm pretty happy with it, and prefer it to the closest Linux terminal RSS reader competitor that I've found, Snownews.[2]
The main problems with it is that when feeds get large (1000+ articles), reading that feed gets to be pretty slow. This is a long-standing performance bug that has not been fixed in years. But, apart from that, if you're reading feeds with a reasonable number of article in them, it's great.
I used to use Newsbeuter. The deal breaker for me was the inability to hook it up to a daemon on an external server. I wound up replacing it with rss2email instead. Now I read both my email and my news in mutt! :)
No one mentioned Gregarius yet : https://sourceforge.net/projects/gregarius/ : it is a fine self-hosted web-based alternative to Google Reader. There has been no project activity lately but the software works just fine, I have been using it since 2006 - just keep it private for security's sake. It scales well with a lot of feeds.
I think the developers of a couple of the biggest RSS readers should get together and decide on a standard file format to store "metadata" such as read items, starred items, etc.
This file could be stored on a server or in a user's Dropbox folder. It would allow users to pick an RSS reader freely (per platform), without losing and rebuilding all their data. It also keeps all this metadata in sync, one less worry for the developers.
What's in it for them, though? I'm guessing that most of the developers want you to use their reader and I'm not sure there's an advantage (for them) in adding code that makes it easier for you to switch to another product.
Don't get me wrong. I totally agree w/ you and wish that switching is easier. That "cost of switching", though, is the primary reason I'm still using the reader that I am (and have been for years).
A rising tide lifts all boats. If something is developed that makes the entire ecosystem more attractive, then everybody benefits.
I'm guessing that most of the developers want you to use their reader and I'm not sure there's an advantage (for them) in adding code that makes it easier for you to switch to another product.
Sure there is... because I'm more likely to try your product in the first place if I know I'm not locked into it. "The best way to capture users is to make it easy for them to leave" and all that.
That's a good point and likely the reason this won't ever happen. The upside for app developers is that they won't have to run their own servers or rely on a commercial third party to keep state in sync.
I also make heavy use of yahoo pipes to munge together a few rss feeds and do other regex'y type things to a feeds: http://pipes.yahoo.com (pls yahoo, never kill pipes!)
The reason I like rnews is the boxed layout (where each feed is seperated), rather than every other rss reader which jams everything into a single feed. With the boxed way I have the feeds I read daily up top and then progressively have boxes for sites which I only skim headlines for every week down lower.
I have a side question which I've been meaning to float on HN for some time: is there anything cool I could do with the fact that my self hosted rss aggregator receives roughly 2,000 hits a day from search bots? I mean I get scraped constantly all day, from ALL engines.
Sigh, I actually started building a RSS reader for fun five days ago. Now Google Reader is shutting down, and it seems like everyone is starting to build one.
Most desktop and webbased feed readers I tried over the years are too much resources hungry for my main laptop (eeepc 1000he, atomN280). I am tempted to try RSS lounge on my Pi, it seems to be a pretty good google reader replacement (I only looked at the screenshots so far).
Why is it that so many of these alternatives are hosted web apps? Isn't the lesson to learn from Google Reader going away that you might not want to trust hosted web apps for the long term? Why aren't there more client-side app alternatives?
Number of times google reader has a planned shut down, in which I still have plenty of time to grab my data: 1
Number of times something has happened to make an old desktop app stop working: numerous
for example (I haven't experienced all of these):
- switching from Windows -> Mac
- having my hard drive fail and finding out my backups were broken
- OSX upgrades breaking backwards compatibility (ie, old binary format)
- having my laptop stolen
- switching jobs, requiring me to give my laptop back
- having multiple devices that I like to read news on (ie, phone, laptop, tablet)
I much prefer to have as little as possible tied to the hunk of metal my sweaty fingers type on. I haven't lost any data yet from using 'cloud services' and the GR replacement I pick will be well vetted.
I value my privacy far more than any feature or convenience a web app may offer. This is one of the main reasons why I stay away from web apps as much as possible, and use open-source client-side apps whenever I can. As a side-benefit, I also don't have to rely on the whims of the web app provider to keep their service running.
Unless you use web apps for absolutely everything, you're still going to have to make backups. And if you're making backups anyway, how hard is it to include a tiny little list of RSS feed URLs which can be used to pick up from where you left off with any RSS reader, should anything happen?
Anyway, if you screw up your backups, you've got far more serious problems than simply restoring an RSS feed list. Do a good job on backups, and the rest mostly falls in to place.
I don't use a client-side reader because one of my use cases is subscribing to a lot of feeds that have dozens of updates a day. Most of those feeds typically only show the last N items, where N is significantly less than the number of posts in a day.
If I close my laptop for the weekend, that means I lose most of those entries in my reader.
If you use OS X, I can recommend Vienna, which has no problem at all with pulling and keeping as many feeds and articles as you want, up to as many as your filing system can cope with. It's mature, having been around for a few years now, and open source to boot.
I stopped using Google Reader and RSS feeds a long time ago without actually intending on doing so. I just started finding so much stuff to read through Facebook, Twitter and Hacker News that I totally forgot about RSS.
That being said, I did make a simple ruby script to email me articles when an RSS feed gets updated. I did this mainly to help me keep tabs on service availability RSS feeds, i.e. Twitter's status RSS, Facebook's status RSS, Amazon AWS stratus RSS, and my local weather advisory RSS. It comes in very handy. Maybe I'll put the script on GitHub.
A general problem with desktop readers is that they don't really sync with each other, unless there is also a back-end service associated with them. (or they support many services).
My news reader is my go-to "I have a few minutes" thing, so I use it equally from desktop/laptop, phone, iPad and so on. I don't want to spend any effort clearing each source of articles I've read on another.
Most clientside newsreaders simply do not scale, several thousand feeds make them die. Also you want to have your rss catcher always online, so a server is a better choice - but many FOSS serverside readers are also poorly implemented, slow, missing features, bad design.
Also the extremely annoying variability of rss feeds is still not handled by many rss parsers, especially the php world misses on this. python ok with feed parser.
One more thing: waste of energy duplicating rss feeds a zillion times - just to be deleted in most cases.
Seems to be a good usecase for a cool pyramid app on a deduplicating filesystem - what are your plans for the weekend?
Google Reader shutting down at least gives me a new hobby project to hack on. There are a few decent alternatives in this list, but nothing I'm particularly enthusiastic about.
The text wasn't displaying properly (Firefox), and my email address scrolled off the side of the textbox you asked me to enter it into, with no way for me to make sure I'd typed the second half correctly...
Does anyone here primarily read their RSS feeds "river of news" style (e.g., http://tabs.mediahackers.org/) instead of "mailbox" style (with unread counts)? If so, what do you recommend?
So far I'm thinking of using a river for my "firehose" feeds while using newsblur (or something) to keep tabs on my "must read" feeds.
I played around with Dave Winer's OPML Editor/River2 but it just never clicked for me.
It's early, but something we're working on with memamsa[1] is a way to keep up to date on your favorite topics using different types of sources: RSS/Atom, Twitter users/lists, and Hacker News. Combining the best of the traditonal (RSS) and modern sources of links.
it will be hard to beat google reader in terms of multiple platform support. I dearly love my android google reader app that lets me load items, view them offline, sync them when i get back online.
Google reader was perfect for that, and it was only on occasion that I used their web interface. Most of the time I was on my iPad/iPhone/Android (using Reeder/Byline/Flipboard and the official android client)