Bobulate


Posts Tagged ‘process’

Changing standards

Monday, November 9th, 2009

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?