Simon Phipps was right

Simon, I'm beginning to think that you were right and I was wrong. You said a standard's process is a crucial aspect of the standard's product, and a process that is not open cannot be trusted to produce a product that can be considered open. I maintained that I had seen and used many wonderful standards that took absolutely zero input from me, and therefore I didn't see my participation as a necessary prerequisite for assuring quality in the future. I believed that no matter what the process, a standard should be judged by the product. Watching the fallout settle from the BRM in Geneva, I'm beginning to think that you were right and I was wrong. What you got right is that when a process is allowed to go out of its way to exclude legitimate participation, we must withdraw from the presumption that the standard can be legitimate, even if the end product does not overtly exclude the possibility of an open source implementation. This is what I have learned by reading the Groklaw report on the BRM. Perhaps the world has always worked this way, but I have become increasingly aware of a strategy that seems frequently employed by the powerful: when caught bending the rules, bend them to breaking, and when breaking the rules, break so many so comprehensively that it seems pointless and small to call any specific infraction to light. But I am also heartened by the response of the open source community. We do small really, really well. With many eyeballs, we have mind and memory capable of tracking and recording even the most chaotic narrative. What I see in the Geneva proceedings (that have been reported, surely not the whole story) is that ISO believed as I did that product was less important than process, and now ISO must decide whether to acknowledge that it failed, damaging its brand in the short term, or deny it was wrong and risk ruining it forever. For myself, I'll make my apology and take my judgement. Hopefully this will help me do a better job of advocacy in the future, even if today I'm a little bit humbled.


Thank-you, Michael - it's not often I see a posting like this. Actually, when we spoke about this at OSCON I found I agreed with many of your arguments, even if that doesn't show in the on-list discussion[1]. The problem is that standards are orthogonal to open source, and attempting to define them in a way that promotes and protects software freedom may be impossible. It's been said that when we create any system we create the game that plays it. The standards system is fully mature and as such is fully gamed, as the DIS29500 debacle is proving. Maybe a more productive approach going forward is to try to define for the other kinds of so-called "intellectual property" a definition of the same spirit as the one OSI has defined for copyright licensing? Perhaps we need to rename OSD to "Open Source Copyright Definition" and then work on an "Open Source Patent Definition", so that we can avoid the entrapment so clearly being created with software patents? And as you know I am convinced we need an "Open Source Trademark Definition" to help us as a community of communities to avoid the IceWeasel problem[2]. If these are interesting, I'd be pleased to spend time exploring them together. Let me know. [1] [2]

To promote and protect open source software and communities...

For over 20 years the Open Source Initiative (OSI) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

Open source software is made by many people and distributed under an OSD-compliant license which grants all the rights to use, study, change, and share the software in modified and unmodified form. Software freedom is essential to enabling community development of open source software.