Re: To the Armchair Directors

On Mon, 15 Mar 2004, Gary W. Swearingen wrote:

> Peter Schultz <pmes_at_bis.midco.net> writes:
> 
> > Don't piss off the programmers!  ;-)
> >
> > If you're not a programmer, restrain yourself from suggesting how easy
> > this or that thing would be to do.  These guys simply *do not* need
> > your "input".  Remember that this is *open source* and that if you
> > think something is worth doing that nobody else is working on, you
> > need to take on the project yourself.
> 
> The above sort of user-off-putting attitude seems inappropriate to
> this mailing list, if we're to believe the Handbook's description,
> which begins:
> 
> This list seems to be the main interface between users and developers

And it is.  As such it has its good points and it bad points.
On the one hand, users to get to talk directly to the developers.
On the other hand, the developers get to talk back :-)

> Jumping on someone for thinking out loud about the difficulty of
> a better (?) design just pisses off users instead of developers.

I have two different things to say about this, which I have stated
elsewhere, so skip over this if you've heard it ...

1. I will agree that it's not right to jump on someone for new ideas.
However ...
2. The email archives, and indeed developers' heads, are brimming with
new ideas -- in fact, many years' worth.  See the 5.3 TODO list for
the ones that the developer community considers especially important.

> Save it for the -hackers list or start up a -current-dev list
> where developers can isolate their delicate sensibilities from
> us whiny users.

You don't really want the latter, IMHO.

There are a number of developers who would immediately gravitate
to such a list, thus losing just that much more interaction between
users and developers, which is what you seem to want, right?

But the "sensibilities" thing is the key here.  With the sheer
number of people reading this list -- never mind whether they are
working at cross-purposes or not -- personality conflicts are
inevitable.  Whether it's right or wrong, you have to have a
thick skin to do well on these mailing lists, because there is
always going to be at least one person "shooting from the hip"
as we say here.

And no matter what technical solutions we can come up with,
there's just no way to work around the fact that we're people.

A corollary: you can help yourself out by not waving any red
flags in front of any bulls.  "It should be easy to ..." is a
classical example of such a red flag, and that applies to Real
Life as well as the FreeBSD project.

Having said all that, let's consider the original point that
Peter was trying to address.  (Time for anyone who's read this
far to go back up to the top and read that).

OK, back?

This is going to get a little bit philosophical here ...

Consider that with rare exceptions, FreeBSD is a volunteer project.
But it does have a "political economy" of sorts -- the source-code
change.  People that consistently generate such changes are better
thought of than people that don't.

How do source-code changes arise?

1. Someone who is sufficiently trusted (a committer) comes up with
a change and puts it in directly.  Even committers tend to keep these
kinds of changes non-controversial, and reserve the changes for:

2. Someone generates a patch and posts it in public.  In general
the GNATS database is our "community memory" for such things, but
changes requiring wider discussion generally get posted to the
mailing lists.

OK, so let's say you're not a programmer.  How can you participate
in step 2?

A. You can convince a developer that it's a Really Good Idea, so
that he or she will want to volunteer to do it, or

B. You can pay a developer to generate it for you.

People rarely do B (although IMHO there's a willing audience of
developers who would like to work on FreeBSD for a living).  And
the archives of the mailing lists probably have somewhere between
10-20% of their messages involving A -- and practically every one
of these discussions ends without changes committed.

Why?  Well, because most of the easy changes ... simply put, aren't.
To do them correctly requires a lot of knowledge about how the
system is architected, who will be affected by the changes, and
a significant committment of time to shepherd the changes through
all the testing needed to confirm that they've been made correctly.
(Never mind the effort to convince the other developers that the
idea is worthwhile in the first place).

A second problem is that many of the new ideas ... aren't new.
There's a number of "hey, how about ..." postings that seem like
they automatically re-arise every few months.  This is the type
of thing that, the 3rd or 4th time around, can drive a developer
to start pulling his hair out.  (And if you've ever seen my
picture, you'll know I have few enough left to not to want to
do that).

Add to this the fact that most of the A discussions at some point
wind up in the exact same way -- with a 'users vs. developers'
discussion -- and what you'll get is an automatic reaction from
some longtime readers of the mailing list: "oh no, here we go again".

And that's the experience that underlies the snippy responses from
developers.  It's not just that we sit around waiting to have a
chance to discourage new ideas -- it's just that in a large number
of cases, we've been through the exact same territory again and again,
and at some point frustration just sets in.

So, that's the end of my philosophical rant.

All just IMHO, I do not speak for the project, etc.

mcl