<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD State of the Union, 1999">
<!ENTITY % navinclude.about "INCLUDE">
]>

<html>
    &header;

    <p><i>From Jordan Hubbard &lt;jkh@FreeBSD.ORG&gt;, Sunday January 10th,
	1999.</i></p>

    <p>Well, it's another year behind us, folks, and probably high time for
      another state of the union report!</p>

    <p>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.</p>
    
    <p>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.</p>

    <p>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.</p>
    
    <p>With that in mind, sites like the <a
	href="http://www.freebsdmall.com">FreeBSD Mall</a>
      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! :-)</p>

    <p>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
      <em>backup</em> 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.</p>

    <h2>The core team:</h2>

    <p>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?</p>

    <p>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.</p>

    <p>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.</p>

    <p>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.</p>

    <p>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.</p>
      
    <p>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.</p>

    <p>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.</p>
      
    <h2>Release numbering:</h2>
    
    <p>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.</p>

    <p>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 <em>every</em>
      release we do, regardless of which branch it's on.</p>

    <p>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! :)</p>

    <h2>Technology:</h2>

    <p>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.</p>
      
    <p>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 <a
	href="mailto:sparc@FreeBSD.org">sparc@FreeBSD.org</a> mailing list if
      you want to follow these efforts.</p>

    <p>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.</p>

    <p>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.</p>

    <h2>Tech support:</h2>

    <p>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
      <em>enjoyable</em> 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
      <a href="mailto:jobs@FreeBSD.org">jobs@FreeBSD.org</a> and indicate how
      much money they're willing to pay, otherwise don't do it.</p>
    
    <p>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! :)</p>

    <h2>Looking forward:</h2>

    <p>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.</p>
      
    <p>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.</p>

    <p>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?</p>

    <p>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 <a
	href="mailto:advocacy@FreeBSD.org">advocacy@FreeBSD.org</a> 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 <a
	href="http://www.daemonnews.org/">www.daemonnews.org</a> or <a
	href="http://www.freebsdrocks.com/">www.freebsdrocks.com</a> and help
      promote the success of BSD evangelical publications.</p>

    <p>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
      <em>really</em> 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.</p>
      
    <p>Executive Summary:  1999, rah rah rah, let's do it! :)</p>

      &footer;
  </body>
</html>
