[Patrick, this part and the two that will follow should largely answer your
questions. If they don't, don't hesitate to ask again.]
Cooperation Between Projects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the previous part, I have discussed how a project can distribute the
effort required for production among those who want to benefit. With these
effort sharing models, it is _not_ necessary for participants to produce by
themselves what they want to consume--if a project produces different goods
(bicycles, cars, etc.), you can take part in producing a good _A_, and in
return get access to any other good(s) _B_ produced by the same project.
This allows you to get access to various goods without having to get
involved in the production of all of them.
But so far these models have only been considered in the context of a
single project, which poses a problem: as consumers, people generally have
many diverse needs and desires. In order to satisfy them all, you would
either need a project that produces _a lot_ of very different goods, and
such a huge project might become inflexible and hard to maintain. Or you
would have to contribute to lots of different projects, which would
complicate your life enormously.
We can understand this problem better by regarding the different aspects
which the participants of a project need to handle:
1. _Goal setting:_ the project participants need to determine _what_ they
want to produce or achieve.
2. _Internal organization:_ they need to determine _how_ to reach these
aims, organizing production, appointing positions, resolving conflicts,
etc.
3. _Effort sharing:_ they need to distribute the effort required to reach
these aims in a way that is acceptable to all.
Apparently, for the last aspect, huge diversified projects would be
beneficial, since they grant participants a wide range of goods to choose
from and a large variety of tasks to handle. But for the other aspects,
smaller and more specialized projects seem preferable, since the internal
organization of a huge project might become difficult and bureaucratic, and
the maintainers or admins of a huge project could become disturbingly
influential in regard to the goal setting process.
Projects can resolve this conflict through cooperation. Different projects
can cooperate in regard to the third aspect, _sharing tasks and produced
goods as if they were a single project,_ but _each of them setting its own
goals_ and _deciding on its internal organization_ independently of the
others. They can do so by using a _single shared system_ for distributing
both the _tasks_ they need to have handled and the _results_ of their
cooperation (the goods they have produced)--such a single shared system I
call a *distribution pool* (or *d-pool* for short). Tasks and products can
be distributed in the same way as before--using _weighted labor_ to assign
tasks and allocation based on _production effort_ or _preference weighting_
to distribute goods that cannot be copied freely--but among all the
participants of a _distribution pool_ instead of just the members of a
single project.
Wouldn't such a d-pool be very similar to a market? It wouldn't, since
there are still only _contributions,_ no _exchange_ is taking place (as
apparent from the fact that producers won't benefit if their product is
auctioned off at a higher cost). But now, while contributions are still
made to a specific project (allowing it to reach its specific goals), the
tying of benefits to contributions takes place in the context of the
d-pool. Contributing to _any_ product in the pool gives you access to (a
suitable amount) of _any_ goods produced in the pool. You don't have to
contribute to dozens of different projects to get all the goods they
produce, just contributing to a single project (or a few) participating in
a d-pool is enough.
The difference between markets (based on exchange) and d-pools (based on
contributions) might sound theoretical, but it has consequences which are
very real. Market production takes place for _profit_ (organized by private
producers competing with each other), but in distribution pools, there is
no profit. Projects joining a d-pool are not motivated by profit (which
doesn't exist), but by the desire of their participants to get access to
the goods produced by other projects. In effect, the participants of
different projects enter a mutual agreement to help each other produce
what they want to get.
Since produced goods are distributed through the d-pool, it makes very much
sense for projects to take the overall demand into account and to
coordinate their own activities with those of other projects producing
similar goods. Otherwise they risk producing too much _(overproduction)_ or
too little _(underproduction)_ of a good. If they produce too much, they
risk "wasting effort," since d-pools will probably recognize as
contributions only efforts spend in the production of goods that somebody
actually wants to have (otherwise projects could just produce worthless
"garbage" which nobody needs and in return get access to other, useful
products distributed through the pool). If they produce too little, the
produced goods will be auctioned off at a higher cost. This wouldn't help
them as producers (who get recognized the _effort_ they spend on behalf of
a project/pool as contribution, and this _production effort_ isn't modified
through product auctioning, as explained above), but it would hurt them as
consumers (who have to pay the higher cost by contributing more). And among
the people cooperating in a project there will usually be some who are both
producers _and_ consumers ("prosumers"), since peer products are
typically started by people out of an interest in the goods they produce
("scratching an itch").
Projects producing similar goods will thus prefer to coordinate their
efforts in order to adjust their supply to the demand. Far from being
forced to _compete,_ they are incited to _cooperate_. For the same reason
(the possible deviation between production effort and cost hurting them as
prosumers), such projects will tend to share their knowledge, experiences,
and inventions to help each other to optimize their production processes.
If they don't, the members of projects who manage to reduce their
production effort won't fully benefit from their optimizations, since their
products will now be more popular than those of the others and be auctioned
off at a higher cost, hurting them as consumers without helping them as
producers. (There are additional reasons for sharing your knowledge, such
as increasing your _reputation,_ which are discussed in my book.)
I use the term *prosumer association* for any institutions projects active
in the same sector of production set up to support this coordination and
cooperation.
Local Cooperation
~~~~~~~~~~~~~~~~~
There are things that concern all the people living in a specific area,
such as the providing and maintenance of infrastructure and of public
services (e.g., health and elder care). To handle these issues, the people
concerned need to jointly deal with two of the three aspects discussed
above: they need to _set goals_, deciding which infrastructure and services
to organize (item 1), and they need to _share the effort_ required to do so
in a way that is acceptable to all (item 3).
I use the term *local association* to refer to institutions that the
inhabitants of an area set up for these purposes. Local associations will
need decision-making structures for _goal setting,_ but they don't have to
handle the providing of infrastructure and public services all by
themselves. Instead, they can cooperate with various peer projects for
organizing the different activities (a project building and maintaining
streets and bridges, another one running a hospital, a third organizing a
fire brigade, etc.), leaving the detail decisions of how exactly to
organize things (item 2) to the specific projects. Local associations will
also have to decide how to make the organized services available--in many
cases, _flat rate_ access might be the most suitable model, but other
allocation models are possible too.
To _share the required effort,_ local associations can rely on the
mechanism discussed above, by joining a _distribution pool._ Due to the
effort-balancing effect of distribution pools, this means that the members
of a local association will have to contribute as much effort to the d-pool
as they take out of it: together, they need to contribute enough weighted
labor to the distribution pool to make up for the overall effort required
for the activities coordinated by their local association.
A special issue that can be considered a public service and that might be
handled by local associations is to ensure that everyone gets access to the
goods they need, regardless of whether they can contribute. The core idea
of the "effort sharing" model is to distribute the effort required for
producing something among those who want to benefit, but it would not do to
exclude those who _cannot_ contribute (say, because they are too old, too
young, ill, or disabled). A part of the goal-setting and
effort-distributing activities of local associations can thus be to decide
who is _exempted_ from contributing and to ensure that those who are
exempted get access to the goods they need or want to have (which means
that everybody else will have to contribute slightly more to make up for
the missing contributions).
Since the scales most suitable for organizing a task vary for different
tasks, I assume that there will be several levels of local associations of
different sizes that nest into each other like Matryoshka dolls (for
example, a _communal,_ a _regional,_ and a _global_ level).
Decision Making and Conflict Resolution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How will projects and associations make decisions, how will they resolve
conflicts? I cannot discuss this here in detail (see my book for a longer
treatment), but my basic assumption is that they will do so in a manner
that is similar to the practices of current peer projects.
Current projects tend to combine a _meritocratic_ element (participants
trust "maintainers" and other specialists to "do the right thing") with a
_democratic_ element (projects strive for _consensus_ or _rough consensus_
among the participants, people "vote with their feet" by choosing which
projects to support). Note that the _meritocratic_ element is far from
being autocratic: since maintainers cannot order anyone around, they have
to _convince_ participants that their decisions make sense--if the project
members feel their decisions to be unfair or incompetent, they will sooner
or later leave the project or start looking for a new maintainer. Note also
that the _democratic_ element hardly takes the form of _majority
voting_--the open character of projects makes it hard to determine who
should be eligible to vote, and narrow majority decisions on controversial
issues would endanger the stability of projects (those who lose a vote
might decide to "fork" the project, founding their own alternative).
The "enforcement" of rules and decisions is often based on _technical
means_ (somebody without write access to the code repository cannot damage
the source code of a project) as well as on _trust;_ most projects manage
to do quite well without formal control and sanction mechanisms. If people
violate the rules, they are usually just told that they did wrong and
admonished not to do so again--mostly this happens in a friendly fashion,
but more aggressive and scolding "flames" occur as well, especially in more
serious cases. Due to the important role of _reputation,_ trying to give
somebody negative reputation by "flaming and shunning" them tends to be a
powerful way of sanctioning people if less aggressive ways prove
ineffectual. If all else fails, _boycott_ and _exclusion_ remain as the
toughest sanctioning mechanisms.
I suppose that future peer projects and associations will pursue similar
ways of decision making, striving for _rough consensus_ among the
participating people and projects and trusting _maintainers_ and other
responsible experts to "do the right thing," especially in regard to
technical issues. One difference to the current situation is that projects
that _require_ contributions might rely more heavily on democratic
decisions, including majority voting (at least as fallback mechanism). In
such projects, the problem of deciding who is eligible to vote and to
prevent duplicate votes becomes void since voting rights can be tied to
contributions; and it seems reasonable that people who have to contribute
will want to have more say in regard to the activities of a project.
However, the concern that narrow majority votes would endanger the
stability of projects still applies, hence it seems likely that majority
voting would only be used as a last resort when (rough) consensus fails to
emerge. Another way of ensuring the influence of contributors while keeping
the meritocratic character of peer cooperation would be to assign
_revocable positions_ for maintainers and other special roles.
Best regards
Christian
--
|-------- Dr. Christian Siefkes --------- christian siefkes.net ---------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production in the Physical World: http://www.peerconomy.org/
|------------------------------------------ OpenPGP Key ID: 0x346452D8 --
As for creation, it would be silly to think that music, a cultural form
without which no human society has existed, will cease to be in our world
because we shall abandon the industrial form it took for the blink of a
historical eye that was the twentieth century.
-- Yochai Benkler, Sharing Nicely: On Shareable Goods and the
Emergence of Sharing as a Modality of Economic Production