Subject: Re: BSD, GPL and macroeconomics (This is a private question to JSS)
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: 18 Feb 2002 19:59:40 +0900

>>>>> "shap" == Jonathan S Shapiro <shap@eros-os.org> writes:

    >> I don't understand this.  The only cost that matters is
    >> support, because it's the ongoing one?  In that case, how does
    >> free SW have an advantage over non-free SW?

    shap> Two reasons:

    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.  So if you have inexpensive free software installed now, if
there is sufficient reason to choose the higher-priced option at the
next "switching window", then you'll switch.  At that point the
higher-priced option has the advantage until the next "window."

So this is not an advantage for free software per se; it merely means
that free software can take advantage of lock-in in the same way that
proprietary software can.

Note that this is independent of the advantage that free software
lessens _vendor_ lock-in.  Eg, although I could easily switch from
Debian to Red Hat, and thus am not locked-in to Debian if I like Red
Hat better.  But if I were running Red Hat, it would be relatively
hard for me to switch to NetBSD, although it is cheaper than Red Hat,
runs well on my hardware, and all of my critical apps are available.

    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".

    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.

So the question this suggests to me is, "how do you know it wouldn't
be easier to generate the necessary revenue to support the enhancement
with an agreement between a proprietary mainline vendor and an add-on
vendor?"

Granted, that is not the classic strategy of proprietary vendors.  But
the current vogue of "the virtual firm" makes it an open question
whether proprietary vendors will be able to move in the direction of
flexible joint response to customer needs faster than open source
vendors can move in the direction of generating revenues that meet
programmer needs, such as "dinner".

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?  Suddenly the
advantages of open source in terms of flexibility start to look a lot
more slender.  From the proprietary point of view, in some cases this
might be enough to compensate for the partial loss of revenue this
would undoubtedly imply.  Surely those are exactly the cases where
FSBs have the strongest business models?

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.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.