Forking and Standards: Why The Right to Fork Can Be Pro-Social

Posted on by Luis Villa

[I originally sent a version of this to the W3C’s Patents and Standards Interest Group, where a fellow member asked me to post it more publicly. Since then, others have also blogged in related veins.]

Blue Plastic Fork, by David Benbennick, from https://commons.wikimedia.org/wiki/File:Blue_plastic_fork.jpg used under CC-BY-SA 3.0.
Blue Plastic Fork, by David Benbennick, used under CC-BY-SA 3.0.

It is often said that open source and open standards are different, because in open source, a diversity of forks is accepted/encouraged, while “forked” standards are confusing/inefficient since they don’t provide “stable reference points” for the people who have to implement the spec.

Here is the nutshell version of a critical way in which open source and open standards are in fact similar, and why licensing that allows forking therefore matters.

Open source and open standards are similar because both are generally created by communities of collaborators who must trust each other across organizational boundaries. This is relevant to the right to fork, because the “right to fork” is an important mechanism to help those communities trust each other. This is surprising – the right to fork is often viewed as an anti-social right, which allows someone to stomp their feet and walk away. However, it is also pro-social: because it makes it impossible for any one person or organization to become a single point of failure. This is particularly important where the community is in large part a volunteer one, and where a single point of failure is widely perceived to have actually failed in the past.

Not coincidentally, “largely volunteer” and “failed single point of failure” describes the HTML working group (HTML WG) pretty closely. W3C was a single point of failure for HTML, and most HTML WG participants believe W3C’s failures stalled the development of HTML from 1999 to 2006. For some of the history, see David Baron’s recent post; for a more detailed
history by the author of HTML5, you can look in the spec itself.

Because of this history, the HTML WG participants voted for permissive licenses for their specification. They voted for permissive licenses, even though many of them have the most to gain from “stable reference points”, since they are often the ones who (when not writing the standards) are the one paid to implement the standards!

An alternate way to think about this is to think of the forkable license as a commitment mechanism for W3C: by committing to open licensing for the specification, W3C is saying to the HTML WG community “we will be good stewards – because we know otherwise you’ll leave”. (Alternate commitment mechanisms are of course a possibility, and I believe some have been discussed – but they’d need careful institutional design, and would all result in some variety of instabililty.)

So, yes: standards should be stable. But the options for HTML may not be “stable specification” or “unstable specification”. The options, based on the community’s vote and discussions, may well be “unstable specification” or “no (W3C) specification at all”, because many of the key engineers involved don’t appear to trust W3C much further than they can throw it. The forkable license is a popular potential mechanism to reduce that trust gap and allow everyone to move forward, knowing that their investments are not squandered should the W3C screw up again in the future.

Published by Luis Villa

12 thoughts on “Forking and Standards: Why The Right to Fork Can Be Pro-Social”

  1. This is helpful Luis. Thanks.

    When I try to rationalize the data in the survey with “… the HTML WG participants voted …”, it appears the data shows approximately 10% of HTMLWG participants voted for a “forkable license”, thus 85% of the WG participants are OK with the HTMLWG’s current document license. Is this accurate?

    Also, I think it would be useful if you would please be more specific about what you mean by “stable specification” and “unstable specification”.

  3. Good post, thanks. Just a couple notes.

    First, it’s a bit of an over simplification to say that W3C screwed up. Standards, like open source projects, are made by people who show up. What mistakes were made extended far beyond the confines of the organisation.

    Second, it’s not that I don’t trust W3C. Its heart is usually in the right place. It’s more that good institutional design is inherently about highly functional distrust, as it were.

    Now let’s make this open thing work :-)

  4. Hello Luis,

    I like the post by its simplicity in exposing some of the arguments. The trust question in absolute is a very good one. Could we explore a bit further some of the issues on both side. In both cases, not the right to fork and the right to fork, the initial community who set the process in place had *good intents*. This is a thing to remember. Like Robin said in a comment “Its heart is usually in the right place.” The non-forking policy was not planned as an anti-community mechanism but as a mechanism to stop a private company to run out with the ideas in the document and ride alone and insert its intellectual property.

    That’s an interesting point to analyze and understand in both social setups (right to fork or to not fork). Often we assume these processes in a way where the community is reasonable enough that things will not be screwed. In social contexts, the reality gets screwed a lot. It’s normal. It’s part of our social interaction.

    In a *not fork* model, the danger is that the community boundaries, in which the document is defined, are not representative enough of the technological landscape. In the case of the W3C model, the issue has been a democratic issue where at a point the influential players (browser implementers) where in a minority with regards to the other participants of the community.

    Issue 1: How do we maintain the right stakeholders around the table?

    Issue 2: How do we ensure that a democratic process is not shutting off the voices of a minority part (by number) of the community?

    In a *right to fork* model, the danger is that a community or a group with enough time and infrastructure power on their hands can deeply influence the work without taking into account the needs of some other specific communities. It is usually working very well, if all players participating have the same social power of contributing. The right to fork gives the *possibility* of doing it (which is good), but because we are not in an anarchy (political sense), it can not be effective when a community or unique structure has the power to be influential.

    Issue 3: How do we ensure that a minority with the power to influence the social dynamics of the full system is not taking over?

    As you can see I have written the issue in a neutral way, so both models (forking/not forking) can be considered when analyzing.

    My natural tendency is to believe in the nature of people with the right to fork which has you say establish the trust in a community. My worries with the right to fork comes that behind individuals there are powerful communities with the power to screw things up. And by that I don’t mean only in terms of taking over a specification, but really changing the market unilaterally. It’s a tough question.

    Still I would vote 100 times for a right to fork. :)

Comments are closed.