[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(FC-Devel) FreeCASE_0.0.1 NeedsA ... / let's prove Lawrence wrong
Hi Jeff, hi all,
At http://www.alt.net/~lk/cathedral-bazaar.html I found
a very sensible email about how not to get Bazaar projects
"high on enthusiasm and low on actually producing something".
In Lawrence's eyes the mistake has allready been made.
Let's be the exception to his rule. No doubt it'll make him happy.
I think we can If we have
1. a schedule: what will be in the next upcoming two/three releases
( 0.0.1 and 0.0.2 assuming a Linuxlike version-number
convention) what has been discussed for later (if known with
version where we hope it's done)
2. a well-maintained list of things to do for all versions
3. a list of all suggestions with a probable version-number.
Now Jeff, this is your call. You may have one of us do it, but
you'll have to make sure that it's done, and the lists are updated
Let's focus on the requirements for FreeCASE_0.0.1.
This will be tough.
To paraphrase Joh Mallet http://www.timaru.com/~kiwi/006/
Complete the following statement:
FreeCASE_0.0.1 NeedsA ...
(Email sent to Eric Raymond
on March 30th, 1998 about his The Cathedral
and the Bazaar paper.)
I just read your Cathedral/Bazaar paper. Since your home page
indicates that you're continuing to think about this topic, I'll throw
in some personal observations.
First some background: when BSD Net/2 came out in 1990,
Brad Grantham and I ported it to the Mac II platform. It was
released a few months later as MacBSD
(in the bazaar style, of course), and later became NetBSD/Mac.
We learned a few things being bazaar coordinators:
I know these two points seem fairly pessimistic, but I think it's too
easy to get carried away with the thought that a lot of activity means
that something is GETTING DONE when in fact it's just Brownian motion.
(Who said, "Never confuse motion with action"? Ben Franklin?) The
coordinator needs to dismiss all the enthusiastic discussions about
what the icon should look like and whether the FAQ should be in HTML
or SGML and concentrate on getting a working version of the product.
Once that happens, people will actually start to help.
- People are quick to volunteer to help, but slow to help. We got
hundreds of messages saying, "I've love to help, please tell me what's
needed." Not one of these people ended up helping, regardless of
the amount of hand-holding. The only people who helped were those
whose first message to us was, "Hey, I fixed this. Here's a patch."
Eventually we ignored all messages of the first type (just pointing
them to the to-do list) and cultivated relationships with the second.
This is something that all coordinators need to know before they're
overcome with euphoria at the sight of all the "volunteers".
(Note that they mean well, they just don't realize what they're
volunteering to do.)
- You mention this, but I think it's extremely important: you
must have a working system before you even announce
As an example, we waited until we had a bootable kernel that got to
the single-user root shell before posting to Usenet. There have since
been (to my knowledge) four different MacLinux projects. All were
announced to big fanfare on the Linux newsgroups, a mailing list was
created, everyone got very enthusiastic, a FAQ was written up, and
there was much debate about what the MacOS icon should look like. In
none of the cases was a single line of code released, or a single
kernel. I think it took MkLinux (run by Apple) to get a working Mac
version of Linux. (In one project, MacLinux was supposed to run on 68k
Macs, and all the discussion on the mailing list was about how to
port it to the PowerMacs. The 68k version wasn't even remotely
working!) These kinds of projects attract the first type of
"helpers" mentioned above. High on enthusiasm and low on actually
producing something. The quickest way to kill a project is to
announce it before you have anything. I've seen it too many times,
especially in Linux circles.
(On the positive side, MacBSD benefited tremendously from its
development style. We got code, device drivers, money, and some
hardware donated and lent for testing and development.)
I look forward to any comments on the above or anything else you might
write on the subject.