When I went looking for unit testing frameworks, I was answered by more than one people (just Tester publicly though), that I shouldn’t care even if there are no new releases of check or cunit, that as long as they do what they have to, it’s normal they don’t get developed. Sincerely, I don’t agree: projects that don’t get maintained actively start to bitrot.
On a related note, I always find it quite intriguing when you can apply organic concepts to software, like bitrot and softdiversity. It mean that even human creations of pure logic abide to laws their creators didn’t explicitly take interest in.
Anyway, the bitrotting process is very natural, and can easily be seen. If you try to use and build the sources of a project written ten years ago or so, it’ll be very difficult for you to. The reason is that dependencies evolve, deprecate interfaces, improve other interfaces, tools also change and try to do a better work, reducing the chances for users to shoot themselves in the feet and so on. Even a software written using no additional dependency but the C library and the compiler will probably not work as intended, unless it relies purely and squarely on standards and it was written so that each part of the code was 100% error-free. As you can guess, it’s an inhuman work to make sure that everything is perfect and it’s rare to provide such a certainty.
But it’s not really limited to this: software is rarely perfect as it is, but hardware also evolves. Software written with a clear limit on the amount of memory to use, used on a modern system is going to be suboptimal; software written for a pure sequential execution, is not going to make proper use of modern multi-core systems. Software features also improve, and you obviously want to make sure that you make the best use of the software so that your performance don’t get hindered by obsolete techniques and features (think of fam versus inotify).
Sometimes bitrotting attacks also very commonly used tools, like strace, and just sometimes they get taken over, like dosfstools. Some other times, the bitrotting attacks more the buildsystem and the syntax part of the code rather than the actual code behind it, like it’s the case for FooBillard (which if I’ll ever have spare time, I’ll import in git and fix up — it’s the only game I actually would like to play on Yamato and I cannot because it doesn’t build here).
But bitrotting does not stop at complete complex software projects, it also applies to small things like ebuilds: a lot of ebuilds I filed bugs for are broken because nobody tended to them in a lot of time: the compiler got stricter and they didn’t get tested. While Patrick did already a few sweeps with his tinderbox on software for the stable tree, there were and still are lots of packages in ~arch that didn’t get tested, and so I’m getting to fill bugs related to glibc 2.8 and gcc 4.3 once again. But it’s not just that, mistakes in DEPEND/RDEPEND variables, problems with ebuilds not using die to terminate on failure, and so on.
There are of course problems with other things, like packages that don’t use slot dependencies yet (and let’s not even start about use dependencies that were introduced so recently — by the way should this mean I can finally have my cxx, perl and python USE flags turned off by default?), but those are quite limited. Instead, I found that the problem with -O0 building that I found quite some time ago is not that common, although I admit I’m not sure whether that’s due to more packages actually knowing to include locale.h or if it’s just that -O0 is not respected.
Hopefully, one day these sweeps will be so common that the glibc 2.8 problems would be found and reported in the first week of entering portage, so that the developers are also fresh enough to know how to deal with those errors. On the other hand, after I’ll be done with this and I’ll have enough free time (since I’m also working on lscube, and FFmpeg, and so on), I’ll see to fix the packages in maintainer-needed for which I reported bugs, it’ll help direct people to the right thing to do, I hope.