http://mail-index.netbsd.org/netbsd-...8/30/0016.html

Subject: The future of NetBSD
To: None <netbsd-users@netbsd.org>
From: Charles M. Hannum <mycroft@MIT.EDU>
List: netbsd-users
Date: 08/30/2006 19:27:23

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 people to code these things, or
encourage existing developers to work on them.

This vacuum has contributed materially to the project's current
stagnation. Indeed, NetBSD is very far behind on a plethora of very
important projects. Threading doesn't really work across multiple CPUs
-- and is even somewhat buggy on one CPU. There is no good flash file
system. There is no file system journaling (except for LFS, which is
still somewhat experimental). Although there's been some recent work on
suspend support, it's still mostly broken. Power management is very
primitive. Etc. Even new hardware support is generally not being
originated in NetBSD any more; it's being developed by FreeBSD and
OpenBSD, and being picked up later. (I think the only recent exception
to this of any significance is Bluetooth support.)

For these reasons and others, the project has fallen almost to the point
of irrelevance. (Some people will probably argue that it's beyond that
point, but I'm trying to be generous.) This is unfortunate, especially
since NetBSD usage -- especially in the embedded space -- was growing at
a good rate in 2000 and 2001, prior to the aforementioned coup.

--

At this point most readers are probably wondering whether I'm just
writing a eulogy for the NetBSD project. In some ways, I am -- it's
clear that the project, as it currently exists, has no future. It will
continue to fall further behind, and to become even less relevant. This
is a sad conclusion to a project that had such bright prospects when it
started.

I admit that I may be wrong about this, but I assume that most people
who have contributed to NetBSD, and/or continue to do so, do not desire
to see the project wallow away like this. So I will outline what I
think is the only way out:

1) There must be a strong leadership, and it is not the current one.
The leadership must honestly want NetBSD to be a premier, world class
system with leading edge features. The leadership must set
aggressive goals, and actively recruit people to make them happen.

2) There must be no more "locking" of projects. Just because one person
is supposedly working on a problem, that doesn't mean you shouldn't.
If there ideas are dumb, or even just suboptimal, do it better! If
there is no progress, hop on it. Don't wait for someone else.

3) The project must become an *actual* meritocracy, not what I call a
"volumetocracy". Right now, the people who exert the most influence
are often the people who produce the least useful product. Indeed,
they are often people who produce little more than fluff (e.g.
changing line-ending whitespace!), and often break things.

4) Speaking of which, there must be negative feedback to discourage
people from breaking stuff. This has been a continual problem with
certain "developers" for more than a decade.

5) There are a number of aspects of the NetBSD architecture that are
flat out broken, and need serious rehabilitation. Again, the
leadership needs to recruit people to do these things. Some of them
include:

* serious problems with the threading architecture (including the
user-kernel interface), as mentioned earlier;
* terrible support for kernel modules;
* the horrible mess that is 32/64-bit compatibility, resulting in
32-bit apps often not working right on 64-bit kernels; and
* unbounded maintenance work due to inappropriate and rampant use of
"quirk" tables and chip-specific tables; e.g. in SCSI, ATAPI, IDE,
ACPI and SpeedStep support. (I actually did much of this work for
SCSI, but am not currently able to commit it.)

6) The existing NetBSD Foundation must be disbanded, and replaced with
an organization that fulfills its original purpose: to merely handle
administrative issues, and not to manage day-to-day affairs. The
extra committees, which mostly do nothing, must be disbanded -- they
serve only to obfuscate things. Everything else must revert to the
historically separate entity, the NetBSD Project, to be managed based
on technical merits. There must be no perceived glamour in
participating in the Foundation; it must be composed of people doing
it because they are dedicated and want to help the project.

(I will note here that this is not due to bitterness over the coup.
Keeping the NetBSD Project as an unincorporated association actually
helps protect it.)

7) The "core" group must be replaced with people who are actually
competent and dedicated enough to review proposals, accept feedback,
and make good decisions. More to the point, though, the "core" group
must only act when *needed* -- most technical decisions should be
left to the community to hash out; it must not preempt the community
from developing better solutions. (This is how the "core" group
worked during most of the project's growth period.)

8) There must be a set of commit standards -- e.g. about when it is or
is not acceptable to commit changes that do not change functionality;
when multiple changed must be batched in one commit; etc. Right now
it is difficult to sort the wheat from the chaff. In addition, there
must be standards of review.

I must repeat a point I've made earlier. The current "management" of
the project is not going to either fix the project's problems, or lead
the project to solutions. They are going to maintain the status quo,
and nothing else. If the project is to rise from its charred stump,
this "management" must be disbanded and replaced wholesale. Anything
less is a non-solution.

--

To some of you, I would like to apologize. There *are* NetBSD
developers doing good work even now. I'd like to particularly recognize
and thank those working on kernel locking and UVM problems; wireless
support (though I'm not sure what happened to my extensive set of rtw
bug fixes); Bluetooth; G5; and improved ARM support. This is all good
stuff. In the bigger picture, though, the project needs to do a lot
more.

--
- Charles Hannum - past founder, developer, president and director of
The NetBSD Project and The NetBSD Foundation; sole proprietor of The
NetBSD Mission; proprietor of The NetBSD CD Project.

[I'm CCing this to FreeBSD and OpenBSD lists in order to share it with
the wider *BSD community, not to start a flame war. I hope that people
reading it have the tact to be respectful of their peers, and consider
how some of these issues may apply to them as well.]

I read this a couple days ago. It's quite shocking and very, very disappointing. I've been using NetBSD off and on for several years and I really like the runs-on-anything appeal, even though I use only x86 so far.

But I was pleased to see various responses of people using NetBSD who are happy with it. So maybe it's not so irrelevant.

Moved: This is definitely news-worthy, and has been moved to News accordingly,
with a redirect staying in BSD.


Cheers,
Tink

I posted this over on the bsdforums. But I tend to disagree with many things it makes seem deadly. Frankly, he has a point about a few items (mostly locking items for people who seem to never get around to working on them)... but this "let's give up" view that permeates most of the email bugs me. It just isn't representative of any of my experiences and interactions with the project.

Yes, he makes some points. But I think overall he's wrong.

Also... it's interesting to note the email sent out to the list today and who has his name in it. Could this have anything to do with his original post? I note that he did have advance notice that this was happening. What is his objection to signing the form and does that play a role in a message designed to create desire to remove the current "core"?

Thank you, frob23, for posting this.
That's quite a different story. The only other piece of information I have is that I have noticed in recent years, the NetBSD website obviously has top notch people taking care of it, and the product itself, though I'm still not at home with it, seems very useful.

I think Alistair Crooks's version is more believable.

Edited: typo

If you have the time, I highly recommend reading the mailing list on this subject. http://mail-index.netbsd.org/netbsd-users/2006/09/ All the "History of the NetBSD Foundation" messages. You will see that this intro post doesn't even start to explain what really went on and both sides of the story come out.

Frankly, after reading that whole thread and the original (which is around 200 messages)... I find myself questioning Charles M. Hannum's motives with the original post. And I find even the points I semi-agreed on to hold less signifigance than I may have originally been led to believe they had. In honesty, I don't know of any projects which are locked and the only patches I have seen not put into the tree are bugfixes which are both very rare and also make drivers incompatable or non-working with many systems.

So... I (a person who posted the original message in at least two different locations where I talk or discuss NetBSD) regret having posted that. I didn't post it here but it did get here anyway.

If I had waited a couple days to see and read it from both ends I may have known the actual intentions of the person. As it was, I feel I was misled in several ways.

But, don't take my word for it. The actual discussion (at least under the History thread) is very interesting and has both sides making their cases and you can draw your own conclusions.

Even as I was reading the original post, I was wondering in the back of my mind what the motive was. If not the face-value meaning, it could be sour grapes or revenge, but consider this from the mail list. So maybe he's really a good guy rounding up help!

For better or for worse, he sure brought NetBSD some attention.

If you read his own words you can see that he wants nothing less than the overthrow of everything and it going back to the way it was. Which happened to include him on the board of directors. I am not at all sure his motives are benevolent. If they were they completely backfired.

DeadBSD ?

This might not be relevant but it is funny to watch:
BSD is dying

I Ihink NetBsd only has a feature in the Internet Service Provider Srctor because Linux, Unix and Mac OS X (Based apon the original Berkly Software Distribution) and of course windows have the lions shae of the market.

I sat here and watched the video, and ultimately downloaded it. This whole discussion seems like affirmation for me. Since when I tried FreeBSD in 2000, I complained then of it not meeting the needs of the user. My posts are still available in various places on the web concerning this.

So here I am now, using Linux as my OS. Specifically, Slackware and it's variants. I am beginning to use the NetBSD pkgsrc as a means to expand the software database for those Slackware variants. However, I am committed to using the Linux kernel, because as I pointed out in 2000, it was better developed, and presented the user with a broader range of utility than any BSD. I was accustomed to using things like software RAID and LVM. Neither of which was nearly as mature in BSD as Linux. So I stopped fighting the community and went where the action was. Although, I must acknowledge my pleasure at seeing Dragonfly's commitment to doing some of the very things I had previously asked for. Clustering, being my greatest concern.

I'm not sure how well my attempts will work, but I have the will to work them into a usable system. I have this knack for taking anything that works, regardless of where it came from, and incorporating those functions into my daily usage. I intend to do the same now, by providing an operating system which merges as many tools as possible into a cohesive environment. My foremost concern is development. So much effort is spent on capturing anything that's out there for that purpose. I personally don't believe it is appropriate to presume that what I don't conceive won't be conceived of by others. So I won't and don't adhere to the thinking that no one would want to do this or that. Instead, I want to give as much latitude as possible for anyone to do anything they want with my system. Including not using it, if they feel so offended that something like it should even exist.

So I will be posting here and elsewhere, looking for the participation of others to provide knowledge and code as they can, to produce this monstrosity of vision.

1. I want the system to be as generic as possible.
2. I want the sources to compile on any system, using only generic code as dependencies. (Nothing specific to Redhat:rpms Debian:debs or anything else like that).
3. I want as much as possible, for sources to be written in an architecture neutral manner as allowable.
4. Code should be as uniform as possible. Using variables most of the time to configure itself for compilation. Using things like $(uname -r), $ARCH, and the like. Instead of being specified by the code, and having then to be modified by the user compiling it, to suit their own environment.

So if any of you might be interested in this sort of thing, feel free to contact me.

Xavian-Anderson Macpherson
Shingoshi

@Shingoshi:
Yeah you are right. It is pretty sad. Unfortunately I have very, very, very little programming skills so I won't be able to help you and I think that you will not find a lot of BSD people here (although there are a few). I think that when Gentoo/BSD takes off a lot of Gentoo users will start to use, or at least look at, Gentoo/BSD and hopefully that will shed a light on *BSD. I also think that you need to represent something working first. Something users would like to see. *BSD is very technically orientated. What makes Linux so popular now is that it is getting user friendly. Maybe make a user friendly *BSD distro that incorporates binary blobs and Microsoft evil and maybe people will start looking at it. I think the reason that most devs leaved *BSD was because Linux was getting so many users.

The other 'problem' with *BSD is that it is released under the MIT license. People who use *BSD claims that it is more free and the GPL is the evil. But in fact it is the GPL that is more free. It is a insurance that everything that is free stays free. Now that is more freedom to me. Now almost nobody (except Apple) is contributing their code back to *BSD. So what happens is that you give it away, but are not getting it back. Giving away and receiving back is a powerfull foundation: You boost others and others boost you back. That would make *BSD a lot more powerful. Not to mention all the GPL code you could use for drivers and alike.

They didn't ask him to sign an agreement, they gave him an ultimatum.

That's a bad thing to do to a developer if you want them hanging around.

-Viz

I didn't really want to take your bait, but there are some facts here that need to be corrected. First, there are no BSD-based operating systems whose kernels or core utilities are under the MIT license; they are under a variation of the original BSD license. According to Wikipedia, PC-BSD even used to place its configuration and graphical configuration tools under the GPL due to the fact that they used Qt. But never to my knowledge has the kernel or a project-specific utility been under the MIT license. (Included libraries, of course, are a different story.) The BSD license is very similar to the MIT license in most practices, of course, but they are not quite the same. Compare the new BSD license with the MIT license.

Second, not all BSD users think GPL is "the evil". I use FreeBSD, NetBSD, and OpenBSD and I think the GPL is generally a good idea. Not to say that it can't be abused, just like the BSD license can be taken advantage of. But then again, one of the reasons which lead to the BSD TCP/IP stack becoming the basis of the Internet was its wide-open nature. And when other operating systems came on the scene looking for a stable, reliable, standards-compliant TCP/IP stack they could use the BSD one, providing credence to the BSD software. So both licenses have their strong points, and to contend one or the other is obviously and ineffably superior is self-defeating.

Third, the BSD projects do receive code back from other companies, for example Sun Microsystems. The reason they don't get tons of code back is because not that many people are writing systems that actually add to the BSD kernels! It would really be a fairer argument to say that code is not contributed back to projects that make available source code under similarly unrestrictive licenses. So let's take Python as an example, which does not disallow the distribution of (perhaps modified) binary-only versions. They have massive use across many industries, as well as many supporting companies which have no doubt contributed back to the original source tree. So this argument about nobody giving back to non-Copyleft systems just doesn't hold water. And there are some who would argue that psychologically it is better, because people are more likely to give back when they're not forced to do so.