The Future of NetBSD

ErisCalmsme writes "In this email Charles Hannum (one of the founders of NetBSD) tells us 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.' What will happen to NetBSD?"

Comments

This is too important NOT to RTFA

[RLiegh]

So, for your convience, I'm posting it here:

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.

As one of the 4 originators of NetBSD, I am in a fairly unique position.
I am the only one who has continuously participated and/or watched the
project over its entire history. Many changes have taken place, and at
the same time many things have remained the same -- including some of
our early mistakes.

I'd like to say that I'm some great visionary, who foresaw the whole OSS
market, but the fact is that's BS. When we started the project, Linux
and 386BSD were both little hobbyist systems, both pretty buggy, and
both lacking a lot of important hardware support. Mostly we were
scratching an itch: there was no complete package of 386BSD plus the
necessary patches to make it run on more systems and fix bugs, and there
was no sign that Bill Jolitz was going to resurface and do anything.

Much of the project structure evolved because of problems we had early
on. Probably our best choice was to start using central version control
right off; this has enabled a very wide view of the code history and
(eventually) made remote collaboration with a large number of developers
much easier. Some other things we fudged; e.g. Chris got tired of being
the point man for everything, and was trying to graduate college, so we
created an internal "cabal" for managing the project, which became known
as the "core group". Although the web was very new, we set up a web
site fairly early, to disseminate information about the project and our
releases.

Much of this early structure (CVS, web site, cabal, etc.) was copied
verbatim by other open source (this term not being in wide use yet)
projects -- even the form of the project name and the term "core". This
later became a kind of standard template for starting up an open source
project.

Unfortunately, we made some mistakes here. As we've seen over the
years, one of the great successes of Linux was that it had a strong
leader, who set goals and directions, and was able to get people to do
what he wanted -- or find someone else to do it. This latter part is
also a key element; there was no sense that anyone else "owned" a piece
of Linux (although de facto "ownership" has happened in some parts); if
you didn't produce, Linus would use someone else's code. If you wanted
people to use your stuff, you had to keep moving.

NetBSD did not have this. Partly due to lack of people, and partly due
to a more corporate mentality, projects were often "locked". One person
would say they were working on a project, and everyone else would be
told to refer to them. Often these projects stagnated, or never
progressed at all. If they did, the motivators were often very slow.
As a result, many important projects have moved at a glacial pace, or
never materialized at all.

I'm sorry to say that I helped create this problem, and that most of the
projects which modeled themselves after NetBSD (probably due to its high
popularity in 1993 and 1994) have suffered similar problems. FreeBSD
and XFree86, for example, have both forked successor projects (Dragonfly
and X.org) for very similar reasons.

Unfortunately, these problems still exist in the NetBSD project today,
and nothing is being done to fix them.

--

I won't attempt to pin blame on any specific people for this, except to
say that some of it is definitely my fault. It's only in retrospect
that I see so clearly the need for a very strong leader. Had I pursued
it 10 years ago, things might be very different. Such is life. But
let's talk about the situation today.

Today,

Not a great loss, I'm sorry to say.

[Cicero382]

The great advantage that NetBSD had was its fast and secure network facilities. Unfortunately, for many potential users the problems far outweigh the benefits. And the situation has been getting worse for some time now.

Bye-bye NetBSD, it was good while it lasted.

Give me a break.

[ad454]

NetBSD is not dying. It is getting better and better with new features and improvements being added all of the time. In addition to steady developments, Google summers have really boasted NetBSD.

I guess for some, having a lightweight, decent, and stable OS that does what it is suppose to do not enough. Admittedly their are many needed userland applications, epecially commercial applications that won't run on NetBSD. But if that was my primary concern than I would only run Windows XP. And when it comes to userland opensource, nothing beats PKGSRC. Especially when compaired to Linux equilibrants like SuSE yast.

When you ask the average person, all that they care about is the bells and wistle in the window manager and not much else. Think aqua in MacOSX or aero in WinVista.

Alicia.

Re:Not surprized

[Renegade88]

What I'm surprised about is that you read the email chain but came to the conclusion that Theo's ideas were "ignored". That's not what happened. They desperated wanted his ideas and his code, but they told him he could not COMMIT the code himself, but rather work through an intermediary, one that had no technical skill. It's like telling the former CEO to report to the janitor. You got it half right, but either you didn't read the whole chain, or your memory is failing you.

Re:What goes around comes around

[Renegade88]

I read the email log extremely closely. Charles was in the process of creating a "special" set of rules for Theo, that only Theo had to agree to. While he was being jerked around, five additional people earned commit priviledges, but where not made to agree to these "new" criteria. This set of rules was never completed, it was dragged out intentionally, basically "you have to agree to these rules first, but you can't do that until we write them, and we can't give you a date when we will write them even though it's already been weeks".

I would love to post the link to the email log but it would crash the server it's on.

Even though the developer put in charge of Theo's sparc port wanted Theo to have his commit priviledges restored, and asked for it a couple of times, the core refused. The only "workable" solution that was offered was that Theo could pass his diffs on to the port developer and let him merge them. Basically it was a set of conditions that nobody would agree to. The email chain is quite clear that Charles was instrumental in Theo losing the commit priviledges and never intended to restore them. It is also obvious they were jerking him around until he just quit on his own.

My take on Theo:
I think his "utter asshole" reputation is not accurate. He's said some things he probably wants to have back, and likely hurt some feelings. I also think he was cordial during this 7 month jerk-around session, enduring it FAR longer than most people would, and he said all the right things to earn the commit priviledges back. He was willing to "play ball".

Charles might be a good guy, but he wasn't well like during this time in 1995 and forcing Theo out is a black mark on his record. You can't tell me NetBSD is better off now (dying) without Theo then they would have been with him on their team.

Re:Sounds bleak

[bradkittenbrink]

I thought it wasn't referring to anything in particular, but I think it should have been referring to Debian kFreeBSD. That's the clear migration path for linux users if linux goes belly up.