You seem to be hinting at a profound distinction between library (or module) and framework. If I'm smelling right, would you care to share your thoughts on the differences?

You hit the nail dead on.

Of course, the distinction gets blurry around the boundary, but in simple terms it comes down to this:

My code calls library modules.

Frameworks call my code.

With the former, I structure my application to fit my requirements and call library routines to perform specific tasks.

With the latter, the framework provides a generic structure for the application, and it calls my code to fill in the details.

Both are perfectly legitimate, but historically, I have had much greater problems with the latter than the former.

With the library approach, if the library goes out of mainenance, takes a divergent course or otherwise fails to meet my requirements, I can substitute another library by providing a shallow interface mapping layer between existing calling code and the new library. At worst, I have to write a replacement from scratch--but my investment in the calling code is not wasted.

With the framework approach, when it takes a course divergent from my requirements or stops being maintained, or when my requirements change to fall outside of it's facilities, my choices are limited. I can petition for changes to the framework to accomodate my needs. I can fork a local version and make my own changes to it, perhaps seeking to feed my patches back into the mainstream with the risk of them being rejected. Or I can move to a different framework, but the chances that my existing investment of code will be easily modified to work with that new framework are low.

Frameworks have a very difficult and fine line to walk. That between being very generic which makes it most flexible, but also has a tendancy to mean sticking to the lowest common denominator; and being highly specific, which makes for clean, targeted interfaces, but can also limit the range of applications that they are useful for.

Open source frameworks carry less risk than the proprietory ones that I have had trouble with on two occasions in the past.

In one case, a small company, 3 or 4 guys got into an internal wrangle that eventually became letigious, stopped development and prevented the company I was working for even attempting to buy the source, because the litigants couldn't decide who owned it.

In the second case, a quite large and successful company producing a quite widely used framework were bought out by a much larger software house who produced a less successful competitive product. They took the designers, programmers and the good ideas and used them to improve there own product, but squashed the one we were using. The costs and difficulties involved in moving from the original to the competitive product were the death knell of what had been a promising application.

So yes, I see a world of difference between libraries and frameworks, and I strongly favour the former to the latter.