The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.

Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.

I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?

The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.

One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.

Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.

(I run a startup that's a software-enabled service to upgrade old Rails apps).

I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.

Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.

"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.