>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