Subject: Re: funding indirect services (tangent)
From: Brian Behlendorf <brian@collab.net>
Date: Sat, 19 Aug 2000 11:29:08 -0700 (PDT)

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

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

I used the term "well-run" above intentionally - no doubt there have been
projects whose core members pushed the schedules forward or made decisions
that they thought were correct but were colored by a fiscal bias.  In the
end, Darwin comes into play there; either the project heals itself 
and survives anyways, or another group decides they can manage the project 
better and fork the code base.

This gets back to the XEmacs/GTK+ thread - the sXc process includes a
comment period after the RFP is posted, so the XEmacs review board would
have had a forum to warn BeOpen that this project would not be integrated
on architectural grounds; or more ideally, either in those comments or in
developer proposals, someone tells them *how* to modify the proposal so
all or some of it would be acceptable.  At that point, BeOpen could have
decided to cancel the project (figuring it was only useful if it was
architecturally kosher with the other developers in the broader
community) or that there was some reason anyways to experiment with this
and perhaps persuade the review board at a later date that GTK integration
is OK (or fork it).

The balances of power between the .orgs and the .coms seem pretty clear to
me, at least in the abstract.

	Brian