State of the RSS

Anyone who sees “RSS” in the title of this post and understands what it means is probably familiar with Google Reader, and is also probably aware that it finally got shut down this month. So now what?

I switched over to Feedly a while before the shutdown, but I honestly haven’t really been using it enough to give it a proper review yet. However, I already know it’s not an ideal solution for me (for one primary reason, which I spend most of the text below covering), so I thought I’d put together a few thoughts on what a perfect world would look like to me when it comes to apps and services used to consume RSS.

My ideal system would be composed of 2 distinct parts or aspects:

1. Aggregation / Sync Service

This means something running somewhere that is consolidating all of your feeds as well as your state information (read items, shared posts, etc.) that has a good external facing API for other user interfaces to build on top of.

Although not as visible, this was arguably the more important aspect of Google Reader, and the thing that caused the most pain when it went away. Sure, GR had its own web UI and official mobile apps, but it also served as the back end for many other 3rd party reader clients who had the rug yanked out from under them along with the direct users and had to scramble to build their own back end or move to support others.

Which brings me to *my* most important requirement for this piece: it should be open source, free (as in freedom) software. It could also be hosted as a paid or free service (which is how most non-tech people would choose to use it), but it’s important that if whoever is primarily behind it decides to make any number of moves for any reason that infringe on the value users originally found in the service, someone else can pick up the ball and run with it, or users can even host it themselves.

2. UIs that work with that service

Whether the provider of #1 also puts together a great web UI and/or mobile apps on top of the service is not too important to me. In fact, I’d almost rather they didn’t, just because that would probably make sure they are focusing on providing a great API as their only “user interface”. If they do that right, there will be plenty of room for lots of other players to build great apps and UIs (free and paid) that use it, again giving users the freedom of choosing among many options in case one ever fails.

Closing thoughts

GR used to be even better when it also had a lot of the social features they removed (sharing & comments) in their initial attempt to push users to G+, but that’s a whole other rant – as well as a service that could be provided as an add-on by either party described above or even a third service player that inter-operates with them.

The funny thing is that the ideal system I described above is pretty much what Google Reader was before it went away.

Ultimately, I thinking making sure that #1 is free software / open source is actually the best way to make sure that users and app partners can’t be burned in the same way that Reader burned them / us.

Some people are gravitating towards paid solutions as an option for mitigating this concern, with the idea that it’s more likely to stick around if it’s paying for itself / making someone money, particularly as the primary or exclusive focus of the business. While I’m all for paid services and there is some merit to that argument, I think it’s just not as strong a protection as free software offers, because it ultimately does not address the true problem, which is lock-in that the service provider can choose to make the same “bad” choices Google did at any time. It leaves users and 3rd parties vulnerable in the exact same way as they were under GR.

Case in point: Google’s Reader did not go away because it wasn’t making money, nor because the company behind it couldn’t afford to keep it up. It went away purely and simply because Google decided they wanted it to. We can speculate on their motivations (still probably mostly having to do with pushing G+), but those ultimately don’t matter, because the real problem is lock-in depending on a sole provider with no easy way to replace them. *Any* company, if they are the sole provider of a service, can leave users and 3rd party apps out in the cold this way, either for their own business interests, or because they ran out of money, or any of the many other potential reasons, but the result is the same.

It’s unfortunate that all the offerings I’ve looked at so far (please point out others) seem to be clinging to this closed source, single provider model, which is just a recipe for the exact same lock-inproblem we had in Reader. I’d love to see a product surface that meets this need and really takes off, becoming the basis for many sustainable businesses while still remaining free at its core. There are many examples of this approach succeeding, with WordPress probably being the most obvious.

Of course, this whole post is simply my opinion, and is based on the particular weight I give in my own considerations to aspects I value in software. Many people weigh or value those aspects differently, or are not even aware of them at all which makes it difficult to give them any weight in consideration, so YMMV and all other appropriate disclaimers…

UPDATE – 2013/7/3 20:35 – Edited to replace “lock-in” references to better, less loaded terminology

This entry was posted in Blog Posts. Bookmark the permalink.

3 Responses to State of the RSS

  1. Dan Cameron says:

    Google Reader had the lock-in effect? Huh. No.

    Feedly allowed you to easily switch and even though I didn’t “migrate” I could export my OPML and use it anywhere I wanted. GR didn’t lock anyone in.

    People are upset about Google Reader closing because they either: one, hate change; two, their favorite feed reading app didn’t support an alternative; third, there were too many choices for alternatives.

    GR just worked and people became familiar with it, no open-source solution will change that.

    GR was popular and Google fucked around with its users. That’s the problem.

  2. jared says:

    You’re right – “lock in” was a poor choice of term to describe what I meant.

    I’ll think about how to better phrase it, but what I meant by lock-in was that Google Reader became a dependency that many 3rd party clients just accepted, without making sure they had an easy way to move to an alternative service if/when Reader became unavailable.

    On the user side, it’s true that they did offer exports of not just OPML but other user generated data (starred items, etc.), but most of the data from those exports (aside from the simple list of subscriptions) isn’t accepted by alternative providers as far as I can tell.

    In both cases (3rd party clients and direct users), I did not mean to imply that Google was doing the locking. What I meant was that by choosing GR as a sole provider and failing to plan for other alternatives, the 3rd party clients and (to a lesser degree) the users had “locked themselves in” when it came to making choices that would make it easy for them to move when the time came.

    It’s certainly not as bad as some other forms of lock-in we’ve previously discussed, so that’s probably another reason that it’s a poor choice of words on my part.

    The main point of the free software / open source benefit that I attempted to describe is that it makes it so that it doesn’t matter what the company decides to do. Whether it fails or just changes its mind for some other reason and decides to screw users, it doesn’t matter as much because those users would have an easy transition.

    In evaluating replacement options, it’s important to realize that any service you choose that isn’t open source – whether paid or free – can (and might) screw you in exactly the same way Google did.

  3. jared says:

    Thanks for the feedback. I edited the post to replace “lock-in” references with more clear, less loaded terminology.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>