[cgiapp] Re: CGI::Application mailing list is evolving

[Mark Stosberg]

> one reason for going through something like google groups is that the 
> membership can come and go and the mail keeps on going. sometimes, after 
> a few years, the maintainer[s] of the email list will have gone on to 
> other things, and will need to be bugged to find the time to fix this 
> relic of their past. with an external provider, this should not be an issue.

Commodity solutions can still be subject to the "human bottleneck"
problem. For example, perhaps there is one person with admin rights, and
they can't be contacted to fix something. A commodity provider like
Google would be providing the service for free, and does not have much
incentive to intervene. 

I recently had a Google Group that was spammed with 50 signups.
(Commodity solutions are great targets for spam). There was no feature
to "select all and delete" at once, and there was no other upstream
admin to contact who just do a quick low-level delete of these spams.

Being primarily a mailing list, we have two things we want to preserve:
- the subscriber list
- the archives

Preserving archives is already taken care of through several archiving
services, no matter which solution we choose. In a "worst case
scenerio", the active subscriber list can easily be rebuilt in a matter
of minutes from recent posts. That's what I did just a couple of days
ago using the "Claws Mail" email client. It allowed me to easily harvest
all the e-mail addresses that had posted in the list 90 days, although I
could have also selected all the addresses which had posted ever.

I like the idea of hosting an open-source, Perl-based solution. A
solution like Lyle's provides list admins remote access to subscriber
management and other features, helping solve the human bottleneck
problem.  I think we are well equipped to deal with the unresponsive
admin problem.

    Mark