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, the project is run by a different cabal. This is the result of a
coup that took place in 2000-2001, in which The NetBSD Foundation was
taken over by a fraudulent change of the board of directors. (Note:
It's probably too late for me to pursue any legal remedy for this,
unfortunately.) Although The NetBSD Project and The NetBSD
Foundation were intended from the start to be separate entities -- the
latter supplying support infrastructure for the former -- this
distinction has been actively blurred since, so that the current board
of TNF has rather tight control over many aspects of TNP.
Were TNF comprised of a good set of leaders, this situation might be
somewhat acceptable -- though certainly not ideal. The problem is,
there are really no leaders at this point. Goals for releases are not
based on customer feedback or looking forward to future needs, but
solely on the basis of what looks like it's bubbled up enough that it
might be possible to finish in time. There is no high-level direction;
if you ask what about the problems with threads or will there be a
flash-friendly file system, the best you'll get is we'd love to have
both -- but no work is done to recruit
