[Airblader]

I see your point (in general terms). But I think people tend to overlook the hidden costs of optional features in terms of maintenance and complexity (in code, documentation, and for users).

In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. It's easy to add a feature, difficult to maintain it, and impossible to remove it.

[secure]

Yup! We even have an FAQ entry on the reasons for not merging features without careful consideration: https://faq.i3wm.org/question/778/why-is-patch-not-merged-an...

Also, saying “it’s not that many lines of code” comparing the before and after state is too simplistic: it doesn’t include the cost of changing the existing code into the desired state, which can be a significant effort, even if the number of lines doesn’t differ much before and after. See https://github.com/i3/i3/pulls?q=is%3Apr+author%3Astapelberg... to get an impression of how much work it was to merge gaps.

[mtlmtlmtlmtl]

I'm impressed with your complete lack of snark in response to my asininely snarky comment, edit or no. I went from thinking you're a bad maintainer to thinking you're one of the more level headed ones I've interacted with. I feel like there's some kind of lesson here about Bayes' Law.

I never used i3 much beyond trialing it for embed stuff(went with dwm). I'm too much of a Lisp nerd not to use StumpWM. I like the fact that your stumpwmrc is essentially just a live patch for your WM. You can redefine arbitrary functions, classes, variables, define commands with arbitrary code in them. And you can patch the WM while running via Emacs.

How is i3 support for more obscure unices like OpenBSD, Illumos etc? StumpWM is kind of a pain to get working after they dropped support for all compilers except sbcl...

And I agree completely general in about the tradeoffs of adding features.

It's tough to do, though my philosophy in this specific case is also that customization is a core feature of any good tiling WM and should be priorited almost above all, except performance and minimalism.

[Airblader]

I can promise you that in a decade of doing this, I've made my fair share of mistakes as a maintainer. There's a learning curve to everything, and maintainer burnout is a real thing, too.

i3 should definitely work on BSD, there are a few awesome folk that regularly send patches when we broke something. I don't have experience with it myself though.

[mtlmtlmtlmtl]

Naturally, the best maintainers are those that are humble enough to learn from their mistakes. And maintainership is just hard, way harder than writing code IMO. You have to have and defend a vision for the project, and yet not be so staunch as to scare off the many users and contributors you depend on. You can't be everybody's best friend; sometimes you really do have to give a list of 18 different bugs in a 10 LOC PR, and yet somehow try to do it without completely disheartening someone who means well and wants to learn. And then on top of all that diplomacy you still have to dig down and figure everything out when a particularly nasty regression slips through the cracks.

I know I couldn't do it worth a damn, just thinking about it gives me an ulcer.

One other maintainer who I admire is Greg KH, maintainer of the Linux stable branch. 15 years ago I sent him this absolutely useless patch cleaning up the code style of a driver that was marked to be deleted and rewritten from scratch. 15 year old wannabe kernel hacker just finished his first read of K&R and wants to go straight for the damn linux kernel next.

In his reply he not only thanked me for what was basically a waste of his time, explained why there was no point taking the patch, then he went and reviewed the patch anyway! This was at least a couple kloc, and he voluntarily wasted even more of his no doubt precious time to teach me a few more things. He even responded to a follow up email asking for reading material. I'm not sure how he does it. My main hypothesis is Greg KH is secretly the identical triplets Greg, Karl and Harold and they're somehow all kernel maintainers.

That interaction, while just one in hundreds he engages in on any given day, to me was oddly enough life-changing. It let me know I was overreaching to an absurd degree, yet also inspired me to keep learning(big deal for a 15yo). And I did end up becoming a capable low level C programmer, doing some of the best work of my career in embed stuff during the brief windows my health has allowed me to be productive. It also helped me accept that I'm just not cut out for hacking on the kernel, which is fine, almost no one is.

[secure]

OpenBSD packages i3: https://openports.se/x11/i3

I briefly (for about a year or so) developed i3 on NetBSD.

I have no knowledge of other more obscure variants, though.

[sophacles]

> In i3 we have always tried to weigh benefit against cost. We also really care about compatibility.

Thank goodness for this. I would say you've succeeded at those goals - sometimes I go deep into tinkering and other times I am focused on something else. i3 is on the short list of software that I can tweak to my liking and then ignore for years without concern that my environment will mysteriously break from an update. I really, really appreciate that, kudos.