Fun Friday - the Curse of BSD and the Four Mistakes

My discussion earlier this week on inaccuracies in papers discussing the evolution and history of 386BSD resulted in some very interesting questions (see Oh, Goodie! Another Academic on 386BSD...). And a really nice question from suresh at Berkeley: "I'd like to hear your opinion: why did BSD lose to Linux in the battle for OSS hegemony..? How was the BSD release architecture (e.g. what was the political process) decided on? Some friends of fine [sic] swear by the FreeBSD operating system, but they are a minority."

So Fun Friday is answering the really simple question "Why Did BSD Fail?". Oh, this is a big one, but I'm game if you are...

First a bit of background here. The BSD vs Linux debate is rather irrelevent, actually, and has diverted from the core issues. While most Americans love football and rooting for teams, and while 386BSD was considered a business success as a publishing project as well as an interesting research project, it wasn't ever instantiated as a substitute for a commercial enterprise release. So all that stuff about winning has been a lot of nonsense.

That it also was a "phenomenon" was a surprise, not an unpleasant one, but a surprise nonetheless. I know that engendered a lot of envy, and that's the source of quite a bit of shill comments. That readers liked it was really nice, since I still have "fans" read my columns and articles to this day. I like that. Shills go off and wreck other things, but readers who like you are gold.

But I was in a Berkeley spinout in the 1980's that did workstations using BSD, and we were quite aware of the difficulty in separating the bundled OS from that of the hardware and still providing a value. Look at the current Red Hat release issues in CNET for an example of an ongoing problem in translating source into revenue. Just more of the same old stuff.

I also ended up handling licensing issues with Unix in the 1980's and believe me, it was quite complicated after a while. For example, Symmetric Computer Systems received venture investment in 1984 for a BSD-based system using the NS32000 microprocessor. During a talk at the Vintage Computer Faire a ways back ("Before 386BSD: The Symmetric 375 and Berkeley Unix") we discussed the costs of pay to play in terms of licensing. In sum, we had to get our investment, pay out six figures to AT&T for a SystemV tape which we immediately threw in the trash, so then we could pay $750 for a BSD tape which we *did* use. We sold hardware with software on it - not separate OS's - just like Sun and Apollo and lots of others (most long gone). Sun got fed up with paying out those royalties so bought them out (as you can do for patent licensing and is commonplace in semiconductors).

Lots of history here. The Symmetric 375, by the way, is a much sought after little machine - a poor man's portable VAX. A lot of the ideas in it went into 386BSD later. And the ones we have still run - sure, a few bad blocks have been mapped out over time, but they still run. I can barely keep any PCs going after five years (just donated a bunch of Aptivas last week sans drives). And my kids swear the version of rogue on it is much better than the ones out today. Not bad for a 1MIP machine. But BSD was much more efficient than what we see today. :-)

386BSD evolved to include much of the Berkeley architectural design that was discussed in the late 1970's and early 1980's. After a lot of the key designers left in the early 1980's (like Bill Joy, William Jolitz, Sam Leffler, and so forth), the new group that took over didn't have the history / background / support to continue those recommendations. They did do great work with the networking release in separating out the university work from the AT&T licensed code, and this became the basis of the Net releases, and the Net/2 release, when it finally came out, was used as the basis for an open source 386BSD which also incorporated our work, but avoided the encumbered parts. Dr. Dobbs Journal and 386BSD were never part of any lawsuit or claim of infringement, yet we were published internationally and did releases.

So where did the other BSD's screw up where Linux succeeded? OK, here's off the top of my head...

None of the other *BSD's out there incorporated these architectural changes to evolve the OS. They wanted to stick with the Release 0.1 stuff and go from there, which was fine with us, although we wouldn't put in any code that was encumbered by "slipping it" past our publishers - that was one of the other "sources" of antagonism, if you will forgive the pun.

We understood these other guys weren't from Berkeley, they didn't have any real architects, and they didn't know how to evolve the system, but they could cudgel together drivers and such, and we figured that's was good enough for the immediate. But we did warn them that innovation and evolution was the only way to move BSD forward. That's what Berkeley was all about.

But they weren't Berkeley people, hadn't worked in industry in the 1980's like I had, and didn't "get it", but they still wanted the Berkeley heritage and academic patina. That was their first mistake.

Linux didn't have that legacy - they just used whatever they could. No pretenses there. They just made it work "whatever".

Linux didn't have a publishing relationship, so code could come from anywhere, including encumbered sources. I heard from a lot of people from companies like SGI throwing code "over the wall" to Linux. The *BSD guys were, in contrast, in awe of the Berkeley / USL / BSDi lawsuit and afraid of doing just that. So Linux scored here too.

386BSD had a publishing relationship, the credibility and integrity intact, and we weren't going to play the patsy for someone else's sticky fingers. Nor did we want to write about old code for some legacy machine - it wasn't fun nor interesting. And we weren't part of all that mess precisely because we had set the rules of engagement to encompass "innovation, not renovation", and were not going to endanger Berkeley or BSD by playing this game. So we were of no assistance to the other *BSD's here - they were on their own as far as this was concerned. You can't have it both ways, and they wanted it both ways. That was their second mistake.

I did not enjoy the claim they "removed" code and did it from scratch to erase names - that clearly wasn't true from an examination of the code, and it was also unnecessary since the code was "freely redistributable and modifiable with attribution maintained" - but again, they were very envious of 386BSD and the writings and must have thought they'd benefit by removing attribution and pretending they had done it all. I heard from many fans at that time that they moved to Linux because they hated this kind of behavior. Still read the articles, and bought the CDROM from DDJ, but told me they'd never use any other BSD again ('cept ours, and we weren't doing commercial releases). I think that's where they seriously began to lose fans - they sold their credibility out of jealosy. That was their third mistake.

As an aside, I do think they should stop throwing in so much garbage in the kernel to the point that popular apps and devices don't work - my son is always complaining to me about their latest silly changes (that's his job - to compare and test). I think he knows more than they do, since he likes to use the latest apps like any high school GenY. But they spend more time outing each other than getting a good release together, and in the competitive world of open source malice kills projects.

I do see a lot more smarts from folks getting around their code to get an app or device driver working than I see working on *BSD directly. I don't think they like smart people, but I always hire the smartest people I can find. Perhaps that in a nutshell is why *BSD's today can't compete with Linux - they don't provide the customer what he wants. But that has nothing to do with kernel or architecture design - it's just PT Barnum's "give the customer what he wants". This was their forth mistake.

The primary purpose of 386BSD was to provide academics, students, and researchers with an inexpensive Berkeley Unix platform for new work in OS design. When 386BSD was released, I heard from people in places like Africa and India saying they finally could afford a Unix system for their college. That was very gratifying.

386BSD was begun in 1989, and releases were made available to source licensed groups prior to the Net/2 release, as parts of BSD that were not our work were not deemed open source then - we did the port under the stipulations that the code be "freely redistributable and modifiable as long as attribution was maintained", along with an additional stipulation that the Berkeley group handling the distribution maintain accredation - which ended and reverted back to us when the group was disbanded.

386BSD did achieve its original aims - develop a platform for colleges and universities to continue work using the incredible wealth of Berkeley software contributed by many researchers over many years, in the tradition of many other prior projects (see the poll as to who really was the father of open source - you might be surprised at some of the names).

So you see, the question as to which *BSD is best or is Linux best now is quite irrelevent to 386BSD. We use open source all the time in my startups, not just 386BSD but also great open source like Apache. So if you're into commercial apps, and run a datacenter, you've got a lot to choose from, and this is just a great time to work on new projects!

With this incredible obsession over "which is better", unfortunately, we rarely see anyone trying anything new. Release variance is discouraged (again, read the Red Hat article above) and new approaches are censored. This began with the frenzy to compete with Microsoft back in the early 1990's (which is where a lot of the bitterness of the old Unix crowd stems from), has stifled innovation in OS design, and basically killed an entire area of knowledge.

I've worked in hardware, software, and services, and enjoy doing new businesses, but I am sorry for all the good tech people who have found themselves without jobs. Because if you don't have a value for innovation, you don't have a value for research, talent, and new ideas. I've been on Sand Hill Road and in the boardroom, so I do know something of what I speak.

So who wins? Ask the customer the next time he gets a virus, or more spam. You'll get a different answer than from OS ideologues. And that's where we stand now.