The Matrix.org Foundation

Introduction

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.

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:

Prof. Jon Crowcroft

Prof. Jon Crowcroft

Jon Crowcroft is the Marconi Professor of Communications Systems in the Computer Lab at the University of Cambridge, and the Turing Institute. Jon is a pioneer in the field of decentralised communication, and a fellow of the Royal Society, the ACM, the British Computer Society, the Institution of Engineering and Technology, the Royal Academy of Engineering and the Institute of Electrical and Electronics Engineers. (He also supervised Matthew on building a pre-Matrix instant messaging system at Cambridge, and complained that it wasn’t decentralised enough!)

Matthew Hodgson

Matthew Hodgson

Matthew is technical co-founder of Matrix, and CEO/CTO of New Vector - the company formed in 2017 to let the core Matrix dev team work on Matrix full-time as their day job. He came up with the idea of Matrix with Amandine in 2013 while they were running Amdocs’ Unified Communication unit. He has a degree in Physics & Computer Science from the University of Cambridge.

Amandine Le Pape

Amandine Le Pape

Amandine is co-founder of Matrix, and COO of New Vector. She previously ran the business side of Amdocs’ UC unit with Matthew. She has an engineering degree in Telecoms, Electronics and Computer Science and uses it most to translate the technicalities of Matrix to humans and businesses, and make sure we keep the users at heart when making decisions!

Ross Schulman

Ross Schulman

Ross Schulman is a senior counsel and senior policy technologist at New America’s Open Technology Institute, where he focuses on internet measurement, emerging technologies, surveillance, and decentralization. Prior to joining OTI, Ross worked for Google. Ross brings a unique perspective as a tech- and decentralisation-savvy lawyer to the Foundation, as well as being one of the first non-developers in the Matrix community to run his own homeserver. Ross has been known to walk around Mozfest clutching a battery-powered Synapse in a box, promoting decentralised communication for all.

Dr. Jutta Steiner

Dr. Jutta Steiner

As co-founder and CEO of Parity Technologies, Dr. Jutta Steiner is dedicated to building a better internet - Web 3.0 - where users’ privacy & control come first. Parity Technologies is a leader in the blockchain space – known to many as the creator of one of the most popular Ethereum clients, it is also the creator of two ambitious new blockchain technlogies, Polkadot and Substrate, that make it easier to experiment and innovate on scalability, encryption and governance.

Parity Technologies have been pioneering Matrix enterprise use since the moment they decided to rely on Matrix for their internal and external communication back in 2016 and now run their own high-volume deployment, with end-to-end encryption enabled by default. Jutta represents organisations who are professionally dependent on Matrix day-to-day, as well as bringing her unique experiences around decentralisation and ensuring that Web 3.0 will be a fair web for all.

Legal details

  • The Matrix.org Foundation C.I.C is registered in the UK as Company #11648710.
  • The official articles of association of the Foundation may be downloaded here.
    • (As of June 7th 2019, Companies House has not yet published the current articles, but they should also be visible here in the near future).
  • The official Rules for the Foundation may be downloaded here.

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 proposal process in order to provide full transparency and review from the wider community. The result was MSC1779 - Proposal for Open Governance of Matrix.org , 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 (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:

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 below from MSC1779 for ease of reference.

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.

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