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.
Bibliographic Wilderness 
Hey Jonathan: you might want to take a look at http://open-ils.org/dokuwiki/doku.php?id=opac-devel:catalog_development – it’s a page in the Evergreen wiki that I just added that shows how the catalog interface talks to the underlying service infrastructure. It might only be understandable by geeks, but they’re the ones building the systems right? Hopefully they, at least, could vouch for my assertion that it’s not really rocket science.
To tie into other modules, or SAP, or whatever, you just need to define the appropriate OpenSRF service(s) and call them from whatever interface (web, XUL staff client, command line) can talk OpenSRF. This is what immediately clicked with OpenSRF and Evergreen for me, and why I will happily argue that Evergreen is much more than a traditional “ILS” in terms of architecture. Maybe we’re closer to “nearly there” than you think?
Dan: Good to know you think so, because I trust your judgement. Maybe I’m not geeky enough, but I’m afraid I don’t really find that page understandable to see what’s going on with how OpenSRF fits the the needs I’m talking about.
For OpenSRF to fit the needs I’m talking about, there would have to be a spec somewhere that someone could look at to write a module that could be a drop-in replacement for any part of Evergreen (including the ‘core engine’ if any!). (Some unit tests would probably be a good idea too, in the sense that unit tests can be considered ‘actionable specs’, so that you could run them against your drop-in replacement and be sure it passes). If that document is supposed to be such a spec… I must be missing something?