[Aqua_Geek]

> I'm talking about bugs in the Rails framework.

I think skidooer was as well.

> I think very few people would like to be having to maintain an outdated framework. And for the ones that actually do decide to maintain a framework that they did not develop themselves [...]

How is maintaining an open-source framework that somebody else made different from maintaining a framework built in-house? At the end of the day, bugs will still be found and need to be fixed. Yes, your devs might be more familiar with your framework than with a third-party one, but I think that is only the case if you can keep your team small and prevent churn and specialization. Regardless of which direction you go, devs need to understand what is happening inside the framework - it can't be a magical black box.

> [...] it will cost them a lot of money.

More than writing something from scratch?

[felipemnoa]

Well, I guess we just have to agree to disagree. When choosing a framework one of my criteria is that somebody else is doing all the work to maintain it so that I can benefit from their work. If I have to maintain it then what is the point? I'm trying to save time here, not add more time to my schedule.

[skidooer]

You certainly make a valid point, but I must add:

Rails is a fast moving target because they are always looking for new ways to save you time. As I mentioned in a previous post, the Rails 1.0 API is painful compared to the current generation. You are saving massive amounts of time during development because the project has evolved so far.

Spending a few minutes patching a framework bug once every five years pales in comparison to the gains you are seeing in development time.

To each their own, but I'd rather have a framework that is better than have a framework that knows it could be better, but won't make the changes because it might break some several year old app.