There's been a debate in the HTML Working Group on distributed extensibility; this led to a session at the Technical Plenary yesterday (and, for me, an interesting lunch discussion afterwards that led me to think about issues I hadn't before thought much about). One issue in that debate is that some people see the debate as a debate specifically about whether to use XML namespaces and some see it as a debate about extensibility in general.

I've come to accept that extensibility has positive value, and that the risk of open platforms having proprietary extensions is outweighed by the risk of stagnation and the benefits of adopting extensions into the platform. The value of openness just needs to stand on its own: people can choose open extensions over proprietary ones, just like they can choose an open core over a proprietary one. (This has similarities to the open source vs. free software debate.)

However, I think XML namespaces have some problems as an extension mechanism. One of the reasons I don't like them is that they're hard to use: people have to remember obscure namespace URIs, which makes markup harder to write. Another is that namespaces can encourage not-invented-here syndrome: they encourage extensions to be complete pieces rather than reusing as many pieces of the core as possible, since once you're writing a subtree in a different namespace, it's easier to use elements in that namespace and it's extra work to switch back into the core namespace. Thus they can encourage extensions to extend more than necessary.

Accepting that extension mechanisms are good doesn't necessarily mean their value exceeds their costs; extension mechanisms, especially in software, can be quite costly. In software, large portions of the cost of extensibility is borne by the core, but it's not clear that's also the case for standards.