RE: Option 3

On Tuesday Mar 22, Ian Hickson wrote:

"If anything, fear of spec forking is an indicator of a lack of confidence in technical ability."

Well, I'm not so sure about your foray here into diagnosing the source of one's fears. There are lots of other reasons I can postulate, and it might be worth doing an inventory of possible reasons for fearing spec forking. I can enumerate half a dozen without so much as the blink of a frog's eye, and none would necessitate postulating technical insecurity.

I've noticed a fear that some seem to have about the fear of "license proliferation." Would your explanation of motives for fearing such proliferation hold here as well. Why not have new licenses for new specs?

Imagine a situation in which specs and licenses are invented numerously, concurrently, pseudo-randomly and in parallel, such that there is a many-to-many mapping between specs and licenses and some sort of Darwinian economics to determine the survivors. An oracle might be needed to pick from all the possibilities.

cheers
David





________________________________________
From: Ian Hickson [ian@hixie.ch]
Sent: Tuesday, March 22, 2011 12:07 PM
To: Dailey, David P.
Cc: public-html@w3.org; PSIG
Subject: RE: Option 3

On Tue, 22 Mar 2011, Dailey, David P. wrote:
>
> When these issues were discussed in 2009, I was of the opinion [1], as I
> gather Larry Rosen has said that the consensus of the Working Group was
> that forking of the spec was not desirable.

This is incorrect. It is possibly the majority opinion of the AC
representatives of company members of the W3C that forking should not be
allowed, but it is not the consensus opinion of the HTML working group. In
fact, two of the use cases the working group presented to the W3C are
explicitly about forking. A solution that disallows forking wouldn't be
one that addresses the requests of the group.

(It would also be pointless, since any solution that disallows forking is
already less permissive than what we already have as the spec's license,
and would therefore not change anything.)


> " An organization or individual modifies the content of the spec in ways
> that intentionally misrepresent its content and that mislead others as a
> result. We do not, I think, want to encourage prosecution against the
> well-meaning author of a book who misunderstands the specification, but
> rather against those who might seek to perpetuate coding practices
> contrary to the spec which might, for example, favor one browser
> implementation over another."
>
> It is specifically that, I think that would constitute a fork.
>
> When two competing specifications for the same thing exist, it seems
> that a "standard" no longer exists.

Competing standards are not a bad thing. On the contrary, they ensure that
it is technical superiority, and not fiat, that continue to be used to
determine the organisation that has the authority to lead the Web.

If anything, fear of spec forking is an indicator of a lack of confidence
in technical ability.

Note that nothing stops someone from doing what you describe (modulo the
intentional misrepresentation). It is essentially how HTML5 started in the
first place, in fact, without any violation of copyright (we started from
scratch). I just want the next person who disagrees with the current path
to be able to do so without having to duplicate the last 7 years of work.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 22 March 2011 22:40:10 UTC