Shall We Dance?

Ten Lessons Learned from Netscape's Flirtation with Open Source UI 
Development

At the time Netscape created mozilla.org and open sourced its codebase 
(3/31/98), we were not aware of any models on how to do large-scale UI 
design and development in open source.  Netscape itself had a history of 
strong, innovative UI design, but had been steadily cutting back, with 
some budget decisions being made by managers who privately considered UI 
design little more than eye candy sprinkled on at the end of a release. 
 Our UE group bore the brunt of each cut, losing designers, usability 
specialists, our lab, and at the bottom, our User Experience group 
manager.  We have since started to turn things around, but during much 
of the open source development through mozilla.org, UI decisions have 
been distributed across numerous individual contributors who have little 
or no training, let alone any cohesive strategy or understanding of the 
system we were building. This is a summary of some of the things I  have 
learned along the way, though each participant would no doubt create a 
different list.  These also seem fundamental and obvious to me, but in 
the context of a wide-open source project, there can be widespread 
disagreement about many things, especially rules and process.

   1. Don't skip the design stage.
      At one point, our  open source project went from being a 'new,
      small, fast, standards compliant browser' to being a superset
      rewrite of Netscape Communicator 4.x (a mature, full featured
      product), without any adjustment in the schedule.  Due to
      impossible time constraints, an explicit design phase was largely
      skipped (along with requirements gathering and functional
      specification), with the substitute being 'just make it work like
      4.x wherever you can'.  Since the product was different, with many
      new participants who had little time, there were many exceptions,
      deviations, and features where the basic look was copied, but
      subtle detail was ignored or wrong. We wound up spending longer
      getting requirements in the form of bug reports, and doing design
      by accretion, backout and rework.  Don't let rushed coders drive
      things, design the product.

   2. Identify intended target users, build the product for them, not us.
      There are many names and methods for this, just be sure to use one
      or more of them.  While companies tend to have at least some focus
      on customers, if not users, open source contributors may honestly
      be working with only their own use in mind.  The default
      assumption seems to be "we are building this for ourselves, or
      people who are just like us".  It may be hard to convince open
      source contributors that for logical reasons,  the product should
      target people whom they consider to be clueless newbies.

   3. Encourage local ownership and global oversight of the UI.
      Especially in a large 'integrated app', there is too much UI for
      anyone to be involved in all the details.  (You can advocate more
      modularity, but that is non-trivial, and may be left for a future
      release that never seems to come)  Components, and even individual
      features may need separate owners in order to deal with the fire
      hose of change requests, questions and 'discussions'.  In order to
      avoid a patchwork quilt, you'll need broad oversight by more
      experienced global UI owners.

   4. Make sure an appropriate person has 'buck stops here' authority.
      To end intractable arguments, it may be necessary from time to
      time to have someone step in and make a call that cannot be
      questioned.  You should hope this isn't needed much, but should
      ensure the right person is ready, willing and able.

   5. Don't create a UI Design Component
      One of the mistakes we made was to create a component in the bug
      system called 'UI Design Feedback' for raising any design issues
      about the UI.  This created an enormous backlog of issues covering
      the entire product, much more work than anyone who already had a
      real job in the UI would ever tolerate.  An open source
      contributor stepped in to fill the void, and became a bottleneck
      for all UI issues.  Bugs assigned to components would be
      reassigned to UIDF if anyone didn't like the component owners
      decision, and when the UIDF assignee disagreed, there was
      contention.  

   6. Ensure that UI designers engage the Open Source community.
      A large open source development project can be a brutal place for
      creative designer types, especially when they are vastly
      outnumbered and must advocate heresy like building products for
      mass consumption rather than for geeks.  Ensure that the people in
      such roles are willing and able to engage the beast, for they can
      only get the needed leverage from impressing those doing the work.
       Its a meritocracy out there!

   7. Allow for open discussion of any/all issues. (and for final
      private discussion and resolution).
      This is something we actually did right, sort of.  We created
      numerous public newsgroups with mailing list gateways for
      discussion.  After a year or so there were still occasionally
      huge, heated discussions that didn't seem to be converging on
      consensus, so we also created a 'by-invitation' group of UI owners
      and stakeholders (PixelJockeys) who semi privately discussed and
      settled the issues that had proven intractable in the larger
      group.  We distribute their meeting minutes (PixelDust) on the
      larger newsgroups.  The group still has no explicit authority, but
      people tend to abide by its decisions, as long as they feel
      represented and the results are explained.

   8. Expose all possible work in the open.
      Rather than just checking the source into the open repository when
      it is ready, we've found it advantageous to open much of the
      development process as early as possible.  On my teams' web pages,
      I have exposed our marketing requirements, engineering plans from
      blurb/swag through schedule, progress reports, etc. Working in a
      fishbowl allows talented people all over the world to help out on
      whatever they want.  Amazingly, they do.

   9. Keep your focus on what you'll ship, but don't ignore the open
      source equivalent.
      We've found a need to keep a balance between the open source
      version of our browser, that all developers run and test, and the
      commercial branded version that my company actually ships.  About
      98% of the work we do is applicable to both, so we tend to focus
      on the version we share in common with all other contributors.
       That's good, because we need to be good owners of it, but we also
      can't forget where the money comes from, and have to take care of
      business.

  10. Be honest about commercial motivations.
      When making decisions about UI that is shared between open source
      and commercial versions of a product, we are sometimes unduly
      influenced one way or the other by factors that exist only in the
      commercial version.  At times, we have tried to justify decisions
      favorable to our commercial needs with open source
      rationalizations rather than just admit the unvarnished truth.
       This nearly always backfires, and the person making such claims
      is exposed as either incompetent or untrustworthy.  Better to be
      up-front about such motivations, there is no shame in doing
      something because you want to make money.