Financial situation of the Matrix.org Foundation
github.com
github.com
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
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.
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.
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.
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?
[0]: "what the hell is this? We have burnt a bunch of time investigating this and trying to help you on this today, and in return we get slagged off on twitter?!" https://github.com/matrix-org/synapse/issues/14481#issuecomm...
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.
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?
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.
Fixing fundamental basic functionality of your app should not be classified as having "burnt a bunch of time investigating this".
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?
Matrix and Element are consistently one of the buggiest messaging applications I interact with, and I've waited years for it to be better.
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.
I think all those issues can be addressed, I wouldn't throw the baby out with the bath water.
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.
Needlessly aggressive tone from you…
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")
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?
I agree that none of those rules are 100% crisp and there's room for smudginess.
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.
https://github.com/matrix-org/matrix-spec/issues/571#issueco...
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
ad astra per aspera
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.
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.
More details and context in my official reply: https://github.com/matrix-org/matrix-spec/issues/571#issueco...
I would rather have them use the small amount of money they have on developing Matrix rather than explaining where each coin went.
This comment seems relevant: https://github.com/matrix-org/matrix-spec/issues/571#issueco...
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.
https://github.com/nextcloud/server#contribution-guidelines-
>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>)
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.
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.
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.
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.
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.
That being said, it's completely plausible that this is salary for development time. Being tight-lipped about it is suspicious though.
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.
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.
FYI The Matrix foundation is not a 501(c)(3), it's not even registered in the US.
[1] https://find-and-update.company-information.service.gov.uk/c...
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.
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.
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.
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 :)
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.
People think running a non profit is easier but its much more difficult considering external, anonymous stakeholders.
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.
More details and context in my official reply: https://github.com/matrix-org/matrix-spec/issues/571#issueco...
Happy to address any other concerns or questions you may have.