Public Domain Python

[Alex Martelli]

"Grant Griffin" <g2 at seebelow.org> wrote in message
news:39C14021.50CF428D at seebelow.org...
    [snip]
> That's an interesting comparison.  However, I'm tempted to say that
> although free trade is a good thing in every case (IMHO), the software

Sorry, but this is just not true -- 99%, yes; every case, NO.  Read
your Krugman (not his extremely pleasant semi-divulgatory stuff, the
hard-core stuff he publishes on learned journals etc; his homepage
has good pointers).  E.g., for an extremely scarce, non-renewable
resource, and different discount rates in the single little country
that has the natural monopoly of production and the huge country (or
countries) that have essentially-unbounded demand curves, it can be
proven that coercive limits on import-export of that resource can
lead to Pareto optima (to oversimplify: without the limits to trade,
the resource would fast disappear in the unsatiable maws of consumers
of it; with the limits, the disappearance is slower, prices rise with
time [as quantities diminish], and given the different-discount-rates
hypothesis, this can work out so _everybody_ is better off than with
the faster-consumption free trade would impel).

> world will forever consist of a mixture of free/open and
> commercial/closed.  I personally believe that as a business proposition
> (rather than an ideology), there still are and forever will be cases
> where commercial/closed software makes more business sense.

Raymond advances exactly the same hypothesis, including at least one
example where, working as a consultant, he advised a firm who was
thinking about opening up its sources _against_ doing so.  I think
such cases probably amount to 1% or thereabouts of code being developed
today, but I'm also sure they exist -- just as equally rare cases where
free-trade is not economically optimal (ideology apart) do exist.

In practice, since today such limits affect well over 30% of trade
and 90% of software development, rather than about 1% of each, it's
a very natural reaction to push with no holds barred for 100% free
trade and/or free software; we're so far off from each, anyway...


> > The unrestrained triumph of open (or free) software will not, by
> > itself, give you that, any more than, say, that of free trade would.
>
> One of my points along the way has been that if free/open software isn't
> economically beneficial in-and-of-itself, it won't fly in the long run;
> conversely, if it _is_ beneficial, the constraints placed on the freedom
> of users of free/open software by the GPL's "copyleft" construct aren't
> necessary, and therefore tend to work against the overall proliferation
> of free/open software.

Not necessarily; again, I invoke the excellent analogy with free
trade.  Mutual treaties *mandating* free-trade are a good thing in
that they arm decision-makers against the rent-seekers who're forever
pushing for their own short-term advantage in protectionism; similarly,
a *mandate* for open source could shield a decision maker (perfectly
aware of its long-run advantages) against rent-seeking behavior by,
e.g., stockholders, threatening legal action unless he (or she) acts
so as to maximize their returns THIS quarter (as opposed to a run
of any real length).


> Although there currently is a lot of "hype" around the concept of
> free/open software, it has now become such a big thing that one can only
> conclude that there must some real economic value in there _somewhere_.

Beware against drawing conclusions from current popularity.  Even
though the conclusion is valid, the process leading you there is
not necessarily so:-).

> Python is a good example of an open-source economic efficiency.

I agree, but not for the reasons you state.

> Although it runs on numerous operating systems/environments, there is
> only one implementation (of the full system); one doesn't see numerous
> re-implementations of the whole thing, as one sees in things which
> didn't originate as free/open software.

One seems many re-implementation of MANY things, including perfectly
free ones.  Consider Scheme, for example; I think there is one or
two proprietary implementations (NOT the original ones), and twenty
or so variously-open-and-or-free ones, of which at least half a dozen
are actively maintained.  (Similar situations hold for, say, ML, and
Haskell -- in these cases, all I know of are free/open).

Such fragmentation has both advantages and disadvantages -- just as,
say, Vyper or Python.NET will if/when they mature.  "One size does
not" necessarily "fit all".  Why not, if the economics make sense,
have an implementation optimized for speed, one for painstaking error
checking, one for a given peculiar platform, etc, etc?  In as much
they all implement roughly the same language/libraries, they can
benefit from each other -- and, incompatibilities apart, users can
benefit from the choice.

It's not a bad thing that there's more than one cola drink on the
market: it gives my tastebuds (and pocketbook) a say in _what_ cola
I drink, rather than having the choice limited to yes-or-no.

Python does show the advantages of openness: in its very high
quality -- thanks to the overriding architectural lead of the
BDFL, of course, but a zillion people can and do contribute
the ideas & implementations among which He can select, the
suggested-fixes He may base definitive-fixes on, &tc, &tc.


Alex