>I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves.

Also I often think:

I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.

For me it's "premature optimization is the root of all evil".

Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity.

Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without considering its impact? It's so easy for intuitive maps of the "hard parts" to dictate insanity across the whole development process.

I agree, but the opposite also happens: teams start by implementing something small themselves because the framework is so 'huge'. Over time, they end up with a semi-huge custom framework because they run into the same issues and feature requests the 'huge' open-source framework ran a few years before them.

That's a really good point.

It's a spectrum of complexity over numerous components, inside the context of a greater development environment which also impacts decision making. As boring as it sounds this is why I force myself to estimate as close to "everything" as best I can early in the project... Not so much to use as an estimate, but to map out areas where my intuitive understanding is inadequate, and to give some rough data to drive decision making. Mapping out the pain points at least gives you a semi-objective breakdown of where the actual work lies, and to what degree that pain will be mitigated/exacerbated by major frameworks. DIY has its limits ;)