Modern XMPP project discussion - 2025-06-05

Wrong chat ✏

erebion, lets not spread foss bro stuff here please. > But it's FOSS, so people can just do what they want. people can not "just fork it" for many reasons.

By the multiple forks that exist, evidently people can

Not all people, no, but it's not impossible, unlike with proprietary software

from what Kris said the forks are abandonded often it seems. So technically they fork, practically nobody has been able to maintain said fork for more than a few months. so we are streching the "can" here 😋️ > Dino+ seems to be abandoned again.

Yeah, they made a statement in the chat a while ago that they are not going to maintain it

Regarding the earlier conversation (which I had missed because, ironically, my primary XMPP client got disconnected from the chat) - it's okay to have negative opinions about XMPP software, but it's not okay to extend such statements to creators. It's not how to foster an ecosystem of software and developers that improves through collaborative efforts.

I agree this person was likely just trolling - I think there is a difference between constructive feedback and insults, and this was the latter, designed to be provocative and trying to make people feel bad. It's not acceptable behaviour here.

> from what Kris said the forks are abandonded often it seems. So technically they fork, practically nobody has been able to maintain said fork for more than a few months. so we are streching the "can" here 😋️ > > Dino+ seems to be abandoned again. What some people tends to forget is that maintaining a project for years is a lot of work and maintainers often decide to not do something because it will create a lot of trouble and maintenance in the future. I made some choices in Movim exactly for that and choose to not integrate some features if I didn't had a simple and clean way to handle them. ↺

So I don't know for the Dino+ thing, but sometimes a PR is not enough to make the original maintainers happy and willing to integrate the stuff in the master branch.

A feature PR is basically "here, I did that, please put it in your project and then maintain it yourself because you're responsible for it".

Still, PR are nice, please do PR <3

> A feature PR is basically "here, I did that, please put it in your project and then maintain it yourself because you're responsible for it". yeah the "lone developer" culture sucks ☹️ ↺

I'd love it if some of my projects weren't "lone developer" projects, but it's not that easy :)

The alternative is that I simply don't publish the code for smaller projects, and I have leant more towards that in recent years due to various negative experiences I've had from publishing

Well I'd say FOSS is mostly composed of these smaller projects. The big ones are the tip of the iceberg really and expectations towards these smaller projects are generally the same as they would be for the bigger ones. So yeah it sucks :/

It's tricky, because I agree that many projects don't pay enough attention to users (from accessibility needs to simple UX and design consideration). There are a variety of reasons for that, a big one is simply that the project is started by developers to scratch their own itch, and they simply don't have a clue where to begin with the non-code aspects of making good software (and so many projects even have poor code quality, not even getting that right). But then there are these smaller projects, which I really think can't be held to the same standards.

If I have a problem one weekend, and I write some code to solve it, I have traditionally felt that it was a net positive for everyone if I published that code freely. Maybe it's useful to nobody in the end, but if it even helps one person, that's good, right? Maybe it could become part of a larger project one day.

But in reality, I've experienced demands from people saying I didn't think of their needs, I didn't package it for disto X, Y or Z, or asking why I haven't written docs, or merged some patch or other, and so on. A small number of these have been exceptionally impolite, and at one low point many years ago I almost took everything offline because I couldn't handle the stress. Developer burn-out is real, and I think it's unfair to make demands.

I've thought about it a lot, and all I can conclude really is that projects should ideally be clearly labelled to set expectations correctly from the start

"This project aims to develop accessible inclusive software for <X>", vs. "This is a weekend project I hacked together and probably won't touch again. Use the code, but please don't send patches or ask for anything more that what is presented here."

I think there are valid reasons for a project to not accept some/any outside contributions, it's that project's choice, and I understand there are reasons for it to be that way. I don't think such projects should be shamed for making that choice, but ideally they make it explicit so that people don't waste their time making contributions.

completely agree and i feel like there are also unrealistic timelines a lot of the time. which AI will probably make it worse

the thing i was alluding to is that often developers after they left that small project stage, don't reach out to share the burden of developing the software. or don't have direct feedback with all the people that actually develop the app but it is just developers and BDFL and that is it. which makes sense culturally because we have a lot of "code speaks" and "one person owns everything" in foss

Speaking of which, AI is another reason added to not simply have free-for-all open contribution :/ (we've already had attempts to contribute to prosody with LLM-generated code)

> from what Kris said the forks are abandonded often it seems. So technically they fork, practically nobody has been able to maintain said fork for more than a few months. so we are streching the "can" here 😋️ >> Dino+ seems to be abandoned again. I prefer software maintainers rejecting patches they don't like over software they don't know to maintain and that might be a convoluted mess. I like that the GNOME maintainers make a lot of intentional decisions, even though I don't use GNOME, but I like reading their blog. ↺

> "This project aims to develop accessible inclusive software for <X>", vs. "This is a weekend project I hacked together and probably won't touch again. Use the code, but please don't send patches or ask for anything more that what is presented here." Maybe repos should just contain an EXPECTTHIS.md that summarises the intentions of the authors. ↺

> I prefer software maintainers rejecting patches they don't like over software they don't know to maintain and that might be a convoluted mess. I like that the GNOME maintainers make a lot of intentional decisions, even though I don't use GNOME, but I like reading their blog. sure. but that also misses *a lot* of "it depends" here. but we are going off topic so i will take it elsewhere 🙂️ ↺

from my personal project experiences there are a lot of reasons why i cant/want to work on a MR

reviewing and directing the person so the MR is actually mergeable, can be a lot of work

if the MR is for some kind of feature i dont even use as a developer or have no personal interest in, then its even harder, reviewing and thinking about this becomes then basically unpaid work, it does not even fall into the category "hobby" because im forced to think about code i have no personal interest in

i would do this if my company forces me to do this because that how i make my money, but doing this on your personal time, takes effort

usually in companies they have dedicated people for different features of the software

this will not end aslong as every developer starts from scratch to write their own thing

instead of joining an existing project

> instead of joining an existing project There should be a good enough project to join first

If i disagree with at least some of the decisions of every project there currently is then there are no projects i can join

In that case of course start your own.

Everyone disagrees always with something. That's normal. Unrealistic that it will ever change

alexkurisu: if things don't go exactly they way you want you leave?

I mean I can understand if major things are not on line, like I will not join a web project of I cannot write web code

Also, most of current XMPP clients are chat apps, but i want an *XMPP client*, not another chat app

But if I join a project and want to implement 10 things but can only agree on 5 with the maintainer, I would do that and try to convince them another day

Obviously if the thing you don't want does not exist you cannot join a project. But for example there is no reason to write yet another android xmpp messenger

> Obviously if the thing you don't want does not exist you cannot join a project. But for example there is no reason to write yet another android xmpp messenger There is. Conversations does not accept PRs, AFAIK

Yeah and? What about the other 5 clients?

They are either very dead, also don't accept PRs or unusable without a full rewrite

Then rewrite them slowly, Gajim is 20 years old and probably every code lone has changed multiple times

At least if the project has users

I agree if a project has 0 users, you may start new

But I rather take over a project with 100 active users and improve it, than start new

Most developers underestimate how much work a full featured client is, most of the way to getting there you have almost no users which further make it harder for you to even get the motivation to improve it

Also if you have users, chances are high one of them joins you in developing

but dont take this as critisism, i can just tell from my experience, if Gajim had 5 users, i would have dropped developing it a long time ago

and if i would start a new project, i would fear never getting to that point where the client is good enough so users even start to using it

> hook is slowly massaging people from Matrix to XMPP, mostly via YunoHost (putting some optimism back into this chat) 👍 ↺

> Also, most of current XMPP clients are chat apps, but i want an *XMPP client*, not another chat app what's the distinction between chat app and xmpp client? ↺

I imagined something like an sql browser but xmpp. 🙂

Gajim with only the XML console? :D

BTW, does the GFW of China block BOSH? I've just been asked by someone, I think he's looking for a way to talk to his parents in China.

Does anyone know that by any chance?

one moment, i call Xi

XMPP on port 5223 is easy to recognise, but small packets on 443 should be more difficult to distinguish from HTTPS, right?