Deciding whether to go with a particular open source product is an exercise in risk management. To be sure, let’s be clear—deciding whether to go with a particular proprietary product is also an an exercise in risk management. (And really, most organizational management decisions probably are, but what do I know, I’ve never been a manager and don’t have an mba).
Evaluating the risk level of an open source product is kind of new terrain for some in the library world. It is comforting to remember that there are some aspects of evaluation that really aren’t much different for open source software than for any other software — for instance, looking at whether the product has the features you need, and how well it works.
There are other aspects that need to be approached differently for open source. In this essay, I’m going to look at just one of them, that is cause for particular concern among some people — open source support models, how you get support for an open source product, what you are risking in terms of support with an open source product. All open source products/projects are not equal here. In trying to explain to others how to approach risk management related to support options in a particular open source product, I’ve found it useful to talk about three situations or statuses an open source project may have with regard to support.
Open Source product support situation statuses
#1) “Home grown”. The product is used only by one library, or by hardly any libraries.
#2) Community support. The product has a thriving community of users and developers accross a variety of institutions.
#3) Vendor support. There are paid commercial support contracts available (from business that you would like to do business with).
#1: “Home grown” software
#1 is basically the situation of “home grown” software of the 1980s, and is the highest risk to the institution to adopt (or start). An institution is relying pretty much only on local expertise for maintenance and support.
#2: Community Support
#2 is really made possible by the internet–that’s the medium on which such a thriving community is built, and can change the ‘support’ environment. The internet is what makes it possible for the new round of ‘home grown’ solutions to be more sustainable than the 1980s ‘home grown’ library solutions proved to be. When #2 condition exists, it is significantly less risky than #1. Of course, there is a continuum of community strength and sustainability within the #2 scenario — the stronger the community, the less risk you are taking in adoption.
In evaluating community strength, you might want to look at: How many institutions have implemented the software; how diverse are those institutions; are there any that share significant characteristics with yours; how much traffic does the project mailing list(s) get; are there contributors (people who submit code; people who answer, not just ask, questions) from multiple institutions, not just the originating institution. The stronger the community, the less risky adopting a product in ‘community support’ status is. And the stronger the community, the less your own local organization staff capacity matters for evaluating your risk.
Another factor in successful ‘community support’ situation is that everyone should be using a ‘shared codebase’. Purely local changes should not be made to shared ‘trunk’ files, and changes of potential benefit to the wider community should be committed back to the shared ‘trunk’. Managing this for a large community requires a proper community infrastructure–another thing to look at in determining community strength for a “community support” scenario.
Some successful general market (not library specific) open source projects do fine with a community support model, with most or even all users never needing vendor support. (It’s worth noting that for some proprietary library software I am local support for, I get more, better, faster support from the user community for free then I do from the vendor we pay lots of money to! So community support in the age of the internet is not new even to proprietary software users).
Got to walk before you can run
The trick, of course, is that software usually has go to through #1 before it can get to #2. Somebody’s got to be willing to take that risk. So an organization willing to take a risk on a #1-status open source product is providing an lot to the library community. “Risk management” should not, and can not for library technology at this point, be “risk avoidance”. Both because the library technology community needs to take risks to survive at this point in time; and even more importantly, because there are risks to choosing proprietary software too. Risk avoidance is fantasy, it’s about risk management. Whether a particular organization is wise to adopt or develop a product still in #1 “home grown” stage may depend on local staff capacity, complexity of the project, need, consequences of failure, and how many other projects are already on your team’s plate.
Likewise, if you do embark on adoption or development of a product in status-#1, your ‘risk management’ plan should include concrete actions and resources spent on moving it into status-#2. The realization of this is why the Code4Lib conference this year was so full of people inviting other participants to work on and adopt their projects–but it requires more than just an invitation (or other ‘marketting’), of course, it requires resources spent on making the project easy to adopt, on maintaining a common rather than forked codebase, etc.
This means resources expended on these tasks by the originating institution, but this is not just altruistic — sharing your project with others is self-interested risk management to build a community support scenario. Once a product has a successful user community around it and is in ‘community support’ status, the risk of adoption is much less for everyone, including the original implementers.
#3: Vendor Support
Yes, there is paid contracted vendor support available for some software released under an open source license. Both library market and general market software. Software with a #3 status, having a paid support option, essentially puts open source software in the same status with regards to support as our traditional proprietary options. For something as complex and central to library business as an ILS (or future software serving similar role), in my opinion you really want vendor support. For other software, you can often be served well enough with community support.
Of course, within #3, there is still a continuum — you evaluate the available vendor(s) quite similarly to what you do with proprietary software vendors. How good is their service? Can we afford the price? How likely is this vendor to stick around (which is market analysis, to some extent). But it is important to note that contracted commercial vendor support does exist for some open source products (including notable library market products), on very much the same support model as proprietary products. With vendor-supported open source you may not need any more local staff capacity than you would with proprietary support! Either way, it ultimately depends on the strength of the product and vendor.
With open source software you have an additional escape hatch you don’t have with proprietary software. If the support vendor fails you, you have the legal right to keep using the software in a situation that is effectively status-#1 or status-#2. Additionally, if there is a community of users (#2), and they agree that the available support vendor(s) are failing them, the market is right for a competitor support vendor to spring up—a competitor with full access to the source code. These escape hatches are important benefits, but I wouldn’t want to count on them for something as complex and central to business as an ILS–I’d want a vendor I could trust to be available. Fortunately, both Koha and Evergreen have this.
Now, these are extra escape hatches you don’t get with proprietary software, and you may in the right circumstances get with open source software. Whether they are feasible can depend on the situation. Escaping to “Community Support” requires a thriving community to exist. Escaping to either community support or home-grown status depends to some extent on your local technology expertise capacity. You can only escape to another vendor if another vendor exists, which depends on a number of factors including the market. Any of these ‘escapes’ depend on the software code in the product being well architected, well written, and documented.
Even if you can’t take advantage of these ‘escape hatches’, you are no worse than you would have been with proprietary software. If the circumstances aren’t right, you’re just in the same place you usually are with proprietary software. Even an institution which can not take advantage of them is no worse off with vendor-supported open source software than they would be with proprietary software with locked-in support from an equal quality proprietary vendor.
But despite these caveats, in the right circumstances these ‘escape’ hatches can be very significant, and can serve to mitigate risk somewhat (remember, we’re talking risk management here). I’m confident that if Horizon 8 had been open source, there would have been a very different outcome when the vendor decided to cancel an almost finished product (leaving most with no legal right to run it, since it was not open source).
0-60 in seconds flat, when you can’t afford to walk.
Most open source software (not library specific) goes through #1 (home grown) and #2 (community support) before it (maybe) gets to #3 (vendor support). But since ILS software is so vital and the risk of failed support so dire, Koha and Evergreen (in different ways) both jumped very quickly to a vendor support situation (via LibLime and Equinox) — as a conscious risk management strategy from organizations who had the foresight and courage to take the initial risk and put resources into moving into vendor-supported status. We owe these organizations a debt of gratitude, they are what makes it possible for others of us to come in with vendor-supported open source at significantly less risk to our organizations then the early adopters took–not neccesarily any more risk, and perhaps less risk, in terms of support status than you get from a proprietary product.
(Another way a product can ‘jump’ to #3, vendor support, is when software originates with an existing strong vendor, but is released with an open source license. We see this a little bit with some library software options, but not with anything as complex as an ILS. (yet?). This is good, in that you have a vendor support option, but if the vendor keeps too tight reins on the legally open source code, it can reduce the likelihood of a successful support community “escape hatch”, as well as reduce other potential benefits of open source software.)
Risk Management, Risk Takers, and Open Source
An open source evangelist (and I include myself in that category) would be providing dis-service to their audience and to the success of open source if they were to dismiss the existence of risk in open source, and the different nature of risk in open source. It’s about risk management. And even the most risk averse organization may in the right vendor-support (#3) situation be well served by an open source product–an open source product with vendor support is inherently no more or less risky in terms of support scenario than proprietary support–it depends on the vendor, in both cases. (Except in the right situation vendor-supported open source may actually be slightly less risky, from support scenario standpoint, due to the ‘escape hatches’).
I think risk management and wise taking on of risk can sometimes include taking on a large risk. It’s important to know the size of risk you are taking on. But whether it is wise to take on significant support risk can depend, among other factors, on the size of the benefit you will get from success (how much do you need this product, how much will it benefit your users?), as well as on the costs of failure. Some failures can be simply learning experiences and interesting experiments, while others can be organizational catastrophes. Which you can expect depends in part on how many resources you put into the experiment–staff time, money, lost opportunity to pursue other options, etc. Risk management is about more than just risk analysis, it’s about determining when a risk is justified, and even large risks can be. It’s important to compare the risks and benefits of all your available options–and doing nothing is an option which also needs it’s risks and benefits evaluated. Doing nothing can in fact be a high-risk choice in the long term.
Of course, as a community, we need more of our institutions to not be in the “most risk averse” category. It’s only those trailbreakers who can make it possible for the others.
And just as importantly, the more organizations we have willing to take calculated and managed risks with #1 and #2 statuses, the good software solutions we’ll get, the more innovation we’ll get. (We have started to see even proprietary vendors start to innovate more as a response to the threat of open source. The more real this threat is, the more innovation we’ll see even from proprietary vendors). I honestly do believe that the very survival of libraries as relevant and useful organizations depends on this innovation, which depends on more library institutions innovating, which depends on eliminating the fantasy that there is such a thing as risk elimination. The status quo carries very dire risks of it’s own.
Thanks to K.G. Schneider, Dan Chudnov, Ross Singer and others on the #code4lib channel for starting a discussion on this issue in IRC that motivated me to write this essay and helped me clarify my thoughts.