Because from a 10,000 foot view, everybody wants the same thing, but when you get down in close it turns out they don't, and the differences dominate the simila

Because from a 10,000 foot view, everybody wants the same thing, but when you get down in close it turns out they don't, and the differences dominate the similarities. Common misunderstanding. A very similar root cause to the UML failure story currently on the front page. Scaffolding tools in particular have the problem that once you union all the different requirements the resulting scaffolding is insane and impossible for anyone to understand. Some people need to have C modules in whatever non-C language you're working in. If your scaffolding doesn't include that they need to do a lot of work. If it does include that, a whole bunch of other projects now have a lot of crap they don't need, which may be difficult to extract properly from the resulting scaffold. Multiply this process by dozens of features and you end up with something that is basically guaranteed to be a monstrosity that nobody can understand, to be missing critical features, or most excitingly, both at the same time. The natural solution many will jump to then is "Oh, we'll make it configurable!" Now the scaffolding authors are responsible for testing the exponentially-growing state space of possible configurations, and the scaffolding, whose whole point in life is to be simple, is now complicated. And most of the time, if you discover your scaffolding configuration was wrong after you've already started work it's non-trivially challenging to fix the config and re-run. This basically turns the scaffolding into a non-Turing complete domain-specific language. Those have their uses, but "operating in a fundamentally Turing-complete programming space" isn't one of them. It's also arguably an inner platform, replicating what the language already has. But jerf, you protest too much. You seem to have disproved the utility of scaffolding in general, but I know that I've used it before successfully! Yes, you can solve all these problems with basically the Gordian knot solution. You just provide scaffolding anyhow, and it can be helpful. But my proposition here would be that you basically just accept that any given scaffolding can't be The Solution For Everyone, you don't go crazy trying to provide endless configuration, and you just accept that it'll be missing features for some people and have unnecessary features for others. There is absolutely value in simple scaffolding even despite what I say here, especially for things like "Here's how to start getting into Ruby on Rails!" or other similar frameworks where it honestly may not be practical to expect someone to be able to bring up a new project from an empty directory. My point here is more to not jump into the Turing tarpit of spending tons of time and resources trying to 100% solve this problem everywhere and for everybody. Grab some quick wins, be aware of the risks, be aware of the infinite regress of feature requests that lies down this path with ever diminishing returns, and move on in life. There's plenty of other situations like this in the programming (and engineering in general) world.