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.