This pretty much sums up exactly where we are at right now.  We're opening a brand-spanking-new library and archive and we're looking at "buying, borrowing or building" each system we need: ils, archival management system, digital asset management system, digitization processing/workflow, and more.

The issues I've encountered so far is that buying often entails a significant financial commitment, and that if you don't know exactly what to ask for, you may have to end up paying extra for it down the road.  This has been a huge issue for us, namely because we can't articulate all our needs yet. Right now, we have very little content or data: We have no cataloged books, so no MARC data, we've only just begun to create finding aids for our archival collections, we haven't started digitizing anything, and what's more, we have no users yet because we haven't even opened our doors!

It's a tough situation to be in because you have to guesstimate a lot, and we worry that we'll either end up paying $$$ for a fantastic system that is way too much for our needs, or we'll underestimate and after committing to a vendor we'll have to pay more for functionality that we didn't negotiate up front.

This makes the build option attractive because you have a lot of flexibility to scale things up or down, or add new services.  However, there are costs in terms of human power.  I'm the only tech guy, so I'd be doing all the programming work.  I've floated the idea of hiring programmers for certain things, but it's hard to say whether paying a vendor for a system would be more or less expensive that building your own with the costs of human resources like programmers and the like.  If you do build your own, you're usually not tied to any contractual agreement, but it's usually those agreements that provide support for your product when things go wrong.  In the "build-your-own" scenario, you are your own support, which is another cost addition that's hard to quantify.  In the end, however, if you build it, it's yours to keep and share with others should you choose.

This brings me to the borrow option, which may prove to be the best solution for us, depending on the system.  For example, we're looking at partnering with another institution for our MARC and ILS needs.  There are tons of consortial organizations that offer similar services, but it tends to be a "one-size fits all" kind of thing.  For basic services, this isn't such a big deal.  ILS-es are fairly straight-forward.  Yes, they're complicated, but they've been around for a while and I don't see much point in building your own one of those since there are so many choices out there, open-source or otherwise.

As we look at choosing systems for our own institution-specific needs, we're finding fewer "buy" options that fit the bill.  This means building some systems from scratch.  Building will take a lot of my time, so it's important to use the buy and borrow options for things that I'm confident will not require lots of additional work maintaining.  Buying and borrowing are ideal here because there's already some kind of support and maintenance framework, which should (ideally!) give you more time to code.

So, I guess I'd break it down like this:

Buy:
 - great for specific needs with lots of known variables
 - best used for "well worn" solutions
 - should always have good support
 - be prepared for real costs of subscriptions and additional functionality

Borrow:
 - ideal when your needs align with the needs of another that already has a solution
 - great for collaboration
 - contractual agreements may be needed
 - can have good support, but not always
 - should continue to work so long as everyone's needs are the same

Build:
 - great for unique requirements or solutions with a lot of unknowns
 - use collaboration if you can
 - you can take it home with you
 - be prepared for human costs (coding, testing, etc.)
 - scalability, maintainability, and flexibility are the big issues

I should add that you can combine these in different ways such as purchasing or borrowing components that your build into one solution.  We're also trying to plan ahead as much as possible and build-in flexibility so that if we need to switch to something else, either go from build to buy, or buy to borrow, etc. when we find our needs changing, we can do that without hurting ourselves too much.

These are just my thoughts from what's happened to us so far... feel free to disagree/agree/chime-in

...adam



-----Original Message-----
From: Code for Libraries on behalf of Frumkin, Jeremy
Sent: Thu 5/6/2010 2:32 PM
To: [log in to unmask]
Subject: [CODE4LIB] Buy, Borrow, or Build
 
Hi all -

One of the interesting tasks on my plate this year is to devise a document that reflects a strategy around "Buy, Borrow, or Build" as relates to technology approaches here at the University of Arizona Libraries. Below is the text of this "reference architecture", and I am particularly interested to hear comments from the community regarding this document. 

 
Rock & Roll: (noun) African American slang dating back to the early 20th Century. In the early 1950s, the term came to be used to describe a new form of music, steeped in the blues, rhythm & blues, country and gospel. Today, it refers to a wide variety of popular music -- frequently music with an edge and attitude, music with a good beat and --- often --- loud guitars.© 2005 Rock and Roll Hall of Fame and Museum.
 
This communication is a confidential and proprietary business communication. It is intended solely for the use of the designated recipient(s). If this communication is received in error, please contact the sender and delete this communication.