It is an ambiguous thing because Bootstrap is not usually treated as a library, but rather as project scaffolding. That is, it's used to start a project, rather than enhance a currently built project. This is not necessary, of course, as Bootstrap is really a set of adjunct resources that can be pulled into your pages as necessary.
The major problem you see with this useage is that people start a project with Bootstrap 1.2, and 2.0 comes out, there's no chance in hell that they upgrade. Partly this is ignorance, partly this is because there is still no good package manager for the open web - and that's not for lack of coding chops, but because, IMHO, we're still not really sure what "package manager for the open web" should mean.
A page as an execution environment is both incredibly rich and incredibly risky. As much as the web itself is a wild-west of innovation, so is the page environment. We can pull scripts, images, css, data and even DOM from around the world. And for the most part we still do it by adding a line in the page and, if we want a local copy, a wget. The only reason resources don't step on each other is luck and convention - usually it's mostly luck (although the "single global object per library" convention for javascript seems to work really really well.)
It's time that coders and designers both start to think of CSS as reactive functions that map from DOM to pixels and are invoked with class names and ids (this is a lot different than their intended uses, but let's face it, semantic markup doesn't really meet any real human need). Perhaps, echoing the success of the javascript convention, we should adopt a convention that lets css libraries to exist within a single, top-level selector.
Projects like Meteor, Derby and AngularJS are a good push in the right direction, but there's still a long ways to go I think.
Just on the point about upgrading, I can remember between two versions of Bootstrap where markup changes were required in order for the site to function properly with the new release, and no backwards compatibility was provided. Unless somebody is waiting for new features in the latest release, I can see them not wanting to bother going through and updating all of their forms or views. However, if the new features are compelling, it will be worth the effort. Really this is the same decision process we go through when deciding whether or not to upgrade any underlying framework or supporting software.
The major problem you see with this useage is that people start a project with Bootstrap 1.2, and 2.0 comes out, there's no chance in hell that they upgrade. Partly this is ignorance, partly this is because there is still no good package manager for the open web - and that's not for lack of coding chops, but because, IMHO, we're still not really sure what "package manager for the open web" should mean.
A page as an execution environment is both incredibly rich and incredibly risky. As much as the web itself is a wild-west of innovation, so is the page environment. We can pull scripts, images, css, data and even DOM from around the world. And for the most part we still do it by adding a line in the page and, if we want a local copy, a wget. The only reason resources don't step on each other is luck and convention - usually it's mostly luck (although the "single global object per library" convention for javascript seems to work really really well.)
It's time that coders and designers both start to think of CSS as reactive functions that map from DOM to pixels and are invoked with class names and ids (this is a lot different than their intended uses, but let's face it, semantic markup doesn't really meet any real human need). Perhaps, echoing the success of the javascript convention, we should adopt a convention that lets css libraries to exist within a single, top-level selector.
Projects like Meteor, Derby and AngularJS are a good push in the right direction, but there's still a long ways to go I think.