Must the library live in perpetual beta to achieve agility

An interesting question brought up by David Seaman here at the Readex Digital Institute.  David provided the opening keynote for the conference and in it, discussed a process that Dartmouth College went through this year to consider how the library can become more nimble within our networked world.  How the library can be given a license, if you will, to allow the library to release services that aren’t perfect and are iterative in their development cycle.  And while I can certainly get where David is coming from, I don’t think that the logical outcome is a service model that lives within perpetual beta.

I think that part my objection to this phrase comes from my development background.  As a developer, I’m a firm believer in a very iterative approach to development.  Those that use MarcEdit can probably attest (sometimes to their dismay) that updates can come with varying frequency as the program adapts to changes within the metadata community.  Since MarcEdit doesn’t follow a point release cycle in the traditional sense, could it be a beta application?  I guess that might depend on your definition of beta — as it certainly would seem to meet the criteria that Google applies to many of it’s services.  However, there is a difference I think.  While I take an iterative approach to development, I also want to convey to users that I will support this resource into the future and as beta, that’s not the case.  My personal opinion is that services that languish in beta are doing two things:

  1. telling users that these services are potentially not long-term, so they could be gone tomorrow
  2. giving users a weak apology for the problems that might exist in the software (and deflecting blame for those issues, because hey, it’s beta).

So, I don’t see this as the road to nimble development.  Instead, when I heard David’s talk, I heard something else.  I believe libraries fail to innovate because as a group we are insecure that our users will leave us if we fail.  And when I hear talks like David’s, that’s what I’m hearing his organization say.  They are asking the library administrators for permission to fail, because what is technological research but a string of failures in search for a solution.  We learn through our failures, but I think that as a community, our fear of failing before our users can paralysis us.  The fear of failing before an administration that does not support this type of research and discover can paralysis innovation by smart, energetic people within an organization.  A lot of people, I think, look at Google, their labs, their beta services and say, yes, that is a model that we should emulate.  But they don’t fully understand I think that within this model, Google builds failure as an acceptable outcome into their development plan.  If libraries want to emulate anything from the Googles or the Microsofts of the world, they should emulate that and engender that type of discovery and research within their libraries. 

I am actually very fortunate at Oregon State University in that I have a director and an administration that understands that for our library to meet the needs of our users now and in the future, we cannot be standing still.  And while the path we might take might not always be the correct one, the point is that we are always moving and always learning and refining our understanding of what our users want today and tomorrow.  What I’d like to see for David’s library is that kind of environment — and I wish him luck in it.

–TR


Posted

in

, ,

by

Tags:

Comments

One response to “Must the library live in perpetual beta to achieve agility”

  1. […] that I don’t like this image or idea of perpetual beta (and I’ve mentioned why here: https://blog.reeset.net/archives/566), David talked about a process that Dartmouth College when through this year to determine how the […]