It would seem that one of the barriers to understanding remixability is in our historical role: many of the libraries I’ve visited view their role as primarily dissemination of knowledge rather than the development of knowledge resources.

Consider how purchasing agents view open source software: it doesn’t make sense. Their job is to buy things, not build them.

Mix that with an admittedly ambiguous use-case (if we open it, people will remix it) and limiting license terms on the data we have, and it’s definitely a hard sell.

Still, one can hope, and, as you suggest, writing remixability into our product requirements is a big step.

The data in the ILS must function as a data store for the unified business of the library. The software can no longer just be about supporting work flow, the data produced must be housed in something that can serve as a unified data store for our unified business.

It was Lorcan’s pointer to the Australian report talking about ’single business’ that got me thinking in these terms.

This way of expressing it is in some respect less ambitious than what you describe, it’s not there yet. But I think we need to figure out a way to express this which makes sense to administrators, on the way to something which can be expressed clearly in a requirements list, so that less technical people (at our libraries who will be evaluating products) can still understand the requirement, whether or not they are qualified to evaluate it.