Havoc's Blog

Four new desktop developers joined Red Hat in the last week; keeping
me busy.

One of the slides at my linux.conf.au
talk on the desktop was Commercial Involvement Will Grow, and I
had these bullet points:

• Companies have contributed relatively little to the desktop so far; perhaps a tenth of what’s been contributed on the server
• This will raise organizational and political challenges for the
  developer community
• We have to keep projects healthy, friendly, and unfragmented
• At the same time, more developers (often) get more done

The issue comes up all the time, here are some examples large and small:

• The X excitement: XFree86 left with
  little support, corporate-looking X.org site, commercial (and
  Debian) love-in for X.org and David
  Dawes comments
• The Mono and Java debate is heavily tied up with commercial
  interests (and even more so now that Sun and Microsoft
  are
  perhaps allies?)
• Luis’s
  comments on interaction design at companies
• Benjamin
  Otte on commercial interests in GNOME
• 
  JBoss guy wants to “own” open source projects, pretty weird

Just a sampling. It’s not new to have this issue; many of us “old
timers” are still battle-scarred from the days when Eazel and Ximian
first appeared, and the GNOME Foundation
was largely motivated by the desire to control and limit commercial
interests.

There aren’t any easy answers. No matter what organizational structure
you build, companies have a couple of inherent power advantages over
independent developers.

• Nearly all users obtain the software from a company; if you lose
  the companies your userbase looks like this.
• Companies have a block of developers moving in a single direction, so
  as long as the changes meet the criteria to go upstream, that
  direction tends to have a lot of pull (on the “show me the code”
  principle that makes open source go).

Companies in turn though are in large part required to follow
customer, partner, and legal requirements, and are not free to do
anything they choose to do. Sometimes the people most actively against
company-advocated directions are those who are happy with a
UNIX-geeks-only sort of project and dislike moving in directions with
broader appeal.

Because the GNOME
Mission Statement defines the project goal to create a
platform “for the general public,” working with companies to find out
what customers want, get wide distribution, and offer support becomes
more or less essential. But “working with” should be on the right
terms, in a way that preserves the nature of the project.

Honestly I think GNOME has the commercial relationship more right than
the vast majority of open source projects. One thing that tends to
happen though, and also happens in the kernel world, is that
independent contributors are regularly hired by companies. I’m hoping
that as GNOME grows the number of companies doing hiring like
this will grow as well, as it has for kernel. Because companies tend
to disagree with each other, this reduces the influence of each one.

A model I’m not a fan of is the Mozilla Foundation or old-style X
Window System model, where a nonprofit organization employs
developers. To me it’s better to have companies employ people
directly, because it’s more transparent where the influence is coming
from, and as corporate interests become irrelevant their influence
naturally disappears. Companies are also more directly responsible to
customers, which is generally a good thing for the software, with the
occasional exception of customers with out-there special-case demands.

One thing that helps avoid conflict is to clearly state the goals of a
project, so that everyone involved knows it up front. It’s tough for
incompatible “visions” to exist in a single project; for example,
GNOME had a lot of growing pains deciding that a project goal was
usability for regular people. Very often a “companies vs. volunteers”
conflict is really a “what is the project about” conflict. If you have
some goals up front, nobody can complain about them later.

Luis’s
post gets at one of the most important priorities: to be sure
discussions of project direction are public. Including both small and
large issues. So I hope we’ll be able to do interaction design “in the
open.” The Mono/Java argument is a real mess in this respect – we
discussed it some in public, but it turns out all the relevant facts
aren’t public. :-/ What one does at that point I don’t know.

I suppose this log entry has no conclusion, I was just thinking about
the topic. I do hope GNOME’s results speak for themselves in many
ways, showing that we do at least some things right.

(This post was originally found at http://log.ometer.com/2004-04.html#8)