Muscle and boneMarch 17th, 2008
My written visits to this page are usually marked by some form of agitation on the part of a heartfelt advocate. I promise this visit will be no different. A couple of months ago I backed off posting a wee flag-burner of a piece, after bashing my head against a piece of software you could charitably call "somewhat ridiculous", in the course of repackaging applications. This role involves making customisations to software in order for it to meet the needs of deployment within the library. The process of repackaging has the side-effect of revealing inherent characteristics - positive and negative - in applications that can be traced back to things like development models and environments, software licensing and anti-piracy measures, sometimes even commercial affiliations. What I have learnt from this is that there are certain software architectural decisions that give me involuntary nausea.
DCOM, hang your head in shame. No biscuit.
It would seem logical to me, that software in use in an institution like a library, have a requirement for a slightly greater degree of inherent robustness than in a private institution. I'm not just talking common-or-garden stability here. I'm also referring to the radius of downstream effects the application has on the environment in terms of dependencies, the accessibility (or otherwise) of support, the responsiveness of the developers to feedback, and the ability to maintain, update, or modify the software. This is to prevent applications from shoehorning us into architectural support obligations, to provide for the contingency of being able to rescue data off desert islands of misuse, or to maintain the theoretical ability to jump platform ship. We cannot insure against the loss of intellectual heritage, whereas a private company can insure against loss of earnings. Our responsibilities are somewhat different, and the way we carry them out must be different too. Common-or-garden commercial computing practices don't always apply to Galleries, Libraries, And Museums.
At this point in the compositional process, I feel the need to point out the obvious fork in narrative I could choose to follow. I could get out my paintbrush and can of vitriol, and do a portrait of some of the characteristics of some really irritating software, without naming names, of course. Alternatively, I could outline a few examples of characteristics really desireable to those of us involved in supporting the software pickaxes in the GLAM goldmines.
//Chooses the latter...
We have to be pragmatic about the platform we run. I would say platforms, but....yeah....
One thing we can count on is the general ubiquity of Windows. Leaving aside the OS debates, an interesting fact about Windows is the huge richness of different applications available - and it's a natural corollary that they have a wide range of characteristics. A GLAM-friendly client application for windows, in my own practical experience, would contain as many of the below characteristics as possible, in order to be robust and benign in the Culture and heritage environment:
- a permissive license, ie, at least per-seat, or site licensed, if not freeware or open source.
- a responsive support community
- a humble standalone .msi or .exe installer, non-obfuscated, straightforward
- it would be cross-platform
- it would be as free of platform-specific dependencies or runtimes like .NET as possible
- it would be compatible with other, similar local client apps for data exchange purposes.
- if an application has a browser-based client interface option, it should not require Active X or any browser-specific third party commercial plugins.
- there should be no registry data anywhere outside of HKEY_LOCAL_MACHINE\SOFTWARE
- there should be no hard-coding of paths, install-time variables, or configuration values
- configurable client settings should be located on either the client, or on the server. Not spread across both.
Yes, I am a rampant idealist.
To flesh out my picture a little more, let me show an example of a piece of software I'd consider supremely GLAM-friendly - dotproject. It is a multiuser, web-based project management application, (web demo link here) A co-worker mentioned to me that a company she was collaborating with overseas had recommended that she look at it as an alternative to emailing back-and-forth excel spreadsheets and project files. The application is freely available (free as in beer and free as in speech) for all platforms, the client interface is a browser, with all data stored server-side. It is open source, and the user, support, training, and documentation resources are quite extensive. If I were told to make it available to end-users in my organisation I could simply provide them with a link. Everyone in the org could be working on it, pounding my server, in less than a minute. Nice huh? How friendly is that?
Now, giving in to my darker urgings... I recently heard the following remark being made during a software deployment test:
"I'm sorry, there is no way it could be a fault of the application - this software costs $250,000."
Such a brilliant one-liner couldn't help but sear itself into my memory. This was a defensive response to a particular piece of software being blatantly stupid, from the Vendor supporting it. I am not scientist; but I felt when I heard that comment a great sense of vindication - the application in question didn't contain a single characteristic from my list above. [And just as a follow-up to the vendor's statement above, it did turn out to be a fault of the application, despite the fact that it costs $250,000.]
Pricetag is sometimes a reflection of software provider rather than the software. Typically this occurs with the more niche nuts-and-bolts software, you know, the stuff we percieve as really indispensable that makes wheels rotate in a well-lubricated fashion. It occurs on a lower level when we value a familiar keyboard shortcut or a particular menu location of a tool, over a general function or software license. It occurs passively when all we try to do is follow a well-trodden path of least resistance. No piece of software used in the Culture and heritage sector should be making dependency requirements that lock-in the institution to particular purchasing decisions. If a piece of software does this, we have a responsibility to have in mind a contingency, a light-at-the-end-of-the-tunnel escape plan. If our environment becomes an ecosystem finely-tuned to supporting only a very particular type of animal, we'll be working in an innovation-hostile world.
If we're in a position where a piece of software has become indispensable, we're not following particularly robust software usage practices as an organisation, and this is an issue because a lot of our software decisions are informed (overruled?) by the usage habits of normal, everyday librarians. People working in the Culture and heritage sector need to look for software that is GLAM-friendly not just in function, but also in design philosophy; in muscle and bone, not just skin.