[Gnu-arch-users] Why MUAs remain broken (was reply-to foo) to the old mailing list

[Tom Lord]

Why does this issue generate flames -- even personal _policies_ of
flaming -- even epithats such as "lazy, uncooperative developers of
the broken software" -- rather than 100 lines of patches to Evolution?

Maybe it's factors like:

*) Setting up a development environment for it is difficult, time
   consuming, and resource intensive.   I doubt that it could be
   done practically on my system, for example.

*) These particular kinds of changes require too much work to
   implement.  It's not very fun work, either, because so much of it
   involves a heavy edit-compile-debug cycle using a low-level
   language rather than just interacting with a high-level
   interpreter.

*) These particular kinds of changes are useless unles they are
   accepted into the mainline.   And not just any mainline: a mainline 
   that is owned by a particular company, with its own particular
   agenda.

*) These particular kinds of changes are useless to most of even
   the technical subset of the user community until they appear
   in a distribution.

*) Even when they are in a distribution, these particular kinds of 
   changes are useless unless you upgrade to obtain them, and 
   even then, since they are intertwingled with other changes, 
   the choice to upgrade or not is not an easy one.

*) Few people have the time or incentive to make this kind of 
   change.   If you're employed to work on this software, it
   seems to me unlikely your employer will see a change like this
   as anything more than a one-pointer for clearing a bug-db 
   item.   It certainly isn't going to help sell desktops to
   municipalities or fortune 500 companies, right?   Do you think
   when you go to a dev-team meeting the manager says "Hey,
   about this reply-commands foo" or do you think he says "Hey,
   about the latest release of Microsoft Exchange...."
   Well, maybe if the dev team gets sufficiently embarassed about
   it that mgt. has to throw them a bone -- I guess there's something 
   to that policy of flaming, after all.

With both software architecture and business model, we've created a
situation in which, given the choice between adding a conceptually
simple feature to an MUA or developing a _policy_ of flaming endlessly
on multiple lists, competent hackers are chosing to flame.  That's
what the magic cauldron has cooked up in this case: ill-will, time
wasting, and no hacking whatsoever.   Having set-out to make
stone-soup, we've produced mud-stew.

Which is a fine creek to have got up because while the unix vendors
we're busy displacing used to be able to employ a _superset_ of the
hackers needed to work on their core product, the free software
industry is nowadays premised on hiring a _subset_ and getting the
rest of the labor for free.

At least for the technical part of the community of users, wouldn't a 
boilerplate reply like "here, put this code in your .evolution file" 
be better than a boilerplate flame?   Ok, let's all warp back to 1993
and, this time, think a little more carefully about the choices we 
make.

-t