[Mailman-Users] query re "message has implicit destination" (devils advocate!)

[Brad Knowles]

At 4:56 AM +0200 2006-08-31, Bretton Vine wrote:

>  So far my experience has been wonderful with the product, good and bad with
>  the documentation, and rather difficult in terms of user-error, namely mine.

I am of the opinion that all software sucks, but some sucks less than 
others.  IMO, Mailman sucks less than any other MLM I've seen.


Of course, amongst most open-source projects, documentation is a 
serious weak spot.  Those who are developers write code, not 
documentation.  And if they do write documentation, you frequently 
wish that they hadn't.  Those who are operational-types (like me) 
don't write code, and usually don't write documentation, and if they 
do write documentation you frequently wish that they hadn't.

The good documentation writers rarely seem to cross paths with any 
open source project I've seen.

It's a known serious weak spot within the Mailman project, and we'd 
love to be able to resolve this issue, but that means we need to get 
some people onboard that are good at writing documentation.  Any 
suggestions you may have in this area would be gratefully accepted.

>  No offence intended, but this is a rather closed-off point of view. It's
>  completely valid yes, but leaves no room for organic growth. A view of "we
>  have enough users, we do this for our own reasons, we know we can improve
>  this and that but there's no urgency" actually shrinks a community in the
>  end.

I can't say where things will end up.  I don't think I can even make 
much of a guess.  I can tell you that we're getting a large enough 
influx of users that it is difficult for us to keep up without doing 
anything more to actively draw in more users.

In that kind of high-growth environment, it's hard to justify doing 
anything that would actively draw in more users and would likely 
hamper other development efforts that we consider to be more 
important than maximum growth of the userbase in the shortest 
possible time.


My preference would be to have a more sustainable growth pattern over 
a longer period of time, based on a higher quality product that we've 
been able to develop and field, then let the growth take care of 
itself.

But that's just my personal view, and is not necessarily shared by anyone else.

>  I'm not saying there's an obligation to use or prove your software (and
>  time/effort interacting with the user base) just that any project can become
>  bigger than the sum of its parts and developers should be aware of that.

I think that the developers are well aware of this issue, especially 
since multiple other groups have taken the Mailman code and made 
unapproved changes to it, and then fielded that to their users -- but 
without providing adequate support for their modified versions and 
thus leaving us holding the bag they created.

>>  That's fine, too.  If they want to go off by themselves and learn their
>>  lessons the hard way, then that at least gets them out of our hair.
>
>  Doesn't seem quite efficient to have people duplicating labour for no reason
>  other than stubbornness.

Sometimes you can't stop them, no matter what you do.  IMO, when you 
discover that the kind of situation you've got with a particular 
person, then the best thing to do is to recommend that they go ahead 
and do whatever they want on their own systems and to report back to 
you regarding their success.

Otherwise, you're mud wrestling with a pig, which only gets you dirty 
and sweaty and annoys the pig.

>  However my point is that Mailman will still be used commercially.

True.  Like it or not, there's nothing we can do to stop them.

>                                                                     Which
>  creates expectations.

Also true.

>                         You can't manage the expectations of others so it's a
>  difficult road to travel.

Indeed.  We do the best we can through what documentation is 
available (including the FAQ), but there's little we can do beyond 
that.

>  I understand. But look at it from a point-of-view of say a prior majordomo
>  installation where the safe defaults are different defaults. Look at it from
>  the point-of-view of someone who knows the prior defaults and may be
>  confused by the change. Yes the new defaults are safe, but why?
>  (obvious answer: changing environment and needs)

Majordomo is different from Mailman, and I would not be surprised if 
certain features were present in one package and not in the other, or 
if certain defaults were set one way in one package and the opposite 
way in the other.

But if people don't understand that different software is frequently 
different, I'm not sure that there's much I can do to help them, and 
I'm not sure that there's much that anyone else can do to help them, 
either.

>>  For the lowest common denominator?  None.  Even the simplest possible
>>  web interface would be too complex for them.
>
>  Boy, that's harsh.

Do you want a complete and total moron to have his finger on the 
nuclear button, and capable of blowing up the entire planet many 
times over?

Oh, waitaminnit, we already have that situation....

>  I've knocked out our system quite a few times (by accident or oversight) and
>  yes there's often hell to pay and some sleepless nights -- but we've yet to
>  find a user who takes the system down because they have a web-interface or
>  email-interface to the system so they can manage their own list.

The number of things that a list moderator or list admin can do 
through the web are limited, and the danger is reduced.  But if/when 
we make all site administration functions available through the web, 
the danger will be quite a bit higher.

Even list admins can subscribe a bunch of other addresses to their 
lists, and create loops with their subscriptions.  It only takes one 
loop that causes every message coming in to the list to be duplicated 
and then re-sent back to the same list (and duplicated again, ad 
nauseum), to bring down the whole system.

If you've got a large system (e.g., something that can generate 
millions of mail messages per day), it's easy enough to make a 
mistake that could take down a lot of other systems around the world 
and not just your own.


These are powerful tools we're talking about here, and it's easy to 
do things to wind up accidentally shooting yourself in the foot -- or 
maybe accidentally shooting your neighbor in the head.

With powerful tools, you also need powerful safeguards.

>  In alternate reality one, the safe defaults are automatically decided for
>  the user. In alternate reality two they are suggested but the user has to
>  enable them. Which reality informs the user more?

Right, but precisely who is our "user", or perhaps I should say "customer"?

I submit that *our* customer is the site admin, and this is precisely 
the kind of thing we offer to them.  The customer(s) of the site 
admin would be the list admin(s), and the customer(s) of the list 
admin(s) would be the list moderator(s) and the list recipient(s).

So, it's up to the site admin(s) to look through the defaults we've 
provided to them and decide which ones they want to change for their 
customers, and it's up to the list admin(s) to look through the 
defaults they're given by the site admin(s) and decide which ones 
that they want to change for their customers.


I submit we've done our job for our customers, and it's up to them to 
do their job for their customers, and so on.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  Founding Individual Sponsor of LOPSA.  See <http://www.lopsa.org/>.