In reply to nunfetishist:
I've never used fetchmail so I had a look at its homepage. It certainly has a lot of features but 90% of them are just not needed for the average RISC OS user who wants an efficient way of fetching email from one or more standard POP3 accounts, and sending outgoing mail to an SMTP server. While Hermes probably lacks some useful features right now, it is actively developed and will over time do what users want it to do, much like any other piece of software.
The notes on fetchmail state quite explicitly that it delivers its mail by SMTP forwarding and that all other delivery methods have been eliminated. This hardly makes it a drop-in replacement for POPstar. Even if it does deliver to file as you claim, where are you going to put it? Same place as POPstar so that existing clients can find it? Er no, because if you're fetching in parallel, two fetching processes that happen to belong to the same user can't write to the same file at the same time, unless each waits until the other has finished and then it isn't parallel fetching. Or you could process it in memory... oops, some other poorly-tested piece of software that was dashed off in a few hours has just crashed RISC OS and you've lost all your email.
On the subject of parallel fetching, the fetchmail notes are a bit obscure but they seem to suggest that "concurrent queries to multiple hosts" are too difficult to implement - so does it support parallel fetching or not? Funny, I didn't find it too difficult for Hermes.
The notes also suggest that using mail UIDs to prevent already-fetched mail being fetched again are a bad idea - apparently it requires "tricky, fragile implementation". How odd - this was a design feature of Hermes right from the start and I haven't found it tricky or fragile. Looks like Hermes might have a few features that people actually want that are missing from fetchmail, instead of cluttering it up with a host of features that no-one needs.
I'm sure you probably could write a POP fetcher in a few hours. I could also write in the same time an application that allows you to draw boxes and enter text into them in a font of your choice. So why has David Pilling spent years developing Ovation Pro? After all, 90% of DTP documents are probably just boxes with text in them.
Five hours to write a UI? So how will users configure your fetcher? Hermes has ten sections in its Choices window, with a mixture of checkboxes, radio buttons and pop-up menus. The Edit Account window has 14. All these have to have windows designed and handlers written for them. Or are you just going to get users to edit the Config and Users files by hand as POPstar does? That's neither user-friendly nor fully-featured, though it cetainly saves development time. The Status window has to cope with dynamically changing the number of accounts displayed and their progress since fetching can be triggered for any account or combination of accounts at any time, i.e. it's not just a case of churning out a window in FormEd with a few icons in it.
What happens when you get errors - incorrect login, server unavailable, corrupted data, malformed send address, lost network connection, file for reading doesn't exist, file for writing is already open etc. etc? Are you going to handle each one individually, make an intelligent guess whether the process can continue, and provide useful feedback, or are you just going to save coding time by sticking up a single-tasking box saying "Error"?
Of course free software can be as idiot-proof and user-friendly as a commercial item. That's not the issue. It's not the price that makes software usable, it's the amount of time and effort put into developing it. So do you also include testing in your 5 hours of development? Or are you one of those people who runs it a couple of times to make sure it doesn't crash and that's it? Good software is often tested for longer than its development time, and I would think that Hermes probably falls into this category.
To sum up, if you want a mail transport that works efficiently and effectively, provides the user with feedback (because most people haven't a clue what goes on after clicking Fetch or Send and don't know what to do if something goes wrong), has handlers for everything that's thrown at it, and timers to clean up later if files are not available when it wants them, and neatly-designed windows and all the other things that make software really usable, then you need many, many hours of development and testing time. If you want quick, cheap, badly-designed and poorly-tested software, that's fine - it's your choice. Luckily R-Comp has plenty of customers who don't.