Here's a different perspective: Bootstrap is evolving as a clean-cut UI framework that can be reliably extended when you stick to its conventions (nonsemantic markup and all.) That's why this list is so massive. Like any framework, I would strongly suggest against forking the library and modifying the code directly. Instead, keep application-specific customizations separate, "on top" of Bootstrap.
The non-semantic aspect of it is baffling to me. As I was learning web development, I read all over the place how class names should be descriptive. Otherwise you end with something a lot like the inline styling that CSS first helped us get away from. I was on the sidelines for all this, and didn't fully understand, but I took it as gospel that I should be working towards having all semantic markup.
Then bootstrap comes along and all that talk is just gone. Gone without passing go, or arguing that it is time to rethink our assumptions. And I feel kind of crazy because it's like this massive cacophony of voices has just disappeared and no one even remembers it was there.
Mind you, I'm fine with the change. I'm still sort of on the sidelines listening to what I assume are the experts. But this has been jarring for me.
Not a good practice. If you keep changes of .less files separate you create an overhead of 50-100% of the resulting style-sheet file size for larger projects, that style most of the components.
We now directly modify everything and try to merge in updates manually. This has proven to be the best practice.
> Like any framework, I would strongly suggest against forking the library and modifying the code directly.
The problem is that it's not a library, it's just scaffolding. There are no agreed standards on how to extend it. Most people include Bootstrap's CSS/JS files, then override on custom stylesheets. That's not viable at all.
