LISTSERV was designed to be a high-end mailing list system offering a lot of
flexibility. Solutions that do not work in the general case are not allowed
in the product. Of course, there is a downside. A tool that only does one
thing in one particular case is always simpler to use than a generic tool
that can do many things in many different situations.

> The probes are a
> list-issue and a list simply probes every user, so multiple lists send
> multiple probes to a given user. Other products like mailman put the
> user first and probe the user just once. That's much more convenient
> from an end-user-point of view.

This is true if you can make the assumption that all the list owners want to
use active probing with a period of one month and with the exact same probe
text. In a typical university, or large company, or service bureau, there
are dozens or even hundreds of list owners, who each like to run their list
a different way. The probe text that the Sales department wants to use is
totally unacceptable to the Investor Relations department. The only solution
is then for each group of like-minded list owners to run their separate copy
of the software, which means higher manpower costs. When someone leaves the
company one day and the new guy does not agree with the rest of the group he
is working with, a new instance needs to be installed just for him.
 
Personally, I think active probing is obsolete anyway. There are cases where
it makes sense, but they are very few. I don't use it on any of my lists.

> One more example for lists first, users second: if internationalization
> is needed, every list-owner can provide his list-templates in a language
> of his/her choice. Imagine a user subscribed to a German, an English and
> a French mailinglist, who wants to change one of his/her options for
> each list. The user will see a German, an English and a French
> interface, depending on the list (...) if it was a
> mailman-installation, the user might choose his/her preferred language
> and have the same interface for each mailinglist. To the end-user,
> that's much more convenient.

This again works fine on the assumption that list owners do not customize
the web interface. Otherwise, you will only have chaos. The user, having
selected for instance German as his preferred language, will see a random
mix of French and German when accessing the French list. The pages or
fragments of pages customized by the French list owners will (I would
assume) be in French, and the default system pages would be in German. Of
course, this problem could be solved if the French list owner would provide
a German version of his customizations (and one for every other supported
language). But what is the motivation for the French list owner to do this,
even assuming that he also speaks German?

In the end, you need to use the tool that works best for you. If you can
assume that all the list owners are in agreement about the text of templates
and the probing method and message text and so on, perhaps something simpler
than LISTSERV will save you time and money. If at the other end of the scale
you are running a list hosting service, you need to look for a product where
most decisions can be made separately for every list.

  Eric