Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

> The “classic” ligature issue.

We try to make our terminals do things no terminal (remember those boxes with a CRT that used to be in a room, then became ubiquitous enough to end up on our desks) ever did, or considered doing. Do I enjoy being able to partition a window without needing tmux? Yes. Do I like text reflowing when I resize the window? Sure. Do I find Tektronix mode useful? No. Do I find it fun? Of course!

We all are passionate about some thing or another (I, for instance, maintain an IBM 3278-2-like terminal font), but I have to agree that, when someone says my suggestion for adding smooth scrolling or double width/height attributes to VTE (I promised to add Tek support to it, but, like so many other side projects, I didn't have the time to start it) is niche or, worse, a Terrible Idea, they are not doing that out of cruelty, but from a position of "I'll have to maintain this idea only you like forever", and, in their place, I'd probably do the same (as I have in the past with `pip-chill` (another thing I maintain), when I think an idea is not great).

OTOH, from the other side, I'd love to see https://github.com/urwid/urwid/pull/434 merged :-(

And, of course, having https://github.com/htop-dev/htop/pull/736 shot down was disappointing, but understandable.

The Rust library ecosystem is small but they tend to be high quality IME; this is a drawback of it I suppose.

As I maintainter myself, I completely disagree. It's a fair complaint that everyone contributing to open source will eventually suffer from.

> Please don't ever post things like this.

What the hell, is this against any HN policy? Or you think no one should post their point of view here if it's against yours?

EDIT: I think it's important to note that burnout is a result of you having an issue within yourself (at least in the context of voluntary projects), it's not something others do to you... you can choose to ignore all pull requests, for example, or say in your README that you won't accept any (I've done that myself to projects I wanted to keep in a certain "permanent" state for reasons). If you choose to engage in discussions, that's your call.

Nope, sorry. Maintainers are not above criticism just like anyone else, and this post did so in a respectful way. It’s a real problem and e.g. the reason we have stopped trying to upstream any fixes to OSS libraries at work - it’s in no way worth the effort to jump through these hoops, take our bugfix or leave it.

I am judging it by the comments.

I have been on both sides of this situation over the years, but it was never too extreme.

On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author.

On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better.

Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve.

The freedom with open source always should go both ways.