> There's a rough cost breakdown available to the Governing Board right now in Discourse, which we'll be polishing and publishing after our first Finance and Fundraising Committee meeting
So the financial report is finally coming together.
We have quite a handful of volunteers and a strong community that is helping us a lot already. But some things cannot be offloaded to volunteers (typically T&S and the SRE team running the matrix.org homeserver).
Can you expand on your doubts for the ability to execute? The Foundation has a narrow set of programs on purpose, and it's not implementing any server or client for example. Most of the budget is going to matrix.org and keeping it safe (which is a lot of invisible and thankless work).
Thank you for sharing that information. It seems like the foundation has been slowly moving in the right direction. I may have written a bit too harshly in my previous comment. I have been checking in on the development of Matrix, the Foundation, and monitoring that Github issue for quite some time.
Questions:
What is the narrow set of programs Matrix.org maintains? Is Trust and Safety referring to moderating the Matrix.org homeserver?
Are there strategies that could offload some of the homeserver hosting/moderation burden to community home server operators?
Are there strategies that could make the Matrix Conf closer to break even or perhaps even revenue positive?
Most importantly, how is the foundation protected and independent of its commercial sponsors? Currently 1/2 of the foundation's "Guardians", its top governance board, are from a single commercial entity. (I am profoundly grateful to Element for their past and continued support of Matrix and its operations, but as we have witnessed in other open source communities, having a single commercial interest having too much control can be disastrous over the long term).
I really, really hope Matrix succeeds in the long term. I am absolutely rooting for it.
> Can you expand on your doubts for the ability to execute?
I have faith that the foundation manages its finance properly. I believe the Matrix protocol (and ecosystem) is full of good, needed, ideas.
But the software produced by the foundation is simply bad. From the clients to the servers. In every single matrix threads, complaints about the UX or performance abound. Usually followed by people from the foundation saying it's fixed in X or 2.0. Or by fanboys saying it's not a real problem and wasting resources on UX is dumb.
That's been going on for almost a decade now. That's a clear demonstration of a lack of ability to execute on a good idea.
> But the software produced by the foundation is simply bad.
The foundation produces things like the spec and the e2ee libs. The last time the foundation produced a client was in 2015, and servers in 2023 - in both instances the wider community builds the implementations, just as W3C doesn’t make web browsers any more.
> Usually followed by people from the foundation saying it's fixed in X or 2.0.
Could this be because… it’s fixed in Element X or Matrix 2.0, perhaps?
I concur! Several of us also subscribe to your blogs' RSS feeds. If you're one of the nice people who put the full content of their blog posts into their feed, you might not see me as a visitor, but I definitely read and enjoy your blog.
As an occasional blog writer myself, I also like to announce manually on my social platforms I use (Mastodon and LinkedIn) when I blogged, and send a link to those socials post. The [full rationale is here][1]. They make it feel less like shouting in the void, which helps me stay motivated. I would be lying if I said I didn't enjoy the occasional likes and boosts I get from these, too :)
Simon Willison also has [good advice on how to write more][2], that I must admit I'm struggling to follow myself.
Figma has a paid plan that we're happy to pay for.
Penpot currently doesn't even have a paid plan anywhere. And their pricing page says that they are planning to offer paid tiers in a year (Q1 2025). A sibling post has answered some questions that they do have some VC funding, which is good. I was concerned about "how have they paid the bills so far, and how will they pay the bills until a year from now when they start charging?"
I've been burned in the past by open source projects that didn't grow enough to have a critical mass of skilled talent (Ember.js being a big one, finding talent was a supreme headache so we abandoned it after 5 years). So I'm always nervous now about "who is going to know this tool, and who is financially motivated to keep it vibrant and going" and also, "is it worth paying to have someone learn this skill if it isn't growing", all tradeoffs we have to make when picking tools/technologies.
We used Zola for https://matrix.org and it was an overall pleasant experience!
One major upside of Zola is that it's very stable, so you don't end up updating your dependencies every other day.
One significant downside is that Zola seems to be sometimes a bit creative with the slugs generation, which can generate slug collisions where there shouldn't be any. It's possible to override them manually though.
I find it very simple to use as a developer, but there are quite a few things happening behind the scenes to make the site itself faster to load for users (e.g. it inlines the CSS so you don't have to load a separate sheet).
The only downside of it is that it depends on a package manager.
That's a very interesting thread, because this is one of the major issues we have with Matrix. It's not directly a product but a (technical) protocol that can't be presented as such to the general public.
We definitely aim for Matrix-based products to be used by the general public, in the same way emails are. For this to happen, we need to be mindful of who our audiences are, what they are looking for, what they know and don't know, and how to deliver a message that works for them.
Indeed the documentation generally needs much more love. In an ideal world, every single page of the documentation would have a person in charge of keeping it up to date.
We're a rather small team on the Foundation side and lack the personpower to do so.
We're in the process of listing what documentation we need and what we need to update. This will be the foundational work to apply to Google Summer of Docs and for individual tech writers to apply to grants like NLNet (who doesn't usually fund "large" organisations like us) to help us out.
Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time.
This kind of article is super valuable since it gives us the perspective of a new user. I opened https://github.com/matrix-org/matrix.org/issues/2178 to translate the gripes mentioned in the issue into actionable items for us. I took action on the most urgent one (updating the Try Matrix page), but want to take the time to go beyond the surface symptoms and address the root cause of the other gripes.
On the Foundation side, we're a small but mighty team of four. The website is currently maintained part time by me and a volunteer who is doing an excellent job at it.
As I wrote recently in a blog post "Tracking what works, not people" (https://ergaster.org/posts/2024/01/24-tracking-what-works/), I would love to have the resources to conduct user research and user testing on the website but I unfortunately don't. We deployed privacy-preserving analytics to see where people drop and what confuses them. It's not nearly as good as proper QA and user testing, but that's what we can afford for now.
Overall I'm grateful to the author for documenting their frustration, and even more grateful for reacting constructively to our responses and integrating them in the blog post! One of the strengths of open source is to find and address issues collectively. I consider this blog post to be a good open source contribution.
If people around believe in our mission and want to help us with their brainpower, I invite them to join our "Office of the Matrix.org Foundation" room: https://matrix.to/#/%23foundation-office:matrix.org
For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.
Hi, hopefully things came across OK, for clarity I wasn't saying "why haven't they done this, they're bad at QA!?!?!" but just wanted to say that most of us should be doing the same kind of thing with our own products/tools/sites and give a shoutout to QA peeps.
Thanks for working on matrix, I'm building some things on matrix and it's been pretty interesting.
> For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.
Just wanted to add that I signed up recently and wanted my wife to sign up too. I managed to figure it out, but the article is correct. Even down to trying to figure out whether I should use Element or ElementX on iOS. I also realized that my wife would never figure it all out.
I think there are several things we can do improve, and the process should be fairly similar with Element:
1. Refine who the website is for, and what they are coming here for. We need to narrow down who our audiences are, what they want, what they known and don't know, and how we can best serve them.
2. Conduct user research with a diverse set of people representative of who we think our audiences are. We need to sit down with them, ask them to create a matrix account unguided, and ask them to comment what they are doing and how they feel about things.
One of the difficulties of the website is to find the right balance between not overwhelming the user with difficult decisions (picking a client? picking a server? I just want to chat with my friends!!) without being too biased. We need to be opinionated to guide newcomers through a decently simple process, but we need to leave room for all the vendors to thrive.
> T&S staffing alone is about $360k/yr, and server and SRE costs about $240k/yr
And per https://matrix.to/#/!sWpnrYUMmaBrlqfRdn:matrix.org/$pupglsTX...
> There's a rough cost breakdown available to the Governing Board right now in Discourse, which we'll be polishing and publishing after our first Finance and Fundraising Committee meeting
So the financial report is finally coming together.
We have quite a handful of volunteers and a strong community that is helping us a lot already. But some things cannot be offloaded to volunteers (typically T&S and the SRE team running the matrix.org homeserver).
Can you expand on your doubts for the ability to execute? The Foundation has a narrow set of programs on purpose, and it's not implementing any server or client for example. Most of the budget is going to matrix.org and keeping it safe (which is a lot of invisible and thankless work).
reply