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.](https://beta.companieshouse.gov.uk/company/11648710) - 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](https://github.com/matrix-org/matrix-doc/issues/1318).

**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](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md);
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](https://www.gov.uk/government/organisations/office-of-the-regulator-of-community-interest-companies),
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.