A roadmap and appeal for help from The Matrix.org Foundation
1–10 of 32 posts
Re: A roadmap and appeal for help from The Matrix.org Foundation
#2> Otherwise, we need to start scaling back programs and staff starting January 2025.
They've already done so. 2023 saw a (rather extensive) wave of layoffs, and a reduction in scale.
Part of the issue is that Matthew is not the best communicator, which isn't great for fundraising. That being said, Josh isn't off to a strong start, either.
Somehow, neither of them managed to spin the Apache -> AGPL move for Synapse as a good thing, despite it pretty transparently being better not only for the ecosystem, but for users. No freedom is lost from the perspective of a user of the software with the switch, as Apache isn't copyleft.
The CLA is unfortunate, and a less controversial strategy would have been to emulate Trolltech's "If we become a bad actor, we're legally compelled to release the source under a permissive license" approach to CLAs.
Further, the wording of docs around the CLA is really scummy, even if unintentional.
> Everyone is welcome to contribute code to Synapse, provided that they are willing to license their contributions to Element under a Contributor License Agreement (CLA). This ensures that their contribution will be made available under an OSI-approved open-source license, currently Affero General Public License v3 (AGPLv3).
It's hard to see this as short of deliberately misleading. For developer trust, they should have just said transparently in the paragraph that they needed it to sell AGPL exceptions. The wording of the CLA itself is pretty bad, though I'm sure the lawyer responsible thought it was clever.
> Element shall be entitled to make Your Contribution available under Element’s proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSI-approved open-source license.
This offers no protection against Element dropping open source entirely the next time they hit a "budget crisis." Your Contribution will be safe in the archived version, but there's not even a guarantee that your attribution will be kept with the OSI license they choose to relicense your commit to upon subsequent releases, and this will still be within the legal rights of Element. The only thing you need to do to fulfill availability requirements for the Simplified BSD License is to put the copyright notice in the binary.
Regardless of the technical merits of the platform, or lack thereof, the consistent failures in communication constantly make it feel like things are going to implode, and it seems like every time an adjustment for sustainability needs to happen, the Foundation drives itself directly into a ditch in terms of communication and outcomes. Even assuming good faith, which is fair, given the middle-upper class salaries of the Foundation members, they consistently choose to take the options that look like they're acting in the worst faith, both from a comms standpoint and an outcomes standpoint.
I don't get it.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#3I've made some money making apps for others using Matrix and contributed a portion of my profits back to them
Hope they can keep going, it is really useful technology.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#4I like matrix as much as anyone else around here, and I would like to see it survive and prosper. That being said, if over 60% of the annual “expenses” of your nonprofit goes to “management” covering the salaries of four people who have other full time jobs, you really need to do a better job at managing finances.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#5I like matrix as much as anyone else around here, and I would like to see it survive and prosper. That being said, if over 60% of the annual “expenses” of your nonprofit goes to “management” covering the salaries of four people who have other full time jobs, you really need to do a better job at managing finances.
Despite having been fairly critical of the Foundation elsewhere in this thread, I have to point out that this comment is wrong.
Josh is full-time employed by the Foundation, without another job.
It does seem pretty odd that they presented their expenses being just two million short of the PSF's expenses as useful for "putting things in perspective," given how much larger in scope the PSF is, especially after the cuts the Foundation made last year, however.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#6Bit of a tangent (though it is directly mentioned in TFA), does anyone knows why Signal spends 1.3M/yr on data storage?
I understand that it's probably the result of a massive amount of requests/transactions done with a cloud provider, and the actual storage needs are probably pretty low given the ephemeral nature of their system.
But at what point does it become financially irresponsible to not run baremetal?
Re: A roadmap and appeal for help from The Matrix.org Foundation
#7They open-cored Synapse. I guess Element needs money, so they're crowdfunding. It doesn't take long to see that the open protocol is pretty geared towards Synapse/Element. By the way this is out of date: https://matrix.org/ecosystem/servers/ It says Apache 2, but if you click it, it goes to an archived repository, and if you click the link in the README to the new repository, it's under AGPL. That would be community-driven and all if they wanted to use it, but it's another case of AGPL for thee, but not for me.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#8> Otherwise, we need to start scaling back programs and staff starting January 2025. They've already done so. 2023 saw a (rather extensive) wave of layoffs, and a reduction in scale. Part of the issue is that Matthew is not the best communicator, which isn't great for fundraising. That being said, Josh isn't off to a strong start, either. Somehow, neither of them managed to spin the Apache -> AGPL move for Synapse as…
I think I don't mind the license change but I'm never contributing code or money to anything with a cla.
I have been burned in the past and I have zero interest in contributing anything that will end up in proprietary code.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#9Bit of a tangent (though it is directly mentioned in TFA), does anyone knows why Signal spends 1.3M/yr on data storage? I understand that it's probably the result of a massive amount of requests/transactions done with a cloud provider, and the actual storage needs are probably pretty low given the ephemeral nature of their system. But at what point does it become financially irresponsible to not run baremetal?
> But at what point does it become financially irresponsible to not run baremetal?
At the point where hosting is part of your value proposition, to the point that you can do significantly better than commodity managed hosting (either because there is something about your use case that allows vertically integrated hosting to outperform, or you're becoming a hosting company). 1.3M of off-the-shelf hosting sounds a fair way short of that to me.
Re: A roadmap and appeal for help from The Matrix.org Foundation
#10Bit of a tangent (though it is directly mentioned in TFA), does anyone knows why Signal spends 1.3M/yr on data storage? I understand that it's probably the result of a massive amount of requests/transactions done with a cloud provider, and the actual storage needs are probably pretty low given the ephemeral nature of their system. But at what point does it become financially irresponsible to not run baremetal?
Good question. https://signal.org/blog/signal-is-expensive/ says:
> When you send a message, the Signal service temporarily queues that message for delivery. As soon as your message is delivered, that small bundle of encrypted data (i.e. your message) can be dropped from the queue. The storage of end-to-end encrypted files is temporary too, and any undelivered end-to-end encrypted data is automatically purged after a period of inactivity. Even though everything is only temporary, this storage still costs Signal around $1.3 million dollars per year.
I assume they're probably speaking honestly, and have no reason to investigate (since I don't use it). But if you were doing a critical analysis, I guess you could consider that, for $1.3M/year, one could also store a lot of "metadata" for later traffic analysis, social network mapping, propagation tracking, etc. It'd be tickling to think that fact could be hiding in plain sight the whole time, in invoices and accounting disclosures.