Bobulate
Home [ade] cookies
Changing standards
The nice thing about standards is that there’s so many to choose from. Joel Spolsky elaborates on Martian handsets in the context of web standards — it’s a fun read, go on. It’s somewhat relevant in the context of Open Standards (there are many definitions out there, largely compatible and differing in details; the FSFE uses on definition of Open Standard, the SIUG uses a slightly different one). Now, one of the characteristics of an Open Standard is that there is some change process — new features are added, ambiguities in the standard worked out. Article 4 of the FSFE definition asks for “managed and further developed independently of any single vendor”. I think none of the available definitions demand “don’t be daft.”
But when changing standards (e.g. producing a new version of a standard with new features, new extensions, or clarification and disambiguation), some form of “don’t be daft” needs to be taken into account. Clearly there’s a need for measured progress, although we can argue about what “progress” means. As a (former) formal-verification-kind-of-guy, I suspect I use words like “specification” and “standard” differently from, say, the ISO. A specification states truth, and does so elegantly. In my academic experience, changing a specification raises two main questions: is this true? is this the best possible way to express the spec? These academic specs, too, are written by small groups of people, with strong co-working ties.
Way down at the other end of the spectrum — no, I shouldn’t suggest that there’s a continuum present here; somewhere there’s a quote like “that’s not the same ballgame; heck, it’s not even the same sport” but I forget where that’s from — are fuzzy processes, ambiguous specifications and fundamental disagreements on what “progress” means. Rob Weir has a three-part blog series (Part I) on the IS29500 update process. Looking at that, I see an update process rife with procedural problems, intellectual dishonesty, and a lack of commitment to a common goal. It’s an interesting read, if only to wonder — what kind of provisions should we make in the definition of Open Standards to ensure a (better) workable change process?