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

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

Hi Eric,

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:

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

  2. You mention this, but I think it's extremely important: you must have a working system before you even announce the product. 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.
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.

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

Lawrence