rent licenses of open code projects that would undermine this threat in the
future.[4-51] Instead, the possibility of forking keeps pressure on the guardians
of an open code project to develop the project in a way that the broadest
range of users wants. As author Peter Wayner puts it, "[I]t prevents one per-
son or clique from thwarting another group."[4-52]

This is democracy brought to code. An open code system can't get too far
from the will of the users without creating an important incentive among
some users to push the project a different way. And this in turn means the
platform cannot act strategically against its own. The threat that created a
federal case in _United_States_ v. _Microsoft_ is not a threat if an operating sys-
tem is built on open code. And the absence of strategic behavior in turn in-
spires others to build for this code.

Now my claim is not that this neutrality is the only factor that affects
whether coders build to one platform rather than another. If 99 percent of
the world is on a closed platform, and 1 percent is on an open platform,
then regardless of the benefits of the 1 percent platform, there are naturally
strong pressures to code for the 99 percent.

Yet this factor is not well enough understood, and its effect on innovation
is systematically ignored. The effect here is similar to the effect we've seen
in other contexts, and our aim, here and in other contexts, should be to bet-
ter appreciate its role in building the Internet we have seen.

///\\\

The users of an open code project are not therefore hostages. That's the
lesson argued so far. They are not hostages to bad code -- the right to tinker
is assured. And they are not hostages to strategic code -- open code can't be-
have strategically. These two features together constitute the innovation
commons that the Internet creates. They capture the public value that open
code supports.

But there is a challenge with open code projects that many believe is in-
surmountable. This is the challenge to assure that there are sufficient in-
centives to build open code. Open code creates a commons; but the
problem with this sort of commons is not the problem of overgrazing. (In-
deed, as "accidental revolutionary" Eric Raymond puts it, open code creates
an "inverse commons." "Grazing" does not reduce the code that is avail-
able. Instead, "in this inverse commons, the grass grows taller when it's
grazed on.")[4-53]

The problem instead is to assure a sufficient incentive to supply new or
improved code -- a provisioning problem, in other words. In a world where

[[68]]

p067 _ -chap- _ toc-1 _ p068w _ toc-2 _ +chap+ _ p069

v?