4 ms·

It won't surprise you that to improve a product, you need people working on it. In a capitalistic society you need to pay them to do that. Telegram sits on the

by rakoo 4y ago

It won't surprise you that to improve a product, you need people working on it. In a capitalistic society you need to pay them to do that. Telegram sits on the billions of its founders and doesn't need to make revenue, they have money. What company with an infinite supply of money (and, thus, developers, managers, QA, interviewers) are building a Matrix client and can afford to have as many people working in it ?

Arathorn 4y ago
Element funds a lot of Matrix work, and we have a large team working on both Matrix, Element clients, Matrix hosting, and our various customer projects (around 100 people). And while Element has taken longer than I’d like to improve in terms of UI/UX, it is definitely getting there - cf https://element.io/blog/an-unrecognisable-improvement-elements-new-design-is-here/ https://element.io/blog/an-unrecognisable-improvement-elemen... etc.
- rakoo 4y ago
  Oh, I didn't mean to say no one is working on the Matrix ecosystem. The reason Matrix is where it is today is thanks to you guys. But I don't think you can say you have as many resources and as many people working on it as Telegram, and you're solving a problem 10x more difficult than what Telegram does.
nikitaga 4y ago
Of course, I see that. But open source projects routinely manage to meet technical expectations while failing specifically at meeting UI / UX expectations. That makes sense for unfunded projects because most developers are not good designers, and designers don't have a culture of contributing to open source, but for a project that pays (some of) its developers, it's their choice how much to pay developers vs designers vs managers, and they are responsible for the way in which they allocate their limited resources. I recently had to move my open source project's chat from Gitter to Discord, not because we like Discord or "don't care about open source" but because everyone is so damn tired of Gitter's terrible UX that it became the overriding concern. Matrix bought Gitter two years ago, and I kept waiting, hoping that they would improve it, but they did literally nothing to it except connect it to Matrix within a couple months – and even that doesn't work well, with Matrix users still unable to respond in threads. I assume there is a good reason for that. I'm not here to judge, only to point out that this "good reason", whether it's lack of funding or priorities or whatever – won't change anytime soon, so I won't be holding my breath anymore.
- Arathorn 4y ago
  > I assume there is a good reason for that. We spelt out the good reason in the original blog post: https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matrix https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matri... > However: in the medium/long term, it’s simply not going to be efficient for the combined Element/Gitter team to split our efforts maintaining two high-profile Matrix clients. Our plan is instead to merge Gitter’s features into Element (or next generations of Element) itself and then - if and only if Element has achieved parity with Gitter based on the above list - we expect to upgrade the deployment on gitter.im to a Gitter-customised version of Element. The inevitable side-effect is that we’ll be adding new features to Element rather than Gitter going forwards. We’re almost at the point of being able to switch Gitter over to being a branded Element.

by rakoo 4y ago

Arathorn 4y ago

Element funds a lot of Matrix work, and we have a large team working on both Matrix, Element clients, Matrix hosting, and our various customer projects (around 100 people). And while Element has taken longer than I’d like to improve in terms of UI/UX, it is definitely getting there - cf https://element.io/blog/an-unrecognisable-improvement-elements-new-design-is-here/ https://element.io/blog/an-unrecognisable-improvement-elemen... etc.

rakoo 4y ago
Oh, I didn't mean to say no one is working on the Matrix ecosystem. The reason Matrix is where it is today is thanks to you guys. But I don't think you can say you have as many resources and as many people working on it as Telegram, and you're solving a problem 10x more difficult than what Telegram does.

nikitaga 4y ago

Of course, I see that. But open source projects routinely manage to meet technical expectations while failing specifically at meeting UI / UX expectations. That makes sense for unfunded projects because most developers are not good designers, and designers don't have a culture of contributing to open source, but for a project that pays (some of) its developers, it's their choice how much to pay developers vs designers vs managers, and they are responsible for the way in which they allocate their limited resources. I recently had to move my open source project's chat from Gitter to Discord, not because we like Discord or "don't care about open source" but because everyone is so damn tired of Gitter's terrible UX that it became the overriding concern. Matrix bought Gitter two years ago, and I kept waiting, hoping that they would improve it, but they did literally nothing to it except connect it to Matrix within a couple months – and even that doesn't work well, with Matrix users still unable to respond in threads. I assume there is a good reason for that. I'm not here to judge, only to point out that this "good reason", whether it's lack of funding or priorities or whatever – won't change anytime soon, so I won't be holding my breath anymore.

Arathorn 4y ago
> I assume there is a good reason for that. We spelt out the good reason in the original blog post: https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matrix https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matri... > However: in the medium/long term, it’s simply not going to be efficient for the combined Element/Gitter team to split our efforts maintaining two high-profile Matrix clients. Our plan is instead to merge Gitter’s features into Element (or next generations of Element) itself and then - if and only if Element has achieved parity with Gitter based on the above list - we expect to upgrade the deployment on gitter.im to a Gitter-customised version of Element. The inevitable side-effect is that we’ll be adding new features to Element rather than Gitter going forwards. We’re almost at the point of being able to switch Gitter over to being a branded Element.