Subject: Re: funding indirect services (tangent)
From: "Stephen J. Turnbull" <>
Date: Mon, 21 Aug 2000 13:18:43 +0900 (JST)

>>>>> "Brian" == Brian Behlendorf <> writes:

    Brian> On Fri, 4 Aug 2000 wrote:

    >> At issue here is a far more subtle question.  The question is
    >> who gets to make the design decisions and why.  The application
    >> of money is the usual strategy of companies.  The application
    >> of programming effort is likewise the strategy of hackers.
    >> Should they seriously disagree, then you get into thorny
    >> issues.

I'm with Ben on this: money changed the path of XEmacs development.
Whether it will have had a long-run impact remains to be seen.

I personally think this is a good thing, because it brings resources
into the community.  However, it does change the nature of the
community and of its decision-making process.  Many developers and
open source users do not like that.

As for "subtle," I think it _is_ subtle.  I know at least two active
Linux developers who have abandoned Linux for the purer fields of *BSD
because they don't like the impact that they perceive money to be
having on the decisions made by people like Dave Miller and Alan Cox.
Other people praise the Linux vendors for the great freedom they give
Miller and Cox.  That is a subtle distinction that different observers
will make differently.

    Brian> I think the question isn't subtle at all, and I think it
    Brian> has a very clear answer: in a well-run open source project,
    Brian> the application of money in any direction (a sXc project, a
    Brian> core developer's salary, a donation to a non-profit)
    Brian> *alone* has no effect on decisions made regarding the code.
    Brian> Those decisions must be entirely based on the quality of
    Brian> the ideas and the code that implements them - meritocratic.

I don't understand where you're coming from.  For example, change a
few lines in the Aladdin Free Public License (or simply substitute the
GNU GPL for it), and Ghostscript would be a perfectly good open source
project by _anybody's_ definition.  But Peter has always made it plain
that money can, does, and will continue to affect decisions about
design and coding schedules for Ghostscript.

To the extent that Cygnus and now Red Hat can more or less get changes
made to GCC at will, this applies to the premier open source project,
GCC itself.

Granted, Cygnus doesn't have _control_ of the GCC project, and Peter's
choice of a non-free license is closely associated with his commercial
orientation.  But I don't see any particular reason why a free
software project can't be entirely directed by commercial motives, and
surely decisions about direction and choice among viable tasks (do we
support Sparc ELC or the latest UltraSparc SMP? do we spend effort on
a new port for an ancient architecture or on optimizing the port of an
existing big donor?) will be affected by financial incentives.

Remember, there is far more good code and excellent design to be
produced than current OSS resources can support.  We must make
decisions among excellent alternatives, not just between excellence
and dreck; surely the financial backing that allows us to springload
that shiny ball into the bumpers again is going to affect which we do
first, and therefore, what ever gets done in some cases.

    Brian> If a commercial vendor "feeds" off of an open source
    Brian> project (repackages it for inclusion in their product,
    Brian> provides support for it, etc) then any needs they have that
    Brian> aren't met by the project need to be provided separately;
    Brian> either by their own fork/distribution, patches, etc.  Of
    Brian> course it's in their interests to not have to do this, so
    Brian> they are incented to provide those patches back to the
    Brian> project in a form the project finds acceptable.

Why can't a commercial vendor _create_ de novo a whole open source
project, lock, stock, and barrel, by staffing it with employees?
Isn't that more or less what is?  Wouldn't it be a better
world if more of them did?

    Brian> This gets back to the XEmacs/GTK+ thread - the sXc process
    Brian> includes a comment period after the RFP is posted, so the
    Brian> XEmacs review board would have had a forum to warn BeOpen
    Brian> that this project would not be integrated on architectural
    Brian> grounds;

I believe the CEO of BeOpen participated in the earlier discussions.
Integration into the XEmacs mainline was not part of the RFC---
Infodock has been forked from XEmacs for some time now, although a
relatively friendly fork.  So basically, it seems to be the BeOpen
decided to put its money where its mouth was.  Unlike the infamous
Lucid/Joe Arceneaux situation, AFAIK BeOpen did not directly contact
any individual XEmacs developer, although they did post a pointer to
the sXc RFC on the XEmacs Developers' list.  I think this strongly
suggests that BeOpen was very sensitive to the impression it might
create by sponsoring this project, and well aware that this could
create a fork.

    Brian>  or more ideally, either in those comments or in developer
    Brian> proposals, someone tells them *how* to modify the proposal
    Brian> so all or some of it would be acceptable.

Ideal, maybe, but impossible; the fundamental issue was the GTK+ event
loop.  To "fix" that would have required pushing GTK+ in a direction
_it_ didn't want to go.  It is often the case that two OSS projects
which could each benefit from cooperation will not do so, while
financial incentive or discipline can instigate such cooperation.

In this case the financial discipline to achieve the goal cheaply also
instigated the correct architectural decision (IMO): XEmacs supports
another event loop ad hoc.  Nor was this an accident.  No toolkit can
really afford to redo something that basic---it would be a new
toolkit.  OTOH, one of the original design principles of Lucid Emacs
was to abstract the event loop for precisely this reason.  It wasn't
as successful as hoped, but XEmacs has managed to support three
separate event loops (Xt, Unix/TTY, and Windows NT) for several years
without imploding.

    Brian> At that point, BeOpen could have decided to cancel the
    Brian> project (figuring it was only useful if it was
    Brian> architecturally kosher with the other developers in the

BeOpen's position might very likely have been something like "We're
betting the firm on a better GUI for our Infodock IDE.  First we need
the GUI, then with luck we can offload support onto OSS volunteers.[1]
If that doesn't work, we'll support it ourselves somehow."

So now we have _three_ OSS projects (I believe Infodock has changed
its license to be open source compatible; they at least made noises
about doing that) with some technical reason to cooperate, but many
technical reasons not to do so.

Without BeOpen's sXc project, it would not have happened.

    Brian> broader community) or that there was some reason anyways to

Define "broader community."  There are many people who would love to
have a GTK/GNOME or Qt/KDE Emacs (mainline or XEmacs, either would do)
who are not part of the [X]Emacs community now although they _are_
part of the OSS community.  So BeOpen could plausibly claim to be (in
part) representing that broader broader community!

    Brian> experiment with this and perhaps persuade the review board
    Brian> at a later date that GTK integration is OK (or fork it).

This is exactly what happened.  If the port proves popular, enough to
elicit some developers willing to deal with the event loop conflicts,
it will be integrated with the XEmacs mainline, and BeOpen can use its
funds to seed more projects rather than support this port.  The XEmacs
board's position was not opposition in principle to a bad idea.  It
was recognition that care and feeding of yet another event loop would
almost surely introduce subtle bugs and require direct maintenance
effort that made them oppose such a project within the framework of  They simply wanted to direct resources at different goals
that are not objectively more worthy.

The point is that did _not_ have the programming muscle to
do the GTK port themselves.  Only by application of financial muscle,
which persuaded a long-time XEmacs developer to concentrate his effort
on that port, was it realized.  This probably had a direct impact of
lessening his contribution to other aspects of XEmacs during the
period of the contract.

So the bottom line is that Beopen wanted a specific task done, and
their money made it happen.  Had that money been contributed directly
to, it almost certainly would have been applied in a
different way.

This is not in conflict with your principle of meritocracy.  At every
step of the way, the patron, the developer, and the review board were
all making choices based on design and code excellence.  The patron
and the board were in (friendly) conflict about the priority of needs,
and the developer, I suspect, chose the path that involved the most
high-Quality development activity (aka "fun").  Win-win-win -- but
different from the outcome that the board alone would have chosen
given the same resources and no contraint on their use.

[1]  This is exactly what you are proposing, although I have put it
very baldly here.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."