Re: [Gnu-arch-users] hmmm.

[Tom Lord]

    > From: Miles Egan <address@hidden>

Let's please be careful with attributions.   I suppose it's my fault
for not commenting on the article I forwarded.   


    > Tom Lord wrote:
    ^^^^^^^^^^^^^^^^^

Actually, _Larry McVoy_ wrote:

    > >Let's put this into context. I got up this morning to find Aaron's
    > >posting and I started looking into the problem. It turned into a mess
    > >and rather than spend Saturday with my wife and kids I sent them out
    > >of the house so I could focus on this and fix it. It took several
    > >hours to track down the bug and the tree has been rebuilding since
    > >about 1pm. I gave up half my weekend to fix this stuff. I made my
    > >family get out of the house for your benefit, my wife is pissed at me,
    > >my kids are pissed at me, and people here are rude to me for giving
    > >them something for free that they should have built themselves.


Miles Egan commented:

    > It's really too bad this relationship has deteriorated so far.


I both agree and disagree.

I agree in the sense that I have a certain amount of empathy for LM,
on a personal level.   It must be quite nice to be sufficiently
economically privileged that encroachment on the time you spend in
your San Francisco house with your family is the biggest problem you
face.   Who _wouldn't_ be protective of that?   I'm sure I'd feel as
strongly as he does, though I might have reacted differently in this
case.

I disagree in four ways:

First, I disagree because LM is flat out wrong in this case.  Check
the archives and look at the the message that sparked his action.  He
decided the message was horribly rude.  It was not.  It wasn't
sweeness and light.  It was critical.  But LM's response was
non-linear and now, it seems, non-linear replies are to be his policy
regarding bkcvs.

Second, I disagree because I think that deterioration of "this
relationship" is structurally inevitable.  It's the inevitable
consequence of relying on gratis access to a proprietary tool for the
development of an important piece of free software.  It's the inherent
contradiction of the situation coming home to roost. It's not "too
bad" it has deteriorated -- it's "unsurprising".  It's too bad that LM
and the community entered into this relationship in the first place.

Third, I disagree because I don't accept Larry's "spin" on this
action.   Note that he isn't talking about shutting down BK -- whe's
talking about shutting down the BK->CVS gateway of Linux kernel
sources.   Let's review what's happened:

        1) LM was starting up BitMover and had concluded that free
           software business models would not work for BitKeeper.

        2) He persuaded Linus to want to use BitKeeper and, in effect,
           to help design it.

           LM has insisted that he did this because he cares about the
           kernel and wants to help the project function better.  He
           has insisted that BK use by the kernel project provides
           little or no benefit to and imposes significant costs on
           BitMover.  

           I don't see how those statements can be credible: Linus
           helped design the system; use of BK by the kernel project
           is featured on the front page of the company web site, both
           in company news and as a demonstration of BK's purported
           performance and scalability; use of BK by the kernel leads
           to press attention to LM and BitMover; criticism of BK or
           BitMover is now a forbidden topic on the linux kernel
           mailing list, the widely observed communications hub of the
           community most impacted by BK's technical, political, and
           economic implications.


        3) After considerable complaints and flames from the community
           about the use of a non-free-software revision control
           system for the kernel and about the dangers having kernel
           history accessible only by a proprietary tool, LM and 
           BitMover built the bkcvs gateway.   All of the history 
           would be available via a free tool -- one of the grounds
           for complaint was removed.


        4) Some groups started working on cloning BK.  LM told them to
           give up.  He threatened to modify the network protocols in
           such a way as to make cloning impractical without examining
           BK in operation -- an action that LM asserted would be
           illegal and that he would take legal action against.

           Other free software hackers created experimental gateways
           from bkcvs to Subversion and arch.   While neither system
           is immediately ready to displace BK, both are credible 
           short-term threats.


        5) A short time later, in response to a bkcvs bug report
           about which LM's complaint is the subject line: "*sigh*
           something is wrong with bkcvs again", LM is now threatening
           to cut off the bkcvs gateway.   On the kernel developer
           list -- the same list on which complaints about BK are a
           forbidden topic -- LM blames the community for its rudeness 
           and insists it will be the communities fault if bkcvs is
           shut down.   

           In light of the history, and the motives to shut down bkcvs
           that that history gives rise to, I do not find LM's "it's
           your own fault for being rude" threat to be a credible
           explanation of the new policy.   To my ear, it sounds like
           a thin excuse to open the door to interfering with the 
           development of free software alternatives to BK without
           having to cop to the fact that that's what he's doing.




The fourth reason I disagree:

The privilege of being a patron to the kernel developer community does
not buy one the right to be tyranical.  "Tyranical patronage" is an
oxymoron.  Tyranny or patronage, LM, which is it going to be?  (And
don't the BitMover business model, BK software architecture, and BK
gratis license already determine the answer?)

The privilege of being a patron _should_ not buy one an asymmetric
immunity to criticism (even though it does, in this case).

I said that I had some empathy for LM.   My empathy would have been
honored if LM had replied to the "*sigh*" message this way:

        I just saw Aaron's email about problems with bkcvs.
        That's quite embarassing: I thought we had nailed
        that tool cold; I think it's likely this will turn 
        out to be a minor problem.

        I try to be very strict about keeping weekends for my family
        time and as off-duty time for the majority of BitMover
        employees (we keep a skeleton crew for support issues, but
        bkcvs is a special case, outside the scope of their jobs).
        I've chosen to stick to that principle in this case.  BitMover
        will make a high priority of fixing the problem beginning
        Monday morning.

        I realize that this is an inconvenience for those of you who
        use the bkcvs gateway for your kernel work.   To our
        credit, I think it's safe to say that for most users,
        a weekend without the gateway is not likely to prevent
        _that_ much work from getting done, at least if such 
        outages are rare.

        Please remember that, as our license states, gratis use of
        BK is available only under the condition that the costs it
        imposes on BitMover are sufficiently small.   We work hard 
        to make sure that BK remains useful within that constraint 
        because we'd like this relationship to continue to succeed
        and continue to benefit both the kernel developers and 
        BitMover.    Sometimes, as during this weekend, that requires
        some compromise.


And I really wouldn't expect it but he might have finished off with:


        Finally, as recent events on the east coast of the
        U.S. illustrate, any _one_ server used as the sole hub of a
        global development project creates a single point of failure.
        Even if our software were 100% bug-free, an outage such as
        this one is still a very real possibility.

        For that reason, the other high priority for BitMover on 
        Monday morning will be to begin reviewing our options for 
        making a more distributed revision control system.   It 
        might make sense to do away with the kerenel developer's
        dependency on bkbits.net and to provide better support for
        distributed operation and mirroring.

        We've been watching Tom Lord's arch revision control system
        over the years.   You may recall that in the past I've
        suggested that as a system for people who wanted to work on
        free software revision control to look into.   Among its 
        strengths is that it easily avoids the "single point of
        failure" trap.   Among its weaknesses are a lack of good
        graphical tools, a few (apparently quite soluble) performance 
        issues, and, from BitMover's perspective, it's distribution 
        under the GPL.

        I'm beginning to see the writing on the wall: whether it's
        Subversion, or arch, or PRCS, or meta-cvs, or any of a number
        of other systems, before _too_ long, the competition Bitkeeper
        faces from free software alternatives will be quite
        significant.   I think it's approaching the time when BitMover
        will have to reconsider its business model with an eye towards
        becoming a free software business.

-t