The pain: discovery layer selection

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 libraries8 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.