AAMD have some pretty specific guidelines around deaccessioning. You can do it as long as the money you get from it is used as investment for your collection. You cannot use it to pay off your utility bills or offset the bath you took on that highly-publicized travelling exhibit that flopped like a Disney summer blockbuster. In the same way that Disney doesn’t ask its movie-going public what kind of movie it wants, neither do museums, although that may be about to change.
We have seen crowdsourced exhibits but normally crowdsourcing means sourcing content from the crowd rather than crowdsuggesting, where a museum might ask its audience what kind of exhibit it wants and it seems the Chicago History Museum is first with its History Bowl project, the result of which will be announced on Jan 7th, 2014. CHM’s claim that this is “the first of its kind” is almost true, ‘cos there was the case of that Canadian art museum that crowdsuggested an exhibit. The result? Remember, this is Canada… and an art museum… that’s right, Ice Hockey. Maybe Painter of Light, Thomas Kinkaid has some ice hockey prints, although fortunately, researchers have found that Mere Exposure to Bad Art does not necessarily make people like it more.
(Incidentally, my WordPress spellchecker suggests I change “crowdsourcing” to “discouraging”. Coincidence? I think not…)
So, back to deaccessioning. Museums are collectors, some might say hoarders, but accumulating is in our DNA and growing a collection is the goal. When it comes to technology however, accumulation should not be a goal.
Let’s imagine a collections management system as a form of transportation. This is what your collection management system looked like when you first bought it:
Awesome and braggable at the time. Now however, its sad and annoying, particularly with all the upgrades and maintenance you forgot to perform, and all the additional requirements you now have that it wasn’t designed to support. So now it looks like this:
Given how much has changed since you first purchased your CMS, it seems reasonable to at least review whether it still supports your requirements which (should) have fundamentally changed: rich authoring, rich publishing, multi-channel deployment, all exacerbated by vendors having a tough time re-engineering their applications to support all this and get customers, us, to upgrade.
My recommendation is, for the number of years you’ve had your CMS, spend that many minutes in concentrated thought about whether its still meeting your requirements. In fact, you should do this with all the technology you have, because accumulating technology is bad – technology can be unreasonable and brutal in the extreme, but don’t take my word for it:
Listen, and understand. That
terminatortechnology is out there. It can’t be bargained with. It can’t be reasoned with. It doesn’t feel pity, or remorse, or fear, and it absolutely will not stop, ever, until you are dead.
Kyle Reese, Terminator.
OK, that’s slightly melodramatic, but technology will not stop and the more you have of it, the more of a problem you have with it. Accumulating technology is not a zero-sum game, every time you bring in another piece of technology, you have to support and maintain it. At least that’s what you should be doing. Every additional piece of technology goes someway to lessening your institution’s ability to support the next tech project.
So, play Survivor with your institution’s accumulating technology and vote something off. Deaccession some technology once in a while, I’m sure AAMD won’t have a problem with it.