Subject: Re: open source process issue
From: "Brian J. Fox" <>
Date: Sun, 07 Oct 2001 08:49:34 -0700

   Mailing-List: contact; run by ezmlm
   Date: Sat, 6 Oct 2001 23:52:36 -0700 (PDT)
   From: Tom Lord <>

   It seems to be that any consideration of FSBs must include
   consideration of the quality and dangers of the loosely
   circumscribed collection of engineering practices known as the
   "open source processes".

   Here is one proposal that I've sent to a project that I think has a
   history of trouble.  It can be applied to other complex projects as

   "engineering on!??"

What you are proposing is a fundamentally different way to create open
source than has been seen in the past -- including many well-known and
successful projects.

From a maintainer's point of view, (i.e., management), what you
suggest is an excellent way to manage the numerous OS developers that
"work for you".  However, from the view of the hacker (i.e.,
employee), this is simply another place in which his or her efforts
must be scrutinized before being utilized.

In traditional OS development, your code gets scrutinized *after* you
write it, and generally *only* if it doesn't work, or if it interferes
with making something else work.  The beauty of this situation is that
developers get to write code which is immediately used, and (this is
the important part) which often prompts the demand for additional
features or capabilities in the code!

If I had to pass my coding on readline by a committee, it never would
have been written.  If Chet Ramey had to get all of his "vi
enhancement" decisions through a committee, he wouldn't have written

As another example, I wrote GNU Finger 1.0 during the 5 day Christmas
vacation of 1988.  It allowed one to see all of the user activity in
an arbitrary network of machines by talking to any one of them, and it
had a ".face" extension which allowed an image associated with a user
to be displayed.  RMS didn't want GNU Finger, and got *angry* with me
for creating it (during Xmas vacation, mind you).  But the users
wanted *something* like it.  So, because it existed, it eventually
(circa 2 years) got adopted by the FSF, and then subsequently hacked
to bits by various individuals.  Some of the changes were good
(e.g., enhancing the communications channel), and some were bad (e.g.,
removing the ability to display faces under X), but those decisions
wouldn't ever have been made if the code that I wrote hadn't existed
in the first place.

Lastly, while I find the essence of your proposal well thought out, I
believe that the choice of Emacs as the way in which your documents
will be read and modified an incredibly bad choice, which would limit
the usuability of your systems to only those that have, *and use*
Emacs.  Even though I happen to be one of those people, I would like
more OS hackers from all walks of life, utilizing whatever tools they
find themselves proficient in.

So, interestingly enough, to get your idea adopted, you should write
the software which makes it easy to manage your new documents, from
creating them, to commenting on them, and you should make that
software be available on a large number of platforms.  Once this is
done, you may stand a chance of having some portion of the OS
community use these tools, perhaps for a specific project in the
office productivity area.

== The Difference Between Cultures: ==
    Einigkeit und Recht und Freiheit
    Liberte', E'galite', Fraternite'
    Sex, drugs and rock'n'roll