Of course, not everyone wants to develop and program their own ILS.  This doesn't diminish the appeal of a system that allows you to implement changes based on your desires.  A system that isn't going to vanish just because a bunch of venture capitalists bought your ILS vendor and decided the next day to cease distribution of the system to which you had spent years preparing to migrate.

The answer to this dilemma is a company like LibLime.  They have taken Koha and developed their own version of it.  As you will remember, under the open source license you can modify the software however you please and distribute it.  Customers of LibLime are paying not for Koha but for the work and vision LibLime put into their "version" of Koha.  After that, it is much like dealing with a traditional vendor: They deliver the software and help you deploy it.  Or maybe they do all the set up work.  They maintain a support system that you can call if you have questions or problems.  They periodically roll out a new version.

Here are the differences.  While your library paid for support services, there was no initial licensing cost for the software.  The upfront costs, therefore, are generally going to be much lower than with a proprietary ILS.  LibLime is a relatively small company with 22 employees and 300 customer libraries, which gives them the potential to be very fast when it comes to updates and requested features.  Joshua gave several examples of libraries submitting ideas for improvements which were implemented in the next release (they do releases quarterly).  I couldn't help but wonder what happens as the customer base expands; presumably, they do their best to expand their labor force to compensate.  I don't know how successful they have been in this area but I do know that they had one employee and one customer library in January 2005.  I also know that there has been a steady flow of respected veterans of the ILS industry to LibLime.  They must be doing something right.

Getting back to the whole concept of feature requests, I was a little taken aback when Joshua stated that most new feature development into LibLime's version of Koha were driven by customer libraries.  He implied several times, in fact, that they are reluctant to add new features without a customer to "sponser" them.  Why would they spend resources to develop new features if they don't know that anyone wants them?  An interesting concept and one that I have mixed feelings about.  I suspect that Joshua was engaging in a bit of hyperbole.  I love the idea of a vendor that is committed to quickly filling new feature requests.  But I also love the idea of a vendor that is always looking forward, thinking about the future of library automation and positioning themselves accordingly.  The inability to do this has been one of the cardinal sins of commercial ILS vendors, in my opinion, and is at least partly to blame for the wretched state of the industry.

Joshua also implied several times that they are willing to implement just about anything if there are customers who want it.  Again, I love the idea but wonder what will happen when they have a few more customers and the requests start to conflict.  Having said that, I found Joshua's approach refreshingly positive and upbeat.  One gets the feeling that you could really get something done partnering with such a vendor.

The rest of the day was spent looking at the features and functionality of Koha, as developed by LibLime.  I'm not going into much detail on that.  It's difficult to adequately convey this kind of information in a blog post.  Suffice to say that I liked what I saw.  I'm not sure it's quite consortia-ready but they are in a good position to get there, in my opinion.  And LibLime has netted a number of consortia recently:  MassCat, WALDO, Central Kansas Library System, Northeast Kansas Library Systems, and Indiana Shared Library Catalog.

This is one to watch.