# Ecosystem Layer

Today's generation of promising projects, often around decentralized systems, need to be ecosystemic from the get-go. We are dealing less with individual endeavors that grow and more with complex projects that require a diversity of stakeholders early and that may cross institutional boundaries.

Experience shows that this is hard to pull off:

- Projects that start from a product-centric approach (build it, then create standards for other implementations to join), will invariably create centralization chokepoints around a single company and struggle to increase community ownership.
- Absent more formal governance the project is effectively led by a self-selected group that may have good intentions but isn't really accountable to the community.
- Centralized hacks deployed in a hurry and supposed to be removed later tend to be sticky. They are even stickier when they are bankrolled by the company that started the project: the community has no reason to start paying, the company needs to keep maintaining them for the broader project to succeed, and as a result the overall system is cosplay decentralization.
- Open source or open standards projects aren't set up to make money. They typically operate on a more or less functional honour code in which some of the major beneficiaries of the infrastructure will have a way to monetize the work and "donate" some time to maintenance. What if open projects could make (fiat) money, which they could then recycle into paying the people who work on the project?
- Infrastructure for shared specifications that make multiple independent implementations possible (formats, change management, maturity level, test suites…) is harder to put together than most realize and there is previous little available off-the-shelf.
- Existing standards organizations are poorly suited for this kind of work, often too bureaucratic, hostile to decentralized projects, or not adapted to this kind of close integration between specification and product work.
- Standard organizations also offer the cooperation avenues but aren't structured around arbitrary deliverables. Decentralized, ecosystem projects often needs specification work, but may *also* be sharing (multiple) implementations.
- It is difficult to organize a project that gives voice not just to a do-ocracy of implementers but instead to multiple types of diverse stakeholders.

The *Ecosystem Layer* is a **cooperative platform** built to tackle those problems and fill that void. It provides a host for open decentralized projects to cooperate in a manner that integrates both product and specification work. The layer notably provides:

- **Governance wireframe**. Projects can elaborate their own but they can build atop an existing toolbox with membership management, a code of conduct, decision rules, group organization, consensus best practices, multistakeholders representation, voting, oversight bodies… Eventually this leads to up DAOs and subDAOs.
- **Funding**. Organizing funding and fund distribution, fiscal hosting, community decision-making (with Arcological and/or Open Collective).
- **Specification tooling**. Spec formatting, references management, maturity levels, publishing area. All the parts that come together to make shared specifications, each of them simple but overall adding up.
- **Legal basics**. Document license, patent policy, CLA automation.
- **Project infrastructure**. Issues, chat, source management, etc. A lot of this is GitHub but the organization can help plan migration to dogfooding and avoid pitfalls (e.g. Slack).
- **Community**. Organizing events, devrel support, communication, marketing, logos, etc.
- **Interface to the world**. Channels to official regulators, an interface to established standards organizations.

The idea is not that all projects operating atop the ecosystem layer need to care about all or even most of these aspects. A small, early days project might ignore many of them. Rather, the idea is that these are all components that *successful* projects will need to care about as they grow. Making them available from the get-go helps eliminate growing pains and makes it a lot easier to kickstart projects that require cooperation that extends beyond a founder's vision.

## Structure

The ecosystem layer (aka the Complex) is a lightweight organization that holds multiple projects (or Polities). Each project may (optionally) in turn hold multiple constituencies. The purpose of constituencies is to account for cases in which multiple different communities (e.g. implementers and operators) are large enough and have sufficiently different requirements and ability to influence the work, and need to be represented as different voices within a project. (Simpler projects don't need to have distinct constituencies, they can have just one and ignore this structure.) Constituencies (or projects directly) then have members. Membership is covered in greater detail in the next section.

Each project is sandboxed from other projects (though they are all encouraged to communicate about their work and to collaborate with others). The Complex provides ecosystem services and has a number of fundamental rules that all projects must abide by. Projects contribute to financing the Complex according to agreements set up when the project is launched and updated regularly. Beyond that, projects are free to set their own internal rules (and the tooling respects that).

## Membership

One major difficulty with many open projects, once they grow beyond a relatively modest size, is deciding who is a member who should have a voice. Another is representing different types of stakeholders who may not have the same de facto power, may have a very different number of people, and may have different voices and differing needs.

The way in which the ecosystem layer solves this is by aggregating as much data as possible about "contributions" and then letting each project decide how contributions map to membership.

Contribution data may include:

- GitHub commits, participation in issues, PR reviews, etc. These can be aggregated easily with either web hooks or by fetching history from the API.
- Presence at a conference. This can be aggregated by pulling from conference registration.
- Financial contributions, for instance via Open Collective.
- Participation in a DHT.
- Any number of other sources.

The idea is to collect contribution data in an unopinionated manner so that projects can layer membership rules atop that data as they wish. For instance, only commits accepted into a specific branch, only accepted PRs, only issues that weren't labelled as spurious, only financial contributions higher than a given level, etc.

A project can use different membership rules for different constituencies, for instance implementers are selected from people who commit code, operators from those that support the DHT above a threshold, or donors people who have provided significant financial support. (And then different constituencies can be given different weights, e.g. donors might max out at 10% of votes — the point is to be flexible so that projects can decide what is fair.)

Projects are encouraged to verify their members by having each new member be endorsed by existing ones. This is to avoid vote stuffing.

Any project member is a project of the Complex, and gets to vote on Complex matters.

## Governance Principles

The governance form that most closely matches the ecosystem layer is the cooperative. Cooperatives abide by the [seven principles of the International Cooperative Alliance (ICA)](https://www.ica.coop/en/cooperatives/cooperative-identity/), an evolution of the original [Rochdale Principles](https://en.wikipedia.org/wiki/Rochdale_Principles):

1. **Voluntary and Open Membership**. Open without discrimination (though there may of course be membership requirements such as having done work).
2. **Democratic Member Control**. The members exert control on the organization (which doesn't mean that everything happens via consensus or that all members have equal right).
3. **Member Economic Participation**. At least part of the capital is common property or distributed in a democratic manner. Profits are recirculated in improving the cooperative and ecosystem.
4. **Autonomy and Independence**. Coops are autonomous. This is notably true in terms of VC control.
5. **Education, Training, and Information**. Educate members and others.
6. **Cooperation among Cooperatives**. Cooperatives work together.
7. **Concern for Community**. Doing good for their communities and for the world.

Each project is (in governance at least) a coop, and the ecosystem layer operates as a coop of coops. Working within a coop frame has multiple advantages:

- It's flexible while also having democratic values.
- There is significant experience and precedent in operating successful cooperatives at scale, as well as a movement willing to provide support and advice.
- Additionally, there is precedent for coop of coops (aka cooperative complexes).
- Coops can use the `.coop` domain, which is an interesting distinction.

Without getting into much detail, an outline of the system's governance is as follows:

- Day to day operations of the Complex are managed by the Executive Director, who gets to hire a team and makes typical managerial decisions.
- The ED is overseen by the Governance Board, who have hiring and firing power over him. The Board is expected to meet several times a year, but not too often (i.e. it's not a job). The Board sets strategic directions, updates the internal rules, etc.
- The Governance Board is elected by different groups each of which has a set number of seats. One group is all project leaderships (so long as the number of projects is manageable, this may just be one seat per project lead). Another is the general assembly of all members.
- There is also a Social Board. The goal of the social board is to represent members as *people* rather than as contributors. Elected by the general assembly, this serves as a union of sorts.

Individual projects need to follow a number of rules (notably, they must be democratic or on track to becoming that) and will be encouraged to adopt a number of best practices. Beyond that, they can organize as they please.

## Ecosystem Services

tk fill out details of the services, funding, etc. operated by the Complex

## Appendix: Prior Art

- The [Apache Software Foundation](https://apache.org/)
- [Open Collective](https://opencollective.com/)
- [Arcological Association](https://arcological.xyz/)
- The [Mondragón Corporation](https://www.mondragon-corporation.com/en/)