> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework

> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible. The other way, which I have personally seen, is that the core developers fight the pressures that lead to generality, but this has one of two side effects. Either non-core developers grow frustrated as they increasingly encounter problems that the framework handles poorly (or not at all) and need to choose solutions to fit the tool, or they just don't use that framework in the cases where it doesn't fit well. There are strong incentives to never choose the second option since it is either a design choice that makes the tool fit poorly or a difficult to describe edge case that requires a different solution. As an analogy, all problems can be solved with X language, so why would you ever need Y language? A framework is something approaching a domain specific language, so I feel like the analogy is appropriate. People naturally fall into this trap of "one framework to rule them all" and what starts off lean and well suited to particular tasks ends up unwieldy and bloated because people aren't willing to pick up a different tool instead of just generalizing the tool they are using. Yet, the expression "one size fits all" naturally leads people to instead think that the fit is going to be ugly on most people nonetheless. So if you want opinion driven development to succeed, you need to tell people what problems you are trying to make easier to solve and admit that there are similar problems for which the framework fits poorly and maybe another opinionated framework is a better choice. You need people that are willing to work with a wide variety of technologies.