There has been a fair amount of criticism of the W3C of late, and I thought I would add my voice to the discussion, especially since I find most of what has been written misses the point completely.

The goal of the W3C is to facilitate the development of specifications that developers and vendors can use the create software products that produce and consume data files that are produced in accordance to the standards.

In an ideal world, these specifications are a complete and correct representation of the wants and needs of their intended market. The quality of the W3C process (or more correctly, the quality of a specific W3C activity) can be and should be measured by the degree to which this goal is achieved.

Specifications that do not correctly meet the needs of their intended market will not be adopted. A specification that is not adopted by its intended market should be considered a failure, as should the specific process that created it. If the WCAG 2 spec turns out the be a failure, then the WCAG activity should be considered a failure, and not necessarily the W3C process as a whole. If the SVG spec turns out to be a failure, then it is specifically the SVG activity that should be considered a failure, and not the W3C process as a whole.

Individuals, even expert individuals, may not agree with the contents of the specification. There may be criticisms of the process by which the specifications were produced, concerns that important voices were not sought out or were ignored. There may be concerns that important quality control procedures were omitted or circumvented. While these criticisms may have merit, they do not determine the ultimate success of the specification.

A related example: there is no shortage of cases of software projects that have ended in failure. These projects were organized and managed based on any number of development models, be it waterfall, spiral, or some form of iterative development. The failure of any of these projects was not due to a single factor, although process often plays a significant role. Sometimes the development model chosen isn't well suited to the nature of the project. Often, though, the development team failed to correctly follow the development model they had chosen.

But just because a process failed for one project doesn't mean that the same development team will not use it on their next project (assuming it is the correct process for the project). And it certainly doesn't mean that a different team would not try to use the same process for their project.

The failure of a process to produce the desired result is not always the due to a deficiency with the process. Software development (including requirements elicitation and specification development) is inherently a human activity, and a complex one at that. We develop processes to try to frame this activity, to give the players a context that can help them guide their individual and collective behaviour so that the intended result is, more often then not, achieved.

When the intended result is not achieved, we need to investigate why this was the case and learn from our mistakes. We may need to adjust our processes. We will probably need to make changes to how we behave, to how we act. And then we will try again.

While the recent criticisms of the W3C may have merit, to conclude that these failings somehow make the W3C irrelevant is to oversimplify the context and specific history of the problem. It may generate a lot of blog traffic, but in the end, it is a distraction and a waste of time and energy, both resources that we are in desperate need of. Especially when, as these detractors themselves have noted, there is so much work to do.