Leading items

WHATWG severs collaboration with W3C on HTML

Fans of HTML will be either thrilled or annoyed by the news that there will soon be two independently maintained standards claiming to be the authoritative definition of HTML. The Web Hypertext Application Technology Working Group (WHATWG), a team comprised of representatives from various browser makers, announced that it is terminating its collaboration with the World Wide Web Consortium (W3C) on the standardization of HTML 5. In WHATWG's account of the split, it is continuing to develop the "living standard" of HTML, while W3C's HTML 5 specification is a frozen "snapshot" of HTML. Based on the public statements and history between the two groups, the underlying issue has more to do with the standardization process than it does with technical differences between their versions of HTML. Nevertheless, competition over who has the right to declare their vision of HTML the official standard will likely cause headaches for web developers.

WHATWG founder and chief public spokesman Ian Hickson posted the news to the WHATWG mailing list on July 19. Hickson (who is a Google employee) had been the primary editor for both the WHATWG and for W3C's HTML Working Group. According to the announcement, Hickson will continue to be the lead editor of WHATWG's HTML work, but leave the W3C editor position. WHATWG will formally be a W3C "community group" (CG), and will continue to use a W3C-hosted issue tracker. On the latter point, however, Hickson and the W3C did go through the existing bugs filed against the previously-unified HTML specification and clone separate copies, one for each of the now distinct specifications.

The upshot is that WHATWG now regards its version of HTML as the definitive standard, which will continue to evolve, without declaring numbered versions. Hickson concluded "My hope is that the net effect of all this will be that work on the HTML Living Standard will accelerate again, resuming the pace it had before we started working with the W3C working group."

Hickson cited two reasons for the split. First, the W3C separated out several parts of the HTML 5 specification into distinct sub-specifications (such as the 2D canvas element, postMessage, and server-sent events). The result, he said, was "an increasing confusion of versions" of the specification, in response to which WHATWG "went back to just having a single spec on the WHATWG side which contains everything I work on." Second is a divergence between the WHATWG and W3C processes. Attempting to explain what that means, Hickson described WHATWG's process as "fixing bugs as we find them, adding new features as they become necessary and viable, and generally tracking implementations." In contrast, he said, the W3C HTML working group is focused on "creating a snapshot developed according to the venerable W3C process."

What, work in a group?

To the untrained ear, those reasons might sound like WHATWG simply does not want to participate in a standards process at all. But there is more pointed criticism of the W3C on the WHATWG site, which calls the term HTML 5 a "buzzword" and enumerates several specific differences between the two standards, linking most of those to W3C HTML working group decisions that WHATWG evidently found disagreeable. The decisions that WHATWG critiques date back to mid-2010, although many of them seem to be connected to the working group's recent attempts to finalize HTML 5 over the course of 2011-2012 — such as disagreements over the actual wording of the specification and its inline advice (as opposed to, say, contradicting definitions of HTML elements or attributes).

WHATWG's disinterest in finalizing the standard was also evident in a blog post Hickson made in January 2011. That post announced that WHATWG's version of HTML would drop version numbers altogether, on the grounds that "the technology is not versioned and instead we just have a living document that defines the technology ." The HTML "Living Standard" terminology persists in the group's current communication. W3C, in contrast, is still moving forward with finalizing the HTML 5 specification and its successors. In an April message to the HTML Working Group list, Maciej Stachowiak said the W3C has begun to extend the HTML Working Group's charter to tackle "HTML.Next" and will proceed to examine proposals, including "the WHATWG HTML specification, which we anticipate will be one such proposal."

Viewed in that sense, the split between the two groups is not so much a forking of HTML into separate proposals as W3C's HTML 5 is a "frozen branch" of WHATWG's trunk. Or it would be, were it not for both groups' claims to represent the official standard for HTML. Hickson made this claim explicitly in his email, calling WHATWG's HTML Living Standard the "canonical description of HTML and related technologies." W3C's claim to ownership is less overt, but the group and its founder Tim Berners-Lee have written and formalized HTML since its inception in the 1990s. The first draft was written in 1993, with subsequent revisions published as IETF RFCs before the W3C process took over.

WHATWG was founded by a group of browser makers who felt that W3C's process was too slow and bureaucratic, so perhaps it is miraculous that the two groups were able to collaborate so successfully as long as they did. In any case, the practical question is what the split means for HTML developers — and, by extension, web users.

The great thing about standards is ...

The principal reason for concern is that if the two specifications drift in different directions, web developers could be forced to add even more workarounds to match both, or else sites could be branded "WHATWG HTML compatible" or "W3C HTML compatible," reminiscent of a return to the dark days of serious browser incompatibilities. In addition, WHATWG's "living standard" approach has its own critics, principally on the grounds that a constantly-in-flux document makes for a poor standard. A commenter named Mike asked on the 2011 blog post "How do you make a test suite and a browser compatibility chart for a “living standard”? It sounds like HTML is becoming a sort of Wikipedia revision style chaotic nightmare." Similarly, Jukka Korpela said:

Indeed, the current presentation of WHATWG's incarnation of HTML does sport a Wikipedia-style "last updated" timestamp at the top (the last update was July 24, 2012 as of press time), plus floating tooltip-style markers that point out certain paragraphs as "ready for first implementations" from the margins — both features that hardly inspire confidence in the specification's stability.

Steve Faulkner replied to Hickson on the WHATWG list and took direct issue with WHATWG's assertion of canonical-ness. "The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification." In particular, Faulkner pointed out that WHATWG's specification, like W3C's, cover only browser implementations and not authoring recommendations (which tackle critical issues like accessibility in addition to stylistic advice). On that front, Faulkner said, the W3C's specification has the "more accurate set of requirements and advice, that takes into account current implementation realities, thus providing [authors] with more practical advice and thus end users with a better experience."

Hickson and WHATWG have not responded publicly to Faulkner's message, but perhaps that is to be expected. It seems clear that WHATWG's primary motivation is continuing to add to HTML and related technologies as quickly and as often as its members wish. Of course, that highlights another thorny issue. As a standards-setting organization, WHATWG is not particularly accountable; membership is by invitation-only and Hickson can only be removed as HTML editor by the members. Other members of the public are welcome to join the mailing lists as "contributors," however. W3C may not be particularly democratic either, but its flavor of bureaucracy is more diffuse, with various working groups, interest groups, coordination groups, and boards.

The H postulated in 2011 that the seeds for the divergence of the two groups could be traced back to WHATWG's dislike of W3C's HTML 5 logo and related branding effort. One would hope that a core web technology like HTML would be above that level of triviality, but the alternative reasons given in public are not much more satisfying. With any luck, though, the web will eventually route around the damage — one way or another.

Comments (26 posted)

Akademy: KDE successes and areas for improvement

As with most conferences, Akademy offered a wide variety of interesting talks. Some of those talks have already been covered over the last few weeks, but there is still a bit more to say about Akademy. It was an energetic conference, in a beautiful city.

Akademy was broken up into a two-day conference portion followed by five days of meetings, workshops, hackfests, and BoFs. Most of the latter sessions are difficult to write about, particularly if one is helping out on a nearly full day workshop on one of those days. But a couple of the talks from the first two days stand out. In some ways, they complement each other well; one looks at some of the successes the KDE project has had, while the other looks at ways its governance could be improved.

Success stories

In the community keynote, Agustin Benito Bethencourt gave several examples of "success stories" that make him optimistic for the future of KDE. It is important to focus on successes because, in uncertain times in the software industry, those stories give the project "confidence in what the future will bring us as a community and as a free software project". He started with the example of the idea that the Qt framework should be free. When he first attended Akademy in 2005, many people were talking about a free Qt, but most people outside of the KDE community never thought it would happen. But inside KDE, "the idea remained strong", and it did eventually happen.

Now Qt has an open governance model, which came about because the KDE community "helped by pushing", he said. It is an example of "active patience", where KDE continued "making good stuff" and pushing for a more open Qt development model, which led to the desired outcome. In the future, if the project can confidently "keep pushing in the same direction", similar results can be achieved.

The KDE development process is unique, and there are "very few big companies that are as efficient as we are", Bethencourt said. Companies often say that KDE isn't succeeding, but they can rarely match it in the ability to develop new code. It is important for the project to recognize that and "to keep the efficiency that we have".

Another good sign for the future is how good KDE has gotten at incubating businesses. There are more and more freelancers and entrepreneurs in the community, with KDE-related companies springing up frequently. KDE provides the "right ecosystem", so the limits on what can be done simply disappear. It is important to "keep that wheel rolling", he said. Developers, translators, and designers will be building more new companies, and the project will be even more business-friendly in the future.

The project has always had a vision of where it is going, which is important. He recalled the days when the discussions about KDE 4 started, and when it was released he put it on a laptop. It worked, but was not perfect—over time that changed. The project has "a clear vision of where we want to go and we deliver after some time and work", Bethencourt said. That makes others want to "develop under our umbrella". Having a vision and sticking to it "will bring in outside energy".

The project also has longevity going for it. It is very difficult for a software business or a project to keep going for a long time, and KDE has been "innovating for the last 15 years". What KDE is doing now is "very different from what we were doing before", but that is a strength. There will be more changes over the coming years and if it keeps that "innovation mode", KDE has a bright future ahead of it. There is very little that can stop KDE from being here in another 15 years, he said—other than limitations that come from within the project itself.

Is life peachy?

Mirko Böhm started his talk with a reference to Mathias Klang's keynote that had come just before. Klang mentioned the "anti-homeless" benches that were installed in Tokyo to make it nearly impossible for anyone to sleep on them. Böhm said that he thinks KDE has some of those park benches, metaphorically, in that the project's governance is designed to keep in people that the project likes, but makes it "hard for those we don't [like] to join us". He wanted attendees to start thinking about "where in KDE those park benches are".

Böhm has been contributing to KDE since 1997 and was a KDE e.V. board member from 1999 until 2006. He helped organize last year's Desktop Summit, and is currently doing research on free software and intellectual property issues at Technical University Berlin.

He has heard the claim that KDE is good at sticking its head in the sand. To illustrate, he put up a flowchart with a bubble that asked "Is life peachy?". If the answer is "yes", then "go do something" (e.g. write code), but if the answer is "no", "stick head in the sand", then "go do something". That is obviously not the right way to approach things, as there needs to be a way to take action to fix the problems. Changing the "stick head in sand" bubble to "change something" and re-routing back to the question is a better way. In order to decide what the "something" is that needs change, one must first observe and then reflect on the problems.

"Is life peachy at KDE?", he asked. For the most part, it is. KDE is the largest meritocratic volunteer-driven free software project; other large projects are mostly not run by volunteers, he said. KDE has an "outstanding product", with a fairly stable contributor base. "As a community, we are pretty healthy." The KDE code of conduct has been copied by other organizations and the project serves as a role model for other communities in free software.

Most folks want to stop at that point with the idea that "everything's fine"—except that it isn't, Böhm said. There are a number of areas where things aren't "peachy". To start with, users are complaining about a lack of technical improvements in areas they care about. At times, the feedback that they are providing "does not lead to tangible improvements".

There are also complaints about a lack of transparency in the governance of the project. Böhm is concerned that contributors are leaving for "non-technical reasons". It doesn't worry him if someone leaves because they graduate and get a job, but if they are "trying to make a difference, but can't" and leave because of that, it's a problem. Similarly, the project suffers from a failure to integrate a commercial ecosystem; it is "good at pissing off companies" so that they leave. That also leads to problems getting vendors to pick up KDE and ship it with their products or distributions. When making a software product, what matters in the end is that someone is using it, he said.

Böhm and Sebastian Kügler recently scored the project using the Open Governance Index (OGI) to try to get a sense of where it ranks. They found that KDE ranked second in openness, behind Eclipse, but ahead of projects like the Linux kernel, WebKit, Mozilla, and others. That shows that the project is doing well, overall, but "we could do better", he said. His goal would be for KDE to rank first.

There are positive points about the KDE community, but some reflection on them is needed. It is a meritocracy with self-directed contributors. That means that whoever does the coding work makes the decisions. But it leaves those who don't contribute code without a voice in the decision-making. That may not be quite right, he said, as there are others that make non-code contributions who may deserve a voice.

KDE e.V. is not "just" a support organization, but is set up to "support and foster the development of KDE". It does a good job of that, but there are some problems. Only individuals are allowed to be members, not companies or organizations. Those entities can sponsor KDE e.V., but they get no vote. People can only become members of KDE e.V. by invitation, which may leave out people new to the project at times. However, those requirements (individual-only, invite-only) are necessary to protect the assets of KDE e.V. as it is set up such that each member becomes a shareholder in the company.

One of the bigger problems that he sees with KDE e.V. is that it is "secret by default". That leads to downgrades in the OGI score, but it also may give the impression that the project is being run by a secret cabal. It is often said that KDE e.V. makes "no important decisions", but he doesn't agree. Akademy was held in Estonia because KDE e.V. decided it would be, for example, and the organization decides on who gets funding for things like sprints as well. Böhm believes that the "secret by default" approach is hurting the KDE community.

Some reflection on the role of commercial contributors is also needed. Currently, there are only individual contributors, mostly volunteers. That can be contrasted with Android, where there are few or no volunteers. But in order to use all of the available effort, there needs to be some thought about how to involve companies in the community. KDE is just about the only community where companies have no voice, he said, which is "not all bad"—indeed, it may be part of why KDE is still around after all these years.

Proposals

That is "enough reflection", Böhm said, and proceeded to outline some proposed actions to rectify some of the problems he observed. First off, he would like to see KDE stop sticking its head in the sand and try to address problems that crop up. Every year at Akademy, it would be good to see improvements in the areas that have been identified. For example, he proposed that there be a corporate liaison for KDE e.V. to work with companies. He also proposed that users get a voice. There is a KDE e.V. user working group that is being formed, but it should be made more formal in order to give users some say.

The Community Code of Conduct should also be extended, he said. It currently lists the responsibilities of contributors, without covering the rights of contributors. Those two things "normally go hand in hand". Contributors' rights would cover things like the ability to influence development, which is something that is not true for companies that contribute today.

The right to be treated as an "equal among peers" is another right that should be enumerated. Currently, there is something of a divide between technical contributors and non-technical contributors that could be addressed by this right. There is an overall need to minimize discrimination within the community between various sub-groups: technical vs. non-technical, volunteer vs. companies, users vs. contributors vs. KDE e.V members, and so on.

He also proposed that KDE e.V. adopt an "open by default" approach. Always defaulting to secret discussions on a closed mailing list, even for topics that have no need for secrecy, results in less open governance. That is bad for KDE, he said. Next year at Akademy, he hopes to have a similar talk, but one that looks at what has been accomplished in these and other areas.

Well-organized, interesting, and fun

Overall, Akademy was very well done. The talks were engaging, and the location was stunning. It is always nice to get a feel for what is happening in a large development project like KDE, and Akademy provided a great way to do that. KDE is a vibrant project and its conference reflected that. Once again, thanks to KDE e.V. for travel assistance so that I could go and have an interesting—and fun—trip to Tallinn.

Comments (1 posted)

Page editor: Jonathan Corbet
Next page: Security>>