Taking ownership of Koha
One of the promises of using Koha or any other Open Source ILS is that you’re not tied any one support company. “No vendor lock-in.” But it’s important to understand that this isn’t a promise that libraries can take for granted–in particular, libraries who contract with a support company for hosting of their Koha system. We need to be aware of what that means in practical terms and be prepared to put that promise to the test when the time comes. There are steps that we can take to make sure we’re protecting our own interests.
Insist on access to your database
We as libraries should own our data. That means the database of our patrons, the items in our collection, our authority records, etc. Everything stored by the ILS should belong to us. After all, we put it there. When we contract with another company to host our Koha system, we’re giving them the keys to the vault. We have to put our trust in them, but we can also protect ourselves.
It’s simple: our data is in the database. If we want to retain ownership of that data we need to have access to that database. In my opinion this should be part of any Koha hosting agreement. If you have read access to your database you can run your own queries and leverage your data in ways that Koha may not do out of the box. Does Koha not include the kind of report you need? Hire a programmer to write a script to pull the data and manipulate it however you want. It doesn’t even matter what kind of scripting language you want to use: Perl, PHP, Ruby–anything that can connect to your database will work.
If you want to be prepared for disaster I also suggest you ask for access to regular database dumps, or ask for privileges to do the data dumps yourself. This should be in addition to whatever data backup plan your host has at their end.
Know what’s going on in the background
There is more to Koha than the database. If you ever decide to change to another Koha host/support company you’ll need to know some things about your Koha installation that aren’t stored in the database. Your host will have set up cron jobs to run background scripts on a regular schedule. Communicate with your host about what these settings are. Know when things are running and how often.
Insist that any development you sponsor be released to the Koha community
If you’re interested in preventing being locked in to any one vendor this is very important. If you pay your Koha support company to develop a new feature for Koha and they don’t release it as open source, your Koha installation will be unique and potentially incompatible with Koha installations built from the official release. Your host will be able to say to you, “Sure you could switch hosts, but you’ll lose such-and-such feature and the data associated with it.” This is what vendor lock-in is all about. Insist that your support company/host to be a part of the Koha open source community. Insist that anything they develop for you gets released to the community as soon as it is complete. Or better yet, ask that they do this development out in the open, using public source repositories which can be accessed by other Koha developers. To insist on these conditions is to protect your organization and make sure you can freely make decisions about Koha support and hosting in the future.
The worst case scenario
In the worst case scenario your hosting and support company vanishes from the face of the earth and takes your data along with it. Because you’ve got a backup and details about other required settings, you can pick right up where you left off with a brand new host. Because the features you sponsored were released as open source, they’re either already in the standard Koha code or can be re-integrated by your new support company.
The best case scenario
In the best case scenario, you’re moving from one hosting and support company to another for reasons other than catastrophe. Because you’ve taken ownership of your data and taken an active role in understanding your Koha configuration, you’re able to bring everything to the table your new host needs. Migrating from one standard Koha installation to another is so simple compared to ILS migrations of the past that you’ll be amazed.