[Gnu-arch-users] Why is "popular" software hard to change? [was some damn OT thread]

[Stephen J. Turnbull]

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

    Tom> It's pathetic that such a conceptually simple change to the
    Tom> popular free software MUAs isn't a practical option because
    Tom> it has to go through so few people and so many layers of
    Tom> process before it's widely available.  We should all be
    Tom> asking why that's the case.

You said it already: "popular."  "Popular" in practice demands a no
fuss, no muss, available in no-user-servicable-parts install-from-URL
packaging.[1]  Such packages don't happen by accident, they happen by
management.

How would you "fix" this problem in an ideal FLOSS environment?  Well,
instead of having "managers" enforce "rules," you'd have the hackers
"cooperate."  But to cooperate without management, you need standards,
or everybody has to spend a lot of time poking their nose into
everybody else's modules to understand what's going on.  That's
definitely not effective programming practice.

Then Jonathan and Robert A will tell you the standards are stupid.
And maybe they're right.  But that doesn't matter, because the
alternative is to have management, to decide when the standards should
be upheld because they're good enough (despite a few unfortunate
conflicts), when the standards can be ignored as an exception, and
when the community (which by the presence of management gets demoted
to a mere "organization") is going to simply ignore the standard as a
matter of best practice.

And on top of the devel process, you need a standard packaging system.
Every project I know of that provides RPMs or .debs outside of the
context of the distro gets complaints that their packages don't work
on certain systems.  Undoubtedly the distro-provided packages are more
popular because they are more likely to work, even if they lag the
bleeding edge (we've seen a similar effect with arch a couple of
times, people saying, oh, but I'm using the Debian package---have
things changed so much since it was released?)

So it looks like we need management to keep the package popular.  But
"popular" is necessary to have the desired impact; an improved but
unpopular package is not going to cut it.

The need for management is not a problem you can fix with software.
Good development environments may be able to help, but you can only
"fix" it by getting agreement to adhere to standards, and to go
through the appropriate (standard) process to amend or replace "bad"
ones.  But people like Jonathan and Robert A are unlikely to do so
because of their myopic utilitarian ("democratic") point of view.

Consider Jonathan's example of TCP/IP vs. OSI.  OSI was a bad standard
generated by a flawed process.  Yes, TCP/IP in some sense came first,
but the important fact is that it is _also_ a real standard, generated
by a better (more realistic) process.  It's unfortunate that for a
period of time there were competing standards (which has depressed
Andrew to the point of nihilism, it seems), but that's the way this
works.

Jonathan prefers to draw the conclusion that "the standards process
doesn't work; you [== sjt] should consider that we still have a
reply-to munging problem."  He's got a point, but he really hasn't
thought it through, I believe.

Up until now, there's been no leverage because there's been no
"popular" free MUA, and no standard way to deal with the problem.  Now
there's Simian Dilution (or whatever it's called ;-), bovines[2] who
prefer free software now have an "industry standard" MUA, and with the
List-* header RFC it's now possible to solve the reply-to-list-only
problem in a standard-conforming way, with changes only to a couple of
MUAs.  So once Evolution and Mozilla fix their admitted bugs, the
FLOSS community can conform with impunity.  This doesn't hurt the
appeal of free software; on the contrary, the FLOSS "industry
standard" MUAs will "just work" in contexts where Microshaft's won't.

Andrew will say that this isn't enough, we need M-F-T and M-C-T
headers, too.  But that's a separate problem, and _could_ have been
immediately addressed in a standard conforming way simply by naming
the headers X-Mail-Followups-To and X-Mail-Copies-To while the draft
RFCs wend their way through the IETF process.  In the meantime, the
document (I assume one exists besides the relevant code in Gnus and
Mutt) that defines these headers could specify that conformant
software should be prepared to migrate to the no-"X-" versions when
the RFC goes through.[3]

Isn't it time we attacked proprietary software where it's weak and
we're strong, by making true standard conformance an issue?


Footnotes: 
[1]  The equivalent for sysadmins is ".configure; make; make install"
source code.

[2]  This is a technical term coined by Larry Lessig in _Code Is Law_.
It simply means you've got better things to do with your time than
hack your MUA (or whatever).  Yes, I'm happy to have this intrepreted
as a flame, but "bovinity" also is now the usual term for the
"software broken[4] by popular demand" problem in the law-econ-of-free
software community, so we may as well use it.

[3]  Except that the people I trust on the matter say those headers
are broken and shouldn't be used, which suggests they might never
become standard, perhaps as a purely political issue.  Unfortunate,
but I don't see this as a huge problem.  If they're that good, the
community using them will eventually demonstrate them as best
practice, and can resubmit.  In the meantime, the "X-" versions are
available.

[4]  Or even evil, as in containing anti-copying "technical measures".

-- 
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.