Spurred by introduction of John Little’s open source planning project to create specs or strategic directions for a future ILS, I was talking “out of band” with someone about my vision for a library software infrastructure, sort or revisiting what I wrote as Notes on future directions of Library System, but hopefully even more clear this time.
Here’s some of what I said, combined into one redundant essay. :)
I also think it’s good to have options, so I’m not sure I expect (or would welcome) total convergence between various open source ILS projects. But to the extent we’re imagining various loosely coupled modules which can be mixed-and-matched, I fantasize that the modules from various open source (AND proprietary!) ILSs can become inter-operable, so an institution can take the one that best meets it’s needs in each class, and mix-and-match them. Different ones may meet different institutions needs best.
I’d like to see an environment where I can mix-and-match individual elements/components/modules to build an environment corresponding to today’s ILS. And for each element, I have my choice of 2-3 (open source AND proprietary choices). And I can mix and match them.
We are not nearly there yet. But I see Koha and Evergreen as more likely to get there than proprietary ILSs, although if Koha and Evergreen DO get there and become realistic opportunities, vendors of proprietary software will jump on the bandwagon with proprietary elements that can be plugged into a Koha or Evergreen environment too–because they’ll have to. That would be the kind of market I’d like to see.
I’m imagining a core specification of a framework, of how the different components will interact, that anyone can use (including any vendor that wants to write proprietary software for that environment). If you build your individual components according to this spec, then the end-user can mix and match them. I’m going to buy a circ component from vendor A, I’m going to buy a component that ties SAP into the system from Vendor B, I’m going to use an open source OPAC, and a separate open source cataloging/metadata-enhancement module.
Is this possible? I dunno. In my fantasies.
If there needs to be a core ‘engine’, that’s just another component. If written according to spec, you’d have your choice of core engine too. You could take a proprietary core engine from a vendor, or you could take an open source core engine (with support from a FLOSS-support vendor, or not). Either way, you can mix and match it with any of the components mentioned above. No need to charge any vendors any kind of fee; vendors are welcome to provide their own ‘core engine’ if they want, that mixes and matches with all the other modules (open source and proprietary), and they are welcome to provide any modules they want, that mix and match with any ‘engines’ (open source or proprietary). Everyone can use whatever pieces meet their needs.
I think this sort of thing is possible, but it’s definitely a bit of an engineering challenge. That will only be solved by someone putting some serious resources into trying it, and learning from what they try to make it better, and trying that, etc.