>One nicety >that Lyris has over Listserv is a Perl/C->Lyris API that you can use to create your own >applications. You can do that with LISTSERV as well, it's called the TCP/IP API (there are also OS-specific APIs that may be more convenient in environments where interoperability is not important). Most of the functions that are "only available in Lyris" are also available in LISTSERV, people just don't know about them. Yes, it is our fault, at least partly. And it is partly due to the fact that we have so many features that the manual is ultra-thick and most people never read it, so they don't know that such and such is available. We are working on a new series of task-oriented manuals that will hopefully make it easier for people to find out about all these features that supposedly LISTSERV doesn't have :-) I've been running hundreds of mailing lists in the last 12 years and I have never wished for the ability to reject postings with more than x% of quoted text, otherwise I would just have implemented it :-) It is possible that there are mailing lists where this is an issue, there are so many mailing lists, but people are not lining up to request this feature. It is also possible that we might lose 1-2 sales because of people who really need this feature very badly and don't want/know how to implement it using a LISTSERV exit, but in itself this is not really a problem. It won't even show up on the bottom line, and more importantly, we lose dozens or perhaps even hundreds of sales because of people who want some totally weird feature (often STUPID - think applications whose source code was lost but that still play a vital role, etc ;-) ) that they can only implement by hacking a freebie coming with source code. We just have to accept that an off-the-shelf product will never solve 100% of problems. We lost more sales to Revnet due to a genuine inadequacy of LISTSERV for the market Revnet was targeting (which has been addressed for 1.8d) than to exotic feature such and such that competing product XYZ just happens to have. We will soon have a better offering than Revnet for their primary market, and this was a technical problem that required a technical solution with non-trivial implementation and testing time. Now if we're genuinely going to lose an unlimited capacity sale because of a missing quote rejection feature that takes 15 min to implement, it can probably be added, I mean I could almost have implemented it in the time it took to type this message :-) Which BTW is how a lot of these exotic features come into being, there is a client who offers to buy the product if you add it, so you figure out the relative importance to the company of closing this sale vs the time not spent on other projects, and you add or don't add as appropriate. Start-ups will add just about anything you request, small companies will add once in a while, IBM won't, at least not unless you're making a very big purchase. When we started L-Soft and badly needed cash, I guess I would probably have added just about any feature whether it made sense or not. Now I only add features that make sense and either take very little time to add or would provide enough value to push aside other work. If we ever grow to IBM's size, there will probably be 20 layers of management before anything can be added (yes, I'm exaggerating :-) ). Anyway, willingness to add new features is mainly a function of the size of the company. If you have 6 figure revenues, you will go a long way to make another $5k sale. If you are in the 8 figures you may still do it on occasion, and in the billion a year arena it is just out of the question to give sales such a direct link to development. So it is perfectly normal for companies to become less willing to add new features just to close one sale as they grow in size. I know there are a few features I had wanted to add to help some new customers, but in the big picture the Revnet issue was more important as it affected hundreds of prospects. As a rule, it is normal for customer service to be much better in a start-up, both because your sale could make the difference between being able to pay the bills on time or not, and because there are less customers and thus more time for senior staff to dedicate to each. But of course start-ups become bigger if they succeed, so you just can't base your purchase decisions on ease of phone access to senior developers and the like, it would be betting on the failure of the vendor you have selected. Eric