Subject: Re: Free Software vs. Disruptive Change
From: Tom Lord <>
Date: Wed, 10 Jul 2002 02:02:57 -0700 (PDT)

       [re: RH stock grants to] everybody (more or less) with a
       ChangeLog entry

That's a nice example of how engineering process creates natural
opportunities for non-contractual transactions which, ultimately, are
the only means available for rewarding creators of free digital
content _as such_.

I keep coming back to the idea of an open source world where there are
lots of little tills for hackers to dip into as they make
contributions to projects -- plus some global constraints to prevent
(counterproductive) gaming of the system.

A while back, I posted pointers to some notes suggesting "computed
paylists" as a mechanism for implementing those global controls.
Maybe that's too heavyweight an approach: I'm starting to think that
just global fiscal transparency is probably enough (large patrons of
many volunteers can implement whatever global controls they want
internally if the volunteer world is more or less fiscally

I still think it would work best if _each_ "employer" (in the
volunteer world) had a surplus of "employees" and vice versa.  That's
practical if pay is linked to performance: projects simply have idle
pools of "occaisionally paid" workers.  It's a good situation for
labor/mgt relations (because the barriers against walking away from
dysfunctional situations are lower) .  It's an environment in which
individual workers can be really opportunistic -- actually working at
whichever job is momentarily the most convenient.

I like this approach because it encourages people to interact broadly
and not over-specialize.  If control over paylists is decentralized,
it might succeed at not centralizing economic power in the open source

If you believe in such a future for the internal money flow 
among open source producers, then I think you can easily
find quite a number of entrepreneurial opportunities in the present
because, in several different domains, such a future has its own
unique set of infrastructure requirements.

One point I think is critical is to not try to _force_ new engineering
processes to fit the needs of an envisioned economy.  Some
monetization technologies (e.g., distributor specific
pay-to-upgrade-over-the-net services) seem to me to be rather
"forced": if you weren't trying to force a buck out of a customer,
you'd never architect the software that way.  I have nothing against
forcing a (fair) buck out of a customer -- but don't break my software
in the process.  If new software and systems become the tool by which
open source labor is monetized, that software better be good and
useful independently of any financial considerations.