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.