If you follow Fowler's link to Michael Feather's post, you'll find some good material. Feathers writes:

"The next time you are tempted to write and distribute a framework, run a little experiment. Imagine the smallest useful set of classes you can create. Not a framework, just a small seed, a seedwork. Design it so that it is easy to refactor. Code it and then stop. Can you explain it to someone in an hour? Good. Now, can you let it go? Can you really let it go?"

In the discussion that follows, he adds:

Here's an attempt at a definition...

A seedwork is a framework that:
1. Has tests for each class
2. Consists primarily of concrete classes
3. Can be explained in an hour
4. Comes with a promise that it will not be expanded or factored further.

I resonate with this. I get a lot more mileage out of simple, minimal frameworks that I do out of fully elaboborated, bloated, incomprehensible solve-the-world frameworks. These minimal frameworks--call them "seedworks" or call them something else--are somewhere between "examples", and what we usually think of as frameworks.

Ward Cunningham writes something related here:

"For example, if you just blatantly ignore a situation that a future programmer needs to deal with, they will come in to the code and discover that you blatantly ignored the situation. That means they have the freedom to do whatever is required. But if you tried to account for the situation, they will come in and realize it isn't working. They'll see you tried to account for it, so they'll first attempt to understand what you were trying to do. Once they understand what you were trying to do, they can figure out how to change it to do what they know they need to do. They would much rather come in and discover you didn't even think about it. Maybe you did think about it, but you did not program one bit of it."

The point, counter-intuitive to some, is that by keeping a framework simple by not allowing for the future, it can be a lot easier to use and extend now.