Date: Sat, 09 Jan 1999 22:47:50 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: current@FreeBSD.ORG Subject: State of the union, 1999. Message-ID: <49859.915950870@zippy.cdrom.com>
next in thread | raw e-mail | index | archive | help
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49859.915950870>