I returned from a week of vacation to land solidly in the middle of a discovery layer selection process -- not for our library, yet, but from a consortial perspective clearly having some impact on possible decisions for us further on down the road. As the systems librarian, I was nominated as the person with the required technical skills for cutting through the skin of the vendor sales pitches and assessing the meat of the proposals. So far, so good. I'm incredibly busy trying to wrap up a number of projects before the return of the students in a few weeks, but this is important stuff.
As today's pitch went deeply into hour 4, I started mentally tallying up the resources that were being invested in simply listening to the presentations:
20-odd library folk from various libraries
8 vendor presentations
~4 hours per presentation
= 640 person-hours
At an average of thirty person-hours per week (a rough project management estimate allowing for vacations, sick leave, lunch, etc), that's going to result in at least 32 person-weeks of effort that could have been invested in taking an open source application like Blacklight, VUFind, or Fac-Back-OPAC, polishing it up to meet the requirement specification, and contributing back the code for the common good of all libraries. The secret sauce to all of these applications is Solr, a faceting full-text search engine (excuse me, "information access platform" in Endeca marketing speak). A few more person-weeks of effort invested in Solr might finish off some of the features that are almost ready for prime-time, like dynamic update of individual fields within a single record.
I know that the buy or build decision is complex. I know that it's very comforting to have someone to blame on the other end of the email, or telephone. But folks? When you're looking at investing in annual support and licensing fees, and possibly roping in 20 fellow libraries, that's a heck of a lot of resources to be committing to technology that's only slightly more advanced (in the best case; significantly behind, in other cases) than existing open-source solutions. And let's face it: with most of these solutions, you're going to be investing the equivalent of a person-year or more in customization costs before you even get out of the starting gate. This particular process may already be too advanced to change direction, so perhaps all I can do is plead with other libraries and consortiums facing a similar decision in the future to please consider the build option (and really -- it's a "build on top of existing components" option, not a ground-up deathmarch I'm talking about) seriously.
If you have concerns about the process please raise them during the web sessions. We go to a lot of trouble to create opportunities for input and we hear nothing -- then we hear carping on blogs or other venues that don't contribute to the process because no one hears them in context. Speak up -- it's the only way to be heard.
Alan
Thanks for reading my blog. I'm sorry that you take this as carping; I feel that I am speaking up, to a much wider audience than just UofT / OCUL, and that my speaking up may help other institutions and consortiums more seriously consider the "build on open source" option in the future.
How to integrate this potential option into the traditional RFI process is an open question; perhaps you hand-pick a two or three person team from inside your organizations with the appropriate skills (project management, software development, vision, ...) and ask them to submit a response to the RFI.
I'll address specific comments about the UofT / OCUL process to the appropriate venues.
2. I'd like to hear/discuss the arguments for "build your own" using open source software.
Also, in response to your response in the comments, my library tends to select small teams to meet with vendors and appraise proposals for all but the last steps of adoption.
Thanks for the post!