Slashdot Mirror

I find humor in the fact that Emmett didn't even provide a link to the Ottawa Linux Symposium website... Anyway a couple others are listed here: Most notable and/or accessible for North-Americaners would be the Linuxworld Expo in San Jose, August 14-17, and the Atlanta Linux Showcase Oct 10-14. Also, here is a list of Corel tradeshows.

If anyone knows of others, please speak up (It took 2 minutes on Altavista to find these).

And I don't see why Slashdot couldn't announce every upcoming conference, or at least every conference that requested announcing. iT's only an inch of screen space... this is supposed to be a community site, after all. Sounds like a slashbox-in-the-making.

imuho

Werner Almesberger will talk about the interesting possibilty of launching a new Linux kernel from within Linux. This sounds like a cool feature, in theory you wouldn't even have to restart a machine for kernel upgrades anymore.

There's an mp3 from a previous talk at the 1999 Ottawa Linux Symposium here. Very good information!

There's an mp3 from a previous talk at the 1999 Ottawa Linux Symposium here. Very good information!

Brooks's Law still applies to free software projects. They just handle it differently. This was the topic of the keynote presentation that Alan Cox gave at the Ottawa Linux Symposium last summer. In essence, if I recall it correctly, he said that free software projects work around it by using communication structures quite different than in commercial development.

Free software projects still tend to have one prime architect who has final say over what goes into the project and what doesn't (e.g. Linux for Linux). These architects tend to be supported by a small team of core developers, an arrangement which recalls the "surgical" team model in MMM.

The size of project teams is limited by the n-squared communications cost. Cox suggested that the useful limit is about six people. More than that, and they spend more time talking than working. Free software projects tend to live to this limitation by aggressive modularization. Whenever a project gets too big, it fissions into a group of smaller subprojects with well-defined interfaces. He gave the GNOME project as a good example of this, as well as the Linux kernel.

Free software projects do have a different communication and training style than the commercial development that Brooks focused on. In free software, you're encouraged to contact directly the person who can answer your question, instead of passing messages up and down the management heirarchy to get permission to do so. Training is somewhat reduced, since new contributors are expected to read the source code before jumping in. One method that Cox mentioned was that an experienced developer will give a new contributor some small individual piece to work - in effect, a new subproject.

Still, as noted elsewhere in this discussion, the biggest advantage free software has in this regard is flexible deadlines. Projects aren't done until they really are done, since there's typically no sales department or management to set a deadline.

You can listen to the keynote in MP3 at ftp://ftp.ottawalinuxsymposi um.org/ols1999/keynote.mp3.

ESR asserts that open source reverse Brooke's Law.Not from what I've seen. Linux being a case in point - lets face it, we all know which 10 or fifteen developers do most of the core work, and X is handled by an entirely different group. Brooke's Law is alive and well.

This is exactly the point that Alan Cox made in his keynote presentation at the Ottawa Linux Symposium last weekend. Alan did a comparison of how software engineering is done in big firms and by free software projects, and found them to be rather similar. It was most striking in regard to team size, where both styles of development work around an upper bound of 6 people per team. In companies, a heirarchical management structure breaks the developers up into small groups. Free software projects tend to fission as they attract developers, becoming a cluster of small related projects, all with small core teams of 6 or fewer developers. He pointed out the GNOME project as a good example of this, and after looking at the number of modules in GNOME CVS, I'm forced to agree.

This has some consequences for free software, that came up intermittantly in other sessions at the conference, so I found the keynote to be inadvertantly a good summation. For this fissioning to work, free software has to be much more modular than proprietary, and this leads to a strong role for developing interfaces in free software. Alan also pointed out that it also tends to lead to a lot of duplicated code. Both of the GNOME sessions, as well as the Mozilla one, strongly emphasized the need for component software, glued together with high-level languages for the user interface stuff.

Appropriately enough for this discussion, the Mozilla presentation by Mike Shaver (and a Netscape engineer whose name I've forgotten) was the session immediately preceding the keynote. As a result of it, I'm extremely confident about Mozilla's future (and I'm not just saying that because I got a Mozilla t-shirt there!).

If you'd rather contribute your code under a BSD license, you're in luck. The MPL is basically a file-granularity BSD license, sans advertising clause. Because of that granularity, new code you write in new files can be MPL'd, though changes you make the NPL'd code will still be under the NPL. This means that you could add mynewcoolthing.c under the MPL, and NSCP/AOL would have no special rights to it. And we at Mozilla would happily take that new file into the CVS tree and cherish it greatly.

I understand that people don't like the NPL-takeback clause very much; I'm not a big fan either -- though I understand the reasons for them, and they are good reasons, covered at length in the mozilla.license newsgroup -- and I'm lobbying gently to have more new code be written that is MPL'd rather than NPL'd. We'll see how much progress I can make. (Probably not much before 5.0 ships, perhaps more after.)

As far as whether it's Free Software, both the NPL and MPL were deemed to meet the DFSG, which was then the canonical metric for such things. I'm sorry it's not free enough for you, and I do sympathize with your concerns, but there aren't a lot of other options, unfortunately.

(Note: IANAL, though I was involved in the NPL design discussions pretty much from the start. I'll see if I can get some legal type to follow up, but I'm not confident that I can.)