To Buy or Not to Buy and the Importance of Identifiers

To buy, or not to buy–that is the question:
Whether ’tis nobler in the end to suffer
The slings and arrows of outrageous vendors
Or to take up coding against a sea of problems
And by opposing end them. To code, to commit–
No, more–and by a bug fix to say we end
The heartache, and the thousand natural shocks
That our code is heir to. ‘Tis a consummation
Devoutly to be wished. — With deepest apologies to William Shakespeare

I bet you didn’t know that Hamlet was a librarian. A librarian who was just as pinned on the horns of a software sourcing dilemma as many of us are today. This was one of the takeaways from the OCLC Research Library Partnership June meeting in San Francisco. Previous posts have summarized other aspects of the discussion.

The classic “build vs. buy” debate is certainly not unique to libraries or the institutions of which they are a part, but we all must wrestle that monster. When are vendor solutions good enough? If there is no good solution, how soon might there be one? What happens if we make a major investment in developing our own software solutions and they are eclipsed by the market in 3-5 years? Do we really want to “build tomorrow’s legacy systems today?” (quoted by attendee David Seaman, who is leaving Dartmouth to become the Dean of Libraries and University Librarian at Syracuse University). What if no vendor understands our problems and no commercial solution will ever be good enough?

It was clear from the presentations that this decision employs a unique calculus that takes a wide variety of factors into account. Here are just a few:

• Local ability (staff with coding skill).
• Available development resources.
• Having a problem worth solving that remains unsolved by any commercial option.
• The potential, or lack thereof, of the commercial market solving your problem.
• Whether keeping control over one’s data is important.
• Whether providing leadership in a new area is important to your institution.

For UCLA, Ginny Steele reported, their answers to questions like those above led them to develop their own academic information and profile system. Dubbed Opus, it is “the information system of record for academic appointees at UCLA” and is just now being rolled out, with additional features to come. It will be interesting to see how it works, and how it compares to any similar commercial systems.

A “middle ground” solution that a number of libraries are adopting, including the Dartmouth Library as reported by David Seaman, is to come together with other institutions to collaborate on software development. One of the most robust of such efforts in the library space is the Hydra Project which Dartmouth chose to join.  Such collective efforts have many of the benefits of writing your own solutions while minimizing some of the drawbacks.

Whichever path you choose to take it was also clear from a number of speakers that identifiers are an important part of a modern technological infrastructure. Identifiers can serve as a kind of “glue” that enables disambiguation and linkages to other data sources, among other benefits. Wouter Gerritsma, Manager Digital Services & Innovation at VU University Amsterdam, probably made these points as well as any of the speakers that day, although the need for identifiers wound like Ariadne’s thread through the meeting.