This problem surfaces now and then in the academic world and it
is important to understand the practicalities of the situation:

1. The technical people are typically hard to find and retain.
   Management will err on the side of keeping them happy.

2. Faculty/staff cannot normally win a technical argument with
   the technical people in question. Eventually the techies will
   say "ARGH! This is irrelevant because of mumble jumble!"
   and faculty will not know that the correct rebuttal was "Do you
   really think I am too stupid not to know that glorf blorf?"

3. In most cases, the techies' evaluation is actually not
   technical. The most common reason is in fact a belief that
   software should be free and that commercial software
   should be avoided at all costs.

4. You know that you are right and can find 100 peers to
   confirm it, but that will not make any difference. Your peers
   have little or no credibility in the techies' eyes.

Unfortunately this means that you are dealing with a political
rather than technical problem. Some popular, tried and true
solutions include:

- Waiting for a major, embarrassing incident attributable to the
  new system. This may take too long if the service is not
  visible enough and incidents are not embarrassing.

- Asking another university to host your list. This is often
  considered a major source of embarrassment.

- Procuring your own departmental solution rather than
  paying for the central IT department to run the list. This
  usually works even if some internal rule prevents you from
  actually stopping payments to the IT department.

- Asking users to petition management. When all is said and
  done, central IT services works for the users. If enough of
  them complain about a new service, it is their job to improve it.

Life was simpler in 1994 when decisions were made on technical
or economical grounds (total cost of ownership).

  Eric