Another post I made to horizon-l. I am trying to be a rational (rather than propaganda-spewing) voice of pro-FLOSS. Feel free to let me know if you think I’ve mis-stepped in any direction.
Another member posted:
and it may be that your library administration would never consider open sourcing your ILS....
To which I replied:
It is important to remember that Evergreen and Koha both have vendors who will provide commercial support. Realizing that an ILS with an open source license can also come with a support contract, I can’t think of any good reason for administrators to rule out open source ILSs as a class. That’s the real meaning of how open source and commercial can be “both/and”. Evergreen and Koha are both commercial software AND licensed under an open source license. .
Is there anything I’m missing about a rational reason to dismiss open source as a class, to specifically reject software that’s licensed under an open source license, preferring software that is not?
Now, just because there may not be any reason to reject open source as a class, that doesn’t mean that any particular existing open source licensed ILS is right for you. The way you evaluate it is the same way you’ve always evaluated software, some particularly pertinent criteria in this case include:
1) Total cost of ownership, naturally. Your support contract for the open source licensed ILS being evaluated, plus hardware, plus if the software doens’t yet have all the features you need/want, the cost to pay a vendor (or hire staff) to add them. Compared to total cost of ownership of your other (proprietary) options.
2) As with any product, strength and staying power of the vendor. While both Koha and Evergreen have vendors providing commercial support, you want to ask yourself the question, how financially and otherwise organizationally healthy are they? How likely are they to stay around for the long term? As you would with any vendor. (And the market has of course seen that there’s no guarantee of continued viability of vendors of proprietary software either).
There will be negatives and positives with any particular solution you evaluate, which have to be balanced against one another and against the other options. For open source or proprietary. Open source by it’s very nature comes with some more _potential_ positives—if the currently existing vendor _does_ go under or decide to stop supporting the product: a) You can still keep using the software as long as you want without permission from anyone (that’s the nature of open source) b) Another vendor(s) can spring into existence to support and/or further develop the same product, without any permission from anyone, with full access to the source code (if not neccesarily the institutional expertise). Another unique possibility, if the open source ILS market continues to develop, is that there could
Many of these unique benefits to open source are just _potential_ in the ILS market at the moment, there are no guarantees—if you don’t want to consider these potential benefits yet, you don’t have to: You can evaluate open source ILS options head-to-head with proprietary options, without giving any weight to the potential unique benefits of open source. I think Koha and/or Evergreen are quite possible to still come out looking good in such a comparison.
But when you undertake the difficult calculus of evaluating what software is best for you among a collection of non-perfect options, I don’t see any reason to exclude open source licensed options from consideration altogether.
Jonathan
Bibliographic Wilderness 
Jonathan,
Another big cost, and one that is hard to estimate, is switching cost. I’ve seen some libraries go through the switch from one vendor to another, and the cost is tremendous. Even the cost of upgrading within one vendor’s line seems to be over the top. Why can’t these moves be smoother? Well, except for our bibliographic records, none of the rest of our data seems to be standardized. But even though the MARC record is standard, we’ve never managed to create a standard or default set of indexes, which strikes me as absurd. Why is every library choosing what fields and subfields will go into the Title index? Part of it is that many libraries (OK, mostly academic libraries) have their own way of doing things. These are also the people who insist on tweaking their cataloging copy, to great expense.
Alright, I’m ranting, but there are some pretty inefficient things we do in libraries that aren’t helping us at all. I’d love to see a vendor put an emphasis on how little the library HAS to do to move to their system, rather than how much they CAN do. Actually, I’d love to see libraries accept that as a viable option.
kc
Very true. Switching cost is of course there when switching to proprietary or FLOSS.
One of the reasons so many Horizon customers are only now considering FLOSS is because they’re now going to have switching cost no matter what, even if they stay with SD.
Do you think that FLOSS switching cost might be significantly less than proprietary switching cost for any reason? I’ve been assuming that switching cost is going to be roughly invariant regardless of which system you choose to switch to, but maybe that’s not at all a good assumption. (I’ve definitely never gone through an ILS migration myself, so have no experience of my own!)
[Note that in the Horizon case, SD has said that they will not charge Horizon customers ‘migration’ fees, at least in some cases, but will still provide migration support. This is definitely their attempt to minimize ‘switching’ costs for Horizon folks to go to Rome/unicorn. Any other vendor, even support vendors for FLOSS products, is going to have to charge migration fees for migration support. Of course, we’ll see what SD _actually_ ends up providing without charge, if anything, when the time comes.]
Proprietary systems are built upon a business model that emphasizes “cost enhancements” and a seriously dysfunctional module segmentation. Wasn’t it an earlier version of Dynix (?) where you actually had to purchase an “Exit Suite” to get tools to export your data? Vendors purposely make data access limited and/or expensive.
The big 3 still have limited and undocumented API access. Can you see your data, how it’s stored, and have ready access to an API to get at all your data to help you keep migration as cost-effective as it ought to be?
Contrast with an OSS solution
– worldwide access to talent pool that could support both your migration and/or ongoing maintenance and development. So if you don’t like Equinox or Liblime, ANYONE else can be selected on a competitive basis.
– OSS “doesn’t hide anything” and this encourages sys admins and librarians to understand their data/databases, helps build skills, encourages you to “know your data” and opens up huge opportunities denied them with proprietary systems.
So “migration costs” can be viewed as part of a larger issue: it needs to be balanced against the costs of continuing to keep our data in proprietary systems. Migration costs are the “big excuse” that prevents us from taking responsibility and a lead role in the future of our data. High migration costs are yet another reason to dump the proprietary big 3 systems IMHO.