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.
Comments
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.
> If you're not updating, it may not work with the latest version of ruby/rails/whatever.
Do Ruby/Rails/whoever often have releases that break backwards compatibility?
Some gems don't function correctly with Ruby 1.9.1, and a lot have minor issues with Rails 3.
Although sometimes it's more an issue with the documentation as opposed to code issues.
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.
[Basing your impression of a given project's quality and health on project activity is dangerous.](http://blogstrapping.com/?page=2011.065.16.43.41)