| |
Subscribe / Log in / New account

Linus on the BK withdrawal

[Posted April 6, 2005 by corbet]

From:  Linus Torvalds <torvalds-AT-osdl.org>
To:  Kernel Mailing List <linux-kernel-AT-vger.kernel.org>
Subject:  Kernel SCM saga..
Date:  Wed, 6 Apr 2005 08:42:08 -0700 (PDT)

Ok,
 as a number of people are already aware (and in some cases have been
aware over the last several weeks), we've been trying to work out a
conflict over BK usage over the last month or two (and it feels like
longer ;). That hasn't been working out, and as a result, the kernel team
is looking at alternatives.

[ And apparently this just hit slashdot too, so by now _everybody_ knows ]

It's not like my choice of BK has been entirely conflict-free ("No,
really? Do tell! Oh, you mean the gigabytes upon gigabytes of flames we
had?"), so in some sense this was inevitable, but I sure had hoped that it
would have happened only once there was a reasonable open-source
alternative. As it is, we'll have to scramble for a while.

Btw, don't blame BitMover, even if that's probably going to be a very
common reaction. Larry in particular really did try to make things work
out, but it got to the point where I decided that I don't want to be in
the position of trying to hold two pieces together that would need as much
glue as it seemed to require.

We've been using BK for three years, and in fact, the biggest problem
right now is that a number of people have gotten very very picky about
their tools after having used the best. Me included, but in fact the
people that got helped most by BitKeeper usage were often the people
_around_ me who had a much easier time merging with my tree and sending
their trees to me.

Of course, there's also probably a ton of people who just used BK as a
nicer (and much faster) "anonymous CVS" client. We'll get that sorted out,
but the immediate problem is that I'm spending most my time trying to see
what the best way to co-operate is.

NOTE! BitKeeper isn't going away per se. Right now, the only real thing
that has happened is that I've decided to not use BK mainly because I need
to figure out the alternatives, and rather than continuing "things as
normal", I decided to bite the bullet and just see what life without BK
looks like. So far it's a gray and bleak world ;)

So don't take this to mean anything more than it is. I'm going to be
effectively off-line for a week (think of it as a normal "Linus went on a
vacation" event) and I'm just asking that people who continue to maintain
BK trees at least try to also make sure that they can send me the result
as (individual) patches, since I'll eventually have to merge some other
way.

That "individual patches" is one of the keywords, btw. One thing that BK 
has been extremely good at, and that a lot of people have come to like 
even when they didn't use BK, is how we've been maintaining a much finer- 
granularity view of changes. That isn't going to go away. 

In fact, one impact BK ha shad is to very fundamentally make us (and me in
particular) change how we do things. That ranges from the fine-grained
changeset tracking to just how I ended up trusting submaintainers with
much bigger things, and not having to work on a patch-by-patch basis any
more. So the three years with BK are definitely not wasted: I'm convinced 
it caused us to do things in better ways, and one of the things I'm 
looking at is to make sure that those things continue to work.

So I just wanted to say that I'm personally very happy with BK, and with 
Larry. It didn't work out, but it sure as hell made a big difference to 
kernel development. And we'll work out the temporary problem of having to 
figure out a set of tools to allow us to continue to do the things that BK 
allowed us to do.

Let the flames begin.

		Linus

PS. Don't bother telling me about subversion. If you must, start reading
up on "monotone". That seems to be the most viable alternative, but don't
pester the developers so much that they don't get any work done. They are
already aware of my problems ;)

Linus on the BK withdrawal

Posted Apr 6, 2005 16:07 UTC (Wed) by gowen (guest, #23914) [Link] (29 responses)

Larry in particular really did try to make things work out
Right, except for dropping his insistence that he's allowed to dictate what other software projects BK users work on in their spare time.

Linus on the BK withdrawal

Posted Apr 6, 2005 16:25 UTC (Wed) by philips (guest, #937) [Link] (2 responses)

Flames, flames and flames.

Most imporatantly I haven't seen among anti-BK flamers for example Tom Lord - who is silently continues his work on GNU/Arch.

And other SCM developers too. They were silent. Most kernel developers were silent too. (Andrea Arcangeli's position is well known - but he is rather exception.)

So who was flaming them? Zealots, who had time to flame - but no capabilities to develop competitor?

Larry did his best. As always. I've seen most BK flames on LKML. Larry has more patience than me - that's for sure.

Linus on the BK withdrawal

Posted Apr 6, 2005 20:06 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

You should be more observant.

Ben Collins is both a kernel developer and a subversion developer, and has
been vocal on the bk issue.

Linus on the BK withdrawal

Posted Apr 7, 2005 9:08 UTC (Thu) by gvy (guest, #11981) [Link]

...and then svn doesn't fit anyways, although the main point for him might be prohibitive clause (don't follow lkml in any ways -- moctly KT -- for quite a time, may just err).

Yep, people who yell and people who implement usually are just different...

Linus on the BK withdrawal

Posted Apr 6, 2005 16:26 UTC (Wed) by pizza (subscriber, #46) [Link] (23 responses)

> Right, except for dropping his insistence that he's allowed to dictate what other software projects BK users work on in their spare time.

Note, that's not "BK users", that's "People using the BK client they didn't pay a dime for." You can't get something for nothing. If you coughed up $$ for a full licence of BK, there are no restrictions on what software you develop using it.

It's his (company's) software, so they can set whatever terms they want. If you don't like those terms, then don't use BK. Simple, mmmm? It's not like you have to use BK in order to participate in kernel development.

I love McVoy's general attitude -- "If you don't like it, develop something better." And you know what? Rather than whining about it, some people are. Thus we have subversion, arch, darcs, codeville, monotone, etc attempting to do just that.

Linus on the BK withdrawal

Posted Apr 6, 2005 16:40 UTC (Wed) by gowen (guest, #23914) [Link] (3 responses)

It's his (company's) software, so they can set whatever terms they want
No one's denying that. Larry is completely within his rights.

The comedic cognitive dissonance arises because the descriptions of his actions

  • "Larry did everything he could" (Linus)
  • "this is really an open source community problem" (Larry)
  • "we represent as open-source friendly a commercial organization as you are ever going to see" (Larry, again)
that are so patently at odds with the facts. (The suggestion that BitMover -- who have released almost no source to any of their products -- are the most open source friendly than Novell, say, is simply laughable).

Or, of course, when he does something insanely moronic, like suggest kernel developers should "Code Red" one of their members, like the Marine Corps.

Linus on the BK withdrawal

Posted Apr 7, 2005 9:16 UTC (Thu) by gvy (guest, #11981) [Link] (1 responses)

Gowen, please stop bragging this BS here.

They ARE (at least were) OS-friendly. They DIDN'T claim to compare with Novell TTBOMK. Whom are you arguing with, or just a troll?

Linus on the BK withdrawal

Posted Apr 7, 2005 13:22 UTC (Thu) by gowen (guest, #23914) [Link]

They DIDN'T claim to compare with Novell
They described themselves as "as open-source friendly a commercial organization as you are *ever* going to see."

Sorry kiddo, but that's a superlative, and that means they're comparing themself with everyone.

Linus on the BK withdrawal

Posted Apr 12, 2005 19:11 UTC (Tue) by zander76 (guest, #6889) [Link]

Hmm, Interesting point.

Well the fact is that they may or may not release there software opensource. They released a commercial product to a group of opensource developers for free. That does sound like an opensource frendly commercial company. They decided to help when there were no other alternatives (aside from cvs of course).

As far as Novel, perhaps you have not been reading but they have released a lot of tech from both Suse and Ximian that were originally closed source. So they are releasing. Perhaps not as quick as you would like but Novel was a completely closed company and Suse was open source yet suse ended up with closed source tech that was later released by Novel. So positions are changing.

Later

Linus on the BK withdrawal

Posted Apr 6, 2005 16:52 UTC (Wed) by jamesh (guest, #1159) [Link]

> If you coughed up $$ for a full licence of BK, there are no restrictions on what software you develop using it.

It is not quite that simple. There has been a documented occasion where BitMover has refused to let a company buy a BK commercial license on the basis of an employee's actions:

http://lwn.net/Articles/103727/

So there are cases where an individual or company can be left in a position where they couldn't use BK, even if they could afford a commercial license.

Come back to earth, please.

Posted Apr 6, 2005 16:53 UTC (Wed) by GreyWizard (guest, #1026) [Link] (10 responses)

Hello? McVoy stated in no uncertain terms that his main motivation for the license restriction was to make it more difficult for anyone to create a BitKeeper competitor. Do you really think he would tolerate reverse engineering from a paying customer? Think again. Even if he has explicitly said he would allow it (I've never read anything to that effect) that would just be spin until a paying customer actually contributed to a free software revision control system. Rest assured if that ever happens the fur will fly.

While I'm on the subject, why is it that when Bill Gates gives software away without charge and puts create terms in its EULA to control the behavior of people who agree there is an uproar but when Larry McVoy does the same people declare him some kind of unappreciated folk hero? Microsoft ought to hire this guy for their public relations department.

Actually, yes

Posted Apr 6, 2005 17:04 UTC (Wed) by bos (guest, #6154) [Link] (9 responses)

Larry has explicitly said, in public and in private, that paying customers are not prevented from working on open or closed source SCM tools. As a paying customer, I've seen and signed off on the commercial BK license, and there are no clauses to that effect in there.

Actually, yes

Posted Apr 6, 2005 17:48 UTC (Wed) by GreyWizard (guest, #1026) [Link]

Well, that's interesting. One of three things is necessarily true here: either you're full of beans (I have no reason to doubt you), McVoy's claims are merely opportunistic spin that would be retracted the moment he discovered a paying customer contributing to a competing system or McVoy is a moron. Placing restrictions on what people who download the free tool can do with it is, as has been clearly demonstrated and easily proven with McVoy's own words, a public relations problem. That has some cost, at least in emotional terms. But if you don't also constrain the paying customers it is also a pointless exercise.

Suppose I'm an evil developer with the skills to reverse engineer protocols who wants nothing more than to "steal" McVoy's precious intellectual property. All I have to do is buy a license. Suppose I don't have the cash. No problem! I'll just get a job with a company that has a BitKeeper site license. Of course, I could probably raise the money in hours if I solicited donations from the hordes of grumpy kernel hackers who flame about the BitKeeper license in the first place, but I'd probably have to use a psuedonym to throw off the sales people. Either way the restrictions in the no charge license are not a significant obstacle to me. All they do is create grief for McVoy.

I remain convinced of what I said in my original post: once this happens the fur will fly. McVoy is more rabid about protecting his secret sauce than just about anyone and while he might be a jerk he is anything but stupid. The claim that he would tolerate competition from paying customers while spending his time threatening legal action on the Linux kernel mailing list seems to me deeply disingenuous.

Actually, no

Posted Apr 7, 2005 16:42 UTC (Thu) by GreyWizard (guest, #1026) [Link] (7 responses)

http://lwn.net/Articles/103727/

BitMover has actually refused to sell someone a license because they suspected that a developer employed by the prospective customer would contribute to a free software source control system. Maybe paying customers are not prevented from working on source code management tools, but if so that is only because BitMover does a background check to decide whether someone is likely to do so before allowing them to become a paying customer in the first place. Do you really mean to suggest that McVoy would ignore the situation if he discovered a paying customer who had passed this screening process later decided to work on a competing project?

If not then my comments in the grandparent post are exactly correct.

Actually, no

Posted Apr 7, 2005 16:55 UTC (Thu) by bos (guest, #6154) [Link] (6 responses)

The guy in question (a) was obnoxious and (b) had said in advance that he wanted to clone BK, so of course they didn't sell him a license. People like that can be a major support burden, and often cost a lot more to deal with than one can make off licensing and support fees.

What occurs *after* someone buys a license is an entirely different thing, because there's then a well-defined legal agreement in place that puts specific obligations on both parties.

As to whether Larry would ignore it if he discovered that a paying customer was working on cloning BK, I'd expect that to depend on the circumstances (surprise, surprise). I do know that a number of companies have bought BK licenses, with Larry's foreknowledge and assent, explicitly so that their employees could continue to work on competing open source SCM tools.

Having it both ways?

Posted Apr 7, 2005 17:47 UTC (Thu) by GreyWizard (guest, #1026) [Link] (5 responses)

On the one hand, we have a clearly documented case where McVoy will refused to sell licenses to someone who declared, in advance, that he intended to work on a competing source control system (I'm not convinced that obnoxiousness and support costs were the reasons because McVoy himself emphasized the competitive issue exclusively in his first comment). On the other, you seem to claim that McVoy happily sold licenses to other companies who claimed, in advance, that some of their developers were currently working on competing source control systems -- all under license terms that place no restrictions on what those developers are able to do with BitKeeper.

Sorry, but this time I actually *do* think you're full of beans. Maybe you could name these companies and provide some sort of linkable evidence?

Having it both ways?

Posted Apr 7, 2005 18:11 UTC (Thu) by bos (guest, #6154) [Link] (4 responses)

Sure. Red Hat has some commercial BK licenses; this has been public knowledge for a while. My recollection is fuzzy, but I believe that David Miller refused to use BK without a commercial license because of the restrictions in the free license.

I also know that at least one much larger company has bought commercial BK licenses for somewhat similar reasons, but I'd rather not say who.

Are we discussing the same thing?

Posted Apr 7, 2005 20:50 UTC (Thu) by GreyWizard (guest, #1026) [Link] (3 responses)

Each of your examples is problematic. RedHat is not well known for their work on source control products. They do quite a lot of kernel development, and if they have a license it is probably intended to resolve cases like this one. That is hardly a reasonable example of competition. David Miller does not directly contribute to any project that competes with BitKeeper, so his purchase is irrelevant. Meanwhile, I'd rather not argue about this mysterious larger company you'd rather not name.

Are we even discussing the same thing? My point is that is that Larry McVoy is zealous about preventing anyone who contributes to a project he considers competitive from using BitKeeper. This is supported by his own statements, such as:

He does not say they don't get to use BK "unless they pay for it." Clearly he doesn't want them to use it at all. To the extent the paid license doesn't explicitly enforce this it's either an oversight or a lazy attempt at spin that would be immediately reversed if it ever became relevant. (I'm not sure exactly how this reversal would be implemented, but a simple license change would probably work because customers like you will eventually need updates, support or both. There may even be a clause allowing BitMover to alter the license unilaterally.) I find it unimaginable that McVoy would not take immediate action in response to competition from a customer.

Are we discussing the same thing?

Posted Apr 7, 2005 21:05 UTC (Thu) by bos (guest, #6154) [Link]

Sure, Red Hat isn't interested in SCM; they still use CVS to do most of their work, for example. The mysterious larger company actively works on SCM, but I doubt there's any overlap between their BK users and their SCM developers.

Certainly, Larry has been pretty vigorous about preventing naked competitors from using BK when he's had foreknowledge.

Are we discussing the same thing?

Posted Apr 12, 2005 19:20 UTC (Tue) by zander76 (guest, #6889) [Link] (1 responses)

Well, I don't know if I would say that RedHat is not a treat. RedHat is a commercial organization and if at anypoint they saw profit in SCM then they would be in there.

And your point is...?

Posted Apr 12, 2005 19:35 UTC (Tue) by GreyWizard (guest, #1026) [Link]

RedHat does not compete with BitMover today. That they could do so at some point in the future is irrelevant because the same can be said for any company that might consider purchasing BitKeeper. Refusing to sell on this basis would mean refusing to sell at all.

Linus on the BK withdrawal

Posted Apr 6, 2005 22:47 UTC (Wed) by kasperd (guest, #11842) [Link] (6 responses)

> It's his (company's) software, so they can set whatever terms they want.

This is not true. In many countries these terms are in conflict with the law. Had I downloaded the client in order to access the kernel sources, I would also have been allowed to reverse engineer it. It doesn't matter what the license says, because the law clearly says I cannot give up my right to reverse engineer software.

Linus on the BK withdrawal

Posted Apr 7, 2005 1:22 UTC (Thu) by hppnq (guest, #14462) [Link] (5 responses)

Actually, this whole reverse engineering debate is not at all about your right as a person to reverse engineer whatever software. (You don't really think that Larry and his legal counsil would have overseen this, do you?)

It's about how much information Larry has to release in order for other developers to use that in their own software. Which is an entirely different discussion and one you are not likely to win in court. Since Larry is not at all obliged to release *any* information.

Linus on the BK withdrawal

Posted Apr 7, 2005 2:02 UTC (Thu) by hppnq (guest, #14462) [Link]

s/overseen/missed, sorry, its' getting late here. Or early, rather. ;-)

Linus on the BK withdrawal

Posted Apr 7, 2005 6:43 UTC (Thu) by kasperd (guest, #11842) [Link] (3 responses)

I don't think their lawyers knows the law in every country. This license might very well comply with American law. But did they actually take a look on the law in every European country? I don't think they did.

You say they are not obliged to release any information about their protocol. While that might be true, releasing the information would change the reverse engineering situation. In the Danish law, the right to reverse engineer only applies if you don't have easy access to this information. By giving everybody access to format and protocol specifications, they could actually make the reverse engineering illegal.

What the law says in other countries I won't say much about, since I haven't read it. I have read on the internet, that multiple European countries have laws similar to the Danish on this area, but American law is different.

Linus on the BK withdrawal

Posted Apr 7, 2005 8:33 UTC (Thu) by hppnq (guest, #14462) [Link] (2 responses)

At least they have most likely thought about it quite a bit harder than most of us here. IANALOT either, I just want to point out that it seems to me that this particular aspect of the debate doesn't get a lot of airplay.

Your example of the Danish law would be perfectly aligned with what Larry has been saying quite consistently: he won't do anything to actively help anyone reverse engineer the inner magic of BitKeeper. (Note, by the way, the contradictio in terminis that is hidden in here. It's not all wordplay, it reflects the absurdity of the demands that some people think they can lay on Larry.)

Linus on the BK withdrawal

Posted Apr 7, 2005 20:31 UTC (Thu) by kasperd (guest, #11842) [Link] (1 responses)

> he won't do anything to actively help anyone reverse engineer the inner magic of BitKeeper.

What is this inner magic of which he talks? Good heuristics to merge branches and avoid conflicts? I don't think there is much magic in software. Good heuristics is what looks most like magic to me.

Reverse engineering the formats and protocols isn't necesarilly the same as reverse engineering the heuristics. But of course when you do reverse engineering it may not be possible to reverse engineer exactly the right corner of the code, and you may end find out a lot more than what you really needed.

Had formats and protocols been published the reverse engineering rights had no longer applied. And maybe that way BitMover could have forbidden me to reverse engineer the code.

So in some sense publishing more information could have made it harder to (legally) reverse engineer the inner magic of BitKeeper.

Linus on the BK withdrawal

Posted Apr 7, 2005 22:06 UTC (Thu) by hppnq (guest, #14462) [Link]

I can't really follow you here, I'm afraid. Maybe it's because I'm much too lazy to reverse engineer a program, I'd much rather spend my time trying to reverse engineer the programmer who wrote the program, for instance, and start from there (not that I am particularly good at it ;-). Or is that what you call "reverse engineering heuristics"?

You seem to suggest that it can't be that hard to write a non-trivial piece of software. I'm quite sure any kernel hacker would agree with me that, looking at random bits and pieces of an OS kernel, none would look too complicated. The general operation of an OS kernel is no rocket science either. Getting everything right all the time, however, that's much more like black magic. (Funnily enough, in physics the exact same problem is related to "degrees of freedom". The similarity doesn't end there, but I won't bore you with that. ;-)

(The term "inner magic", by the way, is not Larry's, as far as I know, if that is of some importance to you.)

Linus on the BK withdrawal

Posted Apr 7, 2005 14:23 UTC (Thu) by harcho (guest, #29107) [Link] (1 responses)

Personally I also wouldn't be all too suprised to find that a certain company in Redmond has quietly passed something under the table to our man of the moment Larry to persuade him that it is not in his best interest to continue supporting a free BK for the Linux Kernel.

What better way to chop the legs out of Linux Development than to target the tools used to support that development. It makes simple sense to me and it explains better why using closed source tools to support Great Open Source Software will always be a dangerous exercise.

It always leaves you open to Subversion without you even knowing that it is happening.

All in all a useful learning experience I would say and one I certainly hope people are paying attention to.

Linus on the BK withdrawal

Posted Apr 7, 2005 22:18 UTC (Thu) by hppnq (guest, #14462) [Link]

Nice one. ;-)

Without any evidence it seems a bit too far fetched for me, at least in this case, but it is not unimaginable...

Linus on the BK withdrawal

Posted Apr 6, 2005 16:10 UTC (Wed) by mvirkkil (guest, #28737) [Link] (4 responses)

Hmmm.. I wonder what he thinks about tla and baz. Any info on what makes monotone so special?

We looked at Monotone last year

Posted Apr 6, 2005 22:13 UTC (Wed) by emk (subscriber, #1128) [Link] (3 responses)

Monotone has an clever, completely decentralized repository model. This makes it easier to handle large numbers of branches and forks. Plus, Monotone scales relatively well, which isn't always true of products like GNU Arch.

(Subversion scales quite well, except for the networking protocol, which is substantially inferior to CVS for initial checkouts and exports. Fortunately, Subversion doesn't do much networking for updates or commits, so it scales well for common operations.)

Monotone is also written in an usually clean C++ style, which makes it easy to improve.

I evaluated many open source version control tools last year, and I was impressed by Monotone. It's not quite ready for prime time, but it's getting there.

We looked at Monotone last year, darcs?

Posted Apr 7, 2005 9:22 UTC (Thu) by gvy (guest, #11981) [Link] (2 responses)

Hmm... how would you characterize darcs for that matter, if you've looked at that too?

try darcs -- it only takes a minute

Posted Apr 7, 2005 10:22 UTC (Thu) by zooko (guest, #2589) [Link]

I use darcs a lot.

It isn't ready for the kernel, but for smaller projects (in terms of number of files, number of patches per day, number of contributors, etc.) it is excellent.

The great thing about darcs is that it takes only a few minutes to try it. Arch/tla is hard to get started with -- I've never managed to get started with arch/tla despite trying a couple of times. But darcs is very easy. In the time it takes you to finish reading this mongo thread on LWN, you could get started with darcs and form your own opinions of it.

http://darcs.net/

Regards,

Zooko

How test VC scalability

Posted Apr 7, 2005 12:42 UTC (Thu) by emk (subscriber, #1128) [Link]

Darcs looked cool, but if I recall correctly, it didn't seem sufficiently scalable at the time. But then again, our project at work is huge.

The Monotone developers have a great stress test, which I strongly recommend to other VC developers: the GCC CVS tree. It contains 20,000 files, 90,000 tree versions, and some completely insane number of branches. If you can import this tree, store it in a reasonable amount of disk space, and carry out day-to-day operations in a remotely efficient fashion, you're golden.

There's been this really great renaissance in open source version control lately, and I'm looking forward to future developments.

Linus on the BK withdrawal

Posted Apr 6, 2005 16:10 UTC (Wed) by mcelrath (guest, #8094) [Link] (31 responses)

This seems an incredibly stupid move on Larry McVoy's part. It ensures that a free, interoperable alternative will appear in short order. Larry's justification seems to be that that is what he was trying to prevent.

Had he left the OSDL contractor alone, a free alternative may still have appeared, but its development would have been much slower, and the motivation to use it would be slim.

-- Bob

Linus on the BK withdrawal

Posted Apr 6, 2005 16:26 UTC (Wed) by dame74 (guest, #29082) [Link] (2 responses)

A solution is simple: as for Blender foundation, OSDL could buy Bitmover's products and convert their licences in GPL. Done! OSDL has cent enough to do that? ..so DO!

Linus on the BK withdrawal

Posted Apr 6, 2005 18:57 UTC (Wed) by bryce (guest, #16388) [Link]

Well, in that case, the lead Blender developer came with the code. Raw
source code without people having the domain-knowledge would be of
limited use.

Linus on the BK withdrawal

Posted Apr 6, 2005 19:04 UTC (Wed) by elanthis (guest, #6227) [Link]

You flunked economics, didn't you? ;-)

Seriously, is BK worth that much to OSDL? Buying BK would cost a good deal of money, I imagine, and that has to have a solid return on investment for OSDL, otherwise it would be absolutely moronic to spend the money on it. What is BK worth to OSDL, exactly? If Linus and crew are able to find another SCM that works well enough, then the worth of BK to OSDL would be near $0. If OSDL buys BK, open sources it, and loses the possibility to generate revenue by selling expensive licenses to big customers - BK's prime income method, I believe - then the worth of BK likewise drops compared to the worth of BK as a revenue generator like it is for BitMover. OSDL needs a solid financial reason to want BK and a solid plan on how to cash in on the investment. Simply going and buying a very expensive piece of software because Linus is too picky to use a "almost good enough" alternative would be a poor decision, and if the people in charge of OSDL were the kind to make such decisions, OSDL would be long gone and all its assets would either be unmaintained or sold back to proprietary development houses.

This is a textbook case for a business school

Posted Apr 6, 2005 17:16 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (13 responses)

Larry's been executing a brilliant marketing strategy all along. Marketing people at startups everywhere should be taking notes.

Larry saw a business opportunity: the version control systems in common use all sucked to one degree or another. But developing a good one would require lots of resources, and open source work wasn't putting bread on his table. And he clearly had the entrepreneurial itch and wanted to start a company. But how to get into a business where the competition is of the size of IBM (ClearCase)? How would anyone ever even hear of his company? And how would he manage to get the product to the rock-solid level required if anyone is going to trust their precious source code to it?

The answer, of course, was working with Linus and the kernel developers. Give them a free-beer license in exchange for serving as dedicated beta testers, and get huge amounts of publicity, so that techs the world over would soon know what BitKeeper is. Get none other than Linus Torvalds to give you publishable quotes. You can't buy that kind of publicity. Once you get to the level you want to get to, drop the free-as-in-beer version, and give people a read-only client so they don't lose access to their own data. Voila, you've bootstrapped a successful company from nothing. I admire Larry for pulling it off. The only thing I don't care for is the notion that there was ever any kind of charity involved; this was always strictly a business proposition.

I don't believe that Larry was ever so naive as to think that the people who cloned Unix and the Windows GUI wouldn't try to clone BitKeeper, so I don't take the claims that the withdrawal of the free BitKeeper has something to do with cloning efforts seriously. After all, withdrawing the free version would only speed up, not slow down, the cloners (unless they lose interest because Linus stops using BitKeeper at the same time, perhaps?). The imperatives of business required that the free version be withdrawn sometime, the only question was the timing.

This is a textbook case for a business school

Posted Apr 6, 2005 17:42 UTC (Wed) by bos (guest, #6154) [Link] (11 responses)

It was definitely a smart business move for Larry to help Linus out, no doubt about it, and he'll acknowledge as much to anyone. The rest of what you say is nonsense, though.

Larry really did bend over backwards, and for a *long* time, to accommodate people who didn't want to use the free BK due to its licensing restrictions, and who were mostly extremely rude about their demands. He did this long past the point where any reasonable person could call his motivations into question.

This is a textbook case for a business school

Posted Apr 6, 2005 17:49 UTC (Wed) by mcelrath (guest, #8094) [Link] (10 responses)

I think JoeBuck and hppnq are spot on. How does Larry bending over backward change that this was all a marketing strategy? Even if totally unintentional (which I doubt), it's still a great case for marketing study.

After making my original post, I read a bit more, and it seems Larry often encourages the development of a free alternative. Perhaps this way he could pull bitkeeper support from linux in a way that didn't alienate linux users. After 3 years, there is still no comparable alternative, and perhaps his company didn't intend to wait this long to end their marketing ploy. Thus, they had to find a way/excuse to pull the plug.

-- Bob

This is a textbook case for a business school

Posted Apr 6, 2005 23:09 UTC (Wed) by darthmdh (guest, #8032) [Link] (6 responses)

Easy. BitKeeper existed long before it was adopted by Linus. Linus adopted it because it was technically superior (and still is technically superior) to anything else that existed, and it was gaining popularity because of that (in a time when CVS was pretty much unmaintained, was failing security audits and wasn't up to the task of modern software development, and anything else in a usable state was proprietary)

All the crap about licences and so forth only started because certain so-called open source developers, who were more like information superhighway robbers, wanted to steal Larry's technically superior product.

And now, thanks to these thieves, we now no longer have a free BK tool. First we lost the source code (yes, BitKeeper used to be distributed with the entire source code back in the day). Now we've even lost the binaries. When we've lost twice, how can anyone claim we're winners?

There's no marketing ploys here, no malice, no excuses. Bitmover were getting constantly screwed by the community they loved and stuck around much longer than any other business would have. Thanks Larry & team, you have done gallantly and I wish you success for the future.

This is a textbook case for a business school

Posted Apr 7, 2005 0:22 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

actually the real story is that bitkeeper was developed FOR Linus to use. that's what shifted Larry from his current projects to full-time work on SCM's.

as part of the process Larry had to figure out how he would pay for the development costs and developed the bitkeeper options we all know about.

I want to add my thanks to Larry. he did a lot of good in the process and I hope that kernel development doesn't suffer too much before something new gets good enough to use.

This is a textbook case for a business school

Posted Apr 7, 2005 1:21 UTC (Thu) by darthmdh (guest, #8032) [Link] (3 responses)

No, it was developed because Larry had a passion for SCM tools, and a heck of a lot of experience in writing them, and wanted to contribute a decent one to the community and hopefully get rich on the side ;)

It was not developed specifically for Linus. When Linus adopted it for the kernel, it already had a rapidly expanding userbase. Bitmover promised and delivered free support to him, no doubt knowing full well that the Linux kernel is the dream test case for any distributed SCM development - an arseload of developers and others spread all over the planet and an extremely active tree with many branches. That being proactive in supporting Linus here would improve BitKeeper is a given.

Bitmover also had at that time (and I assume still do) many commerical clients paying for support - they didn't have to give Linus any help whatsoever - but what software engineer in their right mind is going to forsake the dream test case for their pet project? Especially one mutually beneficial?

I can't recall any options of note being added since the adoption by Linus, just a lot of polishing in the backend (eg improving the protocol to make updates much faster). But maybe my own use of SCM functionality isn't deep enough to notice everything so I'll believe you.

Bitmover already used revenue from support contracts and custom consulting to pay for development costs (like most software houses) and I assume this will go on regardless.

I know I've been somewhat negative in a few posts on the various articles in LWN on this topic today, I guess the bright side to the story is that BitKeeper is still around, still the best, there's a very good incentive for Open Source SCM alternatives to get their acts together (adoption by Linus Torvalds and possibly hundreds of thousands of others), and the usual anti-BK trolls now have to crawl back under their bridges and find something else to whine about meaning we won't see them for a while hopefully. I especially like the new kick in the pants for SCM developers which will hopefully benefit the open source community, and the opportunity to look at eg Monotone and Bazaar, neither of which I'd heard of until now. What can I say, I like new toys :)

This is a textbook case for a business school

Posted Apr 7, 2005 1:37 UTC (Thu) by hppnq (guest, #14462) [Link] (2 responses)

Nobody claims BitKeeper was written especially for Linus, so I don't really see your point.

I agree with the kick though. ;-)

This is a textbook case for a business school

Posted Apr 7, 2005 2:26 UTC (Thu) by darthmdh (guest, #8032) [Link] (1 responses)

Nobody claims BitKeeper was written especially for Linus, so I don't really see your point.

dlang wrote in the comment I replied to, in fact, opened it with "actually the real story is that bitkeeper was developed FOR Linus to use. that's what shifted Larry from his current projects to full-time work on SCM's."

I was addressing this mis-truth (apologies for not quoting it originally)

This is a textbook case for a business school

Posted Apr 7, 2005 9:04 UTC (Thu) by hppnq (guest, #14462) [Link]

See your original post, to which dlang responded... There are many accounts of how BitKeeper was developed and adjusted to Linus' needs (google for "Larry McVoy Linus Torvalds Dave Miller").

This is a textbook case for a business school

Posted Apr 7, 2005 6:41 UTC (Thu) by irios (guest, #19838) [Link]

> And now, thanks to these thieves, we now no longer have a free BK tool.

What exactly makes these people thieves that makes the Samba or NTFS teams heroes? After all they are all reverse-engineering proprietary protocols for their perceived benefit of the free software community.

Are we all thieves, in your eyes? You too?

This is a textbook case for a business school

Posted Apr 7, 2005 20:20 UTC (Thu) by kasperd (guest, #11842) [Link] (2 responses)

> Larry often encourages the development of a free alternative.

If he really wanted to encourage the development of a free alternative, he should have removed those restrictions about using BitKeeper and working on a competing product. Not that they were ever as legally binding as Larry McVoy thought.

How were people supposed to write a competing product without trying out BitKeeper to find out what they were competing against. Don't you think BitMover tried the alternatives as well so they knew what they were competing against?

Is there really any business (software or not) where developers don't take a look on competing products to know what they are up against?

This is a textbook case for a business school

Posted Apr 8, 2005 2:37 UTC (Fri) by darthmdh (guest, #8032) [Link] (1 responses)

There's a difference between developing a competing product, and producing a clone of an existing one.

The first has a future and is beneficial to society. The second is just pointless Xeroxing. What Larry was trying to prevent was the second, and he has every right to do so.

Cloning is stupid. How does the adage go; "those who do not learn from the past are doomed to reimplement it... poorly". If you're simply cloning something else you will always be at least one step behind, usually more. Take a look at all the OSS projects that attempt to imitate Microsoft Windows. They came close to getting Win95 and then Microsoft come out with the re-designed XP. They might come close to getting XP, but then Microsoft will come out with Longhorn. If you're constantly chasing someone else's coattails, you will always be behind them. Less than them. Worse than them. Also, all you achieve is to confuse and distract people, maybe divert funds from those actually creating/innovating (those being cloned) to the undeserved (the cheap knockoffs), create division and fanatical polarisation causing harm, not good.

Competition is meant to encourage innovation. Doing something new. And by something new, its not just change some keywords and remove some functionality (like Java/C# over C++). It's more like Lisp versus C (bad choice in examples, but I hope my point is clear). Solve problems that either haven't been solved before, or solve them in an unarguably better fashion, or at least different enough that there's some kind of mass appeal (functional versus procedural versus object-oriented versus ...). Raise the bar.

Notice how Microsoft never went after projects duplicating their UI efforts - because a) it shows flattery towards their UI (ie, there's good stuff there people want to copy) and b) they remain the ones out in front. But they did go after projects that did things better (such as Samba, which not only fixed bugs in the SMB protocol but ran on hardware existing in peoples networks that Windows could not run on, meaning people could stick with what they knew and loved - Microsoft's competitors (UNIX vendors) - not needing to not only purchase Windows licenses but even equipment Windows was capable of running on, dissolving future migration paths to their cruddier OS).

This is a textbook case for a business school

Posted Apr 10, 2005 10:56 UTC (Sun) by peet (guest, #29170) [Link]

Cloning is not always stupid. The classic example is when you have an unmaintained product (possibly, but not necessarily, closed-source). OpenCVS is just one example, but there are many. You might be reaching a bit to describe OpenOffice.org as a clone of Microsoft Office, but you wouldn't be reaching too far.

Even if the being-cloned product is actively maintained, cloning is not necessarily stupid. If it's unmaintained - and especially if it's closed-source - cloning can be an extremely useful thing to do.

This is tridge :)

Posted Apr 7, 2005 9:29 UTC (Thu) by gvy (guest, #11981) [Link]

It's not about "Windows GUI" -- it's about Samba and Andrew Tridgell.

http://kerneltrap.org/node/4966

Linus on the BK withdrawal

Posted Apr 6, 2005 17:27 UTC (Wed) by hppnq (guest, #14462) [Link] (13 responses)

I think you underestimate Larry's technical competence, as well as his insight in all things Open Source. People have been hacking for years on suboptimal Open Source SCM software. The only thing that Larry has been trying to prevent (and he has publicly stated so on numerous occasions, also here at LWN) is that people use *his* software to further their own efforts, through reverse engineering. I think he deserves better than our unfounded criticism.

That, of course, doesn't mean that all the blame lies with the Open Source community per se. The BitMover press release provides enough clues to suspect the company of a huge publicity scam at the expense of Open Source in general and the Linux kernel in particular. In fact, the whole press release seems to have no other goal than exactly that.

Linus on the BK withdrawal

Posted Apr 6, 2005 19:13 UTC (Wed) by iabervon (subscriber, #722) [Link] (3 responses)

I think convincing Linus to start using an SCM and then allowing a situation to occur in which Linus feels compelled to stop using BitKeeper is likely to throw a lot more support behind an open-source replacement. I wouldn't be surprised if Linus himself makes Monotone (or a new system of his own) do everything that he needed BitKeeper to do, much like he did with sparse. If Larry had left things at some previous state, an open-source SCM just wouldn't be nearly as interesting to work on.

Linus on the BK withdrawal

Posted Apr 6, 2005 19:47 UTC (Wed) by hppnq (guest, #14462) [Link] (2 responses)

And still BitMover is on the map as a technology leader. (Who isn't, eh? ;-) The fact that there might be an Open Source alternative for BitKeeper in the near future -- which is a quite optimistic view -- doesn't change anything about that.

Joe's interpretation of how things went is the only one I've read so far that explains most of the *facts* without adding too much haphazard guesswork. Still, I think there is room for a bit more nuance: I do think that Larry has been genuinely wanting to help Linus out all along. Just not, literally, at all costs. Combine that with the fact that of course BitMover != Larry.

(Hey, we could always ask him, no? ;-)

Anyway, I am not even really interested in this whole affair. I do care about how we're going to continue from here. And I'm quite afraid that Linus won't be that motivated to start writing SCM software himself -- sparse is an entirely different beast. But who knows.

Linus on the BK withdrawal

Posted Apr 6, 2005 20:14 UTC (Wed) by iabervon (subscriber, #722) [Link] (1 responses)

I do think that Larry honestly wanted to solve the SCM problem, and honestly wanted to have a viable strategy for funding the research, which wasn't really getting done (or not getting done sufficiently effectively). And he honestly wanted to help Linus and Linux development, and it seems like he has done that. And I think he doesn't want BitMover to go out of business and put the people who have done a lot of great work on the problem out of work.

I just think that he's making some strategic errors on the business side in how he's going about it. I think he could probably get better PR results out of the whole thing, more money to work on it, and be more beneficial to the community if the licensing was simply such that it didn't generate so much flaming and wasn't chasing off Linus.

I wouldn't count Linus out on doing the SCM himself; sparse was completely different from anything else he'd done when he did it, too.

Linus on the BK withdrawal

Posted Apr 6, 2005 20:57 UTC (Wed) by hppnq (guest, #14462) [Link]

Well, I think the comment Linus made at the end of his post to LKML is significant: the monotone developers are aware of his problems.

(I do share your observation up to some point, but again, "Larry" is not "BitMover", and apparently there are technical "issues" that would prevent Linus to keep using BitKeeper as well, so at least from one point of view this is not solely a question of "business strategy".)

Linus on the BK withdrawal

Posted Apr 6, 2005 19:43 UTC (Wed) by ballombe (subscriber, #9523) [Link] (8 responses)

>The only thing that Larry has been trying to prevent is (...) that people use *his* software to further their own efforts, through reverse engineering. I think he deserves better than our unfounded criticism.

Forbidding reverse-engineering and refusing commercial licenses to people based on their opinions is morally corrupt as far as I am concerned, and illegal in a lot of juridictions anyway.

Linus on the BK withdrawal

Posted Apr 6, 2005 20:15 UTC (Wed) by hppnq (guest, #14462) [Link]

I don't think you understood what I meant to say: it's not that Larry doesn't deserve *any* criticism, just *unfounded* criticism. He's anything but stupid.

Let's try to refrain from useless moralism and stick to the facts. There are many people who *try* every trick in the book, whether it's legally or morally just or not. It's obvious that Larry has tried very hard to prevent other people using his software for their own purposes. It's not up to me to deliver the verdict on whether this is right in whatever respect, IANAJ, IANAP. I would have liked things to develop in another way, but that is an entirely different matter.

(You might find this an odd statement, but because I care quite passionately about freedom, I try to keep things *realistic* instead of academic. If you can only see black and white you're missing out on all the colours that make up the spectrum that is real life.)

Linus on the BK withdrawal

Posted Apr 7, 2005 6:57 UTC (Thu) by jarto (guest, #3268) [Link] (6 responses)

> Forbidding reverse-engineering and refusing commercial licenses to people based on their opinions is morally corrupt as far as I am concerned, and illegal in a lot of juridictions anyway.

Morally corrupt? Excuse me but how's the weather in the world you live in?

I understand Larry's point very well. Why should he help anyone in creating a competing product or reverse-engineering his?

Linus on the BK withdrawal

Posted Apr 7, 2005 8:17 UTC (Thu) by gowen (guest, #23914) [Link] (5 responses)

Why should he help anyone in creating a competing product or reverse-engineering his?
No-one's suggesting he should help. But once he's made his opinion clear that he's not going to help, and that he'll be as obstructive as possible (no licenses sold to people working on SCM), he should stop pretending to be the good guy.

JFYI: "gowno" is "shit" in Russian

Posted Apr 7, 2005 9:41 UTC (Thu) by gvy (guest, #11981) [Link] (1 responses)

> But once he's made his opinion clear that he's not going to help

Quote/link, please. Or STFU :-/

title removed because gvy is a silly child, who'd be better of at /.

Posted Apr 7, 2005 13:11 UTC (Thu) by gowen (guest, #23914) [Link]

Erm. OK. You want evidence that Larry won't help clone BK. He's only said it a million times, and written at least 3 license clauses precisely to that effect. How about this one :
"It's pretty clear what you want to do and you keep asking for us to help you and the answer now, and forever, is no, we aren't going to help you create a copy of our product."
-- Larry McVoy on lkml, 11 Feb '05
As to "gowno" -- grow the hell up. It's not even the same letters as my log in.

Linus on the BK withdrawal

Posted Apr 7, 2005 14:29 UTC (Thu) by jarto (guest, #3268) [Link] (2 responses)

No-one's suggesting he should help. But once he's made his opinion clear that he's not going to help, and that he'll be as obstructive as possible (no licenses sold to people working on SCM), he should stop pretending to be the good guy.

You're suggesting that the only way someone can be a good guy is by letting themselves be a**fu*ked. Look at it from his point of view:

1. You spend a lot of resources to create an excellent piece of software.
2. You let Open Source people use it for free to create Open Source software. Especially the Linux kernel.
3. Some people in the OS community want to reverse engineer it and create a competing free version.
4. You try to solve the problem with the license.
5. You notice that someone working for OSDL is doing reverse engineering.
6. You ask OSDL to stop it.
7. OSDL doesn't want to or can't stop the person.

Should you let those people you've helped for free walk all over you and jeopardize the future of your company?

Linus on the BK withdrawal

Posted Apr 7, 2005 15:54 UTC (Thu) by GreyWizard (guest, #1026) [Link] (1 responses)

Should you let those people you've helped for free walk all over you and jeopardize the future of your company?

No, you should not. You should do exactly what Larry has done. He has every right to change his business strategy in response to perceived threats. However, he should not be claiming that his company is the most open source friendly that anyone is ever going to see. That claim is absurd. Furthermore, he should not suggest that the open source communty has failed and must strive to be more like the marine corps. This merely demonstrates that he doesn't understand the principles that this community stands for in the first place.

Personally I'm quite pleased that McVoy will be withdrawing the free client. As long as BitKeeper was free enough for Torvalds there was little actual need for a free software replacement. Once the kernel development team adopts Monotone or whatever they eventually choose that project will get an enormous amount of feedback and attention from smart people. I'm sure that after a few years of this the result will be as good or better than BitKeeper for free software development. Since McVoy will be now be focusing on proprietary software developers everybody wins.

Linus on the BK withdrawal

Posted Apr 8, 2005 10:52 UTC (Fri) by gowen (guest, #23914) [Link]

Yes, exactly what GreyWizard said

Linus on the BK withdrawal

Posted Apr 6, 2005 17:38 UTC (Wed) by hppnq (guest, #14462) [Link] (2 responses)

I guess KDE won't be switching to BitKeeper after all then? I took a quick look at kde.org but couldn't find anything.

KDE's April Fool

Posted Apr 6, 2005 18:04 UTC (Wed) by dmarti (subscriber, #11625) [Link] (1 responses)

Look again at project announcements dated 1 April. (Some people didn't believe GMail was real because it came out on that day.)

KDE's April Fool

Posted Apr 6, 2005 18:11 UTC (Wed) by hppnq (guest, #14462) [Link]

Cheers!

(Heh, I *do* have a gmail account. ;-)

RMS on the BK withdrawal

Posted Apr 6, 2005 18:17 UTC (Wed) by tjc (guest, #137) [Link] (1 responses)

We've heard from Linus. I'm waiting for RMS' forthcoming response condemning this as unethical.

RMS on the BK withdrawal

Posted Apr 6, 2005 18:49 UTC (Wed) by rknop (guest, #66) [Link]

RMS is more likely just to say "I told you so".

-Rob

Linus on the BK withdrawal

Posted Apr 6, 2005 19:18 UTC (Wed) by sbergman27 (guest, #10767) [Link] (6 responses)

There is one thing that I have never understood about Larry McVoy's position. Perhaps it would be more accurate to say "Larry McVoy's positions (plural)".

One position seems to be that if you are using the free version of BK, and are also, at the same time, working on another source code control project, we will take whatever action is necessary to stop you, even if you are just a dinky little open source project.

The other position seems to be that Bitkeeper is so many orders of magnitude beyond anything else out there, and even more orders of magnitude beyond anything that some dinky little open source project could ever create, that we're not even concerned.

Which is it?

Larry?

Linus on the BK withdrawal

Posted Apr 6, 2005 20:20 UTC (Wed) by vmole (guest, #111) [Link] (5 responses)

IANLMcV, but as I understand it, his position is both: "It's hard to figure out how to do these things, and I think the only way you folks are going to be able to catch up is by analyzing BK, and I'm not going to let you do that."

So far, he seems to be right.

Actually, Monotone is *sweet*

Posted Apr 6, 2005 21:48 UTC (Wed) by emk (subscriber, #1128) [Link] (4 responses)

I'm not convinced that SCM is as hard a problem as Larry claims. BitKeeper is very well designed, but there's some great R&D work in the open source community. In particular, I'm quite fond of Monotone, which has an exceedingly clean model for distributed repositories.

I think the big problem with SCM is simply that everybody's been using the wrong models...

Seriously... version control is hard

Posted Apr 7, 2005 0:46 UTC (Thu) by gstein (guest, #3612) [Link] (3 responses)

Larry is right. Version control is hard. Believe me, I was part of the team that built Subversion. It took us four years to get to 1.0. It was useful long before then. But polishing the edges and making dead sure that you would never lose a single piece of data... that takes a long time.

We were self-hosting in 1.5 years. The next 2.5 years were the fit and finish.

Go ahead and try to build a version control system. To some extent, yes: it isn't all that hard. You'll have the basics done in a month. We are all so familiar with the functionality of the system that we understand the needed functionality very well. But reducing that to practice is really, really frickin' difficult. Have you considered a delta algorithm? network protocol? working copy metadata? merge system? storage system? authentication, encryption, authorization? The list goes on and on.

I've said it before at CodeCon 2003: Larry's right. Version control is hard. I'm sad to see what's happening [to the kernel] right now, and I don't think Larry's been acting all that nicely towards OSDL, but I will agree with him on this topic.

Hard, but apparently not impossible :-)

Posted Apr 7, 2005 12:55 UTC (Thu) by emk (subscriber, #1128) [Link] (2 responses)

I'm truly impressed by the work you've done on Subversion, and I know that any kind of serious storage software requires a scrupulous attention to detail.

In a previous life, I hacked on compilers. Sure, they're hard--especially good ones--but I'd never doubt the ability of Cygnus or Ximian (and their many volunteer hackers) to write a world-class compiler.

Maybe I'm being unfair to McVoy, but it always seemed that he considered version control software to be somehow unique: harder than compilers, harder than kernels, harder than X11--harder than all these terrifyingly complex projects which the open source community does so well.

Certainly, building a good version control system takes years, and requires many skilled programmers. But the open source community can presumably do that, and do it well, without reverse-engineering BitKeeper.

Hard, but apparently not impossible :-)

Posted Apr 7, 2005 13:41 UTC (Thu) by hppnq (guest, #14462) [Link]

It's an interesting question: how does one (the Open Source community in general) enforce the creation of a technically superior piece of software? I'd say the distinction between something that "just works" and something that is extremely well engineered (and therefore much more succesful than its peers) is largely attributable to factors that cannot really be controlled: brilliance being the most obvious one.

Compare this to the way we ended up with the theory of special relativity. The problem solved by this theory had been known for decades before one spark of genius solved it in a revolutionary way of thinking. In retrospect it is hard to imagine that several Nobel prize winners spent so much time on theories that high school students now would find offensively naive. However, there's no guarantee that we would view the world in the way we do now if Einstein hadn't been around.

(Actually, the current state of physics demands that someone like Einstein step up to the plate..)

I'm sure dwheeler has much more to say about this. ;-)

Hard, but apparently not impossible :-)

Posted Apr 7, 2005 23:08 UTC (Thu) by lm (guest, #6402) [Link]

Perhaps it's because I've done significant work on kernels, X11, and written the better part of two different SCM systems. Oh, and compilers long ago. But not optimizers which may be where the really hard compier work lies. Working on BK is harder than any of those including multi-threading kernels.

It's certainly harder than all the things you listed in _my_ experience. And history has shown it not to be easy for anyone else either. Greg Stein's post nailed it: it's easy to get something that looks like it works, it's a lot harder to get something that always works.

We've counted more than 10,000 replicas of the Linux kernel in BK. More than 150,000 changesets over the 2.4/2.5/2.6 series. Making that work, where all of them synchronize with each other, using versions of BK that differ by years without having it all fall apart, yes, that's hard.

I'm sure one of the many open scm systems will get there some day but it's going to take a while and it's going to be no fun when they issue a new release that breaks your old repos, etc. Or they aren't around to answer the phone when it gets corrupted, etc.

I'm not saying you can't do it, you can. It's just hard. And not much fun once the thrill of having people use your code wears off and you have to stick around and support them. Please don't take this as looking for strokes or whatever else it is that I'll be accused of next, it's simply a statement that it is really hard and if you want a good answer it is going to take a lot of people a lot of time to get there. I don't care how good they are, I think I'm very good at this and I've done it twice already and it would take me years if I had to start over with everything I know now. It's hard, there are a zillion corner cases. None of which are very important in isolation but all of them added up are somewhat overwhelming.

You'll see. Whoever emerges as the person doing this work for you deserves a lot of your support. Please give it to him or her.

--lm

Linus on the BK withdrawal

Posted Apr 6, 2005 19:57 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

The issues are:

1) SCM is hard. Too few people can get a handle on the many person problem and get it even 1/3 way right.
2) Zealots like to stir up hornets nests no matter what.
3) If Larry McVoy decided to GPL the whole thing, there would be a large crowd saying that he needed to MPL it, BSD it, etc so they could use it in their XYZ project.

I think the best advertising Larry has gotten for his product is all the zealots who hate it. As a boss of mine said "I love linux except all zealots that go with it."

McVoy

Posted Apr 6, 2005 22:00 UTC (Wed) by emk (subscriber, #1128) [Link]

Well, to put it charitably, McVoy brought some of his problems on himself, just as Stallman does. McVoy appears to be both a bit combative and slightly thin-skinned, which is a fatal combination in the open source world. Linus, on the other hand, may be downright rude, but he doesn't get upset easily.

McVoy has also gone through a lot of license revisions, each time adding more restrictions. (This is what apparently got Alan Cox upset at various times in the past.) I don't find this behavior endearing from any company, whether the software is free or commercial--evaluating licenses takes time (and sometimes lawyers), and you can't trust anybody who makes major license changes with little warning.

Personally, I'm glad that the kernel is moving away from BitKeeper. McVoy was frequently upset about something, and a lot of kernel hackers resented having to use his software to access the kernel repositories. It's better for everybody this way.

Good will doesn't always lead to good results

Posted Apr 6, 2005 21:19 UTC (Wed) by huaz (guest, #10168) [Link]

I've been watching almost every BK flamewar that happened on LKML from the very beginning.

I think Larry is a good guy who wants to help. He surely has also got some free marketing from it, but that's OK. We should welcome a win-win situation. It's only a good thing if BM gets more revenue as Linux gets more productivity. In the end it's what all companies do and how most of us make a living in this world. I am not gratious toward Larry and BM, but I do want to say "thank you" to him and it's a pity that things didn't work out.

I think Larry's biggest problem is that he thought "the open source community" is well disciplined, while in fact, it's a community of turmoil. You certainly can't tell people what to do or what not to do, and one "bad apple" could just ruin the whole thing. So although his position of "we give for free as long as you don't screw us up by using our gift" is very reasonable, it was doomed not to work.

Looking back at it, BK certainly has shed some lights on how a decent SCM should look like. This is the major contribution in my opinion is. We should thank BM for it, and I hope the open-source community would show the effort as well as talent to come up with a really competitive SCM.

Linus on the BK withdrawal

Posted Apr 6, 2005 21:56 UTC (Wed) by JoeF (guest, #4486) [Link]

Subversion's Open Letter on the topic: http://subversion.tigris.org/subversion-linus.html

More info about OSS/FS SCM programs

Posted Apr 6, 2005 22:17 UTC (Wed) by dwheeler (guest, #1216) [Link] (1 responses)

Again, for more info on OSS/FS SCM tools, see Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems.

More info about OSS/FS SCM programs

Posted Apr 6, 2005 23:02 UTC (Wed) by ballombe (subscriber, #9523) [Link]

LWN need a feature to automatically link to the relevant dwheeler papers. That would save a great deal of time to everybody involved :)

They are quite interesting and thorough pieces, but once you have read them twice each, they start to be boring.

(For example I think I first learnt about monotone there)

Linus on the BK withdrawal

Posted Apr 7, 2005 12:43 UTC (Thu) by stock (guest, #5849) [Link] (1 responses)

This must be why Linus didn't start the 2.7.xx developer tree yet.
and also why we have such weird kernel version numbers like 2.6.8.1 ..

If a tool, no matter if opensource or not, free or thousands of dollars,
is forcing you to part from your original development strategy and
roadpath, it should be thrown out.

Luckily the Linux kernel coders now have an idea how a new tool should
work, which is fine, because programming a tool is peanuts once its
design and functions are clear.

Robert

Linus on the BK withdrawal

Posted Apr 7, 2005 19:33 UTC (Thu) by proski (subscriber, #104) [Link]

This must be why Linus didn't start the 2.7.xx developer tree yet. and also why we have such weird kernel version numbers like 2.6.8.1 ..
As far as I understand, the reason is that there is enough manpower and the tools are good enough for the kernel to be developed at full speed without destabilizing it so much that it takes years to re-stabilize it.

As for x.y.z.w releases, they could (and should) have existed long ago. If a serious bug is found in x.y.z, it shouldn't force immediate release of x.y.(z+1), but it's good to have a corrected version.

For example, if I'm tracking a bug that appeared between 2.6.7 and 2.6.9, and 2.6.8 is known to kill my filesystem, I'll rather try 2.6.8.1. After all, it's unlikely that the bug I'm tracking is related to the bug that corrupts the data, but I prefer not to reinstall the OS after the test.

If a tool, no matter if opensource or not, free or thousands of dollars, is forcing you to part from your original development strategy and roadpath, it should be thrown out.
I disagree. Sometimes the strategy becomes suboptimal in presence of new tools. In particular, extensive regression tests may reduce need in beta versions. I'm not sure it applies to BK, but you are making a general statement here.
Luckily the Linux kernel coders now have an idea how a new tool should work, which is fine, because programming a tool is peanuts once its design and functions are clear.
Not always, especially when speed and correctness are important. SQL exists for years, but how much time does it take to develop a database that can compete to Oracle?


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds