Linked by Eugenia Loli on Thu 31st Aug 2006 01:29 UTC, submitted by sequethin
NetBSD Charles Hannum, co-founder of NetBSD posted to 3 major BSD lists saying that "The NetBSD Project has stagnated to the point of irrelevance. It has gotten to the point that being associated with the project is often more of a liability than an asset. I will attempt to explain how this happened, what the current state of affairs is, and what needs to be done to attempt to fix the situation."
Thread beginning with comment 157340
To read all comments associated with this story, please click here.
Linux
by nick on Thu 31st Aug 2006 02:32 UTC
nick
Member since:
2006-04-17

Interesting read. I don't think he's quite right about
leadership in Linux though: Torvalds doesn't set goals
and directions, others do. He arbitrates. He is pretty
fair, doesn't take personal offence or do special
favours, and largely lets the developers take it where
they want.

That said, he has input design and direction into some
areas (eg. VM) but that is more as a developer than as
a leader.

Now one of the reasons he is such a good arbitrator is
that he is technically brilliant, and is familiar with
most areas of the kernel at any one time.

But he isn't really the top man calling all the shots.
He is top in that he maintains the git tip, but
responsibility and leadership is very distributed (and
was, long before a distributed SCM was adopted).

The difference I see with linux kernel development
and BSD development (the latter I'm not that familiar
with), is that Linux doesn't have any secret mailing
lists, cabals, repositories. People aren't elected or
given the right to make decisions by anything other
than their technical abilities. You don't need to have
some special bit, or be inducted into the club, or
have a "mentor" before you can get a patch in. You
just have to write good code.

Possibly the very development oriented mailing lists,
where people post their intermediate results, peer
reviews happen, etc. is much more common on lkml and
this may have actually been the lack of a SCM that got
them working in this good mindset.

And GPL. I have a feeling that people and companies are
more inclined to want to contribute to a GPL project
than a BSD one (although there are obviously counter
examples in each direction).

Reply Score: 5

RE: Linux
by phoenix on Thu 31st Aug 2006 03:39 in reply to "Linux"
phoenix Member since:
2005-07-11

The difference I see with linux kernel development
and BSD development (the latter I'm not that familiar
with), is that Linux doesn't have any secret mailing
lists, cabals, repositories. People aren't elected or
given the right to make decisions by anything other
than their technical abilities. You don't need to have
some special bit, or be inducted into the club, or
have a "mentor" before you can get a patch in. You
just have to write good code.


No, the difference is that Linux CVS access only lets you play with the kernel sources, while BSD CVS access lets you play with the sources to an entire OS.

You don't need a mentor, or to be elected to core, or have access to "secret" mailing lists in order to get patches commited to a BSD CVS repo. You just need to send patches that make sense, with nice style, and actual design behind it. In other words, you just need to submit good code.

Not just any Tom, Dick, or Harry can get a patch commited to a BSD or Linux CVS repo (although sometimes it seems like they can on the Linux side of things).

Reply Parent Score: 5

RE[2]: Linux
by sbergman27 on Thu 31st Aug 2006 03:44 in reply to "RE: Linux"
sbergman27 Member since:
2005-07-24

"""No, the difference is that Linux CVS access only lets you play with the kernel sources, while BSD CVS access lets you play with the sources to an entire OS."""

How do I obtain this Linux CVS access you speak of?

Git outa here! ;-)

Reply Parent Score: 1

RE[2]: Linux
by nick on Thu 31st Aug 2006 03:50 in reply to "RE: Linux"
nick Member since:
2006-04-17

What do you mean, "no"?

Yes. That *is* a difference I see.

While non committers can have patches accepted, it
seems like it isn't that easy; and those with commit
access can get patches through virtually unreviewed.

Secondly, Linux doesn't use CVS for SCM, but git. And
I don't see the big deal (or much difference,
development-wise) by having everything in a single
tree.

It isn't like BSDs can make a wholesale change to the
kernel API and audit their base system + everything
they pull in (not unlike most Linux distros). BSDs
tend to need to be very conservative with kabi
changes like Linux. For example there was a recent
netbsd debate (IIRC) about whether to disallow 0 length
mmaps. If such a change was to be made, they wanted
a new syscall so it wouldn't impact old programs.

But hey, if I want access to glibc sources I can
download them. If I want access to gcc sources I can
download them. What's the problem and why would that
difference make a big impact to success of the project,
on a development level?

Reply Parent Score: 2

RE: Linux
by asenchi on Thu 31st Aug 2006 04:48 in reply to "Linux"
asenchi Member since:
2006-08-31

"You don't need to have some special bit, or be inducted into the club, or have a "mentor" before you can get a patch in. You just have to write good code."

Wow, I haven't laughed that hard in a long time. I am not sure you should say such things until you look at the source for *BSD's and then compare it to Linux. Linux source code is disgusting and someday will come back to bite...

Reply Parent Score: 2

RE[2]: Linux
by nick on Thu 31st Aug 2006 04:59 in reply to "RE: Linux"
nick Member since:
2006-04-17

Wow, I haven't laughed that hard in a long time. I am not sure you should say such things until you look at the source for *BSD's and then compare it to Linux. Linux source code is disgusting and someday will come back to bite...

Actually I have looked at parts of Linux and FreeBSD
(VM in particular) kernel source code. I happen to
think there is nothing wrong with Linux.

But you don't have to take my word for it:
http://lwn.net/1999/0121/a/vmreview.html

"In general terms, linux's VM system is much cleaner
then FreeBSD's... and I mean a *whole lot* cleaner"

"Well, the main thing is that the Linux VM system is
very, very clean compared to the FreeBSD implementation."

"Linux demarks interrupts from supervisor code much
better then we do."

And while FreeBSD may have been improved since then,
it retains the same overall VM design from that time,
as does Linux (although Linux now has a reverse
mapping infrastructure).

What makes you say it is disgusting?

Reply Parent Score: 4

RE: Linux
by Mark Williamson on Thu 31st Aug 2006 14:37 in reply to "Linux"
Mark Williamson Member since:
2005-07-06

> And GPL. I have a feeling that people and companies
> are
> more inclined to want to contribute to a GPL
> project
> than a BSD one (although there are obviously
> counter
> examples in each direction).

Interesting that you say that - I don't often hear that line of reasoning but it's one I agree with.

Personally, I'm inclined to GPL my own work so that people will be required to make source of modifications available - makes it harder to create a closed fork. However, I'd have no problem BSD-licensing code if contributing to a BSD licensed project - it's a fine license.

People often say the BSD license is company-friendly because it allows source to be imported without having to release modifications. I think there are two kinds of company friendliness at work:
1) BSD license: the ability to import code without worrying about needing to release changes, getting sued for not doing so, having to contribute code which may benefit other companies
2) GPL: the guarantee nobody *else* will be able to benefit from any changes you contribute without also letting you benefit from their changes. Other companies can build on your work, but you get to do the same.

Although most companies would obviously like high quality open sourced code that they can incorporate into closed projects, I personally believe the latter protection is where the GPL appeals to many companies: it enforces co-operative development by forcing changes to be released. Nobody else can build on stuff you paid for, without doing you the same favour - so you've always got code thats at least as good as competitors using the same base.

This in turn has the nice effect of allowing smaller companies to punch above their weight: leveraging existing open codebases has allowed companies like RedHat and Novell to share changes even though their competing, which makes the system better and enables them to compete more effectively with larger companies with a closed model.

Not to say the open source model is always right, but it does seem to encourage co-operation that benefits the consumer.

Reply Parent Score: 5