A Primer in Risk

Deciding whether to go with a particular open source product is an exercise in risk management: understanding the risks of your possible actions and choices, calculating when a certain level of risk is appropriate to reach a desired outcome, and planning for how to handle negative outcomes. To be sure, opting to go with a particular proprietary product is similar, but evaluating the risk level of an open source product is new terrain for many in the library world and deserves special attention.

There are some aspects of evaluation that really aren't much different for open source than for any other software (what features the software offers and if they meet your identified needs, how well they work, how satisfied existing customers are, what the technical requirements for running the software are, and so on). But some issues need to be approached differently for open source. One issue of overriding concern among most librarians is support.

With traditional vendor-supported proprietary software, when you have a problem you pick up a phone and get tech assistance, because you've paid for it. If the software has bugs, you can expect they will be fixed, and you can expect new features now and then, too—again, because you've paid for these things. With an open source product, how much risk are you taking on with regard to support? Not all open source products are the same in this regard. Various scenarios exist for open source software, including contractual vendor support very much like what we're used to with traditional proprietary software.

All open source products and projects are not equal. In trying to explain how to approach risk management related to support options for a particular open source product, it's useful to talk about three scenarios.

1. Homegrown products are used and developed by only one or very few libraries. They are usually written to meet very local requirements without much effort to generalize and are supported by the same local staff who wrote them. A risk of homegrown software is managing the transition when that original staff leaves.
2. Community support products have a thriving network of users and developers across a variety of institutions. A community of users and developers is, of course, not contractually bound to provide help, but many open source products have strong groups willing to spend time helping you for the greater good of the project.
3. Vendor support products are backed by paid commercial contracts available from companies in the business of supporting open source products. Even though these vendors don't own the software, they provide technical help for the software via contract, very much like a support contract for proprietary software. In the general market, a well-established and successful example is Red Hat Enterprise Linux, a variant of the open source Linux OS, for which the Red Hat company offers support contracts.

Homegrown software describes much of the custom-built software from the 1980s and is the highest risk to the institution to adopt (or build from scratch). The path of the early successful homegrown software was often to become proprietary, like the NOTIS ILS that originated at Northwestern University, Evanston, IL, but was later successfully commercialized as NOTIS Systems (and even later merged with Dynix).

A more recent example is ILLiad, software for managing interlibrary loan created at Virginia Tech and commercialized by Atlas Systems, eventually bought by OCLC. Unsuccessful homegrown software followed a different path: it was most often regretted, replaced with proprietary software, and forgotten. Increasingly, successful homegrown software is more likely to transition to community-supported software—not to make a profit for the originating library but to meet mutual needs cooperatively and sustainably.

The risk of homegrown software that doesn't transition to community support is that an institution is relying pretty much only on local expertise for maintenance and backup. One of the biggest challenges is to make sure the expertise necessary is transferred when the original developers leave your organization and that your organization continues to allocate sufficient staff resources to keep the product viable. Over the past few years, many institutions used homegrown solutions for keeping track of locally licensed databases (i.e., ERM, or electronic resource management), and many are currently looking for (or have found) an exit strategy for what has started to look like an unsustainable approach.

Community-supported software has been made possible by the Internet, a medium that enables such a vital and diverse community and that radically alters the “support” environment. The Internet allows the new round of homegrown solutions to be more sustainable than the 1980s versions proved to be. The Firefox web browser is a good example of open source software that thrives with a healthy community. The Apache web server is another example of enterprise server software that many organizations run without any support contract, relying instead on a group of users and developers to write documentation and provide help.

Finally, there is paid contracted vendor support available for some open source software, in the library market and beyond. Paid support essentially puts open source software on the same level as traditional proprietary options with regard to maintenance and backup. For something as complex and central to library business as an ILS (or future software serving a similar role), you will likely want vendor assistance. For other software, you may be served well enough by community support. The two popular open source ILS packages, Koha and Evergreen, both have vendors providing contracted support, as appropriate for software with such high stakes. On the other hand, some open source packages with more limited scopes have become popular in libraries without paid vendors in the mix, including the LibX and Zotero Firefox plugins for searching library catalogs and managing citations respectively, as well as VuFind, a replacement catalog interface. As libraries become more comfortable with the community support model, we can expect increased popularity of such software as Umlaut, an OpenURL link resolver; Blacklight, a facted discovery interface; and Scriblio, a catalog built on top of the WordPress platform.

Of course, even within the vendor support category, there is a continuum, and you should evaluate any available open source support vendors the same way you would proprietary software vendors. How good is the service? Can you afford it? How likely is this vendor to stick around? With vendor-supported open source, you may not need any more local staff capacity than you would with proprietary assistance. Either way, your success ultimately depends on the strength of the product and the vendor.

When community support exists, it is significantly less risky than experimenting with homegrown software. Of course, there is a continuum of community strength and sustainability within this scenario as well.

In evaluating community strength, you might want to look at how many institutions have implemented the software; how diverse those institutions are and whether any share significant characteristics with your own; how much traffic the project mailing lists get; and whether there are contributors from multiple institutions, beyond the originating institution. The stronger the community, the less risk there is in adopting its product and the less you will need to rely on local staff.

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 a vendor. (It's also worth noting that community support is not new even to proprietary software users: for some of the proprietary library software I support locally, I get more, better, and faster help from the user community for free over electronic discussion lists than I do from the vendor.)

The trick, of course, is that software rarely starts out at the community support level; it usually begins as something homegrown first. So someone must be willing to take that first risk, and those who do provide a lot to the library community. Whether a particular organization is wise to adopt or develop a product still in a homegrown stage may depend on local staff capacity, complexity of the project, need, and the consequences of failure.

If you do embark on the adoption or development of a homegrown piece of software, your risk management plan should include concrete actions and resources spent on building a community of users and collaborative developers. That is one reason why the Code4Lib conference, held this year in Portland, OR, hummed with people inviting other participants to work on their projects. But community requires more than just an invitation or other marketing—it requires resources spent on making the project easy to adopt, on maintaining a common rather than forked codebase, and on fostering easy and open communication.

Of course, all of this is not purely altruistic: sharing your project with others is a way to build a community support scenario and as such is a form of self-interested risk management. Once this is accomplished, the risk of adoption decreases for everyone, including the original implementers.

With open source software, you have an additional escape hatch you don't have with proprietary software. If the support vendor fails to comply, you have the legal right to keep using the software under a community support or homegrown scenario. I'm confident that if Horizon 8 had been open source, there would have been a very different outcome when SirsiDynix decided to cancel an almost finished product (leaving most with no legal right to run it, since it was not open source). Additionally, if many others in the user community agree that available vendor support is insufficient, there is a market for a competing vendor easily to step in—a competitor with full access to the source code.

Of course, whether these escape hatch aspects are even feasible will depend on the situation. Moving to community support requires a thriving community to exist. Moreover, escaping to either community support or homegrown status depends on the capacity of your local technology expertise. You can only escape to another vendor if there is another vendor, which depends on a number of factors including market viability. Finally, all of these options depend on the software code in the product being well architected, well written, and well documented.

Under the right circumstances, these exit strategies can be significant and can serve to mitigate risk (remember, we're talking risk management here). Even if circumstances are not right to make use of these alternatives, you are still no worse off with a support contract for open source software than you would be with a support contract for vendor-supported software.

Now, while these escape hatches are important benefits, 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 LibLime and Equinox offer sound support for open source ILS options.

Since ILS software is so vital and the risk of failed support so great, Koha and Evergreen (in different ways) both jumped very quickly to a vendor-support situation via LibLime and Equinox, respectively. This was a conscious risk management strategy from institutions that had the foresight and courage to take the initial gamble and put resources into moving toward vendor-supported status. We owe these vanguard libraries a debt of gratitude, as they made it possible for the rest of us to benefit from vendor-supported open source at significantly less hazard to our organizations than that taken by the early adopters.

Another way a product can jump to a vendor-support scenario is when software originates with an existing strong vendor but is released with an open source license. We see this 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 the reins too tight 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.

An open source evangelist (and I include myself in that category) would be doing a disservice to the library community and to the success of open source if they were to dismiss the existence of risk in open source and ignore the different natures of those risks. It's true that open source software and support may not be appropriate in every situation, but it's probably also true that in any organization there are some appropriate circumstances for the right open source software. Even the most risk-averse organization may be well served by an open source product with the right vendor package. Remember, an open source product with vendor support is not inherently any more or less risky than a proprietary product.

Risk management can sometimes include taking on a large risk. Whether it is wise to take on significant support risk will depend, among other factors, on 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 salvaged as learning experiences and interesting experiments, while others can be organizational catastrophes. Which to expect depends in part on how many resources you put into the experiment—staff time, money, and lost opportunity to pursue other options—and how well you've assessed all of these risks. Risk management is about going beyond risk avoidance and taking action when a risk is justified. After all, avoiding action can itself be a high-risk choice in the long term.

The more organizations we have that are willing to take calculated and managed gambles on homegrown and community-supported software, the more innovation and the better software we'll get. We have started to see proprietary vendors innovate more as a response to the mere threat of open source.

The very survival of libraries as relevant and useful organizations depends on such innovation. For library technology at this point, risk management should not, and cannot, be “risk avoidance.” The library technology community needs to take risks to remain relevant and useful to our users. In the current environment appropriate use of open source technology can often provide a route to innovation.