The solution to the three problems I outlined in the first part of the post is not easy, for it is the problem of the governance (management of risks and cares, or more precisely, the legitimacy of the game of risks and cares) of large communities with different degrees of participation and stakes.
Ana Manzanedo and her colleague Alícia Trepat have documented a set of practices that platform coops are setting in order to solve the downside of platforms. The first outcome of these practices is to set fairness distribution of risk and value generated by the platform activity. In that sense, it is not only that assuming risk is rewarded, but also that the consequences of bad decisions or actions affect those that made them (what Taleb calls having “skin in the game”: he or she who wants a share of the benefits needs to also share some of the risks). The second outcome of the practices is that it establishes the responsibility for the care of all those involved in the platform, which means that their vulnerabilities are covered so the reproduction of the activity of the platform is assured, even beyond the nowadays generation who carries it. We could call that having “skin in the care”.
The real world examples captured by Ana and Alicia reflect the insight explained in this previous post: that solutions for communities having thick relationships do not scale for communities with thin relationships. In fact, in the first kind of communities, emerge a behavior hardly seen in the second: voluntary risk-taking for others, which Taleb calls “soul in the game”. Accordingly, it is not unusual to see voluntary care-taking for others, which we could call “soul in the care”.
The desirable governance of a Platform Coop is the one that promotes skin/soul in the game/care:
Table 1: Desirable approach for risk and care management
(extreme case: stock trading)
(extreme case: child nurturing)
skin in the game
soul in the game
skin in the care
soul in the care
Communities of peers have their own ways to avoid risk and care transfer, particularly between their members. Most of the practices described by Ana and Alicia fall in at least one of the following approaches:
Table 2: Peer’s communities approaches to avoid transfer of risk and care
Avoid transfer of risks
Partial mutualisation, Economic Democracy, Rent Free Markets
Partial or total mutualisation
Avoid transfer of care
Partial or total mutualisation
Platform Coops are, like the rest of the platforms, trapped by the “law of power” and by “winner-takes-it-all” dynamics. Yet, departing from the new possibilities offered by technological progress and societal change, we know where the solution might be:
a) Opening and commoning knowledge and resources as much as possible, in order to promote diversity of players and non-monopolistic (rent-free) markets: showing that Platform Coops do not maximize self-interest, and that abundance is possible through cooperation. Attracting individuals and communities with soul in the game and making them interact to create new subjectivities.
b) Making decision-making as much distributed as possible in the communities of life (clubs, neighborhoods, etc.) that are affected by the decision, and in the communities of production (i.e. foundations, coops, etc.) working in a federated way, according to their proved competences. Involving communities with skin in the game, and letting them jump in the logic of the soul in the game.
That, of course, draws a completely different network dynamics, and therefore, a different governance. Here it is my proposal to rethink Platform Cooperativism as Platform Ecoopsystems, (a sort of mix of Platform Cooperativism and Open Cooperativism).
1. Platforms should not be conceived as monolithic architectures owned and managed in a centralized way. They should be conceived as ecosystems, or we will be trapped in the same logic from which we want to escape.
The only reason why platforms are monolithic is because it is the way in which value can be easily extracted in a centralized manner. It is true that some of them offer API’s to third party developers (i.e. Facebook) as long as those development supports their extractive business models. Platform Ecoopsystems, instead, should think in terms of distributed architectures. I suspect that, too often, p2p and sharing initiatives are secretly pervaded by the darling image of the individual entrepreneur, because the tools and practices used are adapted from those of the traditional rent-seeking economy, instead of being created from scratch.
2. There is no technological obstacle to design Platforms with distributed architectures. Let’s do it in order to promote ecosystems.
Once the extractive business model motivation is removed, there is no technological reason to prefer a centralized architecture. Resources are usually already distributed, infrastructures can be distributed, and platforms themselves can be distributed. Although blockchain is the new kid on the block, torrent technologies should not be discarded.
Table 3: Key Differences in Centralized and Decentralized Systems across the layers – taken from the Platform Design Toolkit Whitepaper:
|Long Tail Layer|
Users (Peers in a marketplace)
As a Service / “Cloud”
Public blockchains /
Owned and centralized
Distributed and leveraged
3. Platforms must be organically built as ecosystems in which sustainability is reached by a combination of federation of communities that are trusted for making certain decisions, and market coordination.
What would happen if we think of Platforms more like an Open Source Operation System (such as Ubuntu) than as an App? What are the decisions to be made?
Table 4: Approach to Platform Decisions
|Risk to be managed through incentives|
|User interface, user experience.||Market coordination: let different developers compete.||Diversity, innovation, customization.||Poor experience (initially).|
|Features||Market coordination: let different developers compete with add-on’s, or even forking.||Diversity, innovation, customization. User autonomy.||Poor experience (initially).|
|Use of data||Market coordination: open data for everyone and let privacy in hands of users.|
Diversity, innovation, customization.
|Complexity for user.|
|Pricing and value distribution||Mixed: some by market, some accorded by a federation of communities after market/user data.||Sustainability, resilience and antifragility based in fairness.||Low engagement of users and communities.|
The key is to minimize the decisions that must be decided by voting to those decisions where scarcity is real, through:
Opening, opening, opening.
Designing in such a way that financial value is distributed through free-rent markets.
Delegating decisions to trusted participants that excel in the required competencies to perform their duty.
If a gatekeeper is unavoidable, then it should be non-profit that distribute value as in rent-free market, assuring the financial sustainability of all participants. In other words, if there is a “cut” that can be captured because of intermediation, it has to be distributed in such way that risk and care is not transferred (see – again – Ana and Alícia for IFTF on positive platforms).
4. The kernel of a Platform Ecosystem should be a non-profit
Depending on the nature of the activity and business model, the initiators and promoters of a Platform Ecoopsystem should not be organized as a cooperative itself, but as a non-profit organization that acts as a sort of kernel of the ecosystem. It could be formed by a group of future stakeholders of the platform that distribute their contribution according to the competencies in which they are publicly recognized. This organization should a) create the initial conditions for the ecosystem flourishing and b) maintain the conditions for its sustainability as a positive platform, that compensate differently to participants according to their contribution and the stage of the project. (For instance, in the early stages, gamification might be used in order to distribute value to those that make the app/platform more viral in order to solve the chicken egg problem.
You may think that how this kernel operates is the actual key of the whole post, and maybe it is, but I prefer to just outline some intuitions about it, and maybe develop the idea in a future post, or just with a conversation in the comments of this post:
It should release a first version of the infrastructure/platform open source software (code also could be sponsored by future stakeholders of the ecoopsystem).
It should put in place the right mechanisms for distributing the value.
It should organize the consultations to stakeholders.
It should choose providers of the ecosystem, whenever that decision must be taken in a centralized way.
It should serve as arbitrator of stakeholders’ disputes.
If value must be centralized because of some unavoidable design reason, an instantly updated and transparent accounting must be available, in which is visually clear how the value (compare with average industry) is distributed in the co-owned platform. Let the community be able to deliberate and vote periodically on how the value should be distributed.
5. Platform Ecoopsystems should leverage their two distinctive features in order to outcompete existing platforms: they do not have to create artificial scarcity, and they do not have to centralize value capture.
The ultimate competitive advantage of Platform Ecosystems is that user experience and value are not conditioned by artificial scarcity of features and services, which only purpose is to keep rent-seeking practices. In that sense, Platform Ecoopsystems do have an important business advantage, for they can better suit the needs and requirements of its users.
6. In the same way that FLOSS created their own array legal license options, Platform Ecoopsystems should create their own array of legal ownership options.
New legal agreements of property and decision-making should be explored, in order to dynamically evolve according to the needs of the Ecoopsystem. These agreements should offer different modalities of ownership and decision-making in which participants can be automatically positioned according to predefined parameters.
Download the following canvases: