Over the course of the next few days, I'll be publishing interviews with a few of the developers of popular feed-reading software. First up is Luke Hutteman, author of SharpReader.

SharpReader is a popular, free, Windows feed reader, based on .NET protocols. Hutteman, a 35-year-old systems architect in Charlotte, North Carolina, released SharpReader a little over a year ago, and since then he's continued to develop the software in his spare time. While he has no plans to turn the project into a full-time business, he is considering selling default feed placements to generate some income to fund future improvements.

Harold Check: I've become increasingly convinced that the future of syndication will be shaped by those who create tools to manage the feed reading process, as opposed to those who create tools to manage the feed producing process.

Luke Hutteman: Well, ideally there will be some level of cooperation between those that produce the specs, those that write the feed-producing tools and those that write the feed-consuming tools. I do agree with you that the creators of feed consumers seem to have a better grasp of what type and form of information is useful?since we're the ones that have to work with it. It's one thing to produce a feed or write some abstract spec with a great theoretical background, it's a whole different ballgame to use this data in ways that benefit end users.

Of course, being an aggregator developer, I could be somewhat biased in my viewpoint here.

HC: How do you approach developing SharpReader? Do you have a vision you're working towards, or is user feedback the main driver behind changes to the software?

LH: For me, it's mainly my own ideas on what would make SharpReader a better aggregator. I initially created SharpReader for personal use only and in some ways still treat it as such. That being said, I'm definitely influenced by user feedback as well. If lots of people ask for certain features, I do try to make those a priority. That is, as long as they won't needlessly complicate the application. I'm a strong believer in keeping things simple, which is why I've tried, for instance, to keep the number of dialogs to an absolute minimum. As an example of this, SharpReader is one of the few aggregators where you can subscribe to a feed without being forced to go though an "add feed" popup wizard.

HC: What do you make of the standards wars? As a developer, does it bother you to spend time addressing multiple formats and the uncertainty of future formats? Are you in touch with any of the keepers of the current standards?

LH: Needless to say, I'm not happy with the standards wars and resulting competing formats. A single, well specified, extensible spec would certainly have been preferable over the current situation of RSS vs. Atom. Since Atom won't replace RSS, it will just be yet another syndication format to support. And while RSS is often blasted over having many incompatible versions, I don't see why the same won't happen to Atom?versions up 'til now certainly have been incompatible, and no guarantees have been made that future specs will remain compatible with the current (already widely implemented) version.

I'm not actively in touch with any of the keepers of the current standards and have been more of a follower than a leader in this aspect. I do keep track of the Atom process but really don't have the time to get too deeply involved in it. I have a lot of respect for people like Sam Ruby and Mark Pilgrim and trust (hope?) that Atom will move in the right direction. That being said, the design-by-committee approach of Atom does lead to a spec that, in my opinion, seems a bit too broad in the base specification. Some Atom elements (like two of the three dates) seem better suited for a namespace extension than as part of the main spec. RSS was "really simple," Atom is not. What Atom is, though, is better specified than RSS, which should make it easier to handle. Unfortunately, like I said earlier, Atom is not replacing RSS any time soon (if ever) so it's just one more format to handle. This means that from an aggregator-writer perspective, Atom just adds extra work for fairly little benefit.

All that said, implementing Atom as if it were nothing more than an RSS namespace took less time than I expected. It still added complexity I'd rather have done without though...

HC: Do you think that standalone readers will ultimately flourish? Or is feed-reading destined to morph back into existing web tools?either on the client or server side?

LH: I think both models will co-exist for the foreseeable future. When I first heard about RSS and aggregators, I tried AmphetaDesk and the Radio Userland aggregator, and did not like either of them. With their web-based UI, I did not really get what was so great about RSS. Then I tried FeedReader and "got it". I prefer desktop aggregators because they tend to give a better user-experience: they're more responsive, can provide a richer UI experience (supporting things like drag-and-drop and taskbar notification of new items), etc. On the other hand, web-based aggregators have come a long way since then. Nowadays they provide services where they can for instance recommend feeds and items based on other users with similar taste; a client-side aggregator cannot do this as it only knows about your own feeds. Also, a server-side aggregator works better across multiple computers since your state is stored online instead of on your local machine.

The ideal aggregator, in my opinion, would be a combination of both models: a rich client application that gets its data from a server-side process. This way a user can have a rich user experience, while still being able to access his data from anywhere (well, as long as he's connected to the net) and data can be mined across users to make intelligent recommendations on feeds and items.

HC: Bookmarks became less useful as the number of sites skyrocketed. What will happen when feeds become much more pervasive?

LH: This is already happening?it's very easy to subscribe to more feeds than you can actively follow and be left with thousands of unread messages. Early versions of SharpReader kept all items until you manually removed them. In retrospect, this was a mistake. RSS is not about history; it's about what's going on now. If you haven't read something after a couple of weeks, chances are, you never will.

Even with an automatic purge of old items (the default in later versions of SharpReader), the flow of new items can potentially be too big to keep up with. This is where things like filters, search folders and Bayesian filters will need to come in, to make the messages that a user is most interested in show up on top. Also, being able to easily follow links, backlinks and comments becomes more important to read an item in context.