Questions & Answers blog

The participants of the W3C tech plenary are back from their lunch overlooking the gorgeous Charles river, to tackle the question of "openness".

This is a development from a topic already raised today: a lot of people's lives and living depend on Web technologies, and there is an enormous pool of opinions and contributions to the work now being done at W3C.

Update 2007-11-08 The slides of the panelists' presentations are now available:

• Deborah Dahl (Conversational Technologies, HyperText CG, Multimodal Interaction WG chair.
• Art Barstow (Nokia, Web Application Formats WG chair)
• Ian Hickson (Google, WHAT-WG, HTML WG, CSS WG, ...)
• Paul Cotton (Microsoft, Web Services Policy WG chair)

I get the impression that a lot is being crammed into this topic of "openness", which seems a bit dangerous. Is allowing public feedback openness? Is letting anyone with enough time and energy participate, in effect keeping out people not able to follow an enormous volume of discussion (in english only...) a real open process? As one contributor from the floor notes, open does not imply inclusive, and "openness" as a mostly US-communities-based mindset defines still has issues of language barriers, not reaching all the communities you need to reach. Also, are we talking about openness, or transparency, or both?

Terminology and definition of openness notwithstanding, getting more people to contribute does have a great appeal: this means more ideas, more pairs of eyes and brains to look at the specification. All this, so far, was covered by a W3C process ensuring public reviews of every specification at every stage of their maturity, but for many, this was not sufficient: there is a clear wish for direct involvement in the decision making.

This indeed has some serious advantages: in the development of our Open source tools, I have observed that contributors react very differently when they feel they are "outside", as bug reporters for instance, and "inside", as part of the development team. Being part of the process means that you have a better chance of understanding it, and, sometimes, go and explain it to others.

In this way I feel that opening working groups to the public in a process similar to what has been done with the HTML Working Group since March this year not only made a lot of people happy and brought up tons (too much too soon?) of ideas, but it also made a lot of people who may have kept a cynical outlook on the new HTML work, ambassadors of this work, genuinely excited by the work.

There are a lot of good concerns about making groups working on specifications more open, and as I write this, Art Barstow of Nokia, on stage, works on debunking them one by one...

• Openness brings too much input? that's the point, he thinks, to get feedback early, not too late.
• IPR and licensing terms become a hairy subject with hundreds of participants, not always clear on their affiliations? Ensuring that patent policy commitment gets signed prior to joining the group would (should?) solve most of the issue.

Does this mean that an open working group is the perfect solution, or are there technologies where a small task force, with frequent calls for feedback on the material they process, is more efficient? Standards veteran Paul Cotton tells us that you can have a very healthy community without needing a lot of "invited experts", if there is a solid submission with early support from a community. And eventually, you get down to a core group that actually does the work.

Which model will W3C adopt for its future? This is hard to tell. we know that the small group, public feedback scheme has worked well (and less well) for many specs in the past, whereas the recently born HTML working group, yet to have its first face-to-face meeting or publish a snapshot of its specification(s), is still an experiment.