I think the money issue is the most pressing. The way I see it there’s a couple problems.
1. Even though feeds are fairly small and easy to serve there’s got to come a point where you have so many users that even their small feeds begin to cost significant money. Feedburner not only has to check the host feed often but serve all the subscribers who poll as often as every 5 minutes. That’s a lot of bandwidth and a lot of server power.
2. With free analytics services all over the place it’s very unlikely you’ll be able to make money on a subscriber model which leaves ads as the only viable revenue stream. But for that to work you need a decent ad network behind you and you can’t very well use adsense
With that said, I'd think it a fairly easy service to duplicate. All Feedburner really does is read your feed and then repackage it while logging the pertinent data from the subscriber http transactions and sticking it in a database. Since every modern language I can think of has free libraries for reading RSS/Atom feeds and logging transaction data the whole thing could probably be duplicated in a couple days.
Technically, it doesn't seem very challenging at all. This is the perfect usage case for caching. The feeds aren't user specific, are they?
If not user specific: user requests feed for xyz.com: try to pull from cache. If there's a miss grab the feed from xyz.com, store to cache, and serve (be sure to set cache to expire in however often is necessary). If cache hit, you're done!
You can throw in extras, like make the cache semi fault tolerant by storing the latest feed to a DB. If your cache ever dies, then you can grab from DB to refill the cache.
Beyond that, it's just logging views and subscriptions to feeds.
Am I missing something? I don't actually use feedburner...
To log views, you have to change links to redirect to your service first and then redirect. But, that's not a huge technical hurdle. Other than that, I think you've pretty much summed up the basics. Oh, I guess the other thing they do, is convert direct links to the feed into something nice in the browser, and provide embeddable widgets and doodads. Again, nothing terribly hard about it.
1. Even though feeds are fairly small and easy to serve there’s got to come a point where you have so many users that even their small feeds begin to cost significant money. Feedburner not only has to check the host feed often but serve all the subscribers who poll as often as every 5 minutes. That’s a lot of bandwidth and a lot of server power.
2. With free analytics services all over the place it’s very unlikely you’ll be able to make money on a subscriber model which leaves ads as the only viable revenue stream. But for that to work you need a decent ad network behind you and you can’t very well use adsense
With that said, I'd think it a fairly easy service to duplicate. All Feedburner really does is read your feed and then repackage it while logging the pertinent data from the subscriber http transactions and sticking it in a database. Since every modern language I can think of has free libraries for reading RSS/Atom feeds and logging transaction data the whole thing could probably be duplicated in a couple days.