As a Ruby developer its sometimes hard to know if a particular Gem is still being actively maintained or if there is a better, more recent alternative. I find that Github does an outstanding job solving both problems. If there haven't been commits in the last year (6 months?) I'll generally look elsewhere. That elsewhere is generally the "Network" page. :)
Y'know, there are some projects that haven't had commits for a while because they do exactly what they're supposed to do, and don't need a bunch of commits. I consider it a good thing when a project gets to the point where nobody can find any bugs and they stop adding features because it has enough of them already. I sure as hell don't want my quick, clean, elegant, productivity enhancing window manager to turn into a featuritis infected monstrosity like OpenOffice.org, after all.
---
edit: Actually, my window manager of choice has basically been abandoned by its developer several years ago, and it's still bug-free, stable, and lacking basically nothing. I finally came up with a feature enhancement I'd like it to have today, after using it for five years with no complaints or wants -- and that enhancement is really just an improvement of an existing feature.
More to the point, it's an enhancement that no window manager has, so I'm likely to need to write the code for this feature enhancement myself if I want it badly enough. I may pick up maintainership for the project to do just that.
Think about that a moment: one feature enhancement requested in have a decade, merely an extension of an already existing feature, and it's something entirely new to window managers as far as I'm aware. This thing has had no need for additional code in all that time, and it has been better as a result of all that.
As a ruby dev, this happens to work (for better or worse) because if you're not updating, it may not work with the latest version of ruby/rails/whatever. If I see a rails-related gem that had its last commit in 2009, I know some work probably needs to be done to make it work with rails 3.
Perhaps a better metric is the most recent commit combined with the number of open issues. Or maybe just the number of open issues, judged by their severity.
It varies, re: Ruby, moving from 1.8 to 1.9 (the latter of which is basically the difference between major versions, though for some reason they aren't calling it 2.0). I think things are worse in this regard for Rails than for Ruby.
Not really. Your example -- keeping up with underlying technology upgrades -- may not even require as many commits as the number of upgrades to the underlying technology version. Especially if the software is well-written without unnecessary "cleverness", software can often survive upgrades to the underlying technology without issues.
Sometimes, such changes do need to be made, though; sometimes, you have at least part of a point. On the other hand, those changes might consist of a flurry of commits every time the underlying technology's version bumps, and the project may appear dormant the rest of the time. Some might think it's a "sick" project because it only gets updates in groups every now and then, with three, six, twelve, or even eighteen months between such flurries of updates (depending on the underlying technology), but they very well might be wrong.
It's unlikely you'll find it in the software management system of your Linux distribution of choice, and (being not very experienced with C) I haven't managed to get it to compile on Debian -- but it's in FreeBSD ports, and has no problems at all on that platform. Given that FreeBSD is my platform of choice, that means it works for me.
This feature bloat is exactly my issue with a lot of commercial software - especially Photoshop. With each release, it includes a load of junk most people don't want, but new ways to make files incompatible with old ones so that people have to upgrade, as well as bug fixes that should in reality have got patches.
Window managers (including tiling ones) are so far from a dead end in research and potential large improvements, that I think that if you can't think of anything useful that any of them does not yet do, you must be unimaginative.
That problem is alleviated by the fact that, for libraries, updates to documentation are commits as well, so even a very stable piece of software still needs the occasional commit to update a FAQ or somesuch. All in all, I've been surprised how well activity meters work when vetting software.
Even that doesn't always apply. The amount of documentation available for my favorite window manager on the (ancient) site for it is mind-boggling. The creator labels the documentation as "comprehensive" and, to quote Bill: "Baby, you ain't kidding."
For most software, though, it's true that documentation can always use improvement.
