Re: [Gnu-arch-users] Why MUAs remain broken

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

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

Because flame is the only enforcement mechanism for standards in a
community like ours.  While the Evolution developers undoubtedly
simply have different priorities (after all, neither they nor their
users are directly violating RFC 2822 themselves), their broken UI is
resulting in calls to have common carriers do so, from people who
would otherwise happily support standard conformance (I believe).

While they may not really be "lazy and uncooperative", they certainly
could fix their UI deficiency with not too much effort, and their
failure to do so is undermining standards conformance, which is an
important component of cooperation in a community like ours.

I think it is preferable to give people an incentive to fix
deficiencies rather than rely on the much cheaper method of relying on
standards-violating practices until somebody else contributes a patch.

    Tom> Maybe it's factors like:

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

I don't see why we should do it at all.  There must be dozens of
Evolution developers, and hundreds of thousands of users.  They should
fix their own software, not ask the rest of the world to violate
perfectly good standards to suit their deficiencies, or come up with
fixes to inconveniences that their users suffer from their UI.

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

Now you're showing your prejudices; corporate management may add some
particular aspects to the agenda, but mainlines always have their own
agendas.  Just ask any of the people whose features are in XEmacs but
not in GNU Emacs.  And vice versa.  I regularly tell people with
certain desiderata to use GNU Emacs instead of XEmacs, in public, too.

The problem is popularity itself.  Popularity begets a mainline, and
being the mainline begets architectual power to a small clique, even
in free software.

    Tom>    Well, maybe if the dev team gets sufficiently embarassed
    Tom> about it that mgt. has to throw them a bone -- I guess
    Tom> there's something to that policy of flaming, after all.

Precisely!

It's also possible to scare _other_ managements, ie, those of
potential customers, with claims of non-standardness.  That leads to
interoperability and lock-in problems, and it's unlikely that the
customer management will be sufficiently clued-in to realize that this
particular nonconformance is irrelevant.

    Tom> competent hackers are chosing to flame.

But they always have.  That's the only enforcement mechanism standards
bigots have.  Sure, it makes sense to be polite when telling somebody
that their software is non-conforming.  They may not know, in fact,
most don't.  But when people say "F**k the standards, they're
inconvenient", there's no reply except to turn up the heat.  And
"inconvenience" is the only argument that the munging advocates have
against complying with RFC 2822.

    Tom> That's what the magic cauldron has cooked up in this case:
    Tom> ill-will, time wasting, and no hacking whatsoever.

How is this different from any other community standard?  Consider the
tobacco example I gave above.  Or the "political correctness"
movement.  Plenty of ill-will in both cases!  I don't see what the
free software aspect of the magic cauldron has to do with this.  It's
simply the absence of a boss to settle disputes that _will_ arise.
Then the only appeal is to community pressure.

I agree with your technical thrust.  If it was _much_ easier for
Robert Anderson to keep Evolution sources around, hack them, and
submit high quality patches to the mainstream developers, then surely
he (or someone very like him, but with an Evolution itch to scratch
that he doesn't have right now) would do so, and this problem would
have been settled in the Evolution community itself some time ago.
Unfortunatley, this only applies in a subset of cases.

In many cases, strict standard conformance would still be
controversial.  AS's favorite M-F-T headers are a case in point.  I
would guess that the reason that they don't have the "X-" prefix that
declares them private is that M-F-T advocates want to use the
additional cachet that RFC-sanctioned headers have to encourage
implementation.  There's a real problem here: M-F-T et al are in some
sense "broken by unpopularity" as long as few MUAs implement them.  So
to give them a fair shot at being proven "best practice", you want
them widely implemented.  "X-" headers rarely are, unless they're
_way_ above the bar, and would get RFC status quickly, anyway.  OTOH,
a fair number of smart people think the M-*-T headers are "broken by
design," in which case you don't want them acquiring a constituency of
those who only see the convenient side, and whose usage patterns don't
run into the problems.

So here you have the problem that the RFC process is inherently
conservative for standards where you only really start to see benefits
when a significant fraction of the community implements them.

    Tom> At least for the technical part of the community of users,
    Tom> wouldn't a boilerplate reply like "here, put this code in
    Tom> your .evolution file" be better than a boilerplate flame?

Only if it comes from an Evolution community member.  Outsiders whose
protocol space is being polluted on behalf of Evolution users should
not have to figure that out.  Emacs users do not ask mutt/vi users for
elisp snippets, or vice versa.  Sometimes they're offered by those
with sufficiently broad expertise.  But that's above and beyond the
call of duty.

    Tom> Ok, let's all warp back to 1993 and, this time, think a
    Tom> little more carefully about the choices we make.

Isn't that when NCSA Mosaic was invented?

Emacs was already nearly 20 years old, w3.el was the only multilingual
web browser, and RMail and Gnus were industry leaders.  Consider---you
and I made the choice to live in a community where the boilerplate
reply _is_ "here, put this code in your .emacs"!  But 40 million AOL
users (and Robert Anderson, as an example of somebody who is _not_ an
AOL user) don't want to hear about it.

We (that is, the 100s of millions of computer/Internet users) will
make the same choices.  Don't you think?  And you and I will remain in
a minority.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.