post

Sound and Fury: Choosing an ILS

I published this article a few years ago in Computers in Libraries.  Nothing in it will be revelatory for most open source advocates but at the time I got a lot of feedback from librarians that it was useful.  CiL’s exclusive publication window is long since past and I just thought of it the other day so I thought I would re-publish it here.  Four years later I still think it’s spot on though I would probably make some changes to either shorten it more or make it longer with practical examples.  


Few decisions cause a library director to fret more than choosing a new integrated library system (ILS).  A new ILS is expensive in money, staff, time and stress no matter what you acquire.  Additionally, the wrong choice can bear costs in morale with lasting consequences.  Sometimes it is easy to identify which ILS is wrong for you – the contract costs are too high or maybe the features are not present that you need.  But, too often selecting the right one is like going to a car dealership where everyone speaks in tongues and the price lists are encrypted.

This is the result of a decade of market disruption.  Once upon a time proprietary ILS vendors were not optional.  Picking the right ILS was fraught with danger but not conceptually difficult.  Two changes in the market have had an enormous impact.  One of these, the growth of applications as services has added new options to the ILS selection process.  However, it has been the growth of open source ILSes, such as Koha and Evergreen that have made it necessary to rethink the selection process. 

Choosing between an open source and a proprietary solution is not a choice between peaches and pineapples.  Frequently, it is assumed that the two types of ILSes cannot be evaluated by the same criteria.  In fact, they can be.  Although they result from radically different economic models and divergent philosophies, in the end both are products and services that can be defined by a library’s needs and resources for the purposes of acquiring.  Four major criteria must be compared – product cost, features, communities and support.  Until open source disrupted the ILS market one could safely ignore communities.  The community of a proprietary ILS product might have added value but it was unlikely to either make or break the selection of an ILS.  Now community plays a much more important role but that will come after we look at the other criteria. 

Perhaps the first thing to dispel is the myth that open source should be discussed as the cheap option. The wise library administrator will realize that while many of the best things in life are free, your ILS isn’t going to be one of them.  Your cost won’t always be in legal currency.  I have met staff so traumatized by a bad migration that they are still visibly shaken years later by what is now a stable and reliable tool.  The library has paid an ongoing price in terms of post traumatic stress and that cost can be too high.  The best migration is pointless if the library’s experience falls apart within a year or two causing the whole thing to happen again – an experience I’ve seen happen with both open source and proprietary.

Each of the four criteria can have multiple metrics as well as multiple vectors to plot them on for both a migration and on going support.  In the end a data set for ILS selection should probably look more like a scatter chart than a report card. Now, can we simplify the process?  The answer is yes.  A detailed consideration would be worthy of it’s own book but by taking a few conservative shortcuts we can sketch a road map for your selection process in a period of time that isn’t comparable to earning another master’s degree.  For example, we will assume that you have the same vendor handle a migration as ongoing support.  This will not be a road map for the adventurous.  This is for those whose boards will require that all core functions work on the day of go live with minimal surprises.  And being conservative does not exclude you from an open source solution.

First, do a needs assessment.  This is the point at which many upgrade processes fail.  Rather than say something like “we need acquisitions” or “we need EDI” do use cases and narratives.  These should create an unambiguous picture of your needs.  Be careful to not attempt to recreate your existing ILS.  This is the point at which libraries realize how deeply embedded their current ILS is in their operations.  The documents you produce at this stage will be used extensively in working with vendors.  Be honest about what you need and what is merely on a wish list.

Now, find your vendors.  Don’t even worry about the ILS itself yet.  That may sound heretical in an ILS selection process but you need to safeguard from fixating on a single product and not evaluating honestly.  Fixate on your needs instead. Some vendors will support multiple ILSes and at this stage you are looking at who can provide support during a migration and ongoing.  Look at each vendor’s ability to support hardware, provide reliable access, and expertise with the ILS, their ability to find solutions, their training resources and expertise at setting a system up.  Do yourself a favor and look in depth at their experience with data migration – it is surprisingly hard to do well.  Do not let a vendor make vague promises about your data.    Looking at vendors before solutions may seem to be putting the cart before the horse but in the long run the greatest frustration most libraries have with an ILS doesn’t stem from software but support.  At this point you should also rank yourself as a vendor to see if you want to fill some of these support roles yourself.  Be honest about your ability to sustain support.  Many libraries begin projects that falter when key personnel leave because the skills are not part of the institution.

Many open source advocates argue that support is an inherent advantage of open source.  Some libraries delay leaving an ILS they are unsatisfied with the support of due to the stresses of migration.  If you use a vendor for support of an open source ILS they cannot lock you into the ILS itself.   Once your contract is up, if you leave a support vendor and extract your data you can import rather than migrate your data into a new system.  That ease of changing support vendors without changing software means that open source support companies have to compete on the basis of support because the threshold of difficulty for the library leaving is reduced by orders of magnitude.

The next step is to define what kind of support contract you want.  Do you want a local install with minimal support, do you want local with remote administration or perhaps an application as service where you sign a check and everything is just made to happen.  At this point evaluating yourself, as a potential vendor, will help you determine if you want to exclude yourself.  A product supported fully by a reputable vendor with skilled support staff is what you’re looking for.  Increasingly, the choice most libraries make is buying an application as service.  Vendors can take advantage of high capacity Internet connections and big virtualization systems to achieve economies of scale and offer remote hosted ILS services much cheaper than a library can locally offer it.  But, you may have factors, such as response times needed, which make a local installation more attractive.  Knowing what kind of support contract you need you can begin looking at the packages offered by the vendors and dramatically simplify the rest of the process.

Next, make two lists to look at support and features separately.  Vendors need their feet put to the fire to answer if they can fill your needs, which is why the use cases and narratives are critical.  Find out what the vendors’ uptime guarantees are, what their response times are and what tiers of support they offer.  For example, do they handle user interface level troubleshooting, will they do custom development to solve issues, or do they simply do systems administration?  What services do they offer during the migration?  Can they extract your old data?  Can they offer project management or training?  Will they offer documentation?  Now, some of these resources may originate in part or whole from a community but at this point worry about the availability through the vendor and their obligation to you to make it happen.  List the support levels of each vendor.  Go back to Buying An ILS 101, call references and do every other thing you would do with any big-ticket purchase.  

Parallel to support, review the ILSes themselves and isolate what software will be viable for you.  Make sure the vendors support those features and how you want to use them.  I’ve had clients spend a lot of time preparing to move to a system only to have their vendor say, “we don’t support serials” even though the ILS has the functionality.  Return to those use cases and narratives your staff developed earlier.  While sharing the use cases get a detailed analysis of what your narrative experience using the ILS(s) will be.  If they can build a comparative scaled system (number of patron, bib, copy records, etc..) for you to test against this is critical for applications as services.  More than one library has been burned by not seeing their data run at scale and not doing hands on features testing.

Think about future features too.  Will there be things you can’t anticipate or live without?  Will the new social network that everyone gushes over be critical two years from now?  Can the company you are working with provide you with development options?  If not, then open source may provide you with other kinds of development paths depending upon the community surrounding it.  What about wish list features?  Maybe like William Henley you want to be the captain of your own soul, or at least ILS.  Ask yourself if you want to make changes to the software and control those changes in the future.  If the answer is a firm yes, then you probably want an open source ILS and will need to allocate resources for development.  Don’t automatically discount a proprietary vendor but giving you that control is not usually a part of their business model.

It is also worth asking if you want to be part of a consortium.   Although really large resource sharing consortiums aren’t unique to open source they do seem to be more common with growths in the Evergreen community, like SCLENDS.  Materials sharing may or may not be on your agenda but adding to an existing installation has a lot of advantages including a built in local community to draw on.  

Since applications as services are delivered over Internet connections it is important to know the impact they will have on your connection.  Prolonged profiling will tell you when you may have interruptions in service and what delays in response time you may have.  Map obscure phrases like “ping times” and “drop rates” to real measurements like “it will take 2 seconds to check out an item.”  Often time, work flows can be adjusted to handle the increased latency from moving an ILS from inside your network to remote hosting but an unexpected impact like that can heavily damage morale.  This is a time to bring in heavy-duty network expertise and make sure they go over issues with a fine tooth comb.

Finally, we get to every library’s least favorite topic that isn’t protected by confidentiality laws: budgets.  Take those support options and the ILSes by the vendors you find acceptable and map them against how much you have to spend.  Any that you can’t afford, toss.  What you’re left with is ILSes that will work for you, companies you can trust to support you and an experience you can afford.  Be wary of rushing into support contracts for applications as services though.  Compare your costs across the lifespan of the longest contract you would have to sign – which should be three years.  A longer contract than that which locks you in should be a concern.  Make sure there are guarantees about maximum rate increases and reasonable rates for extracting data. 

Many an ILS has been chosen because the library administrator feels overwhelmed.  An implementation by the current ILS vendor can seem like an easy and safe choice. That is a poor assumption to make.  In the course of development or corporate acquisitions sometimes the upgrade path defined by a vendor is actually to a whole new product.  When that happens an upgrade is really a migration.  So, donÕt be deceived by the potential level of difficulty of the project.  Vendors like to define upgrade paths because they know many local governments provide clauses that allow organizations to upgrade without going through a competitive bid process.  ThatÕs also how you can get stuck doing two migrations in two years Ð something no one wants to do.

At this point you may be ready to select an ILS but you should take one more step.  So far we have flattened out the modern twists to ILS selection and used a model built on common sense.  The next criterion is not a leap into uncommon sense but it is much harder to define.  Evaluating community requires the administrator to understand how their staff as professionals will interact with a larger community rather than perform workflows.  Community is not an open source specific criteria though it might be more central to those ILSes.  The communities of proprietary ILSes can be hampered or facilitated by the corporation linked to the ILS.  Open source ILSes are built by their communities but may still have large corporate presences.  When evaluating those dynamics don’t frame the discussion as business versus community, as that’s a false comparison.  Evaluate the businesses as members of the community by their actions and consider that when developing a picture of the whole community.  

As you investigate vendors, how they interact with communities might tell you something about the character of the company.  Does it allow for independent user groups and conferences?  Are there emails lists and public forums?  Are there places to share and ask questions of others who use the ILS?  Some proprietary ILS vendors have encouraged these things and allowed outside repositories for documents.  In open source communities these are the norm.  Do not underestimate the value of community.  Not only do ILS communities help you make the most of one of the largest pieces of your infrastructure but also an active engaged community can be invaluable for the professional development of your staff.

Look at your resources and ask if you are the kind of organization that is ready to be part of a larger community or if you prefer to play alone on your own ball field.  Sometimes it is the larger libraries that are less prepared to be strong community members because they are accustomed to making decisions as an independent entity.   In the end you may choose to leave community out of your considerations for an ILS selection. However, at least some awareness of the larger community should always be there, to compare experiences with a vendor at the very least.  If you are using an open source ILS vendor and you successfully vetted them they should be involved in the community and may be a gateway to you becoming involved in the future if your priorities change.

At this point you have decided on the viability of a given ILS migration and looked at communities as added value.  Do you need a tiebreaker query?  If you do look at what your gut tells you.  The truth is that for all of our development as a species we still sometimes process information subconsciously and have gut instincts that lead us well. Do you have a philosophical leaning towards open source?  Does one vendor click as a partner? 
 
If you are willing to endure some hardships you can play fast and loose with this process.  Risks can pay off but it’s a luxury most boards don’t give their directors.  Open source succeeds where it is the best solution, not because of philosophical biases just as commercial software succeeds when it does so on quality, not on spreading fear, uncertainty and doubt about competition. As we look critically at these solutions, their vendors and communities we also have to look to the future.  Mark Twain said a sure way to look a fool is to try to predict the future.  But we need a sense of how the future of these ILSes will unfold since we will be tied to one once we make that selection.  Communities and companies can be filled with amazing people who can make all the difference, and they can fall apart.  Engagement with partners in companies and communities are where we will the future unfolding.  We need to remain aware of these dynamics – they are often why we end up moving to a new ILS after all.

post

SQL for Librarians

Here it is, SQL for Librarians.  I closed out the Cambridge Evergreen Conference (for good or ill) and actually keep a few folks there until 12.  I had a lot of great comments so I think it was fairly successful despite being a tad loopy from allergy medication.  And I blame the medication for a few things that upon listening to this I cringed at.  In a perfect world I’d love to do this again and do it with a full workshop format.  

Slides: http://www.slideshare.net/roganhamby/sql-for-librarians

Youtube: https://www.youtube.com/watch?v=3Iz-HFiDq6E

Conversations At ALA About ILSes

Normally I leave my rabid pro-FLOSS pro-Evergreen attitude for the web.  In person I make a conscious effort to not be so forward as it’s usually a hinderance to meaningful conversations.  Today at ALA in Vegas I threw that rule out the window.

I didn’t do it right away but eventually I was worn down.  Worn down by what you ask?  Since this morning, I’ve had six conversations with people bitching about their ILSes.  And their complaints were legitimate.

“I went to Blue ILS years ago and it was great but the founders left and they’re now evil corporate sociopaths who abuse us regularly.”

“I was about to go to Red ILS which is great with great support but they just got bought out by evil sociopaths and I don’t feel good about this anymore.”

Valid concerns.  What annoyed me was the fatalism.  “Whatcha gonna do?”  Go open source.  There, I solved it for you.  I told the last one that in those terms.  I usually say it anyway but with more respect for the difficulties their situations face.  But I’m tired of having those issues used as excuses for why libraries should allow themselves to be abused.  The difficulties make things non-trivial, maybe even hard, but not impossible.  And it is the answer.  If you’re not being abused, you just wish it was better and you’re willing to live with it because you have higher priorities then that’s fine.  But if your voice sounds like you’re beaten regularly when you talk about your ILS vendor  … yeah, you need an intervention.

So, how do you do this?

Well, you could host yourself in which case you only have to trust yourself.  But, that may not be efficient.  I use hosting from Equinox Software.  My hosting and support provider has the advantage of expertise from hosting many installs and economies of scale.  Why do I use Equinox? Because I trust them.  Why do I use Evergreen and open source?  Because I don’t have to trust them tomorrow.

Implicit in the complaints is lock in – whoever they go with for support owns the software.  Changing support means changing software which is a huge deal.  But when no one owns it, everything is different.  My contract allows free access to my data.  If the leadership changed at Equinox I would just change service providers.  My users won’t know.

And yes, that’s why open source is the answer.  There’s no reason for anyone to ask me if I’m happy with my ILS support because if I wasn’t, I’d just change it, year to year if I had to.  And that’s a very good thing for my library.  

Sharing is Good Business

I was thinking today about intellectual property in the library world.  Specifically, what prompted my musings was Elon Musk’s blog post about patents and the Tesla Motor Company last week.

http://www.teslamotors.com/blog/all-our-patent-are-belong-you

Already the global news cycle has come and gone on it.  But, I think it’s interesting to think about the obligations of those interested in shaping social change and how intellectual property plays a part in that.  Next week I will be at ALA and one of my favorite parts of a large event like ALA is looking at the vendor floor filled with businesses eager for my library to accept an invoice.  But the question is, are they people I want to do business with?

Let me back up a bit.

Elon Musk has stated that his goal isn’t merely to build successful businesses but to push the world forward.  And he’s now realized it has to inform how he as a capitalist interacts with and shares with others.  He wants to help create a common baseline any manufacturer could build a vehicle off of.  Should all businesses have an obligation to help move the world forward rather than just their profit margins?  Is there a possibility of one day developing a core set of freely shared technologies that anyone could build an ILS from?  Oh, wait a minute, that’s already being done …

Stepping back a bit more, the industrial age was dominated by the development of technologies that allowed goods to be made in greater precision and volume than ever before.  Often the knowledge of how to do this was freely stolen.  Note, I don’t say they were shared but once a competitor acquired the knowledge of how to do something there was little going back.  And I’m not saying that this was good but it was an aspect of an age of expansion.  We did socially reap benefits from information being distributed, even illegally. 

The information age finds us making goods out of information itself.  Never have we been so well prepared to defend intellectual property.  As a society we litigate – comprehensively and aggressively.  Maybe we instinctively hoard information because we know it is valuable.  And libraries, entities who should be at the forefront of sharing, who make our very existence off making information available to our patrons, are as guilty of not sharing as anyone.

Fortunately, that is changing.  OCLC is embracing the Open Data licence and is encouraging their members to do the same, which is a wonderful thing.

Open Data Commons Attribution License

I would love to see this go further into institutional data far beyond what is collected on the state and federal level.  I periodically find archives being loaded on the web by libraries using some variant of the Creative Commons licences, also a good thing.

When we share, everyone wins

And finally, a few libraries are embracing Open Source.  The licences vary by project but the heart of all the licences is allowing new tools to be built on existing ones.  And there are many small projects like libraries to handle data types or protocols but those are building blocks.  Musk realized that he had to start sharing how you stack the building blocks – how you make the big stuff.  Are we doing that?  Frankly, Koha and Evergreen are pretty big things so companies involved in improving those are already building, and changing, the future.  Opening ILSes, making them freely available, giving powerful tools to everyone regardless of income, valuing knowledge over money, these things change the world if they gain enough adoption.  Don’t believe me?  Look at Linux, Apache, PHP, MySQL, Postgres, Perl and so on.  If you think widely adopted open source products haven’t changed the world you live in a state of denial.

Musk realizes that companies need to change the world as there is a role there no one else will fill.  His businesses are means of supporting positive change as well as generating profit.  Being open is not anti-capitalist, it’s an adaptive strategy for a changing world.  He’s invoking the ideology of the FLOSS movement in his blog entry even if he is not participating in it.  The simple act of adding to the base of freely used, functional, technology gives the future a deeper toolbox with each contribution.  That is a morally virtuous act that he wants to align with even if he can’t adopt it due to the nature of the patent system.  But it’s not the moral element that fascinates me about Musk’s entry, it is the implication he makes that by opening access to technologies protected by his patents, essentially vowing to not pursue his intellectual property rights, he is declaring that is the ethical mandate of his company to share.  To rephrase and repeat, like any good reference librarian, Elon Musk is saying that profit is not the sole ethical mandate of his company. 

I would call out library corporations to look at what they can open source or at least share by some means.  I would say that library vendors who don’t share where they reasonably can are acting immorally.  Note, I don’t say unethically, that is an entirely different matter, determined by their own corporate structure.  In fact I worry that they have an ethical obligation in their roles to do immoral things.  

What can they share?  I don’t know.  Clearly it’s not realistic for an ILS vendor to GPL their entire codebase and dump it on Github.  But I find it hard to believe there isn’t anything they can share.  Maybe a library of code for RDA checking.  Maybe a Z29.50 server.  Maybe a network diagnostic tool.  Maybe data about usage needs.  

Elon Musk’s blog post raised eyebrows because he rejected the idea that hoarding information is a business’s ethical obligation.  We already have vendors who support open source and believe that sharing is an ethical requirement to being in the library community.  I think libraries should hold vendors to that standard.  I want to support companies who act in a manner I think is both ethical and morale in regards to supporting not only my library this fiscal year but the libraries of tomorrow and open source is a big part of that.  

Sound and Fury

Well, I got home from a road trip to find my comp copies of the July/August Computers in Libraries waiting for me and some emails!  I sat down to re-read it because frankly I wrote it long enough that I don’t remember much of what I wrote.  

http://www.infotoday.com/cilmag/jul13/index.shtml

The article is about open source, including Evergreen, and selecting an ILS.  A few bit things:

1) They gave it a nice attractive spread.  That’s vanity on my part but I like it. 

Front spread of the article.  

Front spread of the article.  

2) I’m still happy with my opening paragraph.  “Few decisions cause a library director to fret more than choosing a new integrated library system (ILS).  No matter what you acquire, a new ILS is expensive in terms of money, staff, time and stress.  Additionally, the wrong choice can damage morale and having lasting consequences.  Sometimes it is easy to identify which ILS is wrong for you – the contract costs are too high or maybe the features that you need aren’t present.  But, too often, selecting the right one is like going to a car dealership where everyone speaks in tongues and the price lists are encrypted.”

3) They re-used an old bio bit for me from my days working at the State Library which is wrong.  I’m at the York County Library System now.

Now, for the email I got and my response:  

From Greg, full name withheld to protect the guilty 🙂  :

I just received my copy of the publication “Computers In Libraries”, July/August 2013. I thought your article “Sound and Fury” was an excellent guide for libraries considering a migration of their library systems, but I was a bit surprised that you cited “LibLime Koha and Evergreen” as examples of open source ILSs. I rather suspect that many open source people would regard LibLime Koha as open source only by the letter of the law, and not by spirit or community. Evergreen is indeed an excellent example of open source software, but I wonder if it suffers by its apparent close association in this context with LibLime Koha.

Koha (!= LibLime Koha) is a much more openly developed and community supported example of an open source application than the LibLime fork. Your article deals very well with the subject of selecting vendors; the paid-support page for Koha (

http://koha-community.org/support/paid-support

) lists 37 vendors world-wide (if my quick count is correct and deducting two entries for PTFS). I’m under the impression that only PTFS supports LibLime Koha, but perhaps there are others. Many of the listed Koha service providers provide hosted application (ASP) solutions as you mentioned in your article. 

A quick count of my Koha mailing list messages for July 24-31 shows 86 entries (sorry, I got tired of counting after going backwards for one week), that probably extrapolates to about 350 messages per month. I don’t follow the free support for LibLime, but I’ve been told that it’s more questions than meaningful answers. Link of possible interest: https://listserv.nd.edu/cgi-bin/wa?A2=ind1308&L=web4lib&D=0&P=15401

Code contributions to the Koha development process are encouraged, with contributions and downloads available on a git code management system, and packages are available for Debian-based operating systems. Koha also has an IRC channel where developers discuss issues, and where users can <mostly> ask questions and get answers to problems they are experiencing. I’m not aware that LibLime Koha is as openly developed or freely supported. 

Again, I thought your article was excellent, but have misgivings about your citation of LibLime Koha instead of Koha as an example of open source software.”

My ill thought out but honest response:

“Hi Greg,

I appreciate the feedback.  Looking back at the article I’m a chagrined about that.  I admit I’m an outsider in the Koha community though I have a fondness for any open source library project.

Just last week got a chance to chat at length with a gentleman [name and association redacted to protect those who didn’t give permission to be used].  He actually reached out to me because of an upcoming talk I’m doing. I was aware of some community conflict with LibLime but he gave me a lot of context of the Koha VS KOHA issues.  Suffice it to say that if I had known I would have mentioned Koha differently.  Technically what I said is correct but obviously doesn’t address the serious community concerns there and looking at community is central to the issue I wanted to discuss.  

Maybe on some level it’s best to not have written about that there.  It really is an issue that deserves discussion in more depth.  I’ve thrown out the idea to the editors of CiL of doing an all open source issue (it’s been about four years since they’ve done one).  If that happens I would love to work with someone to write about the Koha community issues in more depth. Still, whether it was the place for it or not I think I would have written that bit a wee bit differently.  I’m always glad to get opportunities to trigger discussion (even if the price I pay is putting my foot in my mouth occasionally).   “

 

Looking back and getting to read my article again it doesn’t really detract from it.  It’s just a quick reference at the beginning but I do regret it and feel that I should write something about communities in open source projects as a follow up which makes me start thinking about projects beyond Koha and Evergreen, failed and successful to look at.

New CiL Article Referencing Evergreen

The new issue of Computers in Libraries (May 2012) features articles about curation and collections.  My own article about de-duplication 10% Wrong for 90% Done: A Practical Approach to Collection Deduping approaching bibliographic was not only selected as a feature but their freebie available directly on the web.  So be enticed, buy the magazine.  Actually, I have a fairly high opinion of Computers in Library compared to the other outlets that dicuss library technologies.

Anyway, in it I discuss the approach we within SCLENDS choose to handle bib dedupping and build a solution that was economically feasible, was positive customer experience centric and could be implemented fairly quickly.  As an Evergreen consortium already live timeliness was important to us.

Although I didn’t post about it at the time, I should mention that since the article mentions me at the South Carolina State Library I have now actually moved to York County as their Manager of the Headquarters Library and Reference Services.  It is nice to be back in thick of public service including children’s and outreach which I’ve dealt with less since I worked more with reference and circulation staff at the State Library (though those are among my departments now too).  I am still working with SC LENDS though and have been retained to continue my project management duties there.

Open Source Reality Check

Library Journal just published an article they interviewed me for entitled Open Source Reality Check.  

http://www.libraryjournal.com/lj/home/891350-264/open_source_reality_check.html.csp

Over all, I thought it was one of the more balanced and fair articles looking at open source from a high level perspective that I’ve read in main stream library journals.  Open source isn’t perfect, it’s a human endeavor after all but it is a proven model though indivdiual projects can fail.  The article spends a lot of time looking at KCLS, which is to be expected.  The bit they quoted from me was me discussing, and dismissing, the idea that open source is somehow magically less stable than commercial software.  The factors that make an open source project stable have to do with scale, which is also true of commercial software – it is the metrics that vary.  

Oh, and they got my place of employment wrong.  I was at the time of my LJ Movers and Shakes award with the Florence County Library System but I’m now the Director of IT and Innovation for the State Library in SC.