FreeBSD State of the Union, 1999

1998 also ended with a bit of a bang as far as FreeBSD’s project management was concerned, frustration with a mostly recumbent core team goading a couple of bearded Danish Vikings into staging a midnight raid on -current, ruthlessly culling the weak and the lame from the source tree. Unfortunately, some of those weak or lame bits of code were still in use at the time and, with no prior public warning having been given, it did not exactly leave the various followers of -current with the feeling that the event was going to be the highlight of their Christmas season. Their complaints led, in turn, to something of a constitutional crisis within core, the rival factions each accusing one another of either impeding progress or using cowboy tactics to achieve that progress, and each faction had its legitimate points just as it had its wholly unreasonable ones. Coming out of this, various suggestions were bandied about concerning how we might put together a "better core team" to which such things simply did not happen (or, if they did, would not be our fault since we’d all be long gone :-) and many of these suggested cures were eventually deemed, quite rightly, to be worse than the disease. So what did we learn from the exercise then?

First off, I think everyone is now pretty much in agreement that these sorts of drive-by shootings are just not an option for the future, no matter what the justification. Anyone who contemplates a major addition or removal of functionality from the source tree MUST communicate those intentions well in advance and give the readership of -current, -stable or -announce (the former two depending on the branch the changes affect and the latter on the extent of the changes) ample time to respond. If there is a conclusively negative response to a proposed change, it just doesn’t happen until and unless the proposal somehow manages to win people over through sheer dint of persuasive argument in its favor. If it’s more a mixed bag of reactions, or there is little reaction at all, the developer is free to proceed at his or her discretion but still never without advance notice.

Second, in reaction to the various proposals put forward to either gut core or have core elected by popular vote, let me just say that we’re not going to do that. There are probably several people currently in core who would gladly step aside and retire if they felt that adequate replacements had been found and the project was in good hands, but none of us like the scenario where anyone is overtly forced out of core. It’s just not a reasonable way of going about it when so many less painful alternatives exist, and I, for one, would far rather simply grow core and let the inactive members fall off when they themselves have come to a decision that they have nothing left to contribute at a "core level", resignation from core having not stopped several folks from remaining as effective committers or making other valuable contributions.

We’re a free software project and nobody’s paid to be in core, no matter how seriously we may be tempted to take the whole core thing sometimes, and we need to remember that all of this started as a bunch of folks who simply wanted to work together in creating something useful and interesting. The day we lose that kind of informal atmosphere of productivity over politics is the day that something pretty fundamental goes out at the center of core and also the day that I’ll retire from it myself, handing my hat to a replacement and wishing everyone the very best of luck.

I can also only sound a similar cautionary note about the idea of electing core from the user base, or with committers serving as a kind of "electoral college", as nice and democratic an idea as that might sound. The FreeBSD core team does not represent a democratically selected body and was, in fact, very carefully put together in a very non-democratic way. We picked core with the specific intention that it represent as diverse a set of hard-core FreeBSD evangelist/developers as we knew how to find and we’ve continued to add people using the same criteria.

In bringing someone into core, we don’t look at whether they’ve been winning popularity contests lately or won the Programming Olympiad 3 times in a row, we ask ourselves: "Does this person bring a unique talent or viewpoint to the group? Will the resulting whole be greater than the sum of its parts?" These are our two most overriding concerns and, in fact, are the only grounds on which we’ve ever felt it necessary to actually ask for someone’s resignation from core. We can tolerate quite a bit from people but not when it impacts core’s fundamental ability to work together or seeks to undermine the very diversity of opinion we’ve worked so hard to cultivate. It’s good to be an effective group of decision makers as a core team, and we do have our moments (both ways), but sometimes it’s even better to know simply when to stay out of the way and just make sure the train stays roughly on the tracks. We’ve prevented a lot more stupidity through having such a diverse and carefully selected core team than I think we’ve ever caused and I do not trust the democratic process to leave us with the same thing after a few elections.

Core is also continuing to work on drafting some internal documents which cover, in much better detail, just what our rules as committers are, those superseding any "core member privileges", governing how large-scale code removal and addition operations should be carried out. We’ll post something to committers just as soon as we finally flesh it out to our mutual satisfaction but, in a nutshell, it basically just insists that people need to be warned before such changes happen and that the owner of a given body of code should be given first say as to whether or not it’s time to kill it in the name of obsolescence or redundancy. Finally, we are looking at the general issue of communication inside and outside core and the question of whether or not to bring in some new member(s) at this time. That discussion is ongoing and I’ll do my best to keep everyone up to date on that as things progress.

Other decisions on the horizon concern returning to our former practice of using "major" version numbers for branches and "minor" numbers for releases, the revision number field only being used to denote point-releases which were done for some reason significant enough to merit such a special release. This means that the next release will be 3.1, not 3.0.1, and the new branch will be 4.0-current instead of 3.1-current. Is this just a marketing ploy? No, it’s not, though marketing has indeed been a frequent casualty of our current numbering scheme.

We have frequently made fairly large changes between our "point releases", jumps like 2.2.5→2.2.6 and 2.2.6→2.2.7 being a lot bigger than most folks gave them credit for given that it was just one little revision number being changed. This one simple facet of human nature reduced the effectiveness of these releases and under-sold the work being done by our developers to substantially improve every release we do, regardless of which branch it’s on.

This is not a trend which seems to be reversing itself and so I feel quite safe in saying that 3.1 will be a "full release" over 3.0 in its own right and not merely the "3.0.1" which conveys such a different impression. It’s also very important to note that since our branches seem to typically last from 12-18 months these days, no matter what we try in attempting to kill a branch earlier, a major version bump (4.0) is entirely merited for something which won’t see full release status until sometime in the year 2000. This will make the marketing people happy since they won’t have such an uphill battle on number perception and it will make the users happy since they’ll get a clearer picture of what changed in, say, 3.1 to 3.2 vs 3.1 to 3.1.1 (which might be an important security update). It will also make this particular developer happy since I’ll have the revision number space back again for doing point releases. It’s a win and so we’re going to do it. 3.0.1 is dead, long live 3.1! :)

This last year also saw a successful transition to ELF from a.out format and a new kernel loadable module scheme which allows modules to be read in without a runtime dependency on /usr/bin/ld. We also got a new boot loader (with a forth interpreter!) to aggregate a "kernel" at boot time. These are both powerful new mechanisms and, coupled with some new stuff which will be coming in 1999, should give us a far more dynamic and extensible system than we’ve ever had before.

Not to be overlooked is also our new SCSI CAM system, giving us more robust behavior with large drive arrays and supporting more of the high-end SCSI controllers, or the support for multiple processors on the x86. We made considerable progress all across the board with the release of 3.0, finally reaching a point with the DEC Alpha architecture port where people starting worrying more about the packages collection than they did about working kernels or a /usr/src which built. That represents considerable progress towards "genuine usefulness" and I hope that 1999 will see a fully desktop capable release of FreeBSD/axp (to say nothing of a server capable one), various difficulties with X server technology making the Alpha desktop a unique milestone in its own right, especially if it’s on an ARC or AlphaBIOS machine. 1999 may also see the early release of a SPARC port, though it’s still far too early to say anything more definite than that. Join the sparc@FreeBSD.org mailing list if you want to follow these efforts.

IPv6 and IPSec were also hotly debated topics in 1998, FreeBSD’s refusal to back any specific implementation being cited by many as an example of core’s over-conservatism in action. Happily for everyone, our wait-and-see attitude proved to be the right one when the two major "competing" groups, KAME and INRIA, finally agreed to merge their implementations. We have, in turn, committed to adopting this merged implementation and have several people from the KAME/INRIA groups on the FreeBSD development team who will be importing and maintaining this code as it becomes available.

There is also substantial work underway with the VM system and the filesystem code, much of which is either being tested quietly in small groups (Dillon/Dyson/Greenman) or is awaiting the 4.0 branch event, still scheduled for January 15th, 1999. In other areas, we have Kazu’s very welcome total redesign of the console driver coming into -current along with USB support, courtesy of Nick Hibma and others. This is just to name a few of the projects underway and I don’t mean to slight anyone by not mentioning theirs directly, these are just 3 ongoing projects right off the top of my head. We seem to be gaining a lot of technical momentum, and that’s great, just so long as we can also keep our heads during the times where not everyone is in total agreement about which technical direction to take.

A point which should also be obvious to everyone yet still somehow requires frequent reinforcement is the fact that we need to maintain participation in this project as something which is also enjoyable for the developer/participants or they will just as quickly go away again and stop giving each and every one of us the benefit of their volunteer labor (on which a dollar value could not even be put). This is something which each and every one of our users needs to be aware of, at least somewhere in the back of their minds, for those times when they’re tempted to start thinking of FreeBSD as just another shrink-wrap solution from Software, Inc. and start treating project members like personal employees. Those looking for actual FreeBSD employees should send mail to jobs@FreeBSD.org and indicate how much money they’re willing to pay, otherwise don’t do it.

I don’t mean to come across so harshly here that people don’t even bother asking us for help, I’m simply saying that those users who avail themselves of the various FreeBSD volunteer tech support mechanisms out there (mail, news, irc, etc) should always understand that asking another perfect stranger for help is just not much different from asking a random person on the street for a dollar. If you want to get free handouts, you’d better at the very least learn to ask politely and when to take "no" for an answer! :-) I’ve seen a lot of abuse of the various tech support forum volunteers this last year and it frankly sucks. People just need to be more considerate and stop regarding free tech support as a god-given right rather than a very special privilege. If you want on-demand tech support, go to www.freebsdmall.com and order yourself a tech support contract. You get what you pay for! :)

What do I see ahead for 1999? Well, assuming that we don’t all vanish in some pre-millennial holocaust, I see more interesting new features, improved marketing, more commercial interest, more magazine articles and press attention, basically more of the same if we can just try to stay reasonably well focused on what we need to do and not get distracted into chasing weird desktop dreams or suddenly become overly minimalist or kitchen-sink biased in /usr/src, continuing to chart the middle course we’re more famous for. The FreeBSD core team, one year older and hopefully a little wiser, needs to continue keeping a light but steady hand on the tiller, relying on our developers as usual to provide much of the actual motive force behind FreeBSD.

Our users also need to become more involved and I’m hoping that 1999 will be the year when a lot more local user groups and other self-help type of organizations are formed. The Handbook and FAQ are documents which are getting better, hopefully another trend we’ll see continue into 1999 as Nik Clayton, our fearless new Documentation Project leader, continues at the helm. We still have to remember, however, that for many users the handbook and FAQ docs are just not enough.

Linux has succeeded largely because of a large grass-roots support and evangelism network which allows it to reach such people and communicate the message to them. If FreeBSD’s own users want to see FreeBSD doing better against whomever they most perceive as its competition, and 1998 was certainly a year where I heard a lot of complaining about this, then they’re going to simply have to get off their collective duffs and put in more of this kind of work. When was the last time a bunch of FreeBSD users got together to hand out FreeBSD literature at a Microsoft product launch, for example, or held an install-a-thon at a local computer show?

The Linux folks do things like that all the time, apparently, whereas only a very few die-hard FreeBSD users currently do it now, so why not help these people out? Join the advocacy@FreeBSD.org mailing list and discuss your plans there so that others with more enthusiasm than ideas can also learn from and perhaps help you with yours. Write short articles for the new advocacy sites like www.daemonnews.org or www.freebsdrocks.com and help promote the success of BSD evangelical publications.

Phrases like "this is your FreeBSD" and "it all depends on you" may seem shop-worn and trite, but they’re also unfortunately still true when there’s so few of us and so many of you. If FreeBSD is to really continue to succeed in 1999, it will only be with substantial user participation and that means you, users! Start a local user group, donate some of your older CD releases to the local library, try and convince a local small business or ISP to use FreeBSD, these are just a few of the many things that can be done if you’re truly interested in putting some energy into FreeBSD and ideas for what to do will be the least of your worries if you’re truly motivated.

Executive Summary: 1999, rah rah rah, let’s do it! :)