> At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it:

> At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it: Wayland is 15 years old and it's written in C. I'm waiting for a rewrite in Rust or whatever, so in 15 years I will still be using X11, because it's the only thing that works reliably across my devices, old and new. > Have you ever tried to play with the X11 C API yes, since 1996. > and find 40 years of workarounds that's called "SOLUTIONS" in professionals' World. The real World is full of edge cases, if your code is dealing with none of them, your solution is probably fragile. https://www.luckymethod.com/2013/03/the-big-redesign-in-the-sky/ https://www.luckymethod.com/2013/03/the-big-redesign-in-the-... > Software should not get into this stage and still be massively used in production > We should avoid projects like X.Org from becoming the next COBOL. That's the wrong way to look at it. We should ask ourselves: why COBOL is still in use after so long, while a JavaScript framework lasts 6 months and it's deprecated after 9? Can I rely long term on that thing or not? If I had to guess, COBOL will still be in use in 20 years from now. The demise of old technologies has been predicted so many times that it's now a joke in the industry. COBOL was already old and on its way out when I was in high school, studying those languages that would SURELY replace it, in the beginning of the 90s of the last century, almost 35 years ago. I understand that a young industry, that mostly runs on young people because of the ageism in SV, feels it can fix everything in a few months, but that's the illusion: we collectively can't. The more a technology stays in place, the more time it will stay relevant. There's also a law about it, I don't remember the name now.