Queen and Open Source

A post by Alan McGee on the Guardian's blog on Tuesday argued that Queen, and especially Freddie Mercury, were actually "punk". He hung his case on the assumption that punk meant "never being boring". The vigorous debate that followed in the comments in part attacked this assumption or definition of punk, and in part added new criteria by which we might identify what deserves that label. For me, I'd say that, given the limited nature of the straw man McGee erected, he's right: Queen were punk. But he's wrong, too, in that punk (to many people) is/was more than simply a good show; more indeed than rebellion or subversion, as some comments argued. To be a useful category that doesn't also include, say, Marcel Marceau, Joan of Arc, Jack Kerouac or a nice crucifixion, we need to bundle these characteristics with others. My bundle of essential punk features might be very different from yours - I'd call the Litter, Faust and, yes, the Creation supreme punks, perhaps only the Pistols and Crass were punk enough for you. The point is that it's helpful to distinguish between the phenomenon or category, and the aspects that define its essence. Otherwise we end up with fun but muddled rhetoric - fine on the blog, of course, but not so fine for serious debate.

This next bit is related, bear with me...

Last week, in a meeting about a new delivery system for collections content, Mia and I had a disagreement which echoed a recent debate on the MCG list (parts of the "CMS specifications" thread here). The issue was Open Source and whether it's something that we should require as part of the system we are planning for (and future systems). My argument was, and remains, that we are interested in certain significant properties embodied by the O.S. concept, but that these may be found elsewhere. To find the ones that are important to use - say, the ability to modify the codebase, or the existence of a supportive community of users and developers - we don't by definition have to look for an OS badge (which relates purely to the licence, after all - definition). Things such as a community of developers that are claimed as virtues of OS software may be there as a consequence (or cause) of the licence, but they are neither required for the label to apply, nor present only when the label applies. Nik Honeysett made a related point the other day, arguing on the Musenet blog that

"the communities that would be best served by Open Source, i.e. small/medium museums, are the ones that can least afford to contribute and participate, so they are no better off whether its open source or not - the crux of selecting software is that it meets your requirements"

Once again, it's not that Open Source is "right" or "wrong" but that we need to think analytically about the aspects of it that matter to us and whether they can be furnished by any given solution, not whether it wears the right badge. Access to source code is good, but it doesn't dictate OSS. Communities of developers are good, but not restricted to SourceForge and the like (GotDotNet has served me well). Freedom from reliance upon suppliers is good, but think about which parts of the technology stack you're most concerned about. In our case at MoL, large parts of our stack are "closed source" - the operating system and web server, the framework (.Net) and the CMS we use are all Microsoft and essentially closed. But I believe that we'd be more vulnerable if we implemented, say, Drupal, because our in-house development skills are with .Net, and it's the ability to develop what we have that gives us power over our destiny. It's limited, yes, because the CMS's core is closed, but (a) the data is accessible and (b) around that core is a cloud of .Net source code that I can and do develop, some sourced in the community, and which underlies the bulk of the functionality on our sites. I can't modify .Net (though there's Mono) but I wouldn't want to, nor can I recode Windows (ditto). But we have access to the code that matters most, and that's what matters most. You could in any case build a CMS in .Net and licence it by OS rules, but the next level of the stack wouldn't be OS - does that matter? Chances are that if you're installing some OSS then there's still a proprietary element in your stack, or at least a bit that you would be unable to fix yourself. And even if you're top-to-bottom LAMP and could dive into the source yourself to tweak Apache or Linux if necessary, you're probably still dependent on patented hardware. Live with it.

Both the Queen argument and the Open Source argument, then, come out of mixing up labels and characteristics that can attach to those labels. OSS is great, but for reasons that aren't always relevant or found only in OSS. Queen put on a great show, but that's not the same as being punk. Significant properties, in other words, aren't The Thing Itself.

Delayed post #1: aspects of [web] preservation

[[this post never got finished but I'm having a clear-out of my drafts and they're getting published or deleted, ready or not]]

Brian Kelly just blogged [[hmm, well, back in July, I think....]] on the JISC-PoWR site about "three key aspects of web preservation": experience, information, and access. I have a fourth, but I've been using it in the context of "sustainability" (the subject of my thesis), and so first I want to say a couple of words about this vs preservation, since although I've been writing papers for Ross for a couple of years arguing about the distinction between the concepts, I've not really rehearsed this in public before.


For the last couple of years I've been arguing that the problem of sustainability (S) is distinct from that of archive-style preservation (P). I won't go into the details of the distinction here but in essence I see P as concerning the persistence of a state, and S as the persistence of a process or activity. Recent work by Chris Rusbridge and others has been blurring the boundary ever more, although in a useful way: by questioning the purpose of preservation and weighing up what are the important aspects ("significant properties") of resources, they have been starting to argue for an approach to preservation that looks a lot more like what I was previously describing as sustaining. I still sort of believe that it is useful to distinnguish between the two concepts, but there's a lot of overlap.


The aspect that I think is especially pertinent to sustaining is "purpose". I don't think this is the same as the "experience" that Brian cites Kevin Ashley on (although experience and information may feed into purpose). It's focused on the objectives of the resource, which may be attainable through radically different experiences; for example (in the case of the environment in which KA operates), the learning objectives that an educational resource was created to serve. For a museum, perhaps a resource was prepared for use in a temporary exhibition, with the objective of enriching the experience visitors to that physical space by illustrating relationships betweeen objects, and providing media resources to bring them to life. When that exhibition closes, the original objective is partially voided - there is no physical visit to enrich - but aspects of it may still be viable - the objects probably still exist and the tales about them are still worth telling, perhaps more so than ever since we've stuck them back in the store-room out of easy access. Brian was talking about web preservation, of course, and I've taken a non-web resource as an example, but my interest in the question of sustainability extends beyond the web and the point applies regardless.

In any given digital resource that we're talking about preserving/sustaining, experience and information at least (perhaps access, too, sometimes) will have contributed to the original purpose to varying degrees - sometimes the experience is the whole purpose, sometimes it's an unimportant side effect of providing access to information. And sometimes it's important to the preserver regardless of its significance to the original purpose.

So if the original purpose is no longer served by a resource, what then for our "preservation" plans? There are still often reasons to preserve (freeze) or sustain (keep alive) an application, or aspects of it - in other words, some sources of value, ranging from historical interest to new uses, which may let a resource adapt and survive. The "significant properties" idea fits in to this. For me, if you are trying to maintain some quality of the original it's more of a preservation activity; whereas if you are more fundamentally interested in continuing to extract value through maintaining utility of whatever sort, we're talking sustaining.

Significant properties workshop - report

DCC/JISC significant properties workshop (British Library, 7/4/2008)

I'm not going to write up in detail all that was presented on Monday, but highlight a few things that seemed important to me, and work out a couple of thoughts/responses of my own. I haven't yet had a chance to read the papers that were sometimes referred to at the workshop (links to them here, some are huge!) so my questions may be answered there.

• JISC’s INSPECT project, run by CeRch at KCL, has set a framework for identifying and assessing the value of significant properties (SPs), and the success of their preservation; and initiated several case studies looking at SPs in the context of sets of similar file formats (still images, moving images etc) and categories of digital object (including e-learning objects and software).
• 5 broad SP “classes” (behaviour, appearance/rendering, content, context and structure) are identified by INSPECT. These don’t seem to include space to describe the “purpose” of a digital object (DO), unless this is somehow the combined result of all other SPs. But an objective such as “fun” or “communicates a KS2 concept effectively to the target audience” needs to be represented, especially for complex, service-level resources. Preserving behaviour or content but somehow failing to achieve the purpose would be to miss the point.
• Something I’m still unclear on: is it that a range of SPs are identified that can be given a value of significance for a given “medium” or format? Or is it that a set of SPs is identified for a format, and the value given according to each instance (or set of instances) submitted for presentation? In other words, it a judgement made of the significance of a property for a format/medium, or for a given preservation target?
• Once identified, SPs provide a means for measuring the success of preservation of a file format (whether the preservation activities entail migration to or from that format, or emulation of systems that support it).
• The two classes of object explored in the workshop (software and e-learning objects) are typically compound, and are much more variable than file formats. They will inherit some (potential) SPs from their components, but others (many behaviours, for example) may be implicit in the whole assemblage.
• Andrew Wilson (keynote speaker, NAA) raised the importance of authenticity. His archivists’ point of view of this concept is not identical with that in museums, or that which I'm using in my research, but it’s useful nonetheless. I have, however, already discarded it as a significant property for most museum digital resources, with the exception of the special case of DRs held as either evidence, or accessioned into collections. Archivists’ focus on informational value and “evidence” as the core measure of (and motivation for) authenticity isn’t always useful for DRs, but it is nice and clear-cut.
• The software study drew out the differences between preservation for preservation’s sake – the museum collecting approach – and preservation for use, where the outputs are the ultimate measure of success. The SPs for these scenarios differ.This paper was very interesting, and perhaps (along with the Learning Objects paper) came closest to my own concerns, but the huge variety of material under the banner of “software” clearly makes it very difficult to characterise SPs. The result is that many of those identified look more like preservation challenges than SPs in themselves. Specifically, dependencies of various sorts might count as a significant property in a “pure preservation” scenario; but in most cases they are, more likely, simply a challenge to address to maintain significant properties of other sorts, such as functionality, rendering, and the accuracy of the outputs.
• I suggested in Q&As that my reason for being interested in SPs probably differed from that of a DO-preserving project or organisation, although they have plenty in common. Andrew Wilson said that he saw the sort of preservation (sustaining value) that I was talking about as being the same as preserving in the archiving sense. I disagree, in part at least, because:
  • He made the case for authenticity. This doesn’t apply when one is using SPs to help planning for good management, where we just want to make sure that we’re making best use of our resources.
  • For me, SPs could prove an important approach for planning new resources, whilst for archives they are primarily for analysing what they’ve received and need to preserve (although they could in theory feed into future formats, or software purchasing decisions)
  • Whilst for preservation purposes it may often be necessary to decide at a batch or format level what SPs are highly valued and hence what efforts will be invested in their maintenance, for questions of managing complex resources for active use, case-by-case decisions (based on idiosyncratic SPs?) may be the norm.
  • For preservation, the “designated community” is essentially a presumptive audience, whose needs should be considered. For museums looking to maximise value from their resources, the SPs will reflect the needs of the museum itself (its business objectives and strategic aims), although ultimately various other audiences are the targets of these objectives. Perhaps there’s not so much difference here.
  • Fundamental to all these differences is the fact that for archives etc, the preservation operation in which they are engaged is the core activity of the organisation. In other situations, like planning for sustainability, it is not preservation of a digital object, but its continued utility in some form (any form), i.e. the continued release of value, that counts.

  These differences are largely of degree, but to me there is still a worthwhile distinction between preservation and sustainability. In a sense, preservation is the action and sustainability the continued ability to perform that action, so SPs are a way of reconciling preservation with the need for it to be sustainable. Perhaps the lack of a category that outlines the objectives, rather than the behaviour, of a digital object reflects this difference between preserving and sustaining.