matrix-spec/proposals/1779-open-governance.md

Proposal for Open Governance of Matrix.org

---

For updated information on the Foundation, please see https://matrix.org/foundation/. This MSC exists for historical reference.

---

This whole document is the proposed constitution proposal for Matrix.org, and will form the basis of the first full Articles of Association (AoA) for The Matrix.org Foundation C.I.C. - a non-profit legal entity incorporated to act as the neutral guardian of the Matrix decentralised communication standard on behalf of the whole Matrix community.

See https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2/ for more context.

This obsoletes MSC1318.

This MSC is now formalised in the official Rules of the Matrix.org Foundation, maintained at https://docs.google.com/document/d/1MhqsuIUxPc7Vf_y8D250mKZlLeQS6E39DPY6Azpc2NY

Introduction

Historically the core team of Matrix has been paid to work on it by the same employer (currently New Vector; the startup incorporated to hire the core team in Aug 2017). Whilst convenient in initially getting Matrix built, we recognise that this could create a potential conflict of interest between the core team’s responsibilities to neutrally support the wider Matrix.org ecosystem versus the need for New Vector to be able to support the team, and it has always been the plan to set up a completely neutral custodian for the standard once it had reached sufficient maturity.

This proposal seeks to establish a new open governance process for Matrix.org, such that once the specification has finally been ‘born’ and reached an initial ‘r0’ release across all APIs, control of Matrix.org can be decoupled from New Vector and better support contributions from the whole ecosystem.

The concepts here are somewhat inspired by Rust’s Governance Model; a highly regarded solution to a similar problem: an ambitious open-source project which has been too many years in the making, incubated at first by a single company (Mozilla Corporation), which also enjoys a very enthusiastic community!

Overview

Governance of the project is split into two teams: the Spec Core Team and the Guardians of the Foundation. In brief:

The Spec Core Team are the technical experts who curate and edit the Matrix Specification from day to day, and so steer the evolution of the protocol by having final review over which Matrix Spec Changes (MSCs) are merged into the core spec.

The Guardians are the legal directors of the non-profit Foundation, and are responsible for ensuring that the Foundation (and by extension the Spec Core Team) keeps on mission and neutrally protects the development of Matrix. Guardians are typically independent of the commercial Matrix ecosystem and may even not be members of today’s Matrix community, but are deeply aligned with the mission of the project. Guardians are selected to be respected and trusted by the wider community to uphold the guiding principles of the Foundation and keep the other Guardians honest.

In other words; the Spec Core Team builds the spec, and the Guardians provide an independent backstop to ensure the spec evolves in line with the Foundation's mission.

Guiding Principles

The guiding principles define the core philosophy of the project, and will be a formal part of the final Articles of Association of the Matrix.org Foundation.

Matrix Manifesto

We believe:

• People should have full control over their own communication.

• People should not be locked into centralised communication silos, but instead be free to pick who they choose to host their communication without limiting who they can reach.

• The ability to converse securely and privately is a basic human right.

• Communication should be available to everyone as a free and open, unencumbered, standard and global network.

Mission

The Matrix.org Foundation exists to act as a neutral custodian for Matrix and to nurture it as efficiently as possible as a single unfragmented standard, for the greater benefit of the whole ecosystem, not benefiting or privileging any single player or subset of players.

For clarity: the Matrix ecosystem is defined as anyone who uses the Matrix protocol. This includes (non-exhaustively):

• End-users of Matrix clients.
• Matrix client developers and testers.
• Spec developers.
• Server admins.
• Matrix packagers & maintainers.
• Companies building products or services on Matrix.
• Bridge developers.
• Bot developers.
• Widget developers.
• Server developers.
• Matrix room and community moderators.
• End-users who are using Matrix indirectly via bridges.
• External systems which are bridged into Matrix.
• Anyone using Matrix for data communications.

"Greater benefit" is defined as maximising:

• the number of Matrix-native end-users reachable on the open Matrix network.
• the number of regular users on the Matrix network (e.g. 30-day retained federated users).
• the number of online servers in the open federation.
• the number of developers building on Matrix.
• the number of independent implementations which use Matrix.
• the number of bridged end-users reachable on the open Matrix network.
• the signal-to-noise ratio of the content on the open Matrix network (i.e. minimising spam).
• the ability for users to discover content on their terms (empowering them to select what to see and what not to see).
• the quality and utility of the Matrix spec (as defined by ease and ability with which a developer can implement spec-compliant clients, servers, bots, bridges, and other integrations without needing to refer to any other external material).

N.B. that we consider success to be the growth of the open federated network rather than closed deployments. For example, if WhatsApp adopted Matrix it wouldn’t be a complete win unless they openly federated with the rest of the Matrix network.

Values

As Matrix evolves, it's critical that the Spec Core Team and Guardians are aligned on the overall philosophy of the project, particularly in more subjective areas. The values we follow are:

• Supporting the whole long-term ecosystem rather than individual stakeholder gain.
• Openness rather than proprietary lock-in.
• Interoperability rather than fragmentation.
• Cross-platform rather than platform-specific.
• Collaboration rather than competition.
• Accessibility rather than elitism.
• Transparency rather than stealth.
• Empathy rather than contrariness.
• Pragmatism rather than perfection.
• Proof rather than conjecture.

Patent encumbered IP is strictly prohibited from being added to the standard.

Making the specification rely on non-standard/unspecified behaviour of other systems or actors (such as SaaS services, even open-sourced, not governed by a standard protocol) shall not be accepted, either.

The Spec Core Team

The contents and direction of the Matrix Spec is governed by the Spec Core Team; a set of experts from across the whole Matrix community, representing all aspects of the Matrix ecosystem. The Spec Core Team acts as a subcommittee of the Foundation.

Members of the Spec Core Team pledge to act as a neutral custodian for Matrix on behalf of the whole ecosystem and uphold the Guiding Principles of the project as outlined above. In particular, they agree to drive the adoption of Matrix as a single global federation, an open standard unencumbered from any proprietary IP or software patents, minimising fragmentation (whilst encouraging experimentation), evolving rapidly, and prioritising the long-term success and growth of the overall network over individual commercial concerns.

Spec Core Team members need to have significant proven domain experience/skill and have had clear dedication and commitment to the project and community for >6 months. (In future, once we have subteams a la Rust, folks need to have proven themselves there first).

Members need to demonstrate ability to work constructively with the rest of the team; we want participation in the Spec Core Team to be an efficient, pleasant and productive place, even in the face of inevitable disagreement. We do not want a toxic culture of bullying or competitive infighting. Folks need to be able to compromise; we are not building a culture of folks pushing their personal agendas at the expense of the overall project.

The team should be particularly vigilant against 'trojan horse' additions to the spec - features which only benefit particular players, or are designed to somehow cripple or fragment the open protocol and ecosystem in favour of competitive advantage. Commercial players are of course free to build proprietary implementations, or use custom event types, or even custom API extensions (e.g. more efficient network transports) - but implementations must fall back to interoperating correctly with the rest of the ecosystem.

Spec Core Team logistics

The Spec Core Team itself will be made up of roughly 8 members + 1 project lead. Roughly half the members are expected to be from the historical core team (similar to Rust). The team must have 5 members to be able to function, with the aim of generally having between 7 and 9 members.

In future we may also have sub-teams (like Rust - e.g. CS/AS/Push API; SS API; IS API; Crypto), but as a starting point we are beginning with a single core team in the interests of not over-engineering it and scaling up elastically.

Spec Core Team members need to be able to commit to at least 1 hour a week of availability to work on the spec and (where relevant) reference implementations. Members must arrange their own funding for their time.

Responsibilities include:

• Reviewing Matrix Spec Change proposals and Spec PRs.

• Contributing to and reviewing reference implementations of Matrix Spec Change proposals.

• Shepherding Matrix Spec Changes on behalf of authors where needed.

• Triaging Matrix Spec issues.

• Coordinating reference implementations.

• Ensuring the code of conduct for +matrix:matrix.org community rooms is maintained and applied.

If members are absent (uncontactable) for more than 8 weeks without prior agreement, they will be assumed to have left the project.

Spec Core Team members can resign whenever they want, but must notify the rest of the team and the Guardians on doing so.

New additions to the team must be approved by all current members of the team. Membership has to be formally proposed by someone already on the Spec Core Team.

Members can be removed from the team if 75% of the current members approves and agrees they are no longer following the goals and guiding principles of the project. (The 75% is measured of the whole team, including the member in question).

Guardians act as a safety net, and can appoint or remove Spec Core Team members (requiring approval by 75% of the current Guardians) if the Spec Core Team is unable to function or is failing to align with the Foundation's mission.

It's suggested that one of the Spec Core Team members should also be a Guardian, to facilitate information exchange between the Guardians and the Spec Core Team, and to represent the technical angle of the project to the other Guardians.

The project lead role acts to coordinate the team and to help steer the team to consensus in the event of failing to get agreement on a Matrix Spec Change. Every 12 months, a vote of confidence is held in the project lead, requiring the approval of 75% of the current Spec Core Team members for the lead to be renewed. There is no maximum term for the project lead. The lead may be removed by the core team at any point (requiring 75% approval of current members), and may resign the role at any point (notifying the team and the Guardians). The lead automatically resigns the role if they resign from the Spec Core Team. Resignation automatically triggers selection of a new lead, who must be selected from the existing Spec Core Team with 75% approval from current members within 14 days.

It is vital that the core spec team has strong domain expertise covering all different domains of the spec (e.g. we don't want to end up with a core spec team where nobody has strong experience in cryptography)

The initial Spec Core Team (and their domain areas) is:

• Matthew Hodgson (Lead, Guardian)
• Erik Johnston (Servers)
• Richard van der Hoff (Servers, Cryptography)
• David Baker (Clients, IS API, Push API, Media)
• Hubert Chathi (Cryptography, General)
• Andrew Morgan (Servers, AS API, Spec Process)
• Travis Ralston (Bots and Bridges & AS API, Media, acting with Dimension hat on)
• Alexey Rusakov (Clients on behalf of Community)
• TBD

MSCs require approval by 75% of the current members of the Spec Core Team to proceed to Final Comment Period (see https://matrix.org/docs/spec/proposals for the rest of the MSC process).

Even though a threshold of only 75% is required for approval, the Spec Core Team is expected to seek consensus on MSCs.

The above governance process for the Spec Core Team is considered as part of the spec and is updated using the Matrix Spec Change process. However, changes to the governance process also require approval by 75% of the current Guardians (acting as a formal decision of the Foundation's Directors), in order to ensure changes are aligned with the Foundation's mission. For avoidance of doubt, Spec Core Team votes and Guardians' votes are distinct and a person having both hats has to vote independently on both forums with the respective hat on.

Spec Core Team decisions (e.g. appointing/removing members and lead) should be published openly and transparently for the public.

The Guardians

This section will be used as the basis for the legal responsibilities of Directors in the Articles of Association of the Foundation.

The Guardians form the legal Board of Directors of The Matrix.org Foundation CIC (Community Interest Company). They are responsible for ensuring the Foundation is following its guiding principles, and provide a safety mechanism if the structure of the Spec Core Team runs into trouble.

In practice, this means that:

• Guardians are responsible for ensuring the Spec Core Team continues to function, and have the power to appoint/dismiss members of the spec core team (with the agreement of 75% of the Guardians) to address issues with the Spec Core Team.
• Guardians must keep each other honest, providing a ‘checks and balances’. mechanism between each other to ensure that all Guardians and the Spec Core Team act in the best interests of the protocol and ecosystem.
• Guardians may dismiss members of the Spec Core Team who are in serious breach of the guiding principles.
• Guardians may appoint members of the Spec Core Team to break deadlocks in the unanimous consent requirement for the Spec Core Team when appointing new members.
• Guardians may also override deadlocks when appointing a Spec Core Team leader (with approval of 75% of the current Guardians).
• Guardians must approve changes to the above Guiding Principles (with approval of 75% of the current Guardians)
• Guardians are responsible for approving use of the Foundation's assets (e.g. redistributing donations).
• In future, Guardians may also be responsible for ensuring staff are hired by the Foundation to support administrative functions and other roles required to facilitate the Foundation's mission.
• As well as the Spec Core Team committee, they may also oversee committees for other areas such as marketing Matrix.org, registering custom event types, or "Made for Matrix" certification.
• Guardians are responsible for choosing if, when and how staff are located by the Foundation to fill administrative and other functions required to facilitate the Foundations' mission.
• Guardians are responsible for choosing if and when additional committees are formed, and to oversee those committees.
• Guardians are not required to be involved on a day-to-day basis, however those not taking a hands on approach are required to monitor to ensure a suitable balance is kept by those that do.

Guardians are chosen typically to be independent of the commercial Matrix ecosystem (and especially independent from New Vector), and may even not be members of today’s Matrix community. However, they should be deeply aligned with the mission of the project, and respected and trusted by the wider community to uphold the guiding principles of the Foundation and keep the other Guardians honest.

Guardians are responsible for maintaining and updating the Guiding Principles and Articles of Association of the Foundation if/when necessary. Changes to the Guiding Principles require approval from 75% of the current Guardians and are passed as a 'special resolution' of the board.

New Guardians may be appointed with approval from 75% of the current Guardians.

Guardians may resign at any time, with notification to the board.

Guardians may be removed due to serious breach of the guiding principles with approval by 75% of the other current Guardians, or if absent from 3 consecutive board meetings, or if they are legally disqualified from acting as a Director.

We aim to recruit roughly 5 Guardians. The initial Guardians are:

• Matthew Hodgson (CEO/CTO, New Vector)
• Amandine Le Pape (COO, New Vector)
• TBA (agreed, needs paperwork)
• TBD
• TBD

The intention is for Matthew & Amandine (the original founders of Matrix) to form a minority of the Guardians, in order to ensure the neutrality of the Foundation relative to Matthew & Amandine’s day jobs at New Vector.

Guardians must arrange their own funding for their time.

Guardian decisions (e.g. appointing/removing guardians; changes to the spec core team; etc) should be published openly and transparently for the public.

The Code Core Team (aka The Core Team)

The "Core Team" (or the "Code Core Team", to disambiguate from the Spec Core Team) is a loose term that describes the set of people with access to commit code to the public https://github.com/matrix-org repositories, who are either working on matrix.org's reference implementations or the spec itself. Commit access is decided by those responsible for the projects in question, much like any other open source project. Anyone is eligible for commit access if they have proved themselves a valuable long-term contributor, uphold the guiding principles and mission of the project and have proved themselves able to collaborate constructively with the existing core team. Active participation in the core team is also signified by membership of the +matrix:matrix.org Matrix community.

Responsibilities include:

• Helping ensure the quality of the projects' code repositories.
• Ensuring all commits are reviewed.
• Ensuring that all projects follow the Matrix spec.
• Helping architect the implementations.
• Contributing code to the implementations.
• Fostering contributions and engaging with contributors constructively in a way that fosters a healthy and happy community.
• Following the Guiding Principles and promoting them within the community.

Code Core Team members must arrange their own funding for their time.

Functions of the Foundation

• Independent legal entity which acts as neutral custodian of Matrix.
• Gathers donations.
• Owns the core Matrix IP in an asset lock, which shall be transferred from New Vector:
  • Owns the matrix.org domain and branding.
  • Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org). By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it.
  • Owns the IP of the website.
  • Owns the Matrix.org marketing swag (t-shirts, stickers, exhibition stands etc).
• Responsible for finding someone to run the Matrix.org homeserver (currently New Vector).
• Publishes the spec.
• Responsible for tools and documentation that support the spec.
• Responsible for ensuring reference implementations and test suite exists for the spec.
• Publishes the website (including ensuring This Week In Matrix and similar exist to promote independent projects).
• Manages any future IANA-style allocations for Matrix, such as:
  • mx:// URI scheme.
  • TCP port 8448.
  • .well-known URIs
• Ensures that Matrix promotion is happening (e.g. ensuring that meetups & events & community activity is supported).

In future:

• Contracts entities to work on Matrix if such contracts help the Foundation to fulfil its mission and obey the Guiding Principles (e.g. redistributing donations back to fund development of reference implementations or compliance kits).
• Manages a "Made for Matrix" certification process? (to confirm that products are actually compatible with Matrix).

Timings

The Foundation was incorporated in October 2018 as a UK limited by guarantee private company, using generic non-profit articles of association combined with a high-level mission lock aligned with the above:

4. The objects of the Foundation are for the benefit of the community as a whole to:

4.1.1 empower users to control their communication data and have freedom over their communications infrastructure by creating, maintaining and promoting Matrix as an openly standardised secure decentralised communication protocol and network, open to all, and available to the public for no charge;

4.1.2 build and develop an appropriate governance model for Matrix through the Foundation, in order to drive the adoption of Matrix as a single global federation, an open standard unencumbered from any proprietary intellectual property and/or software patents, minimising fragmentation (whilst encouraging experimentation), maximising speed of development, and prioritising the long- term success and growth of the overall network over the commercial concerns of an individual person or persons.

The foundation was then converted into a Community Interest Company, formalising its non-profit status under the approval of the independent Community Interest Companies Regulator, which took effect Jan 2019.

We are currently planning to release r0 of the Matrix Spec at the end of Jan 2019, and finalise the Foundation's articles of association shortly afterwards based on the contents of this MSC once passed FCP.

This will coincide with the formal asset transfer of Matrix.org's assets from New Vector Ltd, and the appointment of the remaining Guardians.