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