We've been doing the same for the past year or so at Mogotest and the results have been great. To build on the points in the articles: - Exceedingly few gems

We've been doing the same for the past year or so at Mogotest and the results have been great. To build on the points in the articles: - Exceedingly few gems provide any semblance of a human-readable changelog and even fewer care about targeting multiple APIs at once. Assuming you don't just blindly update your entire Gemfile at once, you're going to end up spending much more time than is reasonable to determine whether you should upgrade that gem you just pulled in. - There's a huge stigma against libraries ever being "done." So, they keep adding new features or coming up with better APIs. You're going to end up having to go along for the ride. - Rails doesn't have much of an API per se or at least not one that's likely to survive a major upgrade in tact. After the Rails 2.3 -> 3.0 upgrade, we just flat out avoid anything that's a "rails plugin." I suspect our 3.2 -> 4.0 upgrade will go much smoother this time around. - If you target multiple rubies, it becomes much, much easier with a slimmer dependency graph. At the end of the day, a lot of this is just the general debate of building it vs using a library that any language or environment has. But I think some of the cultural aspects of Ruby amplify the debate as it's just a much faster moving target, which may be at odds with stable apps.