matrix
/
matrix.org
mirror of https://github.com/matrix-org/matrix.org.git
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
matrix.org/content/foundation/about/index.md

11 KiB
Raw Permalink Blame History

+++ 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
  • The official articles of association of the Foundation may be downloaded here
  • 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 here 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 Spec Core Team, and 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:

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() }}