I love challenges to conventional wisdom, and in an after-hours conversation at ETech the rhetorical magician R0ml came up with a doozy. Standards are bad, he asserted. Or, less confrontationally, standards are an inferior solution to the problem that open source software solves.
That problem is technology monopolization. To avoid it, we write standards that abstractly describe technologies, and that can be independently implemented by multiple providers. Competing implementations are a feature of this process.
Open source avoids monopolization differently, by abolishing ownership of core technology. In this realm, a competing implementation is called a fork. It looks more like a bug than like a feature.
In the case of infrastructure that we agree not to monopolize, R0ml asks, why can't the standard description and the standard implementation be the same thing?
Imagine that when you visited the website for Business Process Execution Language for Web Services (BPEL4WS), what you found there was working code and associated tests. And imagine that the code and tests were written according to the tenets of literate programming, so that they both enacted and explained the relationship of BPEL to WSDL, the structure and flow of business activities, the correlation of messages, and the handling of faults.
It's a crazy idea, of course. There are all sorts of reasons it could never work.
Objection: We don't write programs that way.
Objection: Our technology platforms are too balkanized to enable us to collaborate on common implementations.
Objection: Ditto for our political agendas.
Fair enough. But setting aside these practical realities for the moment, is R0ml's suggestion wrong even in principle, and if so, why?
Update: A reader counters my question with this one: "You don't allow comments on your blog, yet you ask questions in your blog entry. Am I missing the link somewhere?" Fair question. I've been relying on two channels for interaction. First, private email. (There's an indirect link on my blog.) Second, public blogging.
I've felt that blog comments awkwardly straddle these two options. If you blog a comment on something I've written, I'll find out about it very quickly -- see for example this comment and this response. Shouldn't my writing happen in my space, and yours in yours, and the intersection be an emergent phenomenon?
Still, although this has worked out better than I would have thought possible, I've got to admit that the loosely-coupled style of interaction doesn't work for everyone. So I have, in fact, been thinking about turning on comments.
If it's going to be necessary to moderate comments, however, maybe the protocol reduces to:
Publishable comments welcome
Further update: My sensors report, via del.icio.us, that Micah Dubinko regards R0ml's idea as "nice contrarian thinking." Mark Baker, however, pushes back, saying that "innovation requires the ability to start from scratch." Agreed. One good starting point, arguably, would be a literate implementation.
Via bloglines, Rafe Colburn asks: "How can we have one true implementation when there are so many languages and platforms out there?" Right. That's the balkanization I pointed to. As we begin to isolate our software engines from both processors and programming languages, though, we can imagine a less balkanized future in which working models could play a more important role.
Former URL: http://weblog.infoworld.com/udell/2006/03/13.html#a1404