I’m disappointed in the article but watching RSS for 25 years (declared dead for most of them) have gotten me used to disappointment. It just seems like every discussion about RSS starts as if it was some brand new thing and not if we didn’t have 25 years of experience with it.

The article makes a matrix out of the least important attributes of the product (free vs hosted) and has nothing at all to say about: (1) user interface and (2) architecture.

(2) of course puts constraints on (1) but gets you to the heart of the RSS predicament. It is possible in principle for an RSS reader to be completely stateless, that is you could make an HTML page with some JavaScript in it that reads an OPML file and then hits all those RSS feeds and formats them somehow. Or you could write some scripts that do the same with curl. [1]

The stateful system has a lot of advantages, particularly that the state never gets corrupted because it doesn’t exist. If you could add some simple and reliable layer that dealt with the worst of the polling problems with a cache then you could still stay pretty simple.

Past that though the architecture could get complex pretty quick in that you may want to reify feed items and store them in a database, keep track of whether you read something or not, run queries against the feed, run a recommender against the feed, etc.

[1] … if your cache mechanisms will protect you from polling some people’s RSS feeds too fast. Maybe you’re better off if they block you.