Or, it’s buying yourself more time to work on option 2 (rewrite your stuff to Rails 3 or 4).

If your application needs to be modified or updated in a few years, you can expect to pay the cost of upgrading to Rails 4 (perhaps 5 or 6 by then) with interest.

So many business find themselves completely dependant on code that’s over a decade old. Who will maintain Rails 2.3 in 2020? How much will it cost to rewrite the application from scratch by then?

Switching to Rails 2.3 LTS doesn’t mean you’re saving $20.000; you’re deferring payment on it, betting that this application, which is currently critical to your business, will become more or less irrelevant in the next five years.

It’s a common trap for successful founders, that they believe to know the “secret ingredient” do repeat or at least conserve this success. Or to be able to “ignore” the market for whatever reasons they have.

In a world with several new languages, frameworks and security issues appearing each week, one needs to question the position within the market quite often.

Of course if your business is in the “cash cow” phase you just want to keep it stable and milk it until it’s dead. To stay on Rails 2.3 using some 3rd party service is exactly doing this.

As you probably know, not only is the community is still innovating and stuff like PJAX, rails-api or even javascript client side apps are more common. Even recent revisions of essential 3rd party gems (test/code quality tools like factory girl, devise …) won’t get supported anymore (soon). What about passenger or unicorn? How long will they support Rails 2.3 apps?

So it’s a trap to think you can just “skip” these changes and stay in your own world. Because in reality, your application depends on much more than just an old Rails framework version.

Again: It’s your job as a business owner, especially one which claims to be educated well in all fields of IT(!), to avoid those problems, remove them in a way your business can still grow and keep speed for the next couple of years (=sustainability).

Paying 150$/month won’t fix your technical debt. It may expand your time to squeeze money out of a mature, dying project. nothing else.

Also, fame and reputation is good, but it will only buy you some time… Time that most of the readers of this blog or on HN will not have.

Rails security vulnerabilities are one of those details that are outside the core competency of easily 95%+ of Rails developers (as it is the case in effectively all languages/platforms). And succeeding in business is about building the business, not getting mired in the details of things that are not your core competency. Paying someone to handle details you don’t understand while you build the business? Totally worth it.

…you seem to think from the perspective of “a business made up of only one long-running project”, which doesn’t apply for many web-based products. In this space, most “business oportunities” have a finite “shelf life”, so you build your business as fast as you can, cash the profit then let it die and reallocate resources (or, preferably, do this inside your business, at project level – or if you’re a real business player, do this at the macro-level, buy investing in multiple companies and letting them all fail, but predictably and in a way that brings you good profit).

Yes OSS has many many benefits, and I am a big supporter – but magically producing talented commited devs to do maintenance work for free over many years really is not one of them