Web @ 25, W3C @ 20 – Creating an Agile Web Standards Ecosystem
Last week I wrote about the future direction of the Open Web Platform. The success of the Web emanates from numerous sources. Its success comes from the basic idea of the Web, generations of innovators who have found better ways to utilize the Web, investments by companies to improve the value of the Web, etc.
The Web Standards community cannot arrogate credit for the success of the Web. Nonetheless, this community has played a significant role. An earlier post described competing pressures from stakeholders which make it hard to reach consensus about future needs. It is even more difficult to reach such consensus with speed – a speed that matches the speed of innovation of the industry. Yet, we have seen success in the rapid introduction of new technology.
At the 20th anniversary of the W3C let’s reflect on how the Web Standards Community has become more agile to address the growing requirements of a stable, open core for our Web of diversity and rich application.
Standards are developed by different standards organizations with different degrees of openness, multi-stakeholder input, speed, and consensus. W3C’s approach to standardization is best summarized by the OpenStand principles to which we are signatories, punctuated by our strong focus on Royalty Free commitments. The formal W3C Process ensures that W3C is faithful to OpenStand requirements of consensus and getting the best possible ideas for the future Web.
The W3C Process was defined several years ago, the world has changed, and we are adapting. We change because we are more committed to the enhancement of the Web than we are entrapped by the details of the W3C Process. We also look for good ideas that come from anywhere in the Web ecosystem – even if they do not follow our process. Finding the right balance between process and flexibility has been a defining characteristic of W3C’s focus in the last several years and provides the agility we need for the future.
The formal W3C process works well when there is a consensus in the community that a particular technical topic is ripe for standardization. However, the overhead of starting and operating a W3C Working Group —due to a charter review process that seeks Member support for new work— is sufficiently high that it does not pay to start a WG unless a topic is ripe. Several years ago, we noticed that due to this high overhead, when stakeholders wanted to work together on pre-standardization topics; topics that might be ripe in 1-2 years they would simply go elsewhere. But once work started elsewhere it was hard to bring it back to W3C. The resulting fragmentation convinced us that we needed a more agile approach for pre-standardization work.
Two and a half years ago we introduced W3C Community Groups (CGs) for the community to collaborate on pre-standardization efforts. The results exceeded our expectations. In just a short time we now have more than 170 Community Groups (typically we have 50-60 Working Groups) and over 3500 engineers working in these groups (our Working Groups typically have about 1500 engineers). In a very short time we have tripled the community of engineers working on the future of the Web at W3C.
The flexibility of Community Groups (low start-up overhead, no constraints on participation) is one plank of our search for greater agility. True to our principles, we made sure that even low-overhead CGs have a (lightweight set of) Royalty-Free declarations.
Standards Track Revision
Community Groups help for early work, but there is a need for mainline standardization work to become more agile as well. In the years since the W3C Process was established we have seen several changes that require a higher degree of agility. These include:
- Open source development which ensures that technologies develop faster and more openly than in the past.
- Browsers ship new functions with much greater speed – users get a new browser download every several months.
- (Partly as a consequence of open source development) there are more browsers in the marketplace and so more early experimentation is taking place.
- In industry, there is no longer a waterfall process of standardization followed by implementation – standardization and implementation happen simultaneously. So standardization processes must adapt.
The heart of the W3C technical standards development process is found in Chapter 7 of the W3C Process Document. It needs to be adjusted to allow more agility, more parallelization of work, and less bureaucracy. W3C is in the middle of a major revamp to simplify the process and make it a more modern for the next 20 years.
Modularity: CSS, WebApps, HTML
Greater agility is not achieved solely through process innovation, it is also achieved through design. We are seeing an increase in the application of this principle across groups. As the breadth of technologies and use cases increase, it is not possible to address these in a single monolithic specification. Major pieces of web architecture are now modular, such as CSS 3 Modules, independent efforts for Web APIs, and HTML Extension Specifications.
Within the Web Standards community, there are those who feel that we need to be even more agile. The WHATWG is a community of web engineers who advocate a Living Standard model. Instead of taking (typically) a couple of years to create a next generation standard, they advocate a model whereby new enhancements are continually included into a specification and the “current version” of a standard is available on a daily basis.
W3C, while respecting the desire for agility, has a different approach. We agree that Web technology is “Living”, that rapid iteration of releases of standards is desirable and that Editor’s Drafts of the current thinking of the community should be constantly kept up to date. However, we reserve the name “Standard” for specifications that have gone through our consensus process, have wide community input, are stable, have demonstrated interoperability, and have patent commitments behind them.
Despite different methodologies, we work together. The reason is simple. When you ask engineers in either community what their primary objective is – it is not related to any particular process or methodology – “it’s all about improving the Web”. So at W3C we’ve taken steps to partner with the WHATWG. These include the aforementioned CGs, liberalization of our Document License, and backing up email lists of the WHATWG. Because the overarching W3C goal is our mission to Lead the Web to its Full Potential.
Liaisons with Other Standards Bodies
The impact of the Web on society is immense and it is impossible for W3C to standardize everything. We may define our mission to be “Leading the Web to its Full Potential,” but it is not realistic that we do it entirely ourselves. Partly this is due to history - some important organizations (e.g. IEEE Standards Association) predated us and were already working on key technologies; partly it is due to the fact that if Web standards affect an industry, it often makes more sense for an industry body to formulate its Web standards. To ensure a good working relationship with other Standards bodies, W3C maintains scores of liaisons with other bodies.
Some of these are of particular note. The Web sits on top of the Internet and so our closest Liaison is with the Internet Engineering Task Force (IETF). The IETF not only provides the Internet layer standards, but also provides key standards that are of direct relevance to the Web, such as HTTP.
At a different level, the International Standards Organization (ISO) develops de jure standards with the involvement of governments. While W3C’s methodology is different (and tuned for the needs of the Web), we recognize that there is a demand for certain standards to be ratified by more formal organizations. Accordingly, we have achieved PAS status (Publicly accessible Specifications), which enables W3C Recommendations to also be endorsed as ISO/JTC1 standards.
Dealing with Controversies
Given the impact of the Web, it is axiomatic that different stakeholders will have different views on key decisions. And no individual or organization has a monopoly on truth to correctly make all decisions. So how do we deal with controversy in a way that supports agility and prepares for the future?
Most controversies are technical in nature and are well contained within Working Groups. Working Groups operate by consensus and on almost every technical area of disagreement they are able to reach consensus and compromise.
Some topics (often those that relate to the scope of W3C) are more complex, including:
- Our decision that “content protection” is in scope for the HTML Working Group. This has been extensively debated in the Restricted Media Community Group.
- Our decision that “Compliance” is in the scope of the Tracking Protection Working Group. This has been a subject of public debate.
We also have controversy related to our internal processes. These controversies include:
- The Living Standards Model
- The copyright license under which W3C Recommendations are prepared.
- Major technical decisions such as the decision to standardize XHTML.
We believe that we have a robust approach to dealing with such controversies which will continue to serve us in the future. Some of the key aspects of our approach include:
- Open dialog and discussion; enhanced with Community Groups
- Consensus decision making
- Formal Objections which allow stakeholders to appeal to Director, Tim Berners-Lee
- A resolution approach (by Tim) to resolve objections via consensus rather than fiat, whenever possible.
W3C is evolving its model to serve the Community in other ways than specifications. Webplatform.org makes it easier for developers to learn about how to use W3C specifications. W3C Validators make it easier for web site developers to validate that they are creating their pages correctly. W3DevCampus provides on-line training in W3C specs to developers.
The Web has long been Global, but the globalization of the Web development community has been intense over the last several years. Much of this is due to rapid penetration of the Internet in Asian countries (e.g. China), as well as the increased importance of Mobile, which has a large global footprint of vendors, service providers, and applications. Moreover, the availability of open source browser tool kits has made it easier for manufacturers around the globe to create their own browsers – driving more innovation and involvement with standards setting.
W3C has intensified its global engagement. We have Offices in about twenty countries. Our Working Groups take up needs of a global marketplace – such as Internationalization, and vertical text support. Our Global Membership has grown. Significantly, in 2013, we added a Host location for the first time in 15 years – in China.
There is more to be done. Participation in W3C activities is still challenged by issues of culture, language, and time-zone. We anticipate that our global Hosts will facilitate rapid improvement in these areas.
As we celebrate the twin anniversaries of the Web at 25, and W3C at 20, we look back at tremendous accomplishment. In a Boston Globe article coinciding with the 150th Anniversary of MIT, the W3C was rated as the most important contribution that MIT has made to society. And the Web is the most impactful innovation of our time. But we are focused on the future. We see opportunity for further impact of the Web and are re-engineering key aspects of W3C so that we may continue our mission to Lead the Web to its Full Potential.