Subject: RE: BSD, GPL and macroeconomics (This is a private question to JSS)
From: "Jonathan S. Shapiro" <>
Date: Mon, 18 Feb 2002 13:51:08 -0500

>     shap> 1. There *is* a cost of displacement. Once the lower price
>     shap> option is installed it tends to stay installed.
> This is inaccurate.  Once any option is installed, it tends 
> to stay installed... [this]
> merely means that free software can take advantage of lock-in 
> in the same way that proprietary software can.

I agree, and I agree that windows of opportunity for displacement open
at selected times. When those windows open, however, free software
benefits from two effects:

1. It's very very easy to try it. If you try it and it's good enough,
chances are good that you can be encouraged to stick with it rather than
spend money to try something else too.

2. When these windows open, people within the organization who are
outside of the normal purchasing decision process frequently come
forward and say "I've been solving that problem for several months/years
because you guys weren't ready to pay attention. Before you displace the
work I've done, I think you should look at it."

Since these people don't tend to have any budget to solve these
problems, they tend to favor cheap solutions.

That is, free software maximizes opportunities for internal advocacy
following ad-hoc technology introduction.

> Note that this is independent of the advantage that free 
> software lessens _vendor_ lock-in.

Agreed. The vendor lock-in is established by the maintainence practices,
quality control, ease of upgrade, and the "stick with what you know"

>     shap> 2. The cost of maintainance of free software can be
>     shap> amortized over more parties, and is therefore cheaper
>     shap> per-party.
> Assuming you can collect from more parties, which is why we 
> have intellectual property in the first place.  As an 
> implication, the statement is correct, but the "is" should be 
> replaced by a second "can be".

I said the cost of maintainance, not the price of support. What I mean
is that there is a significant body of experienced developers who will
accept all kinds of compensation other than full-time salary. Some of
the cost of maintainance that a proprietary company must carry for
itself can be replaced by a lower cost of *relationship* maintainance
with these developers in an open source company. This is a source of
leverage, and sometimes a significant one. The ability to get 20% of a
real expert when you need it is extremely valuable.

>     shap> [There is] the likelihood that open source can potentially
>     shap> adapt to customer need more adroitly than closed.
> This is an interesting point.  I tend to agree, but I think 
> the flexibility depends on the ease with which small scale 
> vendors can enter the open source market.  It's pretty clear 
> that mainline open source projects can be just as resistent 
> to satisfying user requests as large proprietary vendors are.

I agree. On the other hand, a really determined customer can either
modify it themselves or hire a consultant from the core team or the
second tier (the people the core team trusts) and work the social
structure to get it adopted. Open source is relationship intensive. That
can be either a strength or a weakness, depending on which problem you
are trying to solve and who you must work with.

> There's also the question of whether "open source" need mean 
> OSD open source.  Suppose some proprietary vendors started 
> publishing (some) source under a "look but don't 
> redistribute" license?...

Or better: look, modify, but only redistribute within your organization.
I consider this a serious threat. Howeveer, there is a mindset issue.
The open source community has built into its social fabric the idea that
people might occasionally contribute things of value. The proprietary
world does not, as a rule, accept such donations easily. Ask any SAS
customer. Further, the equity imbalance in the license structure
reinforces the customer in deciding not to donate something of value:
there is no quid pro quo.

Also, the rise of the agilely composable work team (across company
boundaries) is going to make a mess of license terms that balkanize
according to traditional organization structure boundaries. All of a
sudden that balkanization will be perceived as a significant impediment
to daily business practice.

So if you are asking: "does this model work?", my answer is "In
practice, probably not."

If you are instead asking "Does this model look enough like it would
work to FUD the issue, generate market confusion, and muddy the clarity
of the open source value proposition?" then my answer is "Probably, and
we really ought to prepare for that."

> Of course, none of this is relevant to your original post 
> about how the government should deal with its contractors 
> (especially researchers).  There it's pretty clear that, if 
> the government is going to fund the initial development, 
> requiring publication as open source will improve 
> responsiveness.  But your most recent post seems to make a 
> more general argument.

I suppose this is because these questions are also at the front of my
mind, as I am in the process of working out how to articulate some of
them to potential investors in a new company.

By the way, your very reasonably framed questions have provided help in
thinking this through. It is appreciated. Thank you.