matrix.org/content/foundation/about/index.md

+++
title = "About Matrix"
aliases = ["/foundation/", "/about/"]
extra.meta_description = """
The Matrix.org Foundation is overseen by its Guardians. The Spec Core Team works
on maintaining the Matrix Specification in accordance with the Foundation rules
and manifesto.
"""
weight = 1
+++

Matrix is an open protocol for decentralised, secure communications.

## 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 Matrix.org Foundation team members
remain 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.

## Governance

The evolution of Matrix is managed through an open governance process, looked
after by The Matrix.org Foundation - a non-profit UK Community Interest Company,
incorporated to act as the neutral guardian of the standard on behalf of the
whole Matrix community.

The Foundation defines the manifesto, mission and values of the project, the
open governance process that determines how the specification develops, and
provides a safety-net to ensure the project stays independent and true to its
goals. The constitution of the project is defined in the Foundation's legal
Articles of Association and Rules, and is enforced by the Guardians of Matrix:
the directors of the Foundation appointed to provide a balance of independent
experts and the founding Matrix team to ensure the project stays on track.

### Legal Details

* The Matrix.org Foundation C.I.C is registered in the UK as Company
  [#11648710](https://beta.companieshouse.gov.uk/company/11648710)
* The official articles of association of the Foundation may be
  downloaded [here](/media/2019-06-10%20-%20Matrix.org%20Foundation%20CIC%20Articles%20of%20Association.pdf)
* The official Rules for the Foundation may be downloaded [here](/media/2019-06-10%20-%20Matrix.org%20Foundation%20CIC%20Rules.pdf)

### The Rules of the Foundation

The Foundation is governed by two sets of documents - its Articles of
Association, which define its legal structure and processes, and its Rules,
which define the scope and mechanisms of its day-to-day activity.

The Rules were originally drafted through the open [Matrix Specification Change](https://spec.matrix.org/proposals/)
proposal process in order to provide full transparency and review from the
wider community. The result was [MSC1779](https://github.com/matrix-org/matrix-doc/pull/1779) -  [Proposal for Open Governance of Matrix.org](https://github.com/matrix-org/matrix-doc/tree/master/proposals/1779-open-governance.md),
providing a comprehensive overview of the whole governance process.

The Proposal for Open Governance was then formalised into legal form and
incorporated into the Articles of Association and a matching Rules document,
which is canonically versioned in [this Google Doc](https://docs.google.com/document/d/1MhqsuIUxPc7Vf_y8D250mKZlLeQS6E39DPY6Azpc2NY/edit)
(for ease of use by lawyers). This is the official canonical version of the
rulebook referred to by the Foundation's Articles.

The full history of the rules can be followed via:

* [https://matrix.org/blog/2018/06/20/towards-open-governance-for-matrix-org](https://matrix.org/blog/2018/06/20/towards-open-governance-for-matrix-org)
* [https://github.com/matrix-org/matrix-doc/issues/1318](https://github.com/matrix-org/matrix-doc/issues/1318) (v1 proposal)
* [https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2](https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2)
* [https://github.com/matrix-org/matrix-doc/pull/1779](https://github.com/matrix-org/matrix-doc/pull/1779)

One of the most important items defined in the Rules are The Guiding Principles
of the project and the definition of the Spec Core Team, which are [reproduced here](#the-spec-core-team) from MSC1779 for ease of reference.

## Who We Are

The ecosystem around Matrix is full of people who are enthusiastic about the
mission to bring secure, interoperable, decentralised communication to the world.
The Matrix.org Foundation, as the nonprofit that serves this ecosystem, is itself
made up of many hard working people across several key groups that you can learn
about on this page: [the staff of the Foundation](#the-staff-of-the-foundation),
[the Spec Core Team](#the-spec-core-team), and [the Guardians](#the-guardians).

### The Staff of the Foundation

We have a small but mighty team of staffers who are responsible for the day-to-day
operations of the Foundation. Because the organization doesn't yet have the capacity
to take on employees directly, all of us are working under contract. We look forward
to building the Foundation such that it can take on employees directly, in addition
to being self-sustaining and more fully independent.

In the interest of transparency, we think it's important for people to know that
most of our staffers are employees of Element, working under a contract with, and
funded by, the Foundation. The exception is our Managing Director who contracts
directly with the Foundation.

{{ staff() }}

### 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.

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

* [Matthew Hodgson](https://github.com/ara4n) (Lead, Guardian)
* [Erik Johnston](https://github.com/erikjohnston) (Servers)
* [Richard van der Hoff](https://github.com/richvdh) (Servers, Cryptography)
* [David Baker](https://github.com/dbkr) (Clients, IS API, Push API, Media)
* [Hubert Chathi](https://github.com/uhoreg) (Cryptography, General)
* [Andrew Morgan](https://github.com/anoadragon453) (Servers, AS API, Spec Process)
* [Travis Ralston](https://github.com/turt2live) (Bots and Bridges, AS API, Media)
* [Alexey Rusakov](https://github.com/KitsuneRal) (Clients)
* [Tulir Asokan](https://github.com/tulir) (Bots and Bridges, AS API)
* [Patrick Cloke](https://github.com/clokep) (Servers)

### The Guardians

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 alphabetical order:
{{ guardians() }}