[conspire] "Fear of Forking" comments

[Rick Moen]

[The old thing in question is at
http://linuxmafia.com/faq/Licensing_and_Law/forking.html ]

 Date: Mon, 15 Dec 2008 14:48:10 +0100
 To: rick at linuxmafia.com
 From: "Christopher Oezbek" <oezbek at inf.fu-berlin.de>
 Organization: FU Berlin
 User-Agent: Opera Mail/9.61 (Win32)
 Subject: Fear of Forking Fanmail

Hi Rick,
   just a thank you note for your excellent Fear of Forking article. I had  
been looking for days for a reasonable account of forks in Open Source  
projects to cite in my thesis, when I finally found yours. It is truely  
great!

Two questions:

   * Did you every think about publishing it at a scientific conference (or  
First Monday, which probably would take it unchanged)?

   * You give three reasons for forks, of which your second is "Decide to  
stand in the way of progress" and I was wondering if with ECGS/GCC (and  
recently TWiki/Foswiki or XFree86/X.org) one could rephrase this reason as  
"Restrict contribution".

Greetings from Berlin,
   Christopher

-- 
Christopher Oezbek | Freie Universität Berlin | Takustr. 9, 14195 Berlin
http://www.inf.fu-berlin.de/~oezbek/ | +49 30 838 75242 | Raum 008





 Date: Tue, 16 Dec 2008 14:42:02 -0800
 From: Rick Moen <rick at linuxmafia.com>
 To: Christopher Oezbek <oezbek at inf.fu-berlin.de>
 Subject: Re: Fear of Forking Fanmail
 X-Mas: Bah humbug.
 User-Agent: Mutt/1.5.11+cvs20060403

Quoting Christopher Oezbek (oezbek at inf.fu-berlin.de):

>   just a thank you note for your excellent Fear of Forking article. I had  
> been looking for days for a reasonable account of forks in Open Source  
> projects to cite in my thesis, when I finally found yours. It is truely  
> great!

Why, thank you, Christopher.  It's been many years since I've even
thought about that article, and I'm glad it stilll has some readers.

[Snip my private discussion with Christophe of the circumstances in
which I wrote the cited essay.]


>   * Did you every think about publishing it at a scientific conference (or  
> First Monday, which probably would take it unchanged)?

I honestly don't think it ever qualified for a true scientific
conference.  You're right about First Monday -- which I'll confess I'd
never really considered for it.

As the essay stands, I think its main problem is that all of its
examples are nine years old.  Thus, it's a snapshot of a particular
point in time (late 1990s), but fails to cover recent software history.

Also, my essay's tone is, I think, too informal even for First Monday,
which seems to aspire to a strictly academic style and vocabulary that I
could probably imitate but never comes naturally to me.  (You might
have noticed that I have a fairly distinctive writing style.)

However, thank you for the suggestion.  If I ever write a new version, I
will certainly consider First Monday.

>   * You give three reasons for forks, of which your second is "Decide to  
> stand in the way of progress" and I was wondering if with ECGS/GCC (and  
> recently TWiki/Foswiki or XFree86/X.org) one could rephrase this reason as  
> "Restrict contribution".

You've paid more attention to my essay than I did.  ;->  (Of course, you
need to do this for your thesis, for which I wish you good fortune.)
Specifically, I'd never bothered to categorise and tally the underlying
reasons for forks, even though I'd described them in passing.


The EGCS affair was very strange:  It was never entirely clear to me why
Richard Kenner (gcc maintainer through 2.7.x) so consistently refused to
accept Pentium-optimisation patches, although he must have known that
there was huge pent-up demand for those improvements.  If you're asking
whether it's fair to say that Kenner simply wanted for some reason to
restrict contributions, I confess I cannot really say whether that is
so.  Perhaps the best course of action would be to ask Mr. Kenner for
his own account of the matter -- bearing in mind that it might remain a
delicate subject even at this late date.

For all I know, Mr. Kenner might have simply been overwhelmed with the
volume of work required for that extremely complex volunteer project,
and might have been unresponsive to some major patches for that reason
only.

(Even in the existing text of my article, you will in at least one place
see signs of both sides of issues contending, albeit politely, to have
their side of a story prevail:  footnote #25 to the glibc story.  After
publishing the initial, uncorrected essay, I received separate and
somewhat conflicting accounts of the affair via e-mail from both Richard
M. Stallman and Ulrich Drepper.  I'm in no position to investigate
further, so I simply summarised both parties' key assertions in the
footnote.)

The recent TWiki/Foswiki matter seems to be a straightforward case of a
commercial firm, under the influence of venture capital people, taking
an open source codebase proprietary and attempting to freeze out the
outside developers, who thereupon left and founded a successor project.

Obligatory disclaimer:  I have no inside knowledge of the TWiki matter
whatsoever, being simply an observer who watched the story develop on
the Internet.  However, what I did hear seemed quite familiar from
observing another, similar case, where a sponsoring firm (which I will
not name) carried out these steps concerning an important open source
codebase:

1.  Keep promising a new official code release, but never delivering it.
2.  Approach past outside contributors privately and attempt to convince
    them to sign over copyright ownership to their past and future 
    code contributions.
3.  After there had been no official code releases for a couple of
    years, quietly disable CVS access with no explanation.
4.  Eventually announce the existence of a proprietary fork, but 
    promise that the "community edition" would continue to be maintained
    -- but then never deliver on that promise.

The codebase in question eventually produced about five competing
community forks, each from a group that either had a CVS checkout or 
was independently patching the most recent public release.  For a long
time, most people (gullibly) waited for the sponsoring firm to produce
new "community edition" releases as promised.  

Finally, the original author of the codebase was laid off from
employment with the firm.  Six months later, apparently when his legal
obligation not to compete expired, he produced a new version of the
original codebase (based on his CVS checkout of the day before the firm
took it proprietary) under a new name for trademark reasons.  It quickly
became the standard version of that software.

(I apologise for not being able to name names, but it's a legal
precaution, especially as I have some past associations with the
parties.)

My point is that there's a characteristic pattern of (somewhat furtive)
behaviour from firms that are taking an open source codebase proprietary
and are seeking to suppress competition:

o   Shut the community out of code access, but placate them with words.
o   Attempt to mislead and delay community reaction.  If possible,
    try to arrange for multiple community groups to exist and not
    unify.
o   Seek copyright assignments to gain sole control to the extent
    possible.
o   Start wielding trademark rights to intimidate competitors.  (To be
    fair, there are also legitimate trademark concerns that must be
    protected by any business relying on them -- and by strictly volunteer
    projects that use them to indicate identity, too.)

(I've been tempted to write a new essay, a set of case studies of
different ways firms have taken codebases proprietary and attempted to
dissuade open source competition.)

Getting back to your question, I would speculate that TWiki.net's
motives can be best called "achieve centralised, proprietary control".
The "restrict contribution" aspect strikes me as incidental to that
underlying aim.  That is, they probably still welcome contribution:
They just want to have clear ultimate control.

(Again, I am going only by what I've read on the Internet.  I have not,
for example, asked Mr. Thoeny for his account.)


The XFree86/X.org split seems to have been equally as bizarre as the
EGCS/Kenner affair:  I gather that the XFree86 Project had never been
very open or healthy (including the highly questionable ejection of
Keith Packard), but that the crisis was caused by David Dawes's quiet
addition of a "credit clause" to the licence, causing severe
copyright-compliance problems to downstream projects that used parts of
the codebase in copyleft (specifically, GPL/LGPL) projects.  That, in
turn, caused an avalanche of support departures, immediately coalescing
around Packard at Freedesktop.org and X.org.

Dawes and the other XFree86 Project Board of Directors members did not, 
to the best of my knowledge, ever seek to take that project proprietary,
_but_ they did attempt to keep very tight control over the development
process and information about it -- which seems to have caused the
friction with Keith Packard, the brief 2003 XOuvert fork (which in turn
inspired Dawes's licence change), etc.  I suppose you could call that
"restrict contribution".