The topic is build configuration of software packages as done by many
authors/maintainers who used GNU Autotools as their build system. I was
challenged on a patch I showed readers of the "mingw-users" List, a
patch to the current glib 'configure.ac' file. My response, which I
"crossposted" to the Autoconf-Users List because of the salience of the
issues, may leave some readers with confusion (even if they don't know
it) about the intent of my statements (especially in view of some
portions with numerous typos ;-). I am going to try to clarify my main
point here. Many may react with disagreement; the views I am expressing
are expected to be seen as "controversial."
I wrote in <[EMAIL PROTECTED]> on Sat, 28 Sep 2002
18:16:09...
> Almost no degree of invective would suffice to express how
> resentful I feel I justifiably am on account of this blindness or
> warped perspective on the part of people who have become
> comfortable and dogmatic about Autotools. It has made people who
> write or maintain Autotools-based 'configure' scripts complacent
> and mediocre about the quality of their scripts and a huge part of
> the problem lies there. I cannot even blame the maintainers of
> autoconf and its chums to the degree that I blame the package
> maintainers out there for laziness and lack of empathy and insight
> into what they are inflicting on their users.
What I meant by that is explained from here.
"So You are a BigShot now"
--------------------------
This is addressed to people who have taken up maintainership of Open Source
software packages (either as an inheriter or especially as an original
author). You know better than anyone what sort of thought process you lived
as you reached a decision to undertake this.
I've read a lot of defensive vitriol in the past along the lines of "how
DARE you criticize or complain about people who voluntarily and without
compensation maintain Free Software for you, the Obviously Ungrateful User,
to enjoy." I have a got a couple observations to make about that old
schtick now.
First of all, in Hackerdom, the line between "Users" and "Producers" is far
from cut-and-dried. Many users of somebody's package are authors or
maintainers of other packages. There's mutual interdependency here.
Secondly there is the fact of human nature that there ARE compensations
for maintaining Free / Open (abbrev "F/O" from here) Software. They are
intangible compensations. Developing software is innately rewarding for
many people who do it (hopefully for those for whom it is not, they'll
eventually get into a different line of work more suited to them). There
is the justifiable pride of workmanship. Software is a creation of the
mind and it *does* things, useful things. Developing a good piece of
software is no different from inventing or making a good tool or
machine.
Also, there are the opinions of peers (others who are 'in the know' about
programming) and the regard one can come to be held in by producing a good
software tool. If your tool is VERY successful, it might become the
foremost of its kind, dominating an entire niche. If it becomes something
that other tools rely on, then you'll be in the position of having others
dependent on you (which is a fundamental type of _power_ in all realms of
human affairs).
Some authors or maintainers also have philosophical beliefs and
convictions that concern a different, more abstract level than the
pragmatic "what it does" -ness of the package. Such people feel a sense
of being a part of an important and liberating movement in Human
history, that supporting a piece of the Free Software movement and Open
Source is promoting values and principles that can lead to a better
society and way of life for all people in the future.
Finally there is an aspect of reward that's possibly more fundamental
than any of the others mentioned above. That is simply the sense of
righteousness or worthiness one gets from giving something to others,
from being the giver of the gift. Individual people vary in capacity in
terms of to what extent they experience this or can be conscious of
experiencing it.
"So You are a BigShot now" means simply to make reference to the fact that
for all these reasons, something we finally have to admit is about "status"
in the F/O Community being connected to authorship or maintainership of
software packages. It is not just ME who says so; those who have read Eric
S. Raymond will be familiar with this discussion. And "BigShot" refers not
only to how others view you, but also to how you (in the secrecy of your
own heart) view yourself.
This mutual-interdependency thing is innate in the philosophy of code
re-use that is a primary principle of GNU. I having been trying to
express something that I see more and more of that I think threatens to
rot the underpinnings of this F/O software world. As I learn, I try
more and more packages, and am especially inclined as a "consumer" of
software to invest my time and attention in F/O software. If there exist
two or more projects that do roughly the same thing, I want to use
("support" by increasing the user-base of) the Free alternative. One
reason is that historically it is becoming clear that F/O software can
often beat any other sort in quality.
But the quality of software isn't just a question of today, the day it
is first released; it is a question of future maintainance and support
and extending of the software. Supposedly F/O software can be evaluated
as much higher in quality than proprietary alternatives, by this
standard. Supposedly.
It is also, in the case of F/O software, very much a question of how the
build support is done. And that's where I am seeing the Open Source
paradigm beginning to list badly in the water. I have been repeatedly
getting obnoxious, ignorant replies from package maintainers (and others
who seem to have some "loyalty investment" in the package in question --
an "affiliation relationship") when I attempt to state my experience and
observations about some aspect of the package and its build setup. The
kind of replies I get are nothing short of *disrespectful* at best. At
worst they can be said to embody a kind of "passive violence."
***********************************************************************
I'd like to tell the maintainers and authors how I feel about this, as a
user. I feel like someone has held out a gift to me in one hand while
with the other hand they are slapping me in the face.
***********************************************************************
I think the people who do this -- and often they have been maintaining a
package for a lengthy time -- have maybe decided that the forms of
"compensation" (intangible) enumerated above are no longer sufficient.
They have decided that their "reward" for the "selfless" work of
maintaining the Open Source software package is going to be to indulge
their own arrogance. Arrogance is a strong word but really is the right
word that fits the situation where someone has decided that their own
instincts about "What To Expect" are beyond questioning and that any
volunteered feedback or expressed opinion directed to them, that
contradicts, it is beneath their contempt.
"TMTOWTDI" is the catchphrase of Perl, the computing language I learned
first. But not all "ways to do it" are equal (and Larry Wall believes as
I do). I believe that factors of human psyche (how we are 'wired') make
some ways more intuitive and natural than others for the majority of
users (whilst I acknowledge that there are important diversities amongst
human beings in how we are 'wired' internally). In the course of
developing a software project, or authoring the build configuration
system in the case of the package maintainer who is not the primary
author, that individual is engaged in a sometimes-lengthy and isolated
task and can *lose touch* with a solid sense of "what to expect". In
that case the thing that needs to happen is *feedback* from users. This
goes as much for issues pertaining to build, in the case of F/O software
where the 'consumers' may be a mass market of people who will be building
the software from source code, as it does for the UI of the package
itself, etc.
Previously I wrote (but typos fixed):
> Experts ignore or dismiss this kind of data point at peril of
> being completely, truly disconnected from the reality of what the
> users they are supposedly 'serving' have experienced. If it's
> just me saying this, then how many other people who you will
> never hear from (because it doesn't seem worth it to them to make
> the effort, because they don't think 'you can fight City Hall',
> or whatever) have similar experiences? You really ignore and
> reject this broad point at risk of being a person who believes in
> a view of reality that is false. Those who believe in false
> realities -- whether religious, or philosophical, or technical --
> are doomed to hit a brick wall sooner or later. And seldom seem
> to even see it coming.
What I was trying to express in the para above is what I expounded on at
length above. The nature of programming as work itself is such that most
if not all developers need at least occasional feedback in order to
improve the useability or robustness of their project. What seems to
have happened is a general subtle shift in attitudes in which more and
more authors and maintainers seem to feel that what amounts to a defeat
and a betrayal of the principles of interdependence (and that which
ought to accompany it: openness and basic showing basic respect for
others) is "OK" behavior. Whatever it is that people think they see
elswhere in the World -- from CEOs and politicians and the like -- the
fundamental truth is that this decision to pay one's self off with
indulgence of one's arrogant nature is a deal with the devil.
Again, I wrote:
> This is unbelievably unfriendly to novice users of Autoconf-based
> 'configure'. Somewhere there is this incredible disconnect in which
> people like yourself say "users of XXX don't know about lib/ or DLLs"
> but then expect someone who would be willing to try running a
> 'configure' script to be an all-out Guru with nearly supernatural
> powers of diagnostic insight.
The point of all this verbiage is *not* that I cannot accept criticism
of a patch I show or submit. I am only a fallible human and so my
suggestions aren't 100% perfect. But it is the _basis_ on which I have
been seeing objections raised that motivates me to compose this article.
More and more I have been seeing people respond in a dramatically
close-minded way, saying what amounts to "that's a stupid waste, it
isn't necessary." This kind of reaction is indicative of the kind of
creeping rot in people's brain cells that I have been describing above.
Because that IS what Arrogance does: it rots your brain (mind).
Criticizing someone for *working too hard* or making extra effort to
make things easier for users is backwards, wrong, foolish,
narrow-minded. And it has impacts that subtract from the vibrancy and
betterment of our whole F/O software movement.
I am not suggesting that being a package maintainer means you ought to
be a doormat for abusive people to wipe their feet on, and I am far from
ignorant of the massive quantities of painfully ignorant ("clueless")
pleas for help you'll get from users who never learned to help
themselves by RTFM'ing before bugging the author. Or from the people who
just write "it doesn't work!" without giving the slightest effort to
providing descriptive detail so you can find an answer for them. I've
spent my time in the old USENET (and yes, even CompuServe before it
ended); many 1000's of hours trying to help newbie users out. I've paid
those dues and I know what I am talking about.
What I am seeing is that some maintainers seem to have no sense
whatsoever of there being a possible middle ground between being a
passive doormat and adopting a posture of passive-aggressive, full-blown
unresponsive arrogance.
Somebody wrote to me:
> > -dnl Initialize maintainer mode
> > +dnl Turn on maintainer mode to save users from Automake Hell.
>
> I don't think GLib's configure.in is the right place for statements
> like this. Personaly, I don't think Automake is that bad. It's libtool
> which is the worst (most complex, hard to read, slow) of the auto*
> tools.
My response was:
> I do not give a damn whether anyone thinks it is appropriate. The
> brief phrase "Automake Hell" does not even begin to convey how much
> trouble, how many umpteen gazillion wasted man-hours has been
> caused by the fundamental design decisions / policies of the
> 'automake' authors. Placing it in a 'configure.ac' script that
> users might read is my expression of my right to Free Speech (which
> somewhere along the line WAS connected to what Free Software was
> supposed to be about) and what's more, is done with the intention
> of emphasizing to anyone who is or might become the author of a
> 'configure.ac' file or become a package maintainer, just how
> crucial this belated Automake band-aide is (absent any better cure
> for the badness that Automake inflicts on users).
I'd like to make the following request. If you, the reader, is a package
maintainer or will become one, and particularly if you decide to base
your package build configuration of full-blown Autotools treatment with
Automake as well as Autoconf and GNU libtool, then please consider this
well.
If you are going to adopt the attitude that simply hacking out a basic,
standard Autotool'd build-config is all that's required by the standard
of Software professionalism / quality that you choose to adhere to, then
please put a BIG logo or something on your site so that I can avoid you
and your software like the Blue Plague. Something like
******* ******* ******* ******* ******* *******
* *
* M A D E W I T H A U T O M A K E *
* *
******* ******* ******* ******* ******* *******
ought to do the trick. That way I won't have to go to the trouble and
waste the time downloading your tarball, unrolling it and getting set to
build only to discover that it is Yet Another Half-Assed Autotool'd
Package (YAHAAP). And I won't have to pull out my Virtual VooDoo Doll and
sticky-note your name to it.
Your Cassandra,
Soren A
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
