How (Not) to Grow a Technology
June 25, 2003
The thing about technologies is, like everything which humans truly value, you have to grow them. They don't fall out of the sky as gifts from the gods. But what's the best way to grow a technology? That depends, of course, on who you are, what kind of tech you need, and what your resources are. Some technologies are the result of a standardization process, which can be public or private, and which often has some degree of formality and consensus. But there are also grassroots technologies, ones which are widely used but not the result of a formal or standardizing process. A widely used technology can also be the result of imposition or coercion: if there is a context in which one institution is large enough to impose its will on everyone else in that context, that institution may simply declare by fiat that such-and-such will be the one and only technology for a particular use.
In this article I consider the two most common ways of growing XML technologies, particularly in the context of standards bodies and the XML development community. While these two methods are well-known, I draw my inspiration from an XML-DEV posting by Roger Costello. His post suggests that there are two ways in which a technology may be developed: by committee or by "the market." In the committee case, a group of people -- often an element of a standards body -- is primarily responsible for the development of the technology. The committee may or may not consider input from outsiders. As Costello put it, "XPath, XSLT, and XML Schema are following this approach." In the second way, an initial framework is created, usually by a small, ad hoc group; and from there "the market" takes over development in that haphazard but perhaps ultimately clever way in which "the market" does things. As an example of this approach, Costello points to RSS 1.0.
"The Market": The RSS Example
Each of these approaches has advantages and disadvantages. I will discuss the disadvantages of the committee approach below, but first I want to point out that Costello's choice of RSS 1.0 is an interesting one. It's not the most flattering or attractive example. RSS -- in its endless variations and versions, both preceding and following version 1.0 -- has been the subject of interminable and painfully annoying debates and shouting matches, during which various rhetorical combatants have (or have not, depending on who you believe) muttered death threats. In other words, "the market" can be a very hostile, ugly, and cruel way to do anything, much less to evolve a technology or grow a technology standard.
Costello's choice of RSS 1.0 has been made even more interesting by what appears to be yet another attempt by "the market" to throw out RSS, and its bathwater, and to start over afresh and anew. Though the new effort doesn't yet, as of this writing, have an official name, I'm putting my money on "Echo". "The market" has a curious habit of starting over from scratch from time to time, and the only consolation that it offers to people who've built various kinds of cottage industry around the "old way of doing things" -- industries which are toppled by the sudden urge to create de novo -- is that maybe the new way will be better. But probably it will just be different. Echo seems likely to be a mixture of both the "just different" and the "better", with a few dashes of vendor-imposed but politically necessary perversity thrown in for good measure.
While I have often complained about the viciousness and stupidity of (a good deal of) the RSS debate, there is one sense in which it may have been necessary. Perhaps the endless debates, their tenor and tone, so exhausted and sickened not only the participants but also the lookers-on that starting over from scratch has begun to seem like a good idea. It may just be that the only way starting over from scratch is even conceivable is to work oneself into such a state of misery that not starting over from scratch is inconceivable. At least, that's the theory I'll offer to the first toolmaker or cottage builder who kvetches about having to retool and rebuild.
But I have another theory to answer "why Echo, and why now?" kinds of questions. Whatever else can be said about RSS, in which ever version you care about or hate most, it's been for the most part a very grassroots effort. And that's been one of the things about RSS which I liked the most. I'm not alone in being attracted to RSS because of its grassroots character.
Except for the earliest Netscape versions, RSS hasn't been something that the Really Big tech companies cared about or even noticed -- and, let's face it, despite apperances to the contrary, in the early days of the Web, most of us didn't even think of Netscape as a corporation at all. Userland Software has been involved in RSS from early days, but Userland is a tiny speck compared to corporate behemoths like Microsoft, IBM, Sun. But with the "rise of weblogs" (please, don't get me started), together with the relatively sudden appearance and then flourishing of RSS newsreaders as HTML browser semi-competitors (or competing supplements, if you prefer), suddenly there are all sorts of noises and rumblings from the Really Bigs that RSS has been noticed. And that can't be a very good thing in the long term for most of the toolmakers and cottage builders who cluster around RSS. It certainly isn't a good thing for lookers-on and users, like me, who like RSS because it is a grassroots affair.
In other words, Echo may really be "the market" deciding to upturn its apple cart just as the Really Bigs try to decide whether to steal or crush it. I guess we'll see soon enough. (I have yet another theory about Pie, one which isn't as flattering to the small, but still for-profit corporate members of the RSS community. Email me at if you're interested.)
Design By Committee: The XPath-XSLT Example
But what about the disadvantages of the committee approach? Costello's post came in the midst of an XML-DEV thread about the growth in size and scope of some key W3C standards: that is, XPath 2.0 and XSLT 2.0 are, to put the matter technically, freakin' huge. To put the matter even more technically, as Roger Costello does in another post, the XPath 2.0 spec is 564% larger (in printed pages) than XPath 1.0, while XSLT 2.0 is 301% larger than XSLT 1.0. Michael Kay countered these numbers by suggesting that if you compare language constructs, rather than printed page counts, XPath 2.0 is 70% and XSLT 2.0 is 40% larger.
That's what committees tend to do to technologies: make them bigger, cramming them with features and tweaks and bright-shiny pieces which are mostly unused, except by those who advocated for them in the first place. Simon St. Laurent suggested that most XML standards controlled by the W3C -- which is, after all, an industry consortium -- have been bitten by the inflationary bug.
In fact, as St. Laurent puts it, "I don't think it is possible at this point to write a 'general XML book' that covers all of the surrounding specs." That's almost certainly true and not particularly happy-making news. But it gets worse: "The perceived barriers to entry in XML beyond really basic markup," St. Laurent said, "have grown much faster than the perceived benefits, and it makes it a much harder sell than it used to be."
So to which devil should we pay our due? Shall we have chaos or complexity? I have, somewhat reluctantly, to be sure, come to the conclusion that there is no devil-free way of growing a technology or a technology standard. Even if technologies were given to us by the gods, or if we, like Prometheus, stole them from the gods, there'd be some other, perhaps even more severe price to pay.