Introducing premium accounts to fund the matrix.org homeserver

2025-06-13T14:00:00+00:00

🔗</a>TL;DR</h2>
As we need to take more concrete steps to improve the financial situation of the Foundation, we will be rolling out a freemium offer for the matrix.org homeserver users. The alternative is to turn off the server, which we want to avoid doing. The goal is for the most active users to support the cost of the service. Free users will have limits on how they can use the service (mostly around media). The change can be supported by any client with limited to no development. Premium plans will be rolled out over the summer, and we will be iterating on the exact scope in the first few weeks. The Homeserver Terms and Privacy Policy will be updated accordingly and deployed in the coming weeks. 
🔗</a>The full story</h2>
We have been communicating on the lack of funds in the Foundation for a while now, the latest being here</a>. And whilst we’ve been working hard to gather new members and are happy to see the number of logos increasing</a> (thank you all for seeing the need for Matrix to stay independent and safe, and the value in supporting it!), none of the big players in the ecosystem have actually committed to one of the higher membership tiers, so we need to find other ways towards sustainability.
The Foundation’s mission</a> can basically be summarised by 4 main goals:

Ensure the specification of the protocol stays canonical and unencumbered, to avoid fragmentation and being overridden by a single player.</li>
Ensure that all players in the ecosystem are at a level playing field, helping them succeed by giving them visibility and listening to their needs.</li>
Promote the Matrix standard, as the value of Matrix is directly proportional to the size of the public network and how much it is used and commercialised.</li>
Ensure the public network is safe by building moderation tools that can be used by the server admins, for the sake of our users and making sure the network is attractive.</li> </ol>
In practice, it means that we are currently spending money on:

A small team of developers and moderators, to develop Trust & Safety tooling, moderate the matrix.org server, and redirect people who do not understand the decentralised nature of Matrix reporting abuse to us towards the appropriate server admins.</li>
The infrastructure of the matrix.org homeserver, including the SRE team, who are on call to keep it running, and the support team.</li>
Organise and sponsor events to promote and evangelise the protocol.</li>
A tiny team to run the Foundation itself, including the support of external contractors for the administrative side (finance, legal, tax). The staff works on governance (organising the governing board elections, running the meetings, liaising between the different teams), raises money and brings members in, manages social media and liaises with the community, keeps the website up and up to date, publishes TWIMs and blogs, organises the events, etc. This team whose day job is to keep the Foundation running is also supported by a lot of volunteer (and sometimes sponsored by employer) time from the Governing Board and its Working Groups, the Spec Core team, the Guardians, and other external staff.</li> </ul>
We haven’t gotten to the point of publishing the public financial report (although it should be almost finalised now), because we are frantically trying to focus on closing the financial gap, but here is an overview of the split of expenditures in the last year:

As you can see, 20% of the Foundation’s expenditure goes towards hosting the matrix.org free and public homeserver. If we add in the cost of the moderation work done by the Trust and Safety team, the total share of the costs attributable to the matrix.org homeserver account for almost 50% of all expenditure. Meanwhile, today, only 50% of the spending of the Foundation is covered by its revenues (donations and memberships), and we are working hard towards reducing this gap.
We’ve kept the matrix.org homeserver around so far, despite its costs, as we consider it essential to seed the network in support of the nurturing part of the Foundation’s mission: despite Matrix being decentralised by design, users need a trusted place to create a free Matrix account to try it out in the first place.
However, we can’t continue to bear the cost of the server as is, and before we get to the extreme position of being forced to turn it off leaving its 370k monthly active users in the awkward position of finding a new home for their account, we’ve decided to try to alleviate some of these costs by setting-up a freemium offering and proposing premium plans in addition to the free ones. The goal is to get the server to an at least financially break-even position. If, by any chance, it was ending up profitable, the profit would directly be invested in Trust and Safety</a>, or other new programmes which can support the ecosystem. As a reminder, the Foundation is a Community Interest Company, i.e. a limited company which operates to provide a benefit to the community it serves rather than private profit.
🔗</a>What will the freemium offer look like?</h3>
The idea is to set some limits for users on the free plans, which would be lifted for users on the premium plans in exchange for an affordable membership.
We are still iterating (and will do for a while) on how it looks, but users can expect limits around media sizes and/or volumes. The goal is to ensure that the most active users participate in covering the costs of the service, in return for the access to a fully encrypted and decentralised open network.
We are limited in scope and design by the fact we need to ship a minimum viable product as soon as possible (we need to reduce costs now) and by not wanting to impose too much development (if any) to Matrix client developers.
Obviously we would have preferred to keep everything free of charge. We will never sell our users’ data or cripple our services with ads, so we need to find ethical sources of revenue.
🔗</a>When will the new plans take effect?</h3>
The roll-out will happen progressively, starting in the coming weeks and hopefully completing in the summer of 2025. We will start by opening up premium plans to new users only, before progressively migrating all existing accounts to a free plan which will give them the option to upgrade to a premium plan. Users will of course be notified ahead of their account being migrated.
🔗</a>Will this work with whatever Matrix client I use?</h3>
Yes. The plan management will be handled via the My Account</a> screens provided by the Matrix Authentication Service (MAS), and notifications to users will be sent in a dedicated room using the Server Notices</a> feature built into the Matrix protocol – already used by the homeserver to send automatic messages to the user – so should be seamless for every client.
🔗</a>I am a Matrix client developer, do I need to do anything?</h3>
There are two considerations from a Matrix client point of view:

support for the Server Notices</a> feature</li>
if the client is distributed via the Apple App Store, then support for MSC4286</a></li> </ul>
If the client doesn't show server notices at all then, whilst the client will remain usable with the matrix.org homeserver, your users will have a degraded UX as they won't receive notifications when encountering usage limits.
Apple places restrictions</a> on how payments are implemented by iOS (et al) apps that are distributed via the App Store.
We expect that most, if not all, apps that fall within scope would be classified as what Apple calls “Free Stand-alone Apps</a>”. Such apps do not need to use in-app purchases so long as “there is no purchasing inside the app, or calls to action for purchase outside of the app”.
In order to meet these requirements we have proposed MSC4286</a> which provides a way for a homeserver (such as the matrix.org homeserver) to flag parts of messages as containing a call to action and for affected clients to be able to hide that content. Example implementations are linked in the MSC.
🔗</a>I am already supporting the Foundation by paying an individual membership, will I have to pay for a premium plan too?</h3>
No, individual members</a> of the Foundation will get access to the premium features at no extra cost. This benefit will be implemented as part of the process of migrating existing accounts to the free plan.
🔗</a>What else will be changing?</h3>
In order to support these changes we will be releasing updates to the Homeserver Terms and the Privacy Policy in the coming weeks. Users of the matrix.org homeserver will be notified and will need to accept the new terms. The scope of change will be clearly highlighted in the release note, but essentially you can expect new terms around payment and additional information on the types of information we will collect about your account, as well as the processors we will use to enable payments.
We realise this is quite a big change, but our position is that a slightly limited service is better than no service at all, so we chose to ask for financial contribution rather than turn off the server. Paying a subscription for the matrix.org homeserver is basically a way to support Matrix, ensuring the Foundation can continue to play its role of neutral custodian, enabler and safeguardian of the protocol and the network. We will be publishing more details and a proper FAQ as the roll-out happens, so watch this space for more details.

Announcing the 2025 Governing Board elections

2025-04-28T00:00:00+00:00

🔗</a>Election schedule</h2>
Here is the timeline for this election season, which will happen in the second quarter of every year:

Announcement on Monday, April 28</li>
Nominations from Saturday, May 3 to Friday, May 16</li>
Campaigning from Saturday, May 17 to Friday, May 30</li>
Voting from Saturday, May 31 to Friday, June 13</li>
Results announced on Monday, June 16</li> </ul>
🔗</a>How our elections work</h2>
Our Governing Board is made up of 9 different constituency groups across 3 categories: nonprofit and community representatives, funder representatives, and foundation representatives. Each group has been allocated seats on the board, gets to nominate its own slate of candidates, and gets to vote within that slate of candidates.
For example, Individual Members get to nominate themselves, and vote on the Individual Members who are qualified candidates. The only exception is with the Managing Director (hi, that’s me) who automatically gets a seat on the Governing Board, but that’s just one seat of many.
Here is the composition of seats on the Governing Board:
Community representatives</th> Funder representatives</th> Foundation representatives</th></tr></thead>

4 Individual Members</td> 4 Platinum Members</td> 3 Guardians</td></tr>
3 Ecosystem Members</td> 3 Gold Members</td> 2 Spec Core Team Members</td></tr>
2 Associate Members</td> 2 Silver Members</td> Managing Director</td></tr> </tbody></table>
Learn how to become a member</a> and see a list of our current organizational members</a>.
We will be seating candidates for half of the constituency groups in 2025, namely: Gold, Silver, Individual, and Associate Members.

There are currently no term limits, but term limits are a best practice in open governance so we intend to introduce them as we find our collective footing.
🔗</a>Who can nominate</h2>
You must be a member of one of the constituency groups in order to nominate yourself or someone else to be a candidate in the election. By far our largest constituency group are Individual Members, who number in the 100’s. If you have donated at least $60 USD to the Foundation since April 20, 2024 on Donorbox</a>, then you are eligible to nominate and vote. You must donate before the election period begins, as we cannot change voter rolls after that.
All nominees must have consented to nomination before being nominated and must be a community member in good standing. That means they must have a clean track record with respect to our Code of Conduct</a>. We want our Governing Board to be a clearing house for a variety of priorities and perspectives, and to be able to hold space for each other even when there are disagreements.
🔗</a>Who can vote</h2>
All members of each constituency group are entitled to vote on the candidates within that constituency group. We will be reaching out to everyone we have contact information for, to ensure we have our voter rolls together before voting begins at the end of May.
We will hold an election in each of the four constituencies that are up for election this year, even if a given constituency has fewer candidates than there are seats allocated for them on the Governing Board. This is, effectively, a vote of confidence.
If you believe you are eligible to participate but have not heard from us or OpaVote</a> – the election system we have chosen for this year’s elections – by May 24th, please email us promptly</a>. We build our voter rolls on May 31st and can't change them after that!
All of the candidates will be listed on an elections page here on our website which we’ll publish on May 17th.
🔗</a>How to prepare yourself</h2>
If you want to be a candidate in the election, there are a few things you should know:

All candidates will be listed on our website, grouped by the constituency group. (See last year's election center here.</a>)</li>
We do not require people to use their “legal name.”</li>
Candidates who are nominated by an organizational member will have their affiliation listed.</li>
We expect candidates to provide a short bio and a short statement, collectively covering qualifications and priorities. Candidates may also provide a link to an extended statement or platform on their personal blog or website.</li>
You are encouraged to make yourself available for conversation with members of your constituency group.</li>
The period for campaigning runs from May 17th to May 30th. Please note our community Code of Conduct</a> while campaigning.</li> </ul>
🔗</a>What to expect if you win</h2>
Congratulations! All of the winners will be announced on June 16th, but since the elections conclude on June 13th, you may get an email with the results of the election you participated in before June 16th.
All elected representatives will be added to a private mailing list and Matrix room so that they can introduce themselves and communicate in between meetings. I will be reaching out to every elected representative to meet one-on-one, get acquainted, and answer questions before we convene for their first Governing Board meeting.
The Governing Board meets as a full board at least twice a year, for at least 90 minutes each time, and meetings are facilitated by the duly elected Chair or Vice Chair. Expect one meeting before the end of the year, and another before the next election.
You are likely to receive a packet of materials before each meeting which you will be expected to have reviewed. Most meetings will be held online, though we may convene meetings in-person, such as at The Matrix Conference. We will make every effort to make in-person meetings accessible to remote participants, and no official business will ever happen without appropriate notice, quorum, and minutes.
While the Governing Board is an advisory board, members are encouraged to play a role in helping to carry out the activities that support the staff in delivering on the Foundation’s collective remit, such as coalescing priorities to share with the Spec Core Team and connecting with contributors and funders to implement proposals.
Most of the work of the Governing Board happens in its Committees and their Working Groups, who meet in between Governing Board meetings and present their assessments and recommendations to the Governing Board.
🔗</a>How to nominate</h2>
We will update this blog post with a link to a nomination form and a template document on Friday, May 2nd. We’ll be reaching out to everyone who is eligible and whose contact information we have to let them know. We’ll also be announcing it on our social channels.
All nominations should be submitted through the form</a>, though anyone who has technical difficulties can fill out the template document</a> and email it to elections@foundation.matrix.org</a>.
For discussion related to the Governing Board and the elections, we encourage people to drop by the Office of the Governing Board (#governing-board-office:matrix.org)</a>.
Thank you for your ongoing support, and good luck to all the candidates in the upcoming elections!

Update on Native Matrix interoperability with WhatsApp

2024-09-16T00:00:00+00:00

Hi all,
Back at FOSDEM</a> in February we showed off how Matrix could be used for E2EE-preserving messaging interoperability as required by the Digital Markets Act messaging interoperability</a> - and we announced that Element had been working with Meta on integrating with its DMA APIs in order to connect WhatsApp to Matrix. You can see the video here</a>, and we also demoed interop working at the technical level to the European Commission a few days beforehand.
Subsequently WhatsApp launched</a> its DMA portal</a> on March 8th, and the proposed Reference Offer (i.e. the terms you have to accept as a Requesting Party in order to interoperate) was revealed. The Reference Offer for Facebook Messenger was launched on September 6th. At the time of the WhatsApp launch we flagged up some significant unresolved questions - the main points being that:

WhatsApp would require their users to manually enable DMA in settings before they can receive any traffic from interconnecting service providers (e.g. Element) - meaning that WhatsApp users would not be reachable by default. </li>

WhatsApp would require the client IP of any interconnecting users, in order to apply ‘platform integrity’ anti-abuse / trust & safety controls. </li>

WhatsApp would not allow an interconnecting service to buffer messages serverside. </li>

WhatsApp would require each Matrix server provider to sign a separate agreement in order to interconnect - i.e. you can’t bridge other server’s users unless those servers have signed a contract with Meta. </li> </ol> 
Now, the good news is that we’ve subsequently been talking with WhatsApp to see if we could progress these points - and we’re happy to say that they’ve listened to us and we’ve made progress on the first 3 items:

Meta recently shared an update</a> on the messaging interoperability user experience and will allow all EU users to be reachable by interoperable services by default. It’ll also give people the option of how they want to manage their inbox as well as a range of features like read receipts, typing indicators and reactions. </li>

We’ve come up with a plan with WhatsApp to reduce the amount of matrix user data we share with WhatsApp. WhatsApp’s interop solution however, doesn’t yet support multi-device conversations or shared conversation history like normal Matrix, which means that normal Matrix server-side synchronised history won’t work for these conversations. </li>

In terms of not allowing open federation: this looks unlikely to change, given Meta needs to know who is responsible for the servers who connect to them, and ensure they agree to the terms of use as required by DMA. </li> </ol>
During discussions, another point came up which we’d previously overlooked: section 7.5.1 of the current reference offer states: “Partner User Location. Any Partner Users that Partner Enlists or provides access to the Interoperable Messaging Services must be located and remain in the EEA”. In other words, interop would only be available to Matrix users physically in the EEA, which is obviously against the Matrix Foundation’s manifesto</a> to provide secure communication to everyone. Moreover, to demonstrate compliance the Matrix side would have to geolocate the client’s IP.
It turns out that this limitation to EU users ended up being the biggest obstacle for productising the native Matrix<>WhatsApp bridge, as it is unclear whether it’s financially viable for anyone (e.g. Element) to launch such a bridge if it only works for Matrix users physically within the EEA (not to mention the costs and privacy issues of geolocating Matrix users).
Now, on one hand, deploying Matrix as a mature standards-based protocol for WhatsApp interop with native E2EE feels like a worthy goal: indeed, it effectively gives DMA interoperators a stable standardised API with pre-existing SDKs to implement against, rather than having to implement against proprietary and potentially shifting vendor APIs. So overall it moves the needle towards the end goal of Matrix’ mission.
On the other hand, this all may be moot if the return on investment of building DMA interop with WhatsApp via Matrix is too far away for any company in the Matrix ecosystem to be able to afford the investment, and if there isn’t an appetite for anyone to fund it. Funding constraints</a> on both the Foundation and the ecosystem today are such that this work will only happen if explicitly sponsored by an organisation who is willing to commit to fund it.
So: if you are an organisation with users in the EU who would like them to interoperate with EU WhatsApp users via Matrix, and have the funds to sponsor development of building out an official production-grade Matrix<->WhatsApp bridge, please get in touch with me</a>.
Alternatively, if the geographic constraints are a showstopper for you, please let us know.
We’re assuming that there may be smaller messaging providers, or domain-specific messaging services who want to connect their end-users through to WA end-users, and may be happy to be constrained to EU geography. However, bridge developers need evidence and financial support to progress this. Meanwhile, if you are interested in the strategic importance of the Digital Markets Act, this is an opportunity to put your money where your mouth is.
Looking forward to hearing feedback!
thanks,
Matthew

Protecting the projects at the heart of the Matrix ecosystem

2024-08-15T19:00:00+00:00

There have been many changes at the Foundation in the last couple of years. We’ve added independent leadership, attracted members, continued working towards sustainability, and expanded our open governance to establish a Governing Board to become better and more capable stewards of the protocol and ecosystem. We’re still in a period of organisational transition, getting into the groove with the Governing Board, focusing on the Spec Core Team, and building the technical and financial foundation for independence.
We’ve also been asking ourselves what it means for a project to be “core” to the Foundation, and how the Foundation should relate to and work with the people who maintain those projects. These are fundamental questions for any open source foundation, and they’ve become even more pressing for us since Element switched developing Synapse and several other projects to AGPLv3, rather than contributing under the Foundation as Apache v2.
This blog post explores our context and sets out to start a discussion on how we should move forward. Already, we’ve been having these discussions in Foundation rooms and on the Governing Board, and we look forward to bringing more people into this discussion so that we can ship a framework that delivers on our mission and meets the needs of the Matrix ecosystem. 
🔗</a>Where we are and where we’re going</h2>
The Foundation’s primary responsibility is to the Matrix specification itself, but the ecosystem has a lot to gain when we provide a neutral home and stewardship for other relevant projects as well.
We currently host an array of projects</a> and even proactively fund maintenance and development on a small number of them. Most of those projects were created by the same set of people who first created Matrix, and the folks they trusted with commit access – providing a consistent set of expectations around trust, security, code quality, maintenance, advocacy, and support – almost all of whom still work on the projects today. This group is referred to as the “Core Team” – which is formally defined</a> as those who have direct commit privileges on any of our repositories. But the structure and expectations for this team are due for an update, and the mix of projects under our banner has grown sprawling and a bit chaotic.
The time has come for us to design a coherent, modern framework, with the benefit of hindsight and a Governing Board that can channel important perspectives from across the ecosystem. And once we’ve established that framework, then we can get to designing the processes by which projects join or leave the Foundation, and how decisions are made about resourcing.
If you’d like to get involved, we encourage you to jump into conversations in the Foundation’s rooms and make your voice heard through your representatives on the Governing Board</a>.
🔗</a>Answering the immediate questions</h2>
But three questions remain that we think are worth offering provisional answers to now: what will the Foundation do to protect projects at the heart of Matrix? How do we determine what those “core” projects are? And are there any projects that don’t belong at the Foundation?
The first question is easy to answer:
The Foundation will seek to fund and coordinate maintenance and development of core projects even if faced with a competing fork. We believe some projects, like the spec, test suites, SDKs, and shared cryptographic libraries, are so important that they require ongoing stewardship, under a permissive open source licence, by an organisation that is accountable to the ecosystem.
The Foundation may host a variety of other projects for the benefit of the ecosystem, and may also fund and coordinate maintenance and development of some of those projects where we see a meaningful gap in the ecosystem. This broader set of projects is more subject to change over time, and is less likely to receive direct investment from the Foundation.
But that second question – what is “core?” It’s not as easy to pin down exactly, and we look forward to formalising a definition and designation process in collaboration with the Governing Board, Spec Core Team, and Guardians.
A non-exhaustive list of projects we think are core includes:

The Spec, Spec Proposals, the matrix.org website and homeserver, and matrix.to link redirection service</li>
Integration test suites, to confirm that implementations conform to the spec:

sytest</li>
complement</li>
complement-crypto</li> </ul> </li>
SDKs and libraries which are used extensively by the wider community:

matrix-rust-sdk</li>
matrix-js-sdk</li>
vodozemac</li> </ul> </li> </ul>
As to the third question – are there any projects that don’t belong at the Foundation? Probably, yes. It’s debatable whether it makes sense to host experimental or speculative projects, and we don’t think it’s appropriate to host projects that don’t have anything to do with Matrix specifically.
🔗</a>Taking the next steps</h2>
We hope this helps answer some of the questions that folks have been raising, illuminates where we are on our journey in defining these things, and provides some assurance that the Matrix.org Foundation is ever evolving in partnership with the community and will draw a line to protect and maintain projects that are truly at the heart of Matrix.
Next, we’ll be deliberating on these things with the Governing Board, Spec Core Team, Guardians, and the broader ecosystem including you, the reader. We encourage you to reach out to your representatives on the Governing Board</a> along the way.
Ultimately, we’ll define a framework and begin aligning our operations with it – including defining a legal and governance framework and setting up the infrastructure to facilitate it.
As always, we can’t do this without your support. Some organisations have stepped forward to support our work, but we still don’t have enough to sustain our operations. The more people that come together to fund the Foundation’s work, the more capable we are of investing in core projects, operationalizing more open governance, and nurturing the broader ecosystem.
Please join the Foundation today</a>, especially if you depend on Matrix, to ensure the Matrix ecosystem is here for you today and tomorrow.
Thanks,
Josh Simmons and Matthew Hodgson

Policy and regulation update 2024: Matrix and the GDPR

2024-06-06T07:00:00+00:00

If you have been following the matrix.org blog for some time, you will know that we’ve never been ones to shy away from complex topics like public policy and its impacts on Matrix. With this blog post series, our aim is to introduce a more regular cadence to our regulatory updates and to be more transparent about where we are focusing our efforts in this area.
Each blog post in the series will focus on a given theme or piece of law, as well as its relevant jurisdiction. We will start this series by taking a deep dive into EU regulation, starting with the General Data Protection Regulation (GDPR). Future blog posts in the series will cover the digital services package (DMA and DSA), the incoming CRA and the highly controversial CSAM regulation. These will be followed by a series dedicated to the UK, particularly UK applications of European law such as the GDPR and ePrivacy directive, as well as the Online Safety Act and the IPA amendment bill. Finally, we will conclude the series by looking across the pond and diving into the Cloud Act, as well as KOSA and other existing proposals. 
🔗</a>The big one</h2>
Over the last decade the most impactful - in terms of grassroots led change, not necessarily enforcement - piece of legislation was probably the GDPR. Although its initial enforcement date (May 2018) was a couple of years before I joined Element and the Matrix.org Foundation, I know that preparing for GDPR was a huge effort that led to a lot of deep thinking about the ins and outs of Matrix.
These have been certainly years of learning, iterating and evolving our approach to this fascinating piece of law, and just like 6 years ago</a>, we keep receiving questions and feedback about how the GDPR applies to the Matrix protocol and how server administrators can remain compliant.
We maintain the view that the GDPR was not built for a decentralised digital world, after all we are (for now!) the exception, not the rule. This does not mean, however, that we don’t make every effort possible to comply with the spirit and the letter of the law. Most organisations using the Matrix protocol will be running strictly closed federations or single servers in closed federation, which they fully control (or appoint others to support them with that control). Compliance is a lot more straightforward in this sense, so for now we will focus on those using Matrix to interact with open federation.
The most difficult part of GDPR compliance for Matrix has always been article 17, right to erasure, or ‘right to be forgotten’ as it is usually known. Our view has always been that this is a relative right, which needs to take into account available technology and other applicable laws in order to be enacted. For example, if an employee leaves a company and asks for all of their data to be erased, in practice not all of that data will actually be erased, due to constraints put in place by other legal instruments (i.e. tax and fraud prevention regulations, employment law, etc.).
Considering this relativity, we looked at what other ubiquitous product offerings already exist in the decentralised space, and how they address erasure. Using email as an analogy was a no-brainer in this regard: one understands that deleting an email account will delete everything from their inbox and sent folders, whilst also understanding that is impossible and not expectable to have the same data deleted from the recipients’ inbox (or the inboxes of those that might have had the same message forwarded to them).
Use of technology is always associated with constant give and take and risk based decisions. Whilst we make every effort to minimise risks for the people using the Matrix protocol, the reality is that one of the main purposes of the protocol is integrity of communications and decentralisation of communications data. This is directly at odds with absolute deletion of communications.
So how do we come to terms with this conflict? Following the email analogy, we address right to erasure from two different standpoints: account data and communications data. As part of the protocol, everyone is able to automatically delete their accounts and select an option to delete all of their data. First, this deletes all ‘external’ data associated with the account, such as e-mail addresses, phone numbers, IP addresses and device identifiers - effectively pseudonymising this data, aside from Matrix IDs which we will address later on. This measure follows recital 28 of the GDPR, which mentions pseudonymisation as a risk reducing measure for data subjects, which helps controllers and processors meet their data protection obligations.
Now, the thornier issue of communications data. How can we apply erasure whilst maintaining the integrity of the service for remaining users? Keeping on with the email analogy, if someone deletes their sent email from their own account, you would still expect an existing thread with multiple users to work and be visible. You just would not expect the same message to leave the original account to new individuals.
That is precisely how the issue is addressed in Matrix - upon deletion of an account, and request for deletion of messages, a flag is applied to the original messages which prevents it from ever being displayed to any new people. This, of course, requires cooperation from the other server administrators who might also have copies of the same message in their server instance. We make this decision by referring to recital 66 of the GDPR, which requires controllers take reasonable steps, taking into account available technology, to inform other controllers of the data subject’s request to have their data erased.
One issue still remains unresolved - Matrix IDs (MXIDs) are always associated with state events (data sent by a user to modify the attributes of a given room - eg its name, its members, its avatar), which means those IDs could still leak over federation. That is a particular concern when one uses their legal name as their MXID. The solution for this is to replace the MXID with a pseudonym, maintaining the integrity of communications and fully removing any last remains of identifiable information in the system.
The Synapse team has also made a lot of progress on message retention policies and media retention, both huge strides to continuously improve the privacy of Matrix users, whilst also helping server administrators comply with their legal obligations.
Things have definitely progressed in the portability space, and chat export is now implemented in multiple Matrix clients, having been first implemented on Element Web in October 2021, in version 1.9.2. We look forward to seeing what the next year brings us in terms of privacy improvements.
For the next post in this series we will continue discussing the EU policy landscape, although from a different perspective. We will be going through the digital services package (which includes the DSA and DMA) and what does it all mean for Matrix now that we have reached implementation stage.
As always, we remain open to your feedback and thoughts. If there is anything you would like to hear more about or have a suggestion for a future blog in this series please feel free to reach out to dpo@matrix.org</a> via email, DM to @gpdr:matrix.org</a> or chat to us in the Office of the Matrix.org Foundation room</a>.

Introducing our first elected Governing Board

2024-06-03T19:00:00+00:00

It is an honor and a pleasure to unveil the election results and introduce the first elected Governing Board for the Matrix.org Foundation!
Congratulations to the winning candidates, we thank you for your willingness to serve the community. We’re also grateful to everyone who threw their hat in the ring, and hope that the candidates who did not get elected consider running again in the future – noting that we have an election of Gold, Silver, Individual, and Associate Members scheduled for next year.
Thanks also to all of the people who cast ballots in the election, and to everyone who asked questions along the way! We learned a lot in this first election process that we look forward to incorporating into the next one.
The level of engagement with the process was a very encouraging sign for the health of the Matrix ecosystem, and we’re proud to have had 100% voter turnout in all but one constituency.
Read on to see who is on the Governing Board, a brief discussion of next steps, and reflections on some of the work that remains to improve representation. 
🔗</a>The Governing Board</h2>
Representing Individual Members</a>, we have:

Andy Balaam (he/him)</li>
Greg Sutcliffe (he/him)</li>
J.B. Crawford (they/them)</li>
Sumner Evans</li> </ul>
Representing Ecosystem Members</a>, we have:

Bram van den Heuvel (he/they), Elm SDK</li>
Kim Brose (he/him), Matrix Community Events</li>
Nicolas Werner (he/him), Nheko-Reborn</li> </ul>
Representing Associate Members</a>, we have

Cleo Menenez Jr. (he/him), GNOME Foundation</li>
Tobias Fella (he/him), KDE e.V.</li> </ul>
Representing Platinum Members</a>, we have:

Neil Johnson (he/him), Element</li> </ul>
Representing Gold Members</a>, we have:

Brad Murray (he/him), Beeper</li>
Kevin Boos (he/him), Futurewei Technologies</li> </ul>
Representing Silver Members</a>, we have:

Jan Kohnert (he/him), Gematik GmbH</li>
Thor Arne Johansen, Verji Tech AS</li> </ul>
Representing Guardians</a>, we have:

Amandine Le Pape (she/her)</li>
Matthew Hodgson (he/him)</li>
Ross Schulman</li> </ul>
Representing Spec Core Team members</a>, we have:

Richard van der Hoff (he/him)</li>
Travis Ralston (he/him)</li> </ul>
And, lastly, representing Foundation staff in an ex officio capacity, we have:

Josh Simmons (he/they)</li> </ul>
🔗</a>Next steps</h2>
All of the elected representatives will soon receive a welcome email and details about onboarding which will take place over the next two months, with our first official meeting being in August or September. That first meeting will include chartering committees, establishing initial committee assignments, and other agenda items within the Governing Board’s remit.
All Governing Board members will soon be added to a private Matrix room and mailing list. We also hope to hold informal gatherings before that first meeting, so that Governing Board members can get to know each other before we dig into business.
We will continue to use the 2024 elections page</a> as a place to aggregate information about the current Governing Board, and our About</a> page will soon be updated. Before next year’s election we will establish a more general landing page for the Governing Board that is not specific to any one year.
🔗</a>Reflecting on representation</h2>
Our mission is to bring secure, private, free and open, unencumbered communication to everyone. In order to succeed in that, we need to bring a representative cross-section of perspectives to bear on our governance and development.
And while we haven’t yet conducted formal surveys of demographics, such that we can be confident about the baseline we’re working from, it’s plain to see that our contributor communities are not yet as representative as we need them to be. This isn’t news to anyone, but the election results make it all the more obvious.
The issue of representation is something we must tackle across the whole of the Matrix ecosystem, and we intend for the Foundation to play a leading role in addressing this internally and externally. We can learn from other successful initiatives, and I myself have been successful in tackling these challenges in partnership with other communities, so I know we can get to where we need to be.
In electing our first Governing Board, we have dramatically expanded the number of perspectives and lived experiences that are directly engaged in the evolution and direction of Matrix. Coming from a place where the majority of decisions were being made by people associated with one company, this is a huge improvement. This is something we should be proud of!
But to be extremely clear: we need to drastically increase the representation of women and people outside of Europe and North America. There may be other lived experiences we are short on, but these two stand out.
I’m eager to dig into this work with everyone here around Matrix. Please stay tuned for a follow up blog post specifically on this subject.
Onwards and upwards 🚀

Voting has begun in the Governing Board elections

2024-05-17T00:00:00+00:00

Voting has started for the Governing Board elections and runs till May 31! This is our first election and we are very excited. All of the results will be published here on the blog on June 3.
You can learn about all of the candidates</a> on our 2024 election page</a>. All eligible voters should have received an email from OpaVote</a>, the election system we have chosen for this year’s elections.
If you believe you are eligible to participate but have not heard from us, first check the inbox and spam folders of the email address you have on file with us (such as through Donorbox or Patreon). Please email us</a> if you have any questions. 
All members of each constituency group are entitled to vote on the candidates within that constituency group. Generally, we will hold elections for half of the constituency groups each year. However, this year we are holding elections for all of the constituency groups:

Community representatives
4 seats for Individual Members – these are people who currently provide financial support to the Foundation.</li>
3 seats for Ecosystem Members – these are FOSS projects and communities around Matrix.</li>
2 seats for Associate Members – these are FOSS foundations, academic institutions, and other communities that are aligned with key parts of our mission.</li> </ul> </li>
Funder representatives
4 seats for Platinum Members – these organisations sponsor at the highest level.</li>
3 seats for Gold Members — these organisations sponsor at a high level.</li>
2 seats for Silver Members — these organisations sponsor at a level commensurate with the size of their organisation.</li> </ul> </li>
Foundation representatives
3 seats for Guardians – these are the members of the Foundation's board of directors.</li>
2 seats for the Spec Core Team – these are the members of the Spec Core Team that looks after the spec.</li>
Managing Director – this is the Foundation's head of staff, no election is run for this seat.</li> </ul> </li> </ul>
Next year, we'll run elections just for Gold, Silver, Individual, and Associate Members.
For more background on the Governing Board and its place in the growth and evolution of the Matrix ecosystem, read: The Governing Board, our next big step in open governance</a>.

Post-mortem of the Matrix.org Outage

2024-04-25T16:20:00+00:00

The Matrix.org homeserver suffered from an outage on Monday 22 April, between 08:00 UTC and 10:00 UTC, followed by slowness for the next 2 hours.
The outage occurred during scheduled maintenance with no expected downtime. It included upgrading the base OS of the machines running Matrix.org’s deployment. 
🔗</a>Technical cause</h2>
The Matrix.org homeserver is large. To operate at this scale and distribute the load on several machines, it relies on Synapse workers.
The first machines upgraded only ran stateless workers and were trivial to upgrade. Upgrading the machines with stateful workers was more difficult. To avoid downtime, the stateful workers had to be moved to other machines from the same deployment, and be restarted.
The machines that received the additional workers ended up being resource-starved. In the meantime, it took significant time to upgrade the free machine and bring its network back online before we could move the workers back to it to better share the load.
🔗</a>Organizational cause</h2>
Matrix.org is a historical and complex deployment that is difficult and costly to replicate entirely in a staging environment at this scale. It is also the largest deployment in the federation and has unique performance requirements.
Through this upgrade process, gaps in the deployment documentation were identified and these gaps contributed to the upgrade taking longer than expected. The deployment specificity has now been properly documented, and we are confident that the next machines’ upgrade will be significantly faster.
🔗</a>Lessons learned</h2>
To perform an upgrade without downtime, the Foundation would need to add another server in the deployment of the Matrix.org homeserver, as a consequence of steadily increasing traffic. An extra server introduces a recurring cost and requires additional work that the Foundation cannot afford right now.
The next upgrade will have about an hour of planned downtime and will be announced shortly. In the meantime, the Foundation is investigating the most cost-effective way to improve redundancy on matrix.org.

Announcing the 2024 Governing Board elections

2024-04-12T14:00:00+00:00

Update: the terms of the board have been updated with the follow changes:

Allow for filling vacancies by appointment or by-election at the discretion of the Managing Director and the Guardians, in consultation with a Governance Committee. (2.7.1)</li>
Allow for the Governing Board to adopt voting mechanisms other than simple majority on a case-by-case basis. (5.5)</li>
Disallow nominees from running for election in more than one constituency at a time. (2.4.1)</li>
Change UTC to AOE in timeline. (2.3)</li> </ul> Welcome to the first ever Governing Board election season for the Matrix.org Foundation! We start with a one week nomination period that opens on Saturday, April 20th and closes on Friday, April 26th AOE time</a>.
We’ll be doing our best to reach out to every constituent group to let them know they are eligible to nominate candidates for the election. That said, this is our first election and we don’t yet have contact information for everybody who is eligible, so we want your help getting the word out.
If you are interested in nominating someone – or yourself – to be a candidate in this election, read this post in its entirety.
To learn about what the Governing Board is, what it does, and the context it operates in, read this blog post from last December</a>. You are also welcome to read the Governing Board’s current bylaws</a>.
Go here for instructions on submitting a nomination!</a> 
🔗</a>Election schedule</h2>
Here is the timeline for this election season, which will happen in the second quarter of every year:

To minimize confusion, and maximize inclusion given our international community, we will be using “Anywhere on Earth” (AOE) time</a>. If you’re not familiar with AOE time, here’s what it means using our nomination period as an example: so long as it’s still Friday, April 26th in any timezone on the planet (from UTC+12 to UTC-12), the nomination period is open.
🔗</a>How our elections work</h2>
Our Governing Board is made up of 9 different constituency groups across 3 categories: nonprofit and community representatives, funder representatives, and foundation representatives. Each group has been allocated seats on the board, gets to nominate its own slate of candidates, and gets to vote within that slate of candidates.
For example, Individual Members get to nominate themselves, and vote on the Individual Members who are qualified candidates. The only exception is with the Managing Director (hi, that’s me) who automatically gets a seat on the Governing Board, but that’s just one seat of many.
Here is the composition of seats on the Governing Board:
Community representatives</th> Funder representatives</th> Foundation representatives</th></tr></thead>

4 Individual Members</td> 4 Platinum Members</td> 3 Guardians</td></tr>
3 Ecosystem Members</td> 3 Gold Members</td> 2 Spec Core Team Members</td></tr>
2 Associate Members</td> 2 Silver Members</td> Managing Director</td></tr> </tbody></table>
Learn how to become a member</a> and see a list of our current organizational members</a>.
We will be seating candidates for all constituency groups in our first election. Starting in 2025, we’ll run elections for half of the constituency groups. This is so that we maintain some level of continuity and institutional knowledge across each election. Consequently, while the first elected representatives from the Guardians, Spec Core Team, Platinum, and Ecosystem Members will serve 2-year terms, the first elected representatives from Gold, Silver, Individual, and Associate Members will serve a 1-year term. We anticipate that many people in those constituencies who are elected this year will run for re-election in 2025.

There are currently no term limits, but term limits are a best practice in open governance so we intend to introduce them as we find our collective footing.
For greater detail, please read this blog post from last December</a>.
🔗</a>Who can nominate</h2>
You must be a member of one of the constituency groups in order to nominate yourself or someone else to be a candidate in the election. By far our largest constituency group are Individual Members, who number in the 100’s. If you have donated at least $60 USD to the Foundation since April 20, 2023, on any of Donorbox, Patreon, or Liberapay, then you are eligible to nominate and vote.
All nominees must have consented to nomination before being nominated and must be a community member in good standing. That means they must have a clean track record with respect to our Code of Conduct</a>. We want our Governing Board to be a clearing house for a variety of priorities and perspectives, and to be able to hold space for each other even when there are disagreements.
🔗</a>Who can vote</h2>
All members of each constituency group are entitled to vote on the candidates within that constituency group. We will be reaching out to everyone we have contact information for, to ensure we have our voter rolls together before voting begins in May.
We will hold an election for every constituency even if a given constituency has fewer candidates than there are seats allocated for them on the Governing Board. This is, effectively, as a vote of confidence.
If you believe you are eligible to participate but have not heard from us or OpaVote</a> – the election system we have chosen for this year’s elections – by May 10th, please email us promptly</a>. We build our voter rolls on May 17th and can't change them after that!
All of the candidates will be listed on an elections page here on our website which we’ll publish on April 29th.
🔗</a>How to prepare yourself</h2>
If you want to be a candidate in the election, there are a few things you should know:

All candidates will be listed on our website, grouped by the constituency group.</li>
We do not require people to use their “legal name.”</li>
Candidates who are nominated by an organizational member will have their affiliation listed.</li>
We expect candidates to provide a short bio and a short statement, collectively covering qualifications and priorities.</li>
You are encouraged to make yourself available for conversation with members of your constituency group.</li>
The period for campaigning runs from April 27th to May 17th. Please note our community Code of Conduct</a> while campaigning.</li> </ul>
🔗</a>What to expect if you win</h2>
Congratulations! All of the winners will be announced on June 3rd, but since the elections conclude on May 31st, you may get an email with the results of the election you participated in before June 3rd.
All elected representatives will be added to a private mailing list and Matrix room so that they can introduce themselves and communicate in between meetings. I will be reaching out to every elected representative to meet one-on-one, get acquainted, and answer questions before we convene for our first Governing Board meeting. Given the size of the board and the international nature of our ecosystem, those one-on-one meetings will likely happen over the course of a couple months.
The Governing Board will meet as a full board twice a year, for at least 90 minutes each time, and our first 1-2 meetings will have a professional facilitator to help us collectively put our best foot forward. Expect one meeting before the end of the year, and another before the next election.
You are likely to receive a packet of materials before each meeting which you will be expected to have reviewed. Most meetings will be held online, though we may convene meetings in-person, such as at the (soon to be announced) annual Matrix Conference. We will make every effort to make in-person meetings accessible to remote participants, and no official business will ever happen without appropriate notice, quorum, and minutes.
While the Governing Board is an advisory board, members are encouraged to play a role in helping to carry out the activities that support the staff in delivering on the Foundation’s collective remit, such as coalescing priorities to share with the Spec Core Team and connecting with contributors and funders to implement proposals.
We intend to charter committees – such as for finance, which would review our annual budget in detail – who will meet in between Governing Board meetings and present their assessments and recommendations to the Governing Board. These committees are where the bulk of the activity will take place since the board, which may have up to 24 members, is quite large.
🔗</a>How to nominate</h2>
Please use this Cryptpad form to nominate for the Governing Board elections</a>. If you are unable to use the form, please refer to this nomination document</a> and email your responses to elections@foundation.matrix.org</a>.
All nominations are subject to review in accordance with our bylaws. We will email you to confirm receipt within 2 business days, and we will publish our elections landing page with all of the nominees, and other details, by April 27th.
Thank you for your ongoing support, and good luck to all the candidates in the upcoming elections!
Ad astra per aspera 🚀

Open Source Infrastructure must be a publicly funded service.

2024-04-04T16:30:00+00:00

Hi folks,
The events of the last week have been utterly terrifying as we’ve seen a highly sophisticated targeted attack on open source infrastructure play out in public, in the form of the liblzma backdoor</a>. Matrix is not impacted by the attack (none of our code or infrastructure is using liblzma or xz 5.6), but it has been a massive wakeup call in terms of understanding the risks posed by overstretched open source maintainership. 
The attack particularly resonates as Matrix’s maintainership is distinctly overstretched currently - despite Matrix ending up at the heart of huge amounts of critical infrastructure, ranging from the Ukrainian MOD</a> to NATO</a> and at least 15 other countries and major international organisations that we know of.
Historically, Matrix development has been largely been funded by Element, the company set up by the team who created Matrix in order to fund their work on it. As unpopular as VC funding is in some circles, the Matrix community owes a huge debt of thanks to Element’s investors (Status, Notion, firstminute, Dawn, Automattic, Protocol Labs and Metaplanet) and Amdocs for funding over $50M of work on both Matrix and Element since 2017. Having a large professional team paid as their day job to maintain Matrix has helped enormously against xz-style attacks.
However, this model is simply not sustainable: these days, Element is focused on being able to pay its own costs rather than being dependent on further VC investment. This leaves a massive hole in funding for Matrix, and we’ve already seen the impact of this</a> with projects like Dendrite, Low Bandwidth Matrix, Account Portability, P2P Matrix and Third Room no longer able to be funded by Element (for now). Meanwhile, the remaining core team is stretched.
This feels particularly unfortunate given the number of governments and public sector organisations who rely on Matrix, but in practice it turns out that finding a way for them to fund open source maintenance can be surprisingly challenging - despite the potential impact of Matrix not being able to invest in security (or cryptography, or trust & safety, or performance improvements) being catastrophic, especially as Matrix becomes more and more of a high value target for large scale adversaries.
There seems to be two types of problems: firstly, those who don’t understand why it might be beneficial for a government to pay for open source at all. A particularly amazing real-life example of this came from a certain Ministry of Defence last week, whose procurement department (on being asked to help fund core Matrix development, given their operational dependency on Matrix) said: “You have to understand, we’re responsible for taxpayer money here. We can’t just make a donation to your open source project.” Apparently if we had built the same tech as a proprietary product, paying for it would apparently have been an infinitely better use of taxpayer money. Now, thankfully, organisations like FSFE</a> and EDRi</a> and OSBA</a> have made major strides in educating governments to understand that funnelling taxpayer money into proprietary software licences does not benefit the public in the way that using open source software does - but old views die hard.
Then, perversely, the second problem emerges: FSFE’s well-intentioned “Public Money, Public Code</a>” campaign is often given to us as a reason to insist on funding features rather than maintenance. This seems to be because procurement departments want to have something concrete to procure as a one-off, rather than making an ongoing commitment to keep the project secure, existing and healthy - and so focus on funding new features (or hiring their own staff to build their features) and ignore maintenance. If you ever wondered why Element has so many weird and wonderful features (which are not always maintained as well as they might), this is part of the problem. The problem is captured beautifully in Tobie Langel’s excellent (and highly topical) talk</a> from this year’s State of Open Con:

However: we think there might (just might!) be a long-term solution in sight.
Particularly in the wake of the xz/liblzma attack, it seems that governments may be more aware that they and their societies depend enormously on FOSS infrastructure to operate. Free and open source software has literally become shared digital public infrastructure. And much like shared physical public infrastructure - bridges, roads, sea defences, etc - FOSS maintenance should be funded by governments on behalf of the taxpayer.
This funding should NOT be tied to specific feature development, but simply funding the core maintenance of the infrastructure - paying for the maintainers (and/or letting them or their umbrella org hire trusted ones!) to ensure the core project remains healthy and secure. Otherwise, the pressure just rises on the core project to chase feature development at the expense of maintenance (making maintenance harder) - or, worse, to be pushed away from open source into building proprietary solutions or crippling the open source by moving valuable features into side proprietary products.
Now, the good news is that some organisations are already trying to solve this problem:
NLnet</a> & NGI</a> are excellent in directing EU funding to smaller FOSS projects (e.g. funding loads of Matrix community projects</a>),</li>
Similarly the Prototype Fund</a> is very helpful for smaller projects (e.g. funding bits of Conduit</a>, ThreeMatrix</a> and alertrix</a>)</li>
OpenSSF</a> is a Linux Foundation project focused on helping solve the problem</li>
Sovereign Tech Fund</a> similarly supports smaller projects to act as a digital public good</li>
Copie Publique</a> takes a different approach to encourage private companies to contribute back directly to FOSS projects</li>
European Digital Infrastructure Consortium (EDIC)</a> is a new strategy from the EU to enable multi-country funding of digital infrastructure projects (but so far seems to be aiming at funding governments themselves, rather than underlying FOSS projects).</li> </ul>
However, most of these are not yet operating at the scale of a project like Matrix, and the irony is that the bigger projects need even more financial support than smaller projects to keep alive and sustainable. High level funding does exist in the form of the EU’s Horizon</a> programme for R&D and Innovation (which provides the upstream for NLnet and NGI), with a total budget of €95.5B. However, it’s currently set up to only fund consortiums rather than independent projects - and the last thing a typical open source project needs is to orchestrate and administer an international consortium of vendors and universities in order to get itself funded.
The perfect solution in the EU would probably be a NLnet-style organisation with the remit to route funds in the range of low-millions a year to larger projects like Matrix which have become widespread critical infrastructure - to allow them to thrive in their mission without trying to coerce typical public sector procurement into picking up the bill. Or maybe a tax should be instantiated to force large scale open source projects users to route recurring funding to the project maintainers. So, Governments: please route taxpayer money to support the maintenance (not just features!) of open source projects that your country depends upon, before it’s too late. This also means educating procurement to the topic and updating procurement frameworks to be able to support this.
Meanwhile, we are in the middle of running a fundraising drive</a> to help address the funding gap, which is currently making cautiously positive progress towards its £900K target, having raised £415K since last year, entirely thanks to Individual, Silver and Gold members joining</a>. Our new membership model is working - giving the wider Matrix community a way to join the Foundation in order to participate in the upcoming Governing Board, and help steer the direction of the project, while contributing funding! So while we hope that governments will read this blog post and point out ways to sustainably fund more of the maintenance they depend on - today, you can help too by persuading your organisation (or yourself!) to become a member today</a> and help keep Matrix funded and pointed in the right direction.
thanks,
Matthew

Update on Native Matrix interoperability with WhatsApp

Protecting the projects at the heart of the Matrix ecosystem

Policy and regulation update 2024: Matrix and the GDPR

Introducing our first elected Governing Board

Voting has begun in the Governing Board elections

Post-mortem of the Matrix.org Outage

Announcing the 2024 Governing Board elections

Open Source Infrastructure must be a publicly funded service.

Matrix.org - Foundation

Announcing Our First Trademark Policy

Matrix Conf 2025 was a blast!

A fond farewell from Managing Director Robin Riley

Matrix for Public Sector: DINUM joins the Foundation as we launch a new forum!

Introducing your new Governing Board representatives

Introducing premium accounts to fund the matrix.org homeserver

Announcing the 2025 Governing Board elections

Matrix.org - Foundation

Announcing Our First Trademark Policy

Matrix Conf 2025 was a blast!

A fond farewell from Managing Director Robin Riley

Matrix for Public Sector: DINUM joins the Foundation as we launch a new forum!

Introducing your new Governing Board representatives

🔗</a>Elected representatives</h2> These are the elected representatives for each of those constituencies:</p> Individual Members</p> Andy Balaam (he/him)</li> Gnuxie (she/her)</li> Greg Sutcliffe (he/him)</li>

Introducing premium accounts to fund the matrix.org homeserver

Announcing the 2025 Governing Board elections

Update on Native Matrix interoperability with WhatsApp

Protecting the projects at the heart of the Matrix ecosystem

Policy and regulation update 2024: Matrix and the GDPR

Introducing our first elected Governing Board

Voting has begun in the Governing Board elections

Post-mortem of the Matrix.org Outage

Announcing the 2024 Governing Board elections

Open Source Infrastructure must be a publicly funded service.