W3C Change: Introduction
Published 17 years, 7 months pastWhen I posted about the W3C, a few people responded with, “All right, fine, you’re angry with the W3C. So what’s your alternative, smart guy?” A fair enough question.
While I applaud the efforts of the WHAT WG and the microformats community, I’m not advocating a complete dismissal of the W3C. The basic role filled by the W3C, that of being a central meeting place and coordinating body, is an important one. It’s also potentially damaging. Think of it like a central file server at work. As long as the server is fine, your work can continue. If it goes offline or, worse, its contents get corrupted, you’re in a very bad position.
When I point to the WHAT WG and microformats, I’m not holding them up as saviors or replacements. I’m simply drawing attention to effects of the basic problem. Both communities arose because of the nature and (lack of) speed of the W3C and its work. We could argue about whether or not they should replace the W3C, but the simple fact is that had the W3C been more responsive and in touch with developer needs, they would never have existed in the first place. They wouldn’t have had to exist.
If the W3C can get back on track, I wouldn’t want to see it replaced. If it can’t, then it will be replaced, no matter what I or anyone else has to say. That doesn’t mean it would cease to exist, of course. It would simply become less and less relevant. I have some ideas about how the W3C might avoid such a fate, but they aren’t things that I can cover in a single post. Instead, I’ll do it in three parts, and the three topic areas I’m going to address are:
- Communication between Working Groups and the public
- Working Group membership and chartering rules
- The basic operating model of the W3C
No small potatoes, those. It will be interesting to find out what people think of my proposals for each.