Adam Green, the CEO of Grazr, co-founded the company with Mike Kowalchik, the CTO and lead programmer. Visit his blog here.

What is Grazr, and what are its strengths over traditional methods of managing feeds?

Grazr is a publishing system for feeds, which means that unlike traditional aggregators that are personal products, Grazr is meant to be used by someone who wants to share a collection of feeds with others. You can take any feed or OPML outline and publish it in Grazr on a Web page or blog. One tremendous advantage of Grazr is that it doesn't require you to subscribe to a feed before reading it. Instead it encourages a model of grazing or feed surfing, in which the user simply jumps from one feed to another as their interests lead them. When a feed worth reading regularly is found through this process, you can use the feed's URL to subscribe in any traditional aggregator. Grazr isn't meant to compete with an aggregator or feed reader. It is part of the growing ecosystem of feed-based products, and serves a key role in the process of feed discovery. One aspect of this is Grazr's auto discovery, which allows you to enter the URL of any Web page to view all of the feeds contained in that page.

What is your business model? Will ads be included in Grazr?

There are no ads in Grazr and we have no plans to use them in the future. Of course, if a feed that has ads within it is displayed in Grazr, those ads will still appear within the feed itself inside Grazr. But we won't put in any additional ads of our own. Our business model is to build a large base of Grazr users and have as many Grazrs in place on Web pages as possible, so Grazr is free for both personal and commercial sites and will continue to be free in the future. Over the next year we will be building a set of online tools for publishing feeds in Grazr, including application development features, such as programmability. One revenue source will be offering both free and paid versions of these tools. We also expect corporations to develop large numbers of feeds for both external and internal use over the next year, so they will be obvious customers for versions of our tools for use behind a corporate firewall.

What is the technology behind the service, and why did you choose it?

The Grazr client is written in Javascript and uses Ajax techniques to communicate with a feed server component. We think Javascript support in major browsers is now be mature enough to handle a serious application, although we still spend a lot of time cursing a certain browser from a large software company. We like to tell ourselves that browser weirdnesses are a barrier to entry for competitors, like having a bed of burning coals in front of the door to your house. Besides, Javascript issues are nothing compared to the insane things people do inside feeds, but don't get me started on that. The feed server component is written in Perl, and uses the traditional LAMP (Linux/Apache/MySQL/Perl) stack. We chose Perl, because all of our coders are very comfortable with it, and it is damn fast at processing text. We are also building a native XML parser in C to replace the standard Expat library. Expat may be a good product, but it follows the XML tradition that says "If a file isn't standard XML, then barf." Anyone who has tried doing feed programming with Expat knows that it is basically bulimic in the frequency with which it finds things that make it barf. Our rule for our new XML parser is "No barfing!" We run the feed server code on a collection of dedicated servers in multiple, geographically dispersed data centers. One of the formative experiences for most of our development team was scaling Slashdot back in the Dotcom days, when we were at Andover.net. As a result, scaling is in our blood, and things like load balancing and active monitor systems are a major ingredient in our architecture. We aren't quite up to Googleplex levels, but in a small way we share the same philosophy.