Material peer production—Part 2: Free Cooperation
[Diesen Artikel gibt es noch nicht auf Deutsch. Wenn du dazu beitragen willst, das zu ändert, beteilige dich bitte an der Übersetzungs-Werkstatt.]
Previous part: Effort Sharing.
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:
- Goal setting: the project participants need to determine what they want to produce or achieve.
- Internal organization: they need to determine how to reach these aims, organizing production, appointing positions, resolving conflicts, etc.
- 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.
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.
Next part: Commons and Possession.