Exactly what I was thinking. He also mentioned that the code base "is littered with monkey patches". I suppose the author does not realize that monkey patches can be very costly for maintenance. Just because you can monkey patch something doesn't necessarily mean you should.
His point is that he HAS to monkey patch, but it clearly saying that it shouldn't have to be that way, if the underlying frameworks, plugins, and gems simply worked the way they should from the beginning.
Why would they not submit bug fixes instead of monkey patching everything? If the library is supposed to work a certain way, then it is a bug and should be fixed. Bug fixes that make their way back to the main repository have a much lower maintenance cost than monkey patches.
Every time you want to write a monkey patch, you should really ask yourself if it is worth the likely future maintenance costs.
Perhaps because so many small project owners don't accept and merge in patches after people kindly submit pull requests containing proper patches. Albeit I see this for many areas of open source, not just Rails, such as ObjectiveResource, Three20, and Moonshine. I've had to wait as long as 3 or 4 months before even getting some feedback from some project admins, and that's after an email or two.
We shouldn't have to beg to get our patches committed. Some project owners are just lazy, or have a very narrow view of what they want to accept for patches. And that's fine, it's their project. But that's more the reason why people monkey patch and not continue to submit patches, of which they'd need to monkey patch anyway to have the change effective immediately. After all, the projects are often still active, and do update with bug fixes, etc. And if you've only modified the tree, then you need to reimplement after you update. A monkey patch avoids this requirement, letting you get on to more important work.
