Make certain that you don’t miss the nice things Jordan says
about the Linux community. It’s at the very end of this article.
-lt eds
Thanks to Zach Beane for forwarding this along.
From: “Jordan K. Hubbard” <jkh@zippy.cdrom.com>
Subject: State of the union, 1999.
Well, it’s another year behind us, folks, and probably high time
for another state of the union report!
Ahem… I’m never quite sure how to word these things since I’m
always reminded of a U.S. president sitting in front of fireplace,
trying to sound down-home and folksy for the corn growing states,
or perhaps England’s Queen on Christmas day, giving her usual
somber-yet-hopeful address on how things went for Britannia during
the previous year and what everyone should perhaps think about for
the next. Neither one of those is really me, basically, so perhaps
I’ll just cut to the chase and focus on the most pertinent lessons
(and objectives) to come out of the year 1998 for me.
1998 was, of course, the year that the Internet got bigger (no
surprise), various “internetpraneurs” (gag) got richer and
FreeBSD’s user base, as measured by the ftp download stats grew at
its usual 200-300% rate. More companies also entered the FreeBSD
arena, either offering add-ons for or solutions incorporating
FreeBSD, and our PR machine, as flimsy and low-key as it often is,
managed to ratchet things up another notch. All in all, it was a
very good year for FreeBSD and I don’t think that even the most
paranoid of us could claim otherwise – Microsoft took one in the
shorts, we got bigger and just a bit better known, life was
good.
Well, mostly. Whipping off my rosy glasses for a second, I can
also say that there were still a number of rocks in the road and
unexpected bends that left us not always in the best of control
there. While downloads have gone up, CD sales aren’t quite
following suit since the whole CD market in general is suffering
from increased Internet availability and its erosion of some of the
CD’s fundamental advantages. We still did quite well, considering
the market’s gradual implosion, but it would be foolish to continue
to rely on a single CD product to provide the kinds of subsidies
that have been steadily oiling the project’s gears (we more than
doubled the size of the freebsd.org computing cluster, for example,
and significantly enlarged our developer equipment grant program in
1998, all things which cost $$$). It’s fairly obvious that Walnut
Creek CDROM will need to increase the number of products it offers
if it wishes to remain an effective player in the FreeBSD game and
we must continue, as a project, to be flexible in exploring all
types of relationships with those who may now have a vested
interest in FreeBSD’s success. Things are well past the point where
we can do everything that needs to be done as a serious and “grown
up” solution just on good will and volunteerism alone.
With that in mind, sites like the FreeBSD Mall
(www.freebsdmall.com) have been set up to try and market a wider
variety of FreeBSD-related products and we’ve also begun exploring
relationships with various companies who can derive measurable
value from any PR campaign that enhances FreeBSD’s reputation
(translation: we want them to help pay for it :). As many people
have somewhat bitterly pointed out by now, this business has become
a 10% technology and 90% perception equation as far as the
direction in which people stampede is concerned, and hate them for
the mindless little sheep that they are, you still need to
understand people’s tendencies and behavioral patterns when it
comes to dealing with anything they don’t really understand. We’ve
done a great job on the technology, we really have (and should be
proud of that), but all too frequently we just throw up our hands
over the perception issue and tell people to think whatever the
hell they want to. Bad techies! Myopic techies! 🙂
What can we do to change this in 1999? Well, I’ve also heard our
advocate corps calling for logistical support (“Backup! We need
some *backup* here!!”) and I’ve listened to them, part of my
project for the new years being to get more digital daemon imagery
made available (which I have already commissioned), more glossies
with various handy comparison charts on them (“FreeBSD and NT”,
“FreeBSD and Solaris”, “FreeBSD and Linux”, etc) and more
newsletters for passing out to people. We can also produce more
marketing periphenalia like buttons, stickers, new T-shirts, etc.
to give people a wider array of stuff to proudly point to in
support of the “emerging FreeBSD phenomenon.” If we can manage to
raise more money for PR, we can also perhaps buy some of these
items in bulk to use as give-aways in various promotional deals.
Other than that, I’m always open to suggestions. We need to do more
effective PR, that much is inarguable, it’s only a question of
picking our targets for maximum effect given a limited operating
budget.
The core team:
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.
Release numbering:
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!
🙂
Technology:
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.
Tech support:
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, to to www.freebsdmall.com and order
yourself a tech support contract. You get what you pay for! 🙂
Looking forward:
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! 🙂
– Jordan