Go Fork and Multiply

The web standards community has been discussing using an open license for W3C standards for quite some time now. We've had a long time to look at this from quite a few angles. Having contemplated the arguments, I still feel that the fears that power the anti-forking sentiment, even though they stem from a desire to help the web, are both unfounded and powerfully counter-productive. Further, I believe that the world has changed a lot since the W3C Document License came into effect — and with the Proposed Permissive Copyright Experiment in HTML Working Group now is a good time to take this evolution into account.

Please note that all of the content in this post captures my personal opinion as a long-time member of the standards community, distilled through listening to many conversations on the topic. It is not at this point the official position of any organisation I may be related to in one way or another.

A lot of the discussion about open licenses has taken place in the context of the HTML WG or of WHATWG. This has needlessly shrouded the issue in now-gone antagonisms unrelated to it. We can usefully dispense with that context; I find the ban on forking to be problematic enough on its own.

Instead, I think that we can usefully take a more general look at the dynamics of forking.

Fragmentation is bad. That much is well established, it hurts the full constituency of the web at every level. We tend to consider that forking is bad because we work on the assumption that forking leads to fragmentation. I don't, however, believe that this assumption is verified.

If the relationship between standards and deployment were a static, mechanical one forking would indeed automatically fragment. But this is an idealised view of standards that does not match reality. Put differently, preventing forks is a solution to the fragmentation problem that only works for perfectly elastic spherical standards moving in a vacuum.

What we have instead is a complex dynamic system of interactions between standards, implementations, developers, users, and a whole diversity of constituents. Energy is directed from most parties in bringing standards and deployment into alignment, but the targets are in continual, unpredictable motion, and equilibrium is never attained.

The delta between the aspirations of standards that are not in implementations, the aspirations of implementations that are not in standards, the aspirations of users/developers/companies/etc. that are in neither is arguably the most important piece of information that we need in order to work on improving standards. Looking at the gap is how we come to know that we got something wrong, or that a piece of the puzzle is missing.

This is where forking becomes a positive force rather than a negative one. Forks require substantial effort, especially if they're going to be successful; they don't happen gratuitously And when they happen, they provide vital information about a problem that we have.

As a result, forcefully preventing forks actually removes information from the system. It also leads to rigidity that can produce a false sense of equilibrium for a while, but that breaks violently when it does (as we've seen before).

This does not mean that we should actively encourage forks or that an arbitrarily high number of forks is good. There is a point at which excessive differences push the fragmentation levels up to unsustainable levels. We should also keep in mind that while the fast release cycle used by many browser vendors today helps ensure that implementation forks can be resorbed promptly, not everyone has access to them. For instance, some accessibility tools are on longer release cycles and upgrades can be costly; leading to an increased of pain for their users when interoperability suffers. But thankfully there are two major factors on our side here.

First, forking is costly the to forker, which means would-be forkers have an incentive not to go ahead if possible. This entails that the simple credible threat to fork can produce the information required to work on solving the problem at hand, without ever reaching the actual forking point.

Second, forking is a self-limiting process. The value of forking drops sharply with every fork. There is overall a strong inclination back to unification.

Those who support an open W3C license have often made the point that openness to forking is something that could “keep us honest”. That is certainly true, but it is important to note that it is also what something that would “keep us informed”.

Finally, the value of flexible forking is not only in revealing information. It also helps with stewardship. W3C has a membership that is interestingly diverse, but for all it's value it cannot easily be representative of the full diversity of the web's constituency. Addressing the shortcomings in this representativity has been a recurring topic over the years.

In fact, switching to an open license is what makes the most business sense for any company whose needs are aligned with the improvement of the open web platform. Forked specifications are not under Royalty-Free protection, which provides an extremely powerful incentive for people engaged in forked work to bring their innovations back to the W3C and contribute to the consensus. The open document license is the other side of that dynamic: go wild, innovate, build new things with what we've done! Then come back to talk about it, and join the community in which consensus can be found around a Royalty-Free standard. It's the most cost-effective and innovation-friendly way we have of improving the web platform.

There is a reason why democracies so often make use of a bicameral system. If you have two assemblies of a hundred people each, provided that the constituencies of representatives in each assembly differ in how they are established, you then obtain far better representation than if you had a unicameral system with 200 representatives.

This does not mean that we should establish an n-cameral system for stewardship of the web, but when new assemblies rise, the existing ones should rely on their strengths in order to better represent the web's many constituencies rather than fight them with copyright. We should encourage harmonisation for the very real value that interoperability brings, and that message will be heard far more clearly if it is not expressed in legalese.

Our world has changed substantially since W3C established its document license. When it came into effect, open source was still the topic of adamant advocacy. Today, I don't even know what an open source evangelist would do. Creating a shared open source repository is now often the first step that a web developer takes in getting started on a project.

Back then, the idea that a government would commit to a massive increment in transparency through opening up its data was a notion that only a few activists dared entertain. If you so much as broached the topic, people would look at you as if you'd started speaking garbled words mid-sentence. Today, the debate on this topic is largely about how to do it well.

Back then, W3C had member-confidential groups. Today, people are often puzzled at the thought that we managed to get anything done without direct input from our community.

Over the past decade I've been aware of multiple attempts to fork W3C specifications. In none of those instances did the restrictive W3C Document License help in any way. Not once, not even a little.

Overall, my experience with W3C copyright is that it has been harmful in collaboration, useless in confrontation, and overall anachronistic with respect to the web society.

It's time for W3C to stick to the core values that led it to create the Royalty-Free policy, and move to an open specification license.