Brian Behlendorf wrote:
> 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.
There are two possible things that I think you could possibly mean
here. One of which I trivially disagree with, the other of which I
think is an important point that I agree with though some would not.
What I trivially disagree with is that the application of money should
not in an ideal world affect the direction that a project takes. I do
not honestly think you mean this, but that is what people responding to
you seem to be responding to. The direction a project takes can and
should respond to available tuits, and the application of money most
certainly affects the availability of tuits!
The other point is that the application of money should not change the
relative priorities of technical vs marketing considerations. As I
said, hackers care more about the quality of the code-base, companies
about getting marketing features in. There are reasons why each will
prioritize the way they do, but I happen to believe that it will be
detrimental to the long-term health of a project to put marketing above
technical quality. (It will certainly be detrimental to your ability
to convince people to get involved!)
> 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.
And here you outline the process by which companies can and should
impact the process.
> 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.
From this I take it that what you meant is the second interpretation.
As I said before, I agree. Others may not though. In particular if a
company labels something open source for publicity reasons but in fact
is willing to take the brunt of developing it (Star Office comes to my
mind for no particularly good reason...), then this need not be an
issue. But if they want to get people involved in the project, then
shortchanging technical quality is a form of suicide.
Did I say that strongly enough? :-)
> 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).
I happen to use vi myself, so I really have no opinion on this case.
But from what people have said here, I don't object to this case. They
want a feature that is not guaranteed to go in the mainstream, but
which a number of people would like to at least see work. They are
willing to supply tuits. The more power to them.
Should they start a fork and then let the code-base degrade though...
> The balances of power between the .orgs and the .coms seem pretty clear to
> me, at least in the abstract.
I wouldn't call it a balance of power. I would say that by nature the
.orgs have more incentives to pay attention to the long-term interests
of both. The .coms can ignore this at their peril.
Cheers,
Ben