I am following the thread for years now and their financials were always a shitshow. I believe they never released anything on time or without the community begging for it. Well, except some fluff blog post at the end of the year without real data. I love Matrix but it's a fishy foundation. With this and Element not releasing server code under apache 2 anymore, it looks more and more like Element is going for entshitification.
Edit: Well, Josh is here so he will again start to deflect for some weeks and hope everyone will just forget about it until the next merry go round. sic
> Well, Josh is here so he will again start to deflect for some weeks and hope everyone will just forget about it until the next merry go round
This has been my experience with how Matrix handles critique in general, e.g. the response to "why not matrix?" which left me disappointed. Looking at this, and also at low quality of the reference clients and servers, over-engineered protocols and the poor UX in general it does not convince me that Matrix is a good solution to consider.
Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) didn't seem to like the issue being posted on Twitter.
The reporter took down the tweet, and it's still now effectively abandoned (despite it still being an issue; I've spoken to quite a few mods about it). This is honestly really disappointing behaviour from a platform owner.
I suggested that GrapheneOS stopped enumerating potential ways to attack Matrix rooms on Twitter if they actually wanted to discourage attacks.
Meanwhile, that issue has not remotely been abandoned, and has continued to be worked on in private (given the risk it might have security impact) - although as it's a rare edge case without a known security impact, it's competing with a lot of the other work we do to support Matrix, hence slow progress; especially with highly constrained funding.
My intent isn't to "pile-on"; it's to provide insight into the issues people have with Matrix. I understand that it's your creation, but judging by this and the GitHub thread, it seems like you get quite defensive in these situations. Ultimately, these are valid criticisms of the platform; people aren't personally attacking you or the project. Personally I commend what you've created.
> I suggested that GrapheneOS stopped enumerating potential ways to attack Matrix rooms on Twitter if they actually wanted to discourage attacks.
Well, the issue was posted above. The Graphene guy posted it on Twitter, and by doing so you claimed he "slagged [you] off"[0].
> Meanwhile, that issue has not remotely been abandoned, and has continued to be worked on in private (given the risk it might have security impact) - although as it's a rare edge case without a known security impact, it's competing with a lot of the other work we do to support Matrix, hence slow progress; especially with highly constrained funding.
This is the part I don't understand. If you're working on it in private, you acknowledge it may be a security risk (plus your use of the word "attack"), but you've also de-prioritized it because it's not a security risk?
> The Graphene guy posted it on Twitter, and by doing so you claimed he "slagged [you] off"[0].
I forget the precise contents of their deleted tweets, and I'd be first to admit that for better or worse I try to be authentic when typing here or elsewhere, rather than faking being calm & anodyne. Based on the feedback here & elsewhere, that's probably a mistake. In this instance, having Graphene screaming about how awful Matrix is and enumerating ways to cause moderation problems was not helpful during a moderation incident, especially where we had been scrambling to help them.
> This is the part I don't understand. If you're working on it in private, you acknowledge it may be a security risk (plus your use of the word "attack")
Correct. Any bug in the state resolution algorithm could potentially eventually turn out to have security implications.
> but you've also de-prioritized it because it's not a security risk?
We haven't explicitly de-prioritised, but other things have come along at higher priority. The reason we haven't bumped its priority higher is because it happens rarely, and the chances of security impact look to be relatively low.
> In this instance, having Graphene screaming about how awful Matrix is and enumerating ways to cause moderation problems was not helpful during a moderation incident, especially where we had been scrambling to help them.
To be fair, from what I hear GrapheneOS doesn't have the best reputation for its communication with other people, but strcat did appear rather apologetic in the thread. Regardless, we're experiencing the bug I linked, so it's definitely still an issue.
> especially where we had been scrambling to help them.
Hmm, this is where I disagree -- if you've been scrambling to help, wouldn't the issue have been fixed by now?
> Hmm, this is where I disagree -- if you've been scrambling to help, wouldn't the issue have been fixed by now?
We scrambled to investigate and fix this particular instance (and previous unrelated instances where they'd had problems). When we realised that they were simultaneously screaming about how shit we were, we put it back on the shelf.
I mean, it's still happening to them, one whole year later. To be completely honest, are you unable to recognize that from their perspective, you are shit, because they're having serious issues with your product, and you stopped helping them because... they tried to tell their users that getting dropped from the chatroom is Matrix's fault, not theirs? Can you not see how completely unacceptable it is for thousands of people to be randomly dropped from rooms?
Fixing fundamental basic functionality of your app should not be classified as having "burnt a bunch of time investigating this".
> When we realised that they were simultaneously screaming about how shit we were
Right, but this is where your response baffles me: they've reported a genuine issue with the implementation, so why not fix it for everybody instead of "put[ting] it back on the shelf" and letting others suffer too?
It sort of sounds like "they complained about us, so fuck them and their issue" (except it's not just their issue). Wouldn't it be better to work around disagreements to benefit everybody, instead?
I know it's incredibly hard to not take it personally when people call your baby ugly, but you're not helping things by being defensive. People seem to have issues with how you (as a company) handle bugs and criticism, and while it may not seem fair or accurate, at very least, it's likely that your company's responses contribute to the perception.
If nothing else, it points out a communication problem.
Talking about a serious bug where thousands of people appear to be kicked from rooms that's been going on for over a year is not a "pile-on". It's a very bad experience for everyone involved, and people are just pointing it out. Your inability to empathize with other people having a bad experience using your product is not doing you favors here.
Matrix and Element are consistently one of the buggiest messaging applications I interact with, and I've waited years for it to be better.
> Matrix and Element are consistently one of the buggiest messaging applications I interact with
Oh same, though I've found that Nheko Reborn is a much better client than Element (like, it's not even close). There's no getting around Synapse though; we're actually experiencing the bug I linked above, and it's absolutely dreadful to deal with.
FYI I'm referring to the specific "why not matrix?" piece which was posted on telegraph and then was replied to by a matrix developer on lobsters. I don't want to link to them directly, hopefully you can find them both, but it's a good read if you thought about going all in on Matrix. The response particularly left me disappointed, since we still experience lots of bugs, which were allegedly fixed.
I get that we're operating in a low trust environment, and you don't yet have any reason to trust me.
I will say this: I'm not here to carry water for past performance. I _am_ here to build the foundation into the organization the community deserves, and I have a track record when it comes to making organizations more responsive to the communities they serve.
Not only will I respond to the questions and concerns, I am actually working on systemic solutions that will provide transparency as a matter of course.
Of course, these are just words for now. Judge me by my actions in the days and months ahead, and know that I do aim to earn your trust. Edited to add: *and I aim to build the foundation into the kind of organization that, by merit of its rules, processes, and community representation in governance, doesn't require us to be trusting in the first place.
Josh has quite the track record from elsewhere, having eg served as president for the very Open Source Initiative itself, so I do think it’s fair to give him time here
Josh literally started less than six months ago and is the first employee of the foundation – do you think that there are some papers ready here and now for him to hand out?
> Edit: Well, Josh is here so he will again start to deflect for some weeks and hope everyone will just forget about it until the next merry go round.
This is more of a meta-comment, but responding to a reply by editing your comment isn't fair play. It retroactively colors their response, and if they want to reply to your edit then the whole thread becomes a mess to follow for anyone else.
Let Josh have his say and reply to him if you think his response is deflection, but please don't preempt him with a sarcastic edit.
If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
(Submitted title was "Non-profit Matrix.org Foundation seems to be moving funds to for-profit Element")
The issue is several years old, but the comments that are new - and of interest - are those that assert the statement int he submitted title.
Without taking a position on the underlying issue (I'm broadly pro-matrix), I wonder: is it worth considering whether this is a scenario worth an addition carve-out of the "original title" rule?
Thanks for the tag on the GitHub issue and for being a persistent advocate for transparency. Transparency is something we should expect from any open source foundation, and I am committed to delivering on that as the Foundation's first Managing Director.
That said, it is the weekend :-) I'm happy to address all of the concerns and questions, and you'll hear more from me tomorrow – both here and on GitHub.
> According to the statement, the book value of cryptocurrency assets did not change between Oct 31, 2021 and Oct 31, 2022. This is questionable, to say it mild, given that there have been incoming cryptocurrency transactions publicly visible on the respective published blockchain addresses of The Matrix.org Foundation.
I'm copying the first part of my response here for y'all's convenience:
Hi @alohapersona, I’ve included answers to your specific questions below, but first I wanted to share some context.
You can expect the Matrix.org Foundation to grow and evolve like other open source foundations, in terms of incrementally staffing up, increasing transparency and community governance, and establishing programs that support the ecosystem.
There are a lot of great examples we can learn from, though the manner in which we are starting adds some complexity. It’s a lot cleaner to start with a small balance and some IP than to inherit massive pre-existing commitments like running the matrix.org homeserver. The added complexity also makes things more difficult, and it’s fair to say the path to now has reflected that difficulty level.
The Foundation hit a key milestone this year when it delivered on its promise to make its first hire. If you look at the landscape and the history, you’ll find that the first hire makes a radical difference in delivering on the kinds of things I see you’ve been seeking for the last four years.
Setting expectations
So, I’d like to set some expectations. The Foundation’s fiscal year, as you know by now, runs from November 1 to October 31, and it takes time to close the books. Especially when we’re still separating out our infrastructure and relying on people for whom the Foundation isn’t their first priority. After we close our books, two things happen: we send them off to the tax accountants, and I begin preparing our annual report. That annual report will cover revenue, expenses, and programmatic activity, all contextualized with our vision and where we are on the path to realizing our vision.
The timeline is a little fuzzy, but I’d expect that annual report to land around March or April.
And we should expect further maturation/normalization of process each successive year: when we seat our first elected Governing Board in 2024 Q2, I’ll finally have a board of community representatives to review and approve my budget! With that, we’ll start to see both a public budget before each financial year begins, and an annual report after it ends.
Getting involved
Ultimately, the project is to build this Foundation up into an independent, transparent, self-sustaining organization with community-driven governance at every layer. We will need continued mutual accountability to stay the course on the way to achieving that vision. To wit, I welcome call-ins and incisive questions, and also stress the need to be charitable with each other. This work is hard, it is painfully incremental, and it happens over the scale of years and decades.
I do not, however, welcome escalation to Hacker News with bad faith editorializing, which brings out the worst in people and leaves me wasting time confronting FUD rather than tending to forward-looking work that truly serves the community. Starting fires like that isn’t helpful.
For those who are invested in Matrix and want greater visibility into the Foundation’s activities, I invite you to join the Office of the Matrix.org Foundation room I launched last month. We have a lovely community of people there who provide input, offer accountability, and join together to celebrate even the small successes on our collective journey to organizational maturity and self-governance.
I hope this helps you and all those who read this to understand where we are, where we are going, why things are the way they are, and how to get involved.
With gratitude,
Josh Simmons
Managing Director of the Matrix.org Foundation
Nothing jumps out that immediately causes me consternation as either an occasional donor or an (even more) occasional user, except perhaps the extreme delays in responses from foundation leadership.
I broadly like matrix best of the chat/comms frameworks, but I keep turning back to signal, telegram, and whatsapp because of network effects. So, if shifting some personal efforts to the for-profit org makes sense to core devs... I can't really fault them.
Cheers to alohapersona for keeping the fire going on this issue.
Hi there! Managing Director of the Foundation here. First, yes, the response times have not been great, though of course that's all been on the basis of volunteerism. Now that there's a full-time staffer you should expect better response times.
Regarding the payments to Element: those are based on the many services for which we still rely on Element.
The Foundation has a Master Services Agreement (MSA) with Element which includes administrative services, operation of the matrix.org homeserver, and secondment of several personnel whose responsibilities include advocacy, program management, standards work, and trust and safety. The MSA also includes provisions for the Foundation to reimburse Element for any bills they pay on our behalf.
This reply about how in reality there's very little benefit to the community from the copyright being assigned to the foundation is a lot more perceptive than that comment, especially now that exactly what it foresaw has come to pass: https://github.com/matrix-org/matrix-spec/issues/571#issueco...
The server-side Matrix code developed by Element is no longer going to be released under the Apache 2 license. It's going to be dual-licensed AGPL/proprietary from now on and released from Element's own GitHub repositories with a CLA requiring copyright assignment to Element so they can use it in the proprietary version, and the foundation is dropping all development on the Apache 2 version since they're not interested in competing with Element. This was specifically to obstruct other companies from providing Matrix-based enterprise offerings. There was an announcement about it which made it onto HN a while back: https://news.ycombinator.com/item?id=38162275
What's interesting about this is that if the CLA didn't exist I would entirely support this move. The AGPL is (imo) a better license for a keeping a hosted project public and Open, it's good for things being built on top of Matrix's server implementation to be openly licensed. And the company is right that the Apache 2 license would not prevent them from taking the code in a proprietary direction later; Apache 2 allows that.
But with a CLA, it becomes much easier for their code to move towards source-available.
The thing is, a GPL or AGPL license without a CLA would actually be a reasonable defense against closing down the software in the future, since it would block Element from being relicensed to something more restrictive without the permission of the copyright holders. Even if there is a legitimate need to sell exceptions, a CLA that gave the company a limited right to sell specific exceptions would be better than full copyright assignment and would actually increase my trust in the project rather than worrying me.
>Nextcloud doesn't require a CLA (Contributor License Agreement). The copyright belongs to all the individual contributors. Therefore we recommend that every contributor adds the following line to the header of a file if they changed it substantially:
>
>@copyright Copyright (c) <year>, <your name> (<your email address>)
Element requiring a CLA has only 1 practical effect: Element are effectively saying that in their repo of Synapse/Dendrite, they won't integrate any copyleft code they can't relicense.
Other organisations could still choose to maintain a repo of Synapse/Dendrite that integrates any AGPL code, including all code released by Element.
That might be a better upstream than Element! — but it would take work. For it to happen, someone would need to do and/or fund that work.
If next there is "Synapse Pro" that is proprietary and sold by Element and includes features not present in the open source version of Synapse but relevant to company or government use of Matrix, the AGPL-only version of Synapse will lack those features. This will hinder companies that (potentially) require "Synapse Pro"-features from contributing to the AGPL-only version of Synapse. We have seen this happen before.
Agreed (mostly). Apache is not a defense against proprietary relicensing regardless of who owns the code (and it's why Matrix is able to make this change even though it didn't have a CLA before).
It's a shame though because this change feels like it's weaponizing the AGPL to make the code harder to use rather than relying on the AGPL to preserve software freedom, and it's a shame because I think a more nuanced and limited contributor agreement with narrower permissions could potentially have the opposite effect and be a highly positive change and a highly credible commitment to keeping the project Open, without closing off any of the revenue opportunities that Element seems to be chasing.
I will push back a little though on the idea that nothing is different at all. This change also has the side-effect of giving contributors fewer rights over the code they write themselves. It's not clear to me whether the copyright assignment here means that the contributor is also bound by the AGPL for the code they themselves submit. If that's the case, then this is a meaningful reduction of contributor rights. I think the GPL works best when it is a universal mutual agreement by all parties to keep the code Open to everyone under the same terms; not when it is used selectively to close off specific rights of only specific parties.
But as it stands, without a CLA I could write the same code for both Element and a more permissive fork of Element and I could choose to relicense the code I offer Element to allow for the more permissive use. With a CLA, I don't know that I can do that.
Not entirely. Under the Apache license, everyone can contribute to the Apache-licensed code and mix that code with proprietary code as they wish. Under AGPL-only that's not possible, only code that was contributed under Element's CLA can be relicensed by them and then mixed with the proprietary code. That makes contributing code under AGPL-only less attractive if you need to use the proprietary code.
Well definitely, but as a net benefit, we'll have less proprietary Matrix code than before. Or the people needing to use Synapse in a proprietary setting can contact Element for a proprietary licence, in which case Element will be able to pay its salaries and keep developing Matrix. It really seems like a net win, except for the people that were planning to build proprietary services on top of Synapse without contributing back.
> they won't integrate any copyleft code they can't relicense.
Right, that's exactly the controversy, people are scared of the code being relicensed.
Rather than a CLA, a limited license grant from contributors to allow dual licensing but not the transition away from AGPL might potentially be a way to provide that kind of funding and to close off companies building proprietary products on top of Element without contributing back, while simultaneously decreasing the danger of the code being relicensed entirely; which the company is claiming they have no plans to do anyway.
The inclusion of copyleft code into Element that isn't owned by the company is the safety measure, accepting contributor-owned GPL code is a way for companies to credibly signal that they will not move to a source available model in the future. Sure, a separate upstream could be maintained, but unless Element is planning to pull from that upstream repo then a separate upstream is indistinguishable from a hostile fork and an abandonment of Element as the primary contributor. It's not about the repository, it's about whether the flagship implementation of the Matrix server code has the possibility of being turned into a proprietary product.
If we're going to go with a different upstream, what we're saying is that Element is not going to be providing the flagship implementations -- and I don't think people are eager to make that kind of decision.
Yeah, that seems fair. Though I suppose a limited licence grant is slightly more complex of an arrangement.
If it's any consolation, compared to a month ago when everything was permissively-licensed, Element is no more or less able to make a proprietary fork, and everyone else is now less able.
The Foundation has a Master Services Agreement (MSA) with Element which includes administrative services (accounting, legal, etc), operation of the matrix.org homeserver, and secondment of several personnel whose responsibilities include advocacy, program management, standards work, and trust and safety. The MSA also includes provisions for the Foundation to reimburse Element for any bills they pay on our behalf.
For the most part, the Foundation hasn't directed much funding to active development as other folks in the ecosystem have been doing that ably. That isn't to say we don't fund development though – most recently we've been investing in developing open source trust and safety tools.
OK? What do we expect them to do with the money, exactly? As a donor, I would expect they fund the development of Matrix, which I believe Element is doing?
Notably, "Code Core Team members must arrange their own funding for their time", which I understand as such that the Foundation does not pay directly the developers (same as other standards organizations like IETF). That said, if it was decided that developers get paid by Matrix.org Foundation for developing Matrix.org clients and servers, I wonder how this process works, given that I highly doubt that developers of Conduit, Fractal or Quaternion received any of the funds of Matrix.org foundation.
Main tasks of Matrix.org Foundation is maintaining the spec, documentation, owning IP, promotion and the matrix.org home server. The home server is "generously hosted" by UpCloud (i.e. is not using New Vector EMS), at least according to the matrix.org website.
Looking again at MSC1779, I noticed it says that one function of The Matrix.org Foundation is "Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org). By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it." That protection apparently wasn't very effective, but also notably, New Vector and their leadership clearly have shown to not stand behind the goals of the Foundation. As the leadership of New Vector is also part of the leadership of the Foundation, I see some huge potential for COI here.
Without looking at how this organization works, let me clarify: a 501(c)(3) cannot be paying for software development insofar as this constitutes Product Development. Product Development is outside the scope of charitable work and, if caught, would open them up to back taxes on those 'charitable' contributions plus fines. This is not something that applies just to Matrix, but to the Free Software Foundation for that matter. Not one fucking dime you give them ever goes to software development, and the fact that they don't make this clear upfront given the obvious misunderstanding on the part of the public and what they think they're funding, is fraudulent.
TL;DR Donations to 501(c)(3)'s managing open source projects might as well be lit on fire because they do not and can not go to software development.
A quick search turned up a registration for them in the UK? Is this them?[1] And if so..... where is any of this even documented on the matrix.org website? Lastly, use of a CIC is a horrible idea for precisely the sort of shady shit we're seeing here.
I am interested in the future of Matrix as an open, decentralized protocol. I increasingly see a risk in the behavior of New Vector as the VC-funded effective owner of the Matrix protocol. To me, the Matrix.org Foundation was supposed to be the organization that saves the community from the interests of VCs.
Over recent years I got the feeling the foundation became mostly a fake nonprofit organization to attract donations from the community while the for-profit company attracts VC money. The foundation did not manage to properly include the community in any of its official positions (Board, Spec Team) in 5 years, clearly showing that this is not in its interest.
For Matrix to be a success, we need to design it such that there can be contributions from others than New Vector. This is not happening and because of that, it's very likely that as soon as New Vector is running out of money, Matrix is going to collapse. Having at least a bunch of money in the foundation would reduce that risk, but New Vector seems to even be siphoning off that.
> For Matrix to be a success, we need to design it such that there can be contributions from others than New Vector.
What exactly do you think is stopping such contributions? It seems to me there is plenty of room for community involvement, it is simply a matter of the community doing it (which many have been of course, but there is also always more work to do and free skilled labor is not easy to come by in large quantities).
> Having at least a bunch of money in the foundation would reduce that risk, but New Vector seems to even be siphoning off that.
I'm not following. How does the foundation having money reduce this risk? In particular, how do you think the foundation would help prevent the "collapse" of matrix if they had more funding? If you ask me I'd think that funding developers would be a good way to do that, and as the primary force behind the reference implementations, wouldn't funding Element/New Vector be a good way to do that? Although I was under the impression that resources primarily flowed the opposite way, from Element to the Foundation, but I haven't kept close track so could be wrong...
In any case, I'd echo the original sentiment of this thread - as someone who joined their patreon back when it first started and still haven't left it, I don't really mind if they haven't documented for the public where exactly every penny went as long as it's going towards the people developing matrix. Yeah maybe not ideal, but given that the foundation has very little money to begin with I have a tough time faulting it. It would change things if they were bringing in millions, but when the community patreon is not even bringing in enough to hire a full time minimum wage employee in California, much less a developer, accountant, or lawyer, documenting the expenditure of a few pennies is pretty low on my priority list.
> What exactly do you think is stopping such contributions?
2/5 foundation board members are from New Vector. At least another 2/5 foundation board members have strong personal ties with New Vector. 7/8 spec team members are from New Vector.
In other words: Nothing at the Matrix Foundation happens without consent from New Vector. If New Vector does not like a competitor, they can block them from participating in the standard (making new features of them standards non-compliant) and then block them from using the Matrix brand or claiming to be Matrix compatible. As a company, you'd be stupid to build your business around being a competitor to New Vector if they can easily throw you out.
That was the whole purpose of the foundation: to manage the spec and the brand independent of New Vector, so that others can contribute.
> I'm not following. How does the foundation having money reduce this risk?
It's much easier to do anything with money. If new structures need to be created in the foundation after a collapse of New Vector, it is way easier to do so if you have money.
> It would change things if they were bringing in millions, but when the community patreon is not even bringing in enough to hire a full time minimum wage employee in California, much less a developer, accountant, or lawyer, documenting the expenditure of a few pennies is pretty low on my priority list.
As I wrote in the linked thread, their total assets exceeded a million dollars end of 2021. That should be enough for a full-time hire with competitive compensation for a few years, especially if that hire is not in California (why the hack hire in California when you don't need to?). Also, even small amounts of money can be very attractive to open source contributors, they're already doing it without any compensation, but just giving them a thousand bucks a month will make them more likely to continue contributing in their spare time. You don't need it to be a full time hire to be effective.
> At least another 2/5 foundation board members have strong personal ties with New Vector
Nope. Neither Ross, Jon or Jutta have 'strong personal ties' with NV. We had met Ross twice(?) before asking him to join (based on his qualifications as a decentralisation-focused lawyer and casual Matrix user). Jutta we'd met once (and was asked based on her qualifications as CEO of a decentralisation-focused company which used Matrix). Jon had supervised me on an undergrad project 20 years ago (and not been in contact since), and was asked to join on the basis of his qualifications as an academic expert in decentralisation. We recruited experts to the board who we were familiar with from the industry, and have asked them to put their professional reputation on the line to ensure that Amandine & myself (as founders of Matrix, and later Element) keep the foundation on mission.
> 7/8 spec team members are from New Vector.
This is only because 3 of the 8 were independent when they joined the team, but subsequently ended up working at NV so they could be paid to work on the Matrix core team as their day job. When performing their SCT duties they do so as independent individuals rather than Element employees, and do a great job of separating the two.
> If New Vector does not like a competitor, they can block them from participating in the standard (making new features of them standards non-compliant) and then block them from using the Matrix brand or claiming to be Matrix compatible.
If that happened, the Guardians (and in future the Governing Board) would step in to fix the abuse. It's a checks & balances system.
> That should be enough for a full-time hire with competitive compensation for a few years, especially if that hire is not in California (why the hack hire in California when you don't need to?)
I am very glad that the Foundation hired a world-class Managing Director in the form of Josh, precisely to address the issues you've been highlighting, with a pretty much unique history and qualifications for managing non-profit open source foundations. That's why the hack we hired in California :)
EMS (New Vector Ltd.) is not the same thing as Element. It is the first-party SAAS offering of Element/Matrix. It would be like Terraform accepting donations, and paying Hashicorp.
That being said, it's completely plausible that this is salary for development time. Being tight-lipped about it is suspicious though.
Thank you for being a donor! Naturally, you can expect us to eventually publish an annual report that details revenue, expenses, and programmatic activities. At a high level, the payments to Element includes administrative services (accounting, legal, etc), operation of the matrix.org homeserver, and secondment of several personnel whose responsibilities include advocacy, program management, standards work, and trust and safety. The MSA also includes provisions for the Foundation to reimburse Element for any bills they pay on our behalf.
In terms of funding development, the Foundation's focus has mostly been on building open source trust and safety tooling since that is a gap that others haven't addressed.
Hi there! I'm the Managing Director of the Foundation. That owing balance is down to the many services for which we rely on Element.
The Foundation has a Master Services Agreement (MSA) with Element which includes administrative services, operation of the matrix.org homeserver, and secondment of several personnel whose responsibilities include advocacy, program management, standards work, and trust and safety. The MSA also includes provisions for the Foundation to reimburse Element for any bills they pay on our behalf.
Edit: Well, Josh is here so he will again start to deflect for some weeks and hope everyone will just forget about it until the next merry go round. sic