BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Confessions of a Recovering NetBSD Zealot
Pages: 1, 2, 3

How much did the (in)famous BSD lawsuit hit NetBSD code base and popularity?

Charles M. Hannum: There was a lot of FUD around this issue--some of it from Linus, actually--and it did cause us some problems. The reality is that we had a signed agreement with USL that essentially said we had to upgrade certain files from their Net/2 versions to 4.4-Lite, and not distribute some other files at all (which we never used in the first place). We were in the process of moving to a 4.4-Lite base anyway, so this had virtually no impact on development. It did, however, delay making our CVS history public--far longer than it should have--because we needed to remove some of that early history in order to meet the conditions of the agreement.

I've never seen the similar agreement between USL and FreeBSD, but my understanding from what I've heard is that it is quite different. This caused some more FUD to be generated, because apparently what we did would not have met the terms of FreeBSD's agreement.

Had Novell not bought USL when it did, it's unclear to me how this would have panned out. I've never been able to convince myself that Berkeley was in the "right." However, Novell put a swift end to the suit, the agreement is very clear, and nobody cares about that early code history any more--so this is all water under the bridge.

Have you read the legal settlement after it was recently made public? Any surprise?

Charles M. Hannum: Yes, I read it. The first thing to note is that this agreement was with Berkeley. We executed a separate agreement with USL (which has not been made public), and that is what governs our relationship. There were no surprises when we read the settlement, but it wasn't really relevant to us.

If you had a separate agreement, you were free to work on your software without problems. Do you think that the general and chaotic FUD about the lawsuit hit you even if you had already solved the problem?

Charles M. Hannum: Absolutely it hurt us. A lot of people (and I don't want to be divisive, but honestly they were mostly Linux proponents, including Linus himself) spread FUD for years about BSD systems being "unsafe"--even after the UCB/USL lawsuit was settled. The fact is that there was no danger in using NetBSD in a product, and a number of companies did so.

How was NetBSD funded during these years? Who managed these funds and how?

Charles M. Hannum: In the beginning, we just put the machines on the UCB and MIT AI lab networks, because we had access to do that and nobody minded. The server equipment was purchased by Chris Demetriou. The project per se had no "funds." Later on, colo space and machines were donated by a variety of organizations (NASA, and, etc.), and again no money changed hands. Later on we started collecting donations to purchase hardware; colo space was (and is) still donated, primarily by ISC now.

As far as funding marketing work, such as conference appearances and merchandise, most of that was paid for by me, d.b.a. The NetBSD Mission. A fraction of the cost of the Comdex booths was paid for by LinuxMall. Most of the other conferences gave us "free" booths--that means the conference itself didn't charge for the booth, but we (I) still had to pay for everything else (carpeting, furniture, shipping or renting equipment, union labor, etc.). Producing CDs and T-shirts to give away (we tried selling them at conferences, but that didn't go over well, especially at Comdex) was also fairly expensive; it adds up quickly.

Do you have any regret about the way NetBSD promoted the project and did advocacy at conferences around the world?

Charles M. Hannum: No. Unfortunately there is no longer a concerted effort to do this, and particularly to give away copies that people can try. Frankly I'm not sure (and wasn't even then) that giving away copies to install on a PC will impress people much anyway, given that NetBSD's installer is still very primitive compared to the Linux distros. Many reviews have focused on this and lambasted NetBSD for it.

What is your opinion about strong links with vendors? For example, NetBSD and Wasabi, or Linux and Red Hat and other commercial distros, where these Linux distros try to push in their code and favorite features, for example, file systems.

Charles M. Hannum: That one is complicated. Part of the point of the "coup" was obviously to get more Wasabi people into the new hierarchy, and there were some very strange and discouraging actions that resulted from that. Wasabi also marketed itself with the tag line "The NetBSD Company" early on, which was clear trademark infringement--but due to the influence of Wasabi people on the organization, there was nothing I could do about it at the time. Meanwhile, the Foundation was sending legal threats to other people producing T-shirts with NetBSD logos on them, alleging trademark infringement.

In addition, Wasabi actually held up a NetBSD release for more than a week, while failing to tell even the developer community why. (The main release engineer happened to be a Wasabi employee, so this was easy.) After I personally pushed the release out without them, it was finally revealed that this was because there was a secret arrangement, which only Wasabi employees and Wasabi board members knew about, to do a combined NetBSD Foundation and Wasabi press release. They were actually upset at me for preempting this.

But it gets even more incestuous than that. The new bylaws were written, also in secret, by people with an interest in Wasabi. They were presented wholesale to the developer community (even I didn't get a say in them before that, and I was one of the two Foundation board members). I repeatedly asked for a definition of what the goals were for a reorganization, and complained about certain problems (e.g. that the dissolution clause actually instructs the Foundation to do something that's illegal), and was completely ignored. In fact, all input on the proposed bylaws was either discarded or completely ignored; no changes were made.

Let me put the question out there. Is this how you think the relationship between a for-profit company and an open source group should work? Even the biggest distros don't have this kind of influence on Linux.

That said, Wasabi mostly does its own thing now, and doesn't really contribute much of its work to NetBSD. I was concerned at the time about the possibility of a "brain drain"--people going to work for Wasabi and no longer hacking on NetBSD on their own--and it turns out that this has in fact happened (and I've seen multiple complaints about it recently).

The Linux structure is set up such that Red Hat can't push things into the Linux kernel on a whim. They do sometimes keep their own changes and put them in their releases, but there is a concerted effort not to do that too much (possibly more because it would annoy the community than because they don't want to). So Red Hat has not really had an undue influence; I think their contributions have largely been positive.

This is rather unlike the current NetBSD situation, where Wasabi people can effectively do whatever they want, and there is no check and balance.

Can you elaborate on the trademark infringement?

Charles M. Hannum: You probably thought NetBSD was free--like Linux, you can download it, burn some CDs, and sell them. Or make T-shirts or bibs and sell them. Well, it used to be, but it's not any more. If you put NetBSD CDs or other merch up for sale, you can expect to get a nasty letter from the NetBSD Foundation accusing you of trademark infringement and demanding royalties. I don't know how many letters they actually sent, but we've gone from at least 6 CD vendors in the U.S. to one in the last few years.

What do you consider the biggest errors made by the NetBSD Project?

Charles M. Hannum: First, the short list:

  1. Not establishing a source of funding early enough.
  2. Not developing a package system from day one.
  3. Not backporting hardware support to the previous "stable" release.
  4. Not restricting access of developers who repeatedly break things.

Now, I'll explain the points in more detail:

  1. FreeBSD, and most of the Linux distros, associated themselves with CD distributors (or were the distributors) early on. This gave them a source of income, which enabled them to do a lot more promotional work. FreeBSD, for example, got a lot of support from Walnut Creek CD-ROM (including revenue from Linux sales!) to ship out free CDs and merch to user groups.
  2. I actually wanted to develop a package system, but I was told that it was "stupid" because people could just build from source. I think the last nail in that idea occurred when we adopted pkgsrc (and started giving out prebuilt packages), but in a way that was too late. We had already adopted a model where the "OS" was really heavyweight and included a lot of things that probably could have been better handled by packages--e.g. GCC, UUCP, sendmail, groff, etc. Maintaining our own separate build infrastructure for these things has been a pain, and it has really slowed adoption of new versions.
  3. What can I say? This has lost us a lot of users, because the "stable" release often just doesn't work on new hardware. The staleness was so bad that I almost singlehandedly put out two releases (1.3.2 and the "Comdex 1999 preview"), just so that I could press CDs that I considered worthy of being demoed.

    Some of this is also due to poor design decisions. Remember when the P4 came out, and it was revealed that one of the CPUID values was chosen so that Windows would boot? We all laughed at Microsoft's shoddy code. I'm sorry to report that NetBSD has had similar problems far more than once. (I always railed against the idea of including CPU-specific code, rather than feature tests, myself.)

  4. I can't even begin to describe how much of a loss this has been. We honestly had (and have) developers who think that changing all the line-ending whitespace was really important. Or that whether there are some "legacy" K&R-style prototypes actually matters. These people go around committing non-functional changes, which makes source management (and specifically patching and merging) really painful, and which, unfortunately, also often breaks things accidentally. What's worse is that sometimes they don't even bother trying to compile it, much less test it. I wish I was making this up; I wish more that I had made these people go away a long time ago.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: