Last month’s Digital Library Federation forum involved a number of interesting discussions, both at the conference site and online.  This forum, different from previous ones, centered around discussions of strategies for innovation in libraries.  It also involved discussions of the future of DLF itself, which earlier this year ended its independent existence and was merged into CLIR.

One theme that quickly emerged in discussions was the importance of failure.  It’s a topic we often feel uncomfortable discussing, especially when we had a hand in whatever failed.  Part of the discomfort in the digital library community has to do with the dual nature of what many of us do: We manage programs and services, and we also try to innovate.  As managers, we don’t want our programs to fail.  (If that happens anyway, we’d at least like to avoid being blamed for the failure.)  And libraries have long-term ongoing service and preservation obligations that make certain kinds of catastrophic failure unacceptable.

But as innovators, we want to be open to failure as a way of learning.  “Fail faster!” is a common slogan of innovative labs and ventures, and knowing the “thousands of ways that don’t work” (part of a quote often attributed to Thomas Edison) help us better understand the ways that do.  I’ve mentioned before that my most widely-cited paper was written about the failure of a software development project I helped work on.  And a new scientific theory isn’t usually worth considering until it is capable of failure– that is, it makes definite predictions that subsequent observations can either confirm or refute.

If we are really serious about innovating, we need to respect failure, and leave room for it.  We need to let people try things that might not work, allow time for encountering dead ends, have contingency plans that let us continue to carry out our missions even as failures occur, and note both what worked and what didn’t in the things we try.  It’s especially useful to note things that we found didn’t work before they were obvious to others, since we might well save others a lot of time avoiding the same pitfalls.

How should these failures be reported, though?  It’s often easier and more gratifying to publish stories of success than stories of failure.  And if we talk about our failures in public, whether in a journal, at a conference of like-minded professionals, or even in a blog or tweet, we may have good reason to worry that it might hurt our own positions in our organizations, or the work that we do.

The question was raised at the DLF Forum whether future forums could be a “safe” place to discuss failures.  I’m not sure any public gathering can be an entirely safe place for that.  People you see are identifiable, and word tends to spread over time, particularly when a large number of people are present.

One alternative that’s been proposed to address this problem, and still make useful information about failure available to a wide audience, is to anonymize reports.  We can still learn a lot from failures in our field even if we don’t know exactly who failed and where.  And perhaps anonymity can produce more useful information about failure, by producing more “safe” places to talk about it.

So, I’d like to try a little experiment.  From now until the end of February, I invite folks involved in library-related failures to send me reports of their failures, for possible publication in this blog.  I will choose which ones to publish (and may or may not request revisions), but whether or not they get published, I will do my best not to disclose your identity.  (I can’t absolutely prevent email hacks or subpoenas, but I consider them unlikely.)  Please clearly note the start and end of the report you’re submitting for publication; I’ll assume any information that might help identify you or your organization in the middle of the report is information that you’re comfortable disclosing.  Reports should be sent to the email address shown on this page.

I’m interested in particular in failures of initiatives you were personally involved with, and what can be learned from the failures. While others may also be involved in the failures, I’m not particularly interested in reports intended primarily to focus blame on a particular third party.  You should use similar care to obscure the identities of others involved as you do in obscuring your own identity.

Some folks may feel more comfortable working with someone else, or under different selection criteria than the ones I use.  So I invite others to make similar offers if they see fit (and I might mention them here if I hear about any similar offers).

Will this produce something useful to the library community?   I don’t know yet, but it seems worth risking a bit of failure to find out.   If you have any suggestions about the proposal, or have some ideas of kinds of reports you’d like to see, feel free to mention them in the comments.  And if you have a report you’d like to make, send me email.