Procurement and an Open Source ILS

There was some discussion on the Koha Mailing List recently about how to go about procuring an open source ILS...or at least, how to remain open to the possibility of moving to either an open source or proprietary ILS.  The thing about the traditional procurement process is that it makes if very awkward (at best) to unmanageable (at worst) for the open source service providers for two reasons:  

1. traditional RFP templates are based on traditional proprietary systems where the vendor makes all the rules about hardware and support and software maintenance.  In an open source world, these decisions are up to the library to decide and make it difficult to compare apples to oranges. 

2. libraries tend to ask for technical details that someone told them to ask for (probably a favorite ILS vendor) instead of focusing on the functionality.  This is a good way to make sure your procurement process gets you the system you want, but it isn't a good way to do a procurement process to really find out what the best product for you is.

So, here's my suggestion for how to go about procuring your next ILS: 

First of all, I recommend that libraries evaluate the products' functionality separate from the pricing.  You can determine the functional capabilities of the proprietary products by issuing an RFP or an RFI or maybe even a questionnaire but that won't necessarily work for the open source products since there is no official sales and marketing department for Evergreen or Koha.  

Therefore, responding to huge RFPs (especially when you have to answer questions that don't really make sense in an open source world) is just too onerous, time-consuming, and very often a huge waste of time (especially if you are working with a consultant that has a boilerplate ILS RFP that they've been using for years....beware.)

I recommend you forget the RFP/RFP process for the open source products and just get the information yourself because...well, because you can!  You can download the products or use a demo server to check out the functionality for yourself.  That's the beauty of it being free and open source (or at least one beautiful aspect).  And honestly, if evaluating the software on a demo server is too challenging for you....it may be that an open source product isn't for you anyway. 

What I can do as a consultant is help the library with the process identifying the functional requirements (what does it need to do) without focusing on "how" it does it (which would be the technical requirements.)  I would then work with the library to establish subject matter experts from each functional area to evaluate the products.  The goal is to end up with a matrix of how each product matches up to the library's need.  The matrix is filled out by the libraries themselves based on  their own testing of the open source product.

As to filling in the same matrix for the proprietary options, you can do that by working with the salesperson.  They won't lend you a demo system to play on (probably).  You could also issue a short, succinct RFI focusing on your functional requirements.

Once you've evaluated the products and know which ones will meet your needs functionly, then you issue an RFQ to the vendors that support the products that you've determined can meet your functional requirements.*  

That means the RFQ/RFP will be short and sweet and you'll be sure to get responses from all the vendors that provide services to any open source products that have passed your functional needs test. A sample of just such an RFP is attached (courtesy of NEKLS) who was a Liblime customer at the time they issued this RFP.

* Another option you have in an open source environment is to contract for development of functional requirements that are lacking.  Say, for example, Koha had everything you needed EXCEPT NCIP support (true) and you've got to have that on Day One.  You could issue an RFQ for development of NCIP support on Koha and weigh the cost of that development (and possibly the time) into your final evaluation.