Subject: Re: the GCC steering committee
From: "Jonathan S. Shapiro" <>
Date: Fri, 15 Mar 2002 19:16:29 -0500

> JS> The only leadership that matters is leadership in the eyes of the
> JS> customer.
> I hesitate to agree with this.  It seems to assume that the customer
> is ignorant of the actual development processes that are in play in
> the project.

I think it depends on the customer. If the customer is a development house,
then we are basically talking about contract programming and I think your
analysis is sound. However, this isn't a mass-market customer.

If the customer is your grandmother, she would much prefer to be completely
ignorant of development and integration. Problems like that are what she
calls you to solve because you are a dutiful relative. :-)

> JS> The customer deeply doesn't care who provides the changes.
> They don't care who provides them, but they do care about your ability
> to provide them.  And they often (but not always) care about your
> ability to get the changes back into the "main" sources, with which
> they are often familiar.  That's been my experience anyway.  YMMV.

I agree with one quibble: the customer cannot assess your ability to deliver
without iterating several times, and mass market customers lack the
evaluation skills to use the criteria you propose. Therefore the customer
cares about their *perception* of your ability to provide.

And then we are back to a state where a lot of marketing combined with a
decent but not stellar technical operation can win the day.

> JS> Therefore, in the "capital is king" view of open source, the
> JS> leadership incentives do not include integrating changes if one
> JS> can do enough work solo to keep the customer focused on the idea
> JS> that you are the leader.
> Suppose you're running a company and you take this approach.  Aren't
> you discarding one of the big benefits of using open source?  Namely
> the work done by people not in your employ?

I wasn't proposing that a company actually go to this extreme. Clearly the
integrator should take any change that (a) improves the product in the
perceptions of the customer and (b) has an integration cost consistent with
its benefit.

My point is not that a dominant integrator *should* ignore third party
changes, but rather that it *can* do so without losing control of the market
so long as it maintains user-perceived leadership.

As a result, the dominant integrator is in a position to refuse patches that
are value-neutral to the integrator but valuable to a competing third party.
This is where it becomes tempting to formalize ownership relationships. The
point of this whole thread, from my end, is that you can formalize anything
you want but doing so won't change the behavior over the long term because
it doesn't change the alignment of incentives.

I think it would be bad practice, but it's doable.