THE MATRIX.ORG FOUNDATION C.I.C.

Rules

Adopted with effect from May 15th 2019

Company limited by guarantee
Registered in England Number: 11648710

1

INDEX

No.

Clause

Page
no.

1

Introduction

3

2

Guiding Principles – Manifesto, Objects and Values

33

How the Foundation is managed – Guardians and Teams

54

Functions of the Foundation

11

7

Transitional arrangements

122

1. PREAMBLE
1.1. The Matrix.org Foundation C.I.C. (the “Foundation”) is a company limited by guarantee andregistered as a community interest company with the C.I.C. Regulator in England and Wales.
1.2. Matrix was originally created in 2014 and since 2017 has been developed and incubatedwithin New Vector (company number 10873661). To safeguard the neutrality of Matrix.org
and allow for further independent development, Matrix.org has been spun out into theFoundation, with assets necessary for the project transferred to the Foundation.
1.3. As a limited company, the Foundation’s governing document is its Articles of Association(“Articles”), a legal document which sets out what the Foundation, as a C.I.C. and acompany, can do in pursuit of the Objects for which it was established (Article 7.1), namely
to:“​empower users to control their communication data and have freedom over theircommunications infrastructure by creating, maintaining and promoting Matrix as an openly
standardised secure decentralised communication protocol and network, open to all, andavailable to the public for no charge; andbuild and develop an appropriate governance model for Matrix through the Foundation, inorder to drive the adoption of Matrix as a single global federation, an open standard
unencumbered from any proprietary intellectual property and/or software patents, minimisingfragmentation (whilst encouraging experimentation), maximising speed of development, andprioritising the long-term success and growth of the overall network over the commercial
concerns of an individual person or persons​.”
1.4. The Objects, and any other change to the Articles, may only be amended with approval of atleast 75% of the Foundation’s members, who for the purposes of company law are also theFoundation’s Guardians (explained further below).
1.5. These Rules govern the day-to-day operations of the Foundation in more detail than can be
dealt with in the Articles.
1.6. In the event of a conflict between these Rules and the Articles, the Articles shall prevail.

3

2. GUIDING PRINCIPLES – MANIFESTO, OBJECTS AND VALUES
2.1. Matrix Manifesto
2.1.1. The guiding principles that define the core philosophy of the Matrix.org project are as

follows:●

People should have full control over their communications.

●

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.

2.1.2. These principles are enshrined in the Foundation’s Objects at Article 7.

2.2. Mission
2.2.1. The Foundation exists to act as a neutral custodian for Matrix and to nurture it asefficiently as possible as a single unfragmented standard, for the greater benefit of thewhole ecosystem, not benefiting or privileging any single player or subset of players.
2.2.2. 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 communications4

2.2.3. "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 selectwhat to see and what not to see)●the quality and utility of the Matrix spec (as defined by ease and ability with which adeveloper can implement spec-compliant clients, servers, bots, bridges, and otherintegrations without needing to refer to any other external material)

2.2.4. Success for the Foundation shall be the growth of the open federated network rather

than closed deployments.
2.3. Values
2.3.1. The Foundation’s values are as follows:●

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

2.3.2. For these reasons patent encumbered IP is strictly prohibited from being added to thestandard, as is making the specification rely on non-standard/unspecified behaviour ofother systems or actors (such as SaaS services, even open-sourced, not governed by5

a standard protocol).

3. HOW THE SOCIETY IS MANAGED – THE GUARDIANS AND TEAMS
3.1. The Guardians
3.1.1. The Guardians are the legal directors of the non-profit Foundation for the purposes ofcompany law. Acting collectively the Guardians are the Foundation’s board of
directors (the “Board”).
3.1.2. The Guardians are responsible for the management of the Foundation’s business, set

the strategic direction of the Foundation, and monitor performance against theFoundation’s objectives and its strategy. This includes ensuring that the Foundation(and by extension the Spec Core Team) keeps on mission and neutrally protects thedevelopment of Matrix.
3.1.3. Furthermore, the Guardians are responsible for maintaining and updating the Guiding

Principles (as set out above). Any amendment to the Guiding Principles shall requirea Special Resolution of the Board.
3.1.4. The Guardians shall consist of not less than two and not more than twelve Guardians(Article 16). The Foundation was incorporated with two founder Guardians, Matthew
Hodgson and Amandine Le Pape. The Founder Guardians shall be joined byadditional Guardians (with the Founder Guardians forming a minority of the Board) toensure there is continuity, but also neutrality, between the Foundation and New
Vector Ltd.
3.1.5. Guardians are typically independent of the commercial Matrix ecosystem and may noteven be members of today’s Matrix community, but are deeply aligned with themission of the project and Guiding Principles.
3.1.6. The Guardians are self-appointing (Article 17.1) meaning that the Guardians currently

in post may appoint any individuals eligible to hold the role, either to fill a vacancy orto act as an additional Guardian. However, any Guardian appointed must be
respected and trusted by the wider Matrix community to uphold the Guiding Principles
and keep the other Guardians honest.
3.1.7. The Guardians are required to act with integrity and transparency. All Guardiandecisions (including all Board resolutions) should be openly published and available
to the public.

6

3.2. Delegation by the Guardians
3.2.1. The Guardians, in exercising the powers the Foundation, also have the ability todelegate responsibility for such functions and activities as they see fit (Article 21). It ison this basis that the Guardians have decided to create the following teams:●

The Spec Core Team - with day to day responsibility for curating and editing theMatrix specification; and●The Code Core Team – those individuals within the Matrix community with access tocommit code to the public Matrix.org repositories (e.g. https://github.com/matrix-org).

3.2.2. The Spec Core Team and the Code Core Team shall at all times conduct their affairs inaccordance with the Articles (in particular Article 21), the Guiding Principles and anyother conditions as the Guardians may decide from time to time.
3.3. Summary of Guardian responsibilities
3.3.1. The Guardians must keep each other honest, providing a ‘checks and balances’mechanism between each other to ensure that all Guardians and the Spec CoreTeam act in the best interests of the protocol and ecosystem.
3.3.2. The Guardians may dismiss members of the Spec Core Team who are in serious

breach of the Guiding Principles.
3.3.3. The Guardians are responsible for approving use of the Foundation's assets (e.g.

redistributing donations).
3.3.4. The Guardians shall also be responsible for hiring staff to support the administrative

functions and other roles required to facilitate the Foundation's mission.
3.3.5. As well as the Spec Core Team committee, they may also oversee committees forother areas such as marketing Matrix.org, registering custom event types, or "Madefor Matrix" certification.
3.3.6. The Guardians are responsible for choosing if, when and how staff are appointed by

the Foundation to fill administrative and other functions required to facilitate theFoundation’s mission.
3.3.7. The Guardians are responsible for choosing if and when additional committees areformed, and to oversee those committees.

73.3.8. Not all Guardians are 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 balanceis kept by those that do.
3.4. The Spec Core Team – general remit
3.4.1. The contents and direction of the Matrix specification is governed by the Spec Core

Team. The team shall steer the evolution of the protocol by having final review overwhich Matrix Spec Changes (MSCs) are merged into the core specification.
3.4.2. The Spec Core Team shall comprise of 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, operating under a delegated remit from theGuardians.
3.4.3. Members of the Spec Core Team pledge to act as a neutral custodian for Matrix onbehalf 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 overindividual commercial concerns.
3.4.4. Spec Core Team members need to have significant proven domain experience/skill andhave had clear dedication and commitment to the project and community for >6 months.
3.4.5. Members need to demonstrate ability to work constructively with the rest of the team,creating an efficient, pleasant and productive team even in the face of inevitabledisagreement. Personal agendas shall not be pursued at the expense of the overall
project.
3.4.6. The Spec Core Team should be particularly vigilant against 'trojan horse' additions tothe 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 shall be free to build proprietary implementations or use
custom event types or API extensions but implementations must fall back tointeroperating correctly with the rest of the ecosystem.
3.4.7. Responsibilities include:●

Reviewing MSC proposals and Spec PRs.

●

Contributing to and reviewing reference implementations of MSC proposals.

●

Shepherding MSC on behalf of authors where needed.

8●

Triaging Matrix Spec issues.

●

Coordinating reference implementations.

3.4.8. MSCs require approval by 75% of the current members of the Spec Core Team toproceed to Final Comment Period as per the proposal process documented athttps://matrix.org/docs/spec/proposals​. Nonetheless, the Spec Core Team shall be
expected to seek consensus on any proposed MSCs.
3.4.9. If any MSC shall impact of the wider governance of the Foundation or its Articles, such achange shall require the approval of the Guardians.
3.4.10. The Spec Core Team decisions (including appointing/removing members and the

Project Lead) should be published openly and transparently for the public.
3.5. The Spec Core Team - logistics
3.5.1. The Spec Core Team shall have a minimum of five members, but shall ideally have

between seven and nine members. One of the members shall take the role of Project
Lead and one of the members should also be a Guardian in accordance with thedelegation requirements as set out in the Articles. The Guardian member may or may
not also be the Project Lead.
3.5.2. The Spec Core Team shall have the ability to delegate certain aspects of their work in

the creation of sub-committees.
3.5.3. Spec Core Team members must commit at least 1 hour a week of availability to work on

the specification and (where relevant) reference implementations. Members mustarrange their own funding for their time.
3.6. Appointment and removal
3.6.1. New additions to the Spec Core Team must be approved by all current members of theteam; membership must be formally proposed by someone already on the Spec Core
Team. Members shall ensure the Spec Core Team has strong domain expertisecovering all different domains of the Matrix specification.
3.6.2. If members are absent (uncontactable) for more than 8 weeks without prior agreementfrom the remainder of the Spec Core Team, they will be assumed to have left the project
and therefore to have resigned from the Spec Core Team.
3.6.3. Spec Core Team members can resign at any time but must notify the rest of the teamand the Guardians on doing so.

9

3.6.4. Members can be removed from the Spec Core Team if 75% of the current members of

the Spec Core Team approve and agree that the member in question is no longer
following the goals and Guiding Principles of the project. For the avoidance of doubt,
the 75% vote shall be based on the whole team, including the member in question.
3.6.5. The Guardians shall also act as a safety net and can appoint or remove Spec CoreTeam members (requiring approval by 75% of the current Guardians) if the Spec CoreTeam is unable to function in instances of deadlock amongst the Spec Core Team
members, or is failing to align with the Foundation's objects including a serious breachof the Guiding Principles.
3.6.6. The Project Lead shall coordinate the Spec Core Team and to help steer the team toconsensus in the event of failing to get agreement on a MSC proposal. Every 12 months
a vote of confidence shall be held in the Project Lead, requiring the approval of 75% of
the current Spec Core Team members for the Project Lead to be renewed. There is no
maximum term for the Project Lead.
3.6.7. The Project Lead may be removed by the Spec Core Team at any point (requiring 75%

approval of current members), and may resign the role at any point (notifying the teamand the Guardians). The Project Lead automatically resigns the role if they resign fromthe Spec Core Team. Resignation shall automatically trigger the selection of a new
Project Lead, who must be selected from the existing Spec Core Team with 75%
approval from current members within 14 days.
3.6.8. The initial Spec Core Team (and their domain areas) is:●

Matthew Hodgson (Project 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)●

Alexey Rusakov (Clients on behalf of Community)

3.7. The Code Core Team – general remit
3.7.1. The Code Core Team shall be a group of individuals with access to commit code to the

public (​https://github.com/matrix-org​) repositories, and either working on theFoundation’s reference implementations or the specification itself.

10

3.7.2. Membership of the Code Core Team is decided by the Spec Core Team, requiring theapproval of 75% of the current Spec Core Team members. The Spec Core Team is
automatically part of this committee.
3.7.3. Commit access is decided by those responsible for the projects in question. Anyone

shall be eligible for commit access if they have proved themselves a valuable long-term
contributor, uphold the Guiding Principles and Objects of the Foundation, and have
proved themselves able to collaborate constructively with the existing Code Core Team.
Active participation in the Code Core Team is also signified by membership of the+matrix:matrix.org Matrix community.
3.7.4. 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.

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

3.8. Other groups not reporting directly to the Guardians
3.8.1. The Guardians may set up or disband such other groups as it sees fit, including but notlimited to advisory groups and sub-committees. Such groups shall not be designated ascommittees, nor shall their leads attend Board meetings, unless invited by the
Guardians as observers.
3.8.2. Teams may set up or disband sub-committees or working groups as needed, whether

permanent or time-limited, but these shall not be designated as committees, nor shalltheir leads attend Board meetings, unless invited by the Guardians as observers. The
setting-up of any such group shall be reported to the Guardians at its next meeting, withdetails of provisional terms of reference and chair, for approval by the Guardians.
3.8.3. Members of any such sub-committees or working groups must arrange their own

funding for their time.

11

3.8.4. All such groups shall conduct their activities in accordance with the Articles and anyother terms as may be set by the Guardians from time to time.

4. FUNCTIONS OF THE FOUNDATION
4.1. The powers and functions of the Foundation are described in Article 8. In particular, it isenvisaged that the Foundation will undertake the following activities:●

Gather donations●

Own and take responsibility for the Matrix.org domain, branding and marketing●

Sub-contracting the hosting and maintenance of the Matrix.org home server●

Arranging the publication of the specification, with responsibility for the tools anddocumentation that support the spec.

●

Ensuring reference implementations and test suites exist for the spec.

●

Publishing the website (including ensuring “This Week In Matrix” or similar titles topromote independent projects).

●●

Managing any future IANA-style allocations for Matrix, such as:omx:// URI scheme.

o

TCP port 8448.

o.well-known URIs

Ensuring that Matrix promotion is happening (including ensuring that meetups, events andother such community activity is supported).

4.2. In future the Foundation shall:●Contract entities to work on Matrix if such contracts help the Foundation to fulfil its
Objects and obey the Guiding Principles●

Manage a "Made for Matrix" certification process to confirm the compatibility of productswith Matrix.

5. TRANSITIONAL ARRANGEMENTS
The Foundation recognises that there may be a need to vary these Rules in order to facilitate
the smooth running of the Foundation. These Rules may be varied by a Special Resolution of
the Guardians.

12