app/concerns is a perfect example of the problem I'm trying to communicate. If I want to extract code out into a concern, everyone is perfectly ok with it becau

app/concerns is a perfect example of the problem I'm trying to communicate. If I want to extract code out into a concern, everyone is perfectly ok with it because Rails has "blessed" the concern pattern by providing a parent object to inherit from and a directory where concerns should be placed. As soon as Rails weighs in with an opinion, everyone is onboard. I think the message I would like to see communicated is that we as developers are free to create app/foo if we feel like foo is a good idea. Technically there's nothing stopping it. Culturally, it's almost unheard of. I brought up lib/ because structurally it is a free for all. Nobody looks twice if I create lib/foo and add some code there. The problem is that I don't want to put app specific code into lib. I'm not sure if app/lib is a good idea, but I feel like it would communicate the idea that it is OK to write app specific code that doesn't fit into anything Rails has approved. Anyway, I realize my concern is very much a culture issue. That culture has its pros and cons, and if we didn't have the strong opinion to stick to MVC, we would probably end up with a ton of spaghetti code in app/lib. I just wish we could strike the right balance.