Standards? Conventions? Design Patterns? Whatever Works!

I see Rick Jelliffe finds the previous post amusing.  Glad to
entertain, but please note my comment.
I definitely agree that "The whole point of a standard is to prevent
one party from having control".  That's what the imprimatur of a
standards organization offers.  The question I was posing  is
how much work refining and field-testing a spec should done before
submitting it to the standards organization.  The dominant
paradigm has been to do fairly little and leave most of the work to the
committee.  The alternative is submit fairly mature specs for
standardization. This doesn't have to be done by some unholy alliance
of the major companies; the W3C itself now has a mechanism to form
"XGs" (X signifying something like "experimental" I guess) that can
develop specs that are not on the Recommendation track, that can be
picked up by a regular WG if they prove themselves.  But when the
standard ultimately  comes  out, the organization, not the originator(s),
own it in any case, whether it was developed by a WG, XG, or industry
cabal. (My attempted comment
on his blog hasn't shown up for whatever reason). 

Another interesting post on this general topic is Kurt Cagle's XML and the Long Tail
"if, as I suspect, standards adoption tends to occur first within the
tail, the growing adoption of that standard creates pressure on those
closer to the head to conform to the standard as well, which in turn
makes the momentum stronger even closer to the head. Eventually, this
forces the market leader into a position where they either adopt the
standards or risk losing their market dominance in the face of
overwhelming opposition from both competitors and clients."  Kurt
doesn't give specific examples, but let's think of some. 
Presumably the model for this would be HTML, which definitely did
emerge out of the long tail and displace the proprietary technologies
of market leaders (e.g. MS's ill-fated Blackbird format).  RSS
also comes to mind.  But most would argue that HTML and RSS moved
out of the long tail not because they were Open Standards but because
they were (originally) simple sloppy
formats that absolutely nailed the 80/20 point of functionality at a
vastly lower price/complexity than the stuff at the "head."  More
recent examples of technologies emerging from the long tail and getting
somewhat grudging support from the head might include REST/POX and
AJAX/JSON.  In these cases, it's again a matter of fundamental
standards (HTTP,XML, ECMAScript/Javasript having been universally
implemented by the head) and sufficing where the head-favored
alternatives added little value (or had not yet been widely deployed).

What drives these things is not standardization in the sense of
their being a formal, approved spec that developers scrupulously adhere
to.  Valid HTML is not particularly common on the Web, many
so-called "REST" apps violate the HTTP spec in fairly dangerous ways,
RSS is actually a constellation of informal conventions rather than a
standard (the real-world success of the Atom 1.0 IETF standard is yet
to be determined), and AJAX/JSON is more of a design pattern than
anything resembling a standard. What does drive this is evolution -- a
diverse pool of ideas, lots of experimentation / recombination,
real-world success to the most practical ideas, and a weeding out of
the bad ones.  At some point things stabilize to the point that
certain ideas get enshrined as "standards" and the evolutionary process
slows down for awhile, until the equilibrium gets punctuated by new
challenges and ideas.  That's very consistent with the
"standardize the stuff that has been field-tested, don't standardize it
direct from the lab" approach I was advocating yesterday.

The larger context of many of these discussions seems to be the controversy surrounding
the OASIS OpenDocument format and the Massachusetts CIO's effort to
mandate it in that state's agencies.  As someone who hopes that MS
Office's profitability continues to fund our little non-profit center
in the bowls of the borg, I'm a bit biased, but c'mon folks:  This
isn't about an Open Standard getting traction in the long tail and
forcing the "head" to reluctantly do the Right Thing, this is about
using government power to counter market realities. That seldom works
in the IT industry, as the fact that Ada is
a niche programming language today should attest 🙂 OASIS ODF will
succeed if it meets an un-met need at a significantly lower real cost
than the alternatives, the way HTML, RSS, etc. have
succeeded.  Historically, it has been more or less irrelevant
whether something hitting that sweet spot has been an Open Standard, bunch
of conventions shared by a developer community, or a de facto standard
derived from a proprietary technology.

Comments (7)
  1. John Coleman says:

    Not whatever works. Whatever’s proper. Just because it works, does NOT make it right. Every (respectable) parent tells their kids that, they need to live it out themselves.

  2. Ryan Tomayko says:

    "a diverse pool of ideas, lots of experimentation / recombination, real-world success to the most practical ideas, and a weeding out of the bad ones."

    Sing it from the highest mountain. 🙂

    "OASIS ODF will succeed if it meets an un-met need at a significantly lower real cost than the alternatives, the way HTML, RSS, etc. have succeeded."

    Agreed. I think the nudge from the state was healthy, though – at least if what little I’ve read about this situation is true. If MS isn’t providing the ecosystem where "a diverse pool of ideas, lots of experimentation / recombination, real-world success to the most practical ideas, and a weeding out of the bad ones" can thrive and, as some suggest, are actively imposing barriers to that ecosystem ever coming about, I think it’s completely within the state’s rights to "clear some brush" with the hopes that the ecosystem might evolve.

    Some believe that in order to truly get to that first situation (the healthy ecosystem), you have to level the playing field. You can’t have a dominate authority calling all the shots and expect the kind of participation needed from others. Personally, I think you guys should jump in on this and see how you can contribute.

    I do agree with you that the Open Standard isn’t the issue. What we should be talking about is community enabling, real openess (Freedom), and simplicity as those are the real drivers for healthy adoption and the seeds of a true ecosystem.

  3. Kurt Cagle says:


    I’m looking forward to seeing you at the XML conference and catching your talks. It should be enlightening as always.

    I think you make a good point here, though I’d qualify this somewhat – the simple sloppy formats usually gain traction first, but eventually, the incompatibilities that emerge from different simple sloppy formats necessitate that someone (or more accurately several someones) step forward, put a flag in the sand, and say this is the canonical standard. It doesn’t always work, and there is no guarantee that it will be the established "Standards Bodies" that will be the keeper of the standards, but typically what emerges tends to be battles to control the tail because the barriers in doing so are lower than the barriers in controlling the head directly.

    As to the Massachusetts controversy, it should be noted that there has been a considerable amount of money and legal brainpower expended on the part of Microsoft in order to counter this, just as there has been a great deal of effort on the part of Microsoft to lock in vendor contracts that limit, or even exclude entirely, other products.

    What Massachusetts mandated was not that Open Office be utilized, but only that ODF be utilized. It would be a remarkably trivial undertaking for Microsoft to add support for ODF – an auto-update and maybe three man-weeks of developer time – and thus render the whole issue moot. What Microsoft is protesting stems more from the fact that ODF adoption would make it much more difficult for them to control THAT standard, and hence would end up selling less copies of Office than would happen otherwise. Given that Microsoft is also using the legal system in order to overturn this indicates that the argument is somewhat disengenuous.

    I’d also disagree fairly strongly with your last line:

    >Historically, it has been more or less irrelevant whether something hitting that sweet spot has been an Open Standard, bunch of conventions shared by a developer community, or a de facto standard derived from a proprietary technology.

    There are two distinct timelines that Open Standards vs proprietary technologies take. Proprietary technologies are typically into markets first – its a question of looking at finding where the market is and taking advantage of the imbalances that make those markets possible, something that proprietary technologies are ultimately most efficient at. Open Standards typically emerge much later in response to the results that occur after too many proprietary providers have been attracted to a given niche. They do not so much solve problems as provide consistent interfaces to help remove fragmentation, and generally it is in the best interest of those companies farther out on the curve to conform to that standard – their investment costs in their own proprietary technologies are not so high that the advantage of working to a standard doesn’t provide a bigger advantage. It should be noted that typically the standards themselves usually tend to most closely model the technology of one of the players in the head, though not always the most dominant one.

    On the other hand, there are considerable disincentives to adopting the open standard for the market leader, because they lose the competitive lock on their customer base + they have to re-engineer their products. There’s also a certain air of disbelief – if they are the market leader, how could someone else’s specification be better than theirs.

    BTW, I’m not sure its always an "Open" Standard that wins, though I do suspect that as open standards become more and more the norm, they will likely be the driving force compared to the market dynamics that characterized earlier eras of software development.

    Software technology evolves, but so does software business. Thus, its dangerous to look at the "historical" record in this case, especially given that the IT sector really has few analogs elsewhere to provide a sense of comparison. Historically, IBM was the largest and most powerful software company on the planet, but while it can be argued that they are powerful, it can also be argued that they do not hold the dominant position they once did. I think the same is probably becoming true for Microsoft – it will never be anything other than a major player, but will it remain dominant? No, of course not.

    I think your next to last paragraph is largely true; standards typically emerge when there are two or three different implementations of a technology that end up making up the bulk of the technology niche, and the costs of non-standardization (i.e., the costs of building shims and filters between standardization) becomes higher than the costs and potential market loss to a company that may come by participating in the standards process. Additionally, if the disincentives for adhering to that standard (complexity of the standard, ambiguities in the standard, competitive gain still outweighing the cost of cooperation) are strong enough, even if a standard exists it may end up not being sufficient to force universal adoption of that standard. While you give RESTian systems as an example of this, I think you could just as readily look at SOAP or, even more appropriately, UDDI as technologies that have not achieved exceptional penetration despite being "standardized".

    — Kurt Cagle

  4. Rick Jelliffe says:

    A consumer deciding on its own criteria for determining what to buy *is* the market, Mike.

    (Mike has also posted, from his perspective deep inside those the non-profit bowels, some useful and interesting comments directly to my blog, which did not show up for a couple days, not due to sinister reasons I am assured.)

  5. Konijn says:

    "this is about using government power to counter market realities."

    Massachusetts role in this case is being a client, not being the government.

    "OASIS ODF will succeed if it meets an un-met need at a significantly lower real cost than the alternatives"

    That un-met need *is* the openness, i.e. the absence of vendor lock-in.

    So, how much does vendor lock-in cost? Depends on the client, I guess. For a government with a duty to keep documents available for a long time it may be more than for a random commercial company.

    When is vendor lock-in absent? Having it declared a Standard by a Standardization Organization is neither a necessary nor a sufficient condition.

Comments are closed.

Skip to main content