In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
"Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version."
I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
Never heard of CADT before, but I have to admit that I've had experiences like this for sure (as the bug-reporter, not as the developer thank goodness).
I think we see that in all software projects.
It is usually more fun and maybe even easier to redesign than to fix.
I prefer to think of it as "aggressive refactoring" - which is not necessarily bad.
I think the process of software maintenance (in the context of KDE development) could be much improved if their reporting process had less friction and collected more relevant information so that the turnaround would be faster.
It is usually more fun and maybe even easier to redesign than to fix.
I think that there are interesting exceptions. For instance, the *BSDs are sometimes maddeningly conservative. But if you have last used FreeBSD 5.0 or OpenBSD 3.0, you are up and running on the latest versions in no time.
I hadn't looked at FreeBSD for years. Tried the latest version 6 months ago or so and configuration was pretty much the same as 10-15 years ago. There are new cool features (ZFS, bhyve), but it is all logical UNIX.
Or if you want to see a funny image, click this link: https://www.jwz.org/doc/cadt.html
If you're easily offended, google instead for "Cascade of Attention-Deficit Teenagers".