P2P Foundation

Researching, documenting and promoting peer to peer practices

Featured Book

Spreadable Media

Book Store




Christian Siefkes on Distribution Pools

photo of Michel Bauwens

Michel Bauwens
11th February 2008

As a trendwatcher with a larger overview of trends than people spending less time on this, I’m often frustrated that I see various initiatives emerging, each working independently, often re-inventing the wheel, and not coordinating on standards and interoperability. A lot of energy is wasted in re-doing things that have already been done and could be built on. An example is the various initiatives on peer to peer infrastructures, which as far as I know, are not correlating.

Christian Siefkes, who is continuing his publication of a series on the material peer economy, tackles this question, and proposes the creation of distributed pools, or d-pools.

Read what he has to say:

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


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>