Bitkeeper News Redux

gosand writes "Newsforge is running Part 1 of a two-part interview with Bitkeeper author Larry McVoy. You may recall that there was quite an uproar in the community over Linus choosing to use a proprietary source management tool. Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK."

Pretty impressive productivity increase

[mindless4210]

What we did to arrive at that number was to simply measure the amount of change over the two-year period in BitKeeper and contrast that with the two-year period before BitKeeper. It worked out to about 2.5x more change.

I'm no mathematician but I'd say that's a decent way of estimating their productivity increase. But does BitKeeper actually help that much? Anyone who has every used it in a production environment please comment.

Linus is processing around 50 patches a day, 365 days a year.

That's a pretty incredible number. If that's the truth, then I'm very impressed.

Productivity

[AKAImBatman]

Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK.

And I'm 1000x more productive with CVS!

Instead of pulling numbers out of the air, just say the guy likes the tool and performs better with it. Sheesh.

10x... riiiight...

[Anonymous Coward]

In one day Linus can hammer out the code that used to take him 2 work weeks? Give me a break.

The right tool for the job

[beatleadam]

...You may recall that there was quite an uproar in the community over Linus choosing to use a proprietary source management tool. Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK...

No interest whatsoever in being a flamebait here so...

Though no hard numbers exist and this is largely speculative all around, one would have to applaud Linus for using any tool that is making him 10x more productive.

Pretty impressive productivity increase-Methods

[Anonymous Coward]

There's only one small problem with measuring things that way. Things basically are more complicated during the second-two years, therby generating more work. So how much is Bitkeepers doing, and how much is simply more work comming in?

I don't see

[Power Everywhere]

Why there was an uproar over this. Who cares if it's Free or not? It gets the job done better, and in the end that's what counts. The flame wars all over LKML and other places were just wastes of time.

Lesson to be learned

[WordODD]

The lesson to be learned here is very simple...
Open source and propriety software can and should be used hand in hand. The best tool for the job etc. etc. The OSS scene suffers from the idea they are members of some religion and by using anything other then Open Source they are committing a crime against the movement.

New unit of measurement?

[EnsilZah]

"...the estimates are that Linus has been 10x more productive with BK." Does that mean we have a new unit of measurement for benchmarking?

Although there are no hard numbers

[frovingslosh]

I'm no mathematician but I'd say that's a decent way of estimating their productivity increase.

Actually, it's meaningless without looking at other factors. Even the concept of more change is so open ended it tells us nothing. As Linux gains users it will certainly increase in these numbers, there is no strong indication that bitkeeper is a factor at all, or how much of a factor it is.

Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK.

Following the statement that there are no hard numbers , the ten percent figure seems more like a number pulled out of thin air and selected to not be large enough to be called outrageous but big enough to encourage people to make a change. That's not to say we are not talking about a good tool here (I have no opnion on that issue), but this is much more hype than a valid study.

10x - I misread it as 10%!

[frovingslosh]

With no hard numbers the 10x number is absurd. I misread it as 10%, and even that number seemed hard to justify since all factors were not considered. 10x is an outrageous claim, and would imply that Linus previously spent almost all his time not doing programming.

Maybe not so great?

[proxima]

We derive benefit from the pro bono work in other ways as well. When we are testing out a new release we can put it on bkbits.net and we know in seconds if we have broken something important; people use old versions of BK to talk to bkbits.net every few seconds.

Perhaps having the repository where Linux and other projects are hosted being broken to older clients now and then is a bad thing for a community (though the bk people obviously see it as positive for them - free testing). I understand they're providing everything for free, but perhaps Linux might be better off on a community-supported service (still running Bitkeeper) that is concerned a bit more production status?

I'm not intimately familiar with this, so it's just my two cents, feel free to argue.

Emphasis on 2x, NOT 10x

[skink1100]

Folks -- the 10x productivity number mentioned in the article was only an anecdotal claim; Larry McVoy claimed 2x. And the latter number is backed up by some pretty fair reasoning. I RTFA and didn't get the impression anyone was pulling numbers out of their ass.

S

Re:Pretty impressive productivity increase

[Just Some Guy]

Depends. Did the move to BK come before or after IBM jumped in and started donating huge amounts of code to the kernel, companies started pumping out device drivers, and Linux became a well-known name in IT circles?

I'd be willing to bet that KDE and Gnome have accelerated a lot since Linux moved to BK, but I don't think that anyone would assert that BitKeeper should get the credit.

In short, that move happened at a fixed point in time when a whole lot of other interesting things were starting to happen. Was BK causative or correlative? I'd put money on the latter.

Since when did Linus...

[goldspider]

...need to justify himself to the Slashdot crowd?

Unlike a lot of you, Linus isn't a Linux zealot. He's said on more than one occasion that Linux/OSS is about making the right tool for the job when one doesn't already exist. It has nothing to do with shoving an ideology down everyone's throat.

In this case, Linus decided that Bitkeeper was the best tool for the job, and it is very telling that people are judging him for not complying with an almost religious ideology that he doesn't even subscribe to.

Success due to Bitkeeper?

[amightywind]

There has been a noticable improvement in the 2.5-2.6 cycle compared to 2.3-2.4. Linus and the team has done a super job. Bitkeeper gets a lot of credit for it. I can't help but wonder if similar results would not have been achieved with CVS, Subversion, or arch. Are there any features Bitkeeper has that the free alternatives do not?

The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?

And for the rest of us..

[Anonymous Coward]

And for the rest of us who enjoy using free software, there's the Subversion [tigris.org] (also known as SVN) revision control system.

The article makes some moot points comparing BitKeeper to CVS - since I'm fairly sure anybody who's tried SVN would never want to go back to CVS. I now recoil in disgust whenever I have to access a CVS database - SVN's implementation solves problems in a much cleaner way than CVS and has far fewer rough edges.

Yes 2.5x better than nothing

[norwoodites]

IIRC he was not using any SCM at all so yes using one in gneral will help. CVS for me was able to get my team about 10x better (but then again I did most of the work anyways and this was for class).
But anything not using a SCM will be helped by using one.

Testing Expertise

[barryfandango]

"When we are testing out a new release we can put it on bkbits.net and we know in seconds if we have broken something important; people use old versions of BK to talk to bkbits.net every few seconds."

I'm sure they're experts in code management, but their testing procedures could use some work.

Re:Lesson to be learned

[cduffy]

No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems. This means that folks working on Free revision control (like me!) are substantially hampered if we want to also do some work on the Linux kernel.

Larry has also been known to change license terms specifically to force a particular user to upgrade to a more expensive license -- I was an employee at a Linux startup (MontaVista Software) when it happened to us. He's been known to spread FUD about Arch in public, and is otherwise not a very nice person to have as a competitor *or* a supplier.

Particularly given that Free alternatives [gnuarch.org] to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available, using BitKeeper is arguably much more destructive than it is useful.

Re:Although there are no hard numbers

[Izago909]

I guess it all boils down to what Linus thinks. If he feel's it's better, and helpes increase his production, then that's all that matters. Something as complex as this will prove very difficult to make hard numbers with because of the large number of uncontrolable variables.

Re:10x... riiiight...

[Malor]

Remember that this number is about perception. Linus himself says he's more than twice as productive. The other developers say he's 10x as productive.

But what's their measurement? The number of patches from them he accepts. For years, Linux development was badly hamstrung by the fact that Linus couldn't work fast enough. The patch submission process, was, in essence, emailing him over and over and over, hammering away at the poor guy, trying to get your patch noticed. The developer frustration with this process was EXTREME. The single most common thing I heard about kernel development was "Linus doesn't scale". BK has changed that completely.

It seems entirely possible to me that Linus is now 10x better at processing and merging patches. But that's not all he does.... a 10x improvement in patch management could easily translate to a 2x overall productivity increase. Measurements of code changes show about a 2.5x overall improvement, which is pretty close to Linus' own guess.

In other words, these numbers aren't incompatible... productivity is a hard thing to measure, and there are a lot of angles from which you can look at it.

If the claim of 50 patches a day, 365 days a year are true... that's 18,250 patches a year. The fact that he can do that and get coding done TOO should be an object of reverence and awe.

Since BK was designed with Linus in mind, it probably won't affect other programmers as dramatically as it did him. Not all coders will think like he does, and his distributed coding needs are very specialized. It's not going to be applicable to all environments, but it's pretty obvious that at least in some cases, it is an enormous win and completely worth what they're charging for it.

Re:I don't see

[rabtech]

The key difference is that if you duplicate MS Access with VS, you are using ADO which contains the Microsoft JET engine (among other drivers); in effect, you are using the access engine to write a product that competes with access.

In the BK instance, you are NOT using BK as the basis to develop a competing source control product.

The BK license (at least regarding that provision) is not enforceable and has all the weight of feather to back it up.

Linus - Practical

[MisterFancypants]

The fact that Linus tends to choose pragmatism over idealism is why the Linux kernel is important and GNU hurd is completely still-born.

Idealism is nice and all but it doesn't get shit done.

Actually, Linus doesn't do very much programming

[Lface]

He reviews the much of the changes that are going in, and he has designed some of the larger changes, but the bulk of the programming is done by others. This is why comparing the rate of the merging of patches makes sense in the first place, that is mostly what Linus does.

Just from following the kernel development from the outside it is obvious that things have been working much more smoothly after Linus started using bitkeeper than it has in a long time. In the past there has been several periods where the tension has gotten very high mostly because large number of patches has been dropped by Linus without explanation. Lately this seems to have been no problem at all. And this has happened when the rate of the patches going into the kernel has increased significantly.

There may be other reasons for this too, ofcourse. Things I can think of is that the cooperation with the "kernel lieutenants" has been working better. In particular Andrew Morton seems to do a remarkable good job. And, the fact that Linus now is working full time on Linux probably also helps.

Re:Success due to Bitkeeper?

[cduffy]

CVS is decent

That is, unless you've actually used anything else long enough to realize that it isn't.

No history-sensitive merging, crappy branching support, a repository format that invites corruption, no changeset support, no distributed operation support, inefficient operation w/ large file counts, a server that can't scale (look at all the issues SourceForge has)... CVS has got to go.

Re:Lesson to be learned

[cduffy]

No, I don't consider BK my competition; I'm not an Arch developer (rather, my pet VC project is CSCVS, a tool for breaking CVS repositories' history into changesets and doing nifty things with those changesets -- one such "nifty thing" being importing them into Arch).

Yes, the commercial version of the license doesn't have that restriction. Your point being? Until my employer is someone doing kernel development again, paying BM for a license isn't likely to happen, so I'm still effectively blocked from its use.

And yes, I do have an axe to grind re LMV. Personally, though, I rather think he's earned that axe.

Re:Pretty impressive productivity increase-Methods

[dgatwood]

It also ignores the obvious: what was he using prior to Bitkeeper? While this article implies that he used CVS, by my memory (and supported by the comments in this article [slashdot.org], he actually used a source tree directory with no SCM (other than periodic tarballs).

In other words, this article basically means that using -some- source code management system makes you more productive than plain old backups. One word: duh.

Move along. Nothing to see here.

What went wrong?

[Trogre]

This seems like just another example where the Free/OSS model has failed.

There are many FOSS alternatives to Bitkeeper such as CVS, Subversion, and arch. And none of them come close to the productivity of this one commercial package.

Why is this? Sure, we've got peer review, no deadline/bottom-line pressure, but we still get outdone. Where is Eric Raymond's bazaar now?

Don't get me wrong, I'm a strong believer in OSS, and occasionally contribute, but there are still areas where we are sorely lacking.

When was the last time you saw a decent FOSS fps game? Crystal Space looks promising, but it's just an engine. Look at Tux Racer, another example of FOSS failure. The game was forked when the original developer decided to go closed source, and the GPL'd OpenRacer project was started. Today the closed-source TuxRacer is a rather beautiful full-featured game, and the FOSS version hasn't progressed beyond a novelty.

Then we get to see Blender, a shining example of when FOSS developers adopt a formerly closed-source project and do it right.

Re:Linus - Practical

[al.cx]

What a bullshit argument. So I guess GCC, Emacs, Bash and the hundreds of other GNU tools that make up the bulk of most Linux distributions are "still-born"?

And for another example of idealism providing great tools via a slightly different ideology, see OpenBSD. Take a look at what they've done with PF and CARP. Neither development would've seen the light of day if it hadn't been for the OpenBSD group's free (BSD) software ideology.

Re: Large CVS projects

[Cochonou]

The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?

The FreeBSD project also uses CVS for development. Keep in mind that FreeBSD is a kernel AND an userland, which might qualify it to be an even more complex project to manage than Linux.
And on a lesser scale, there is also the example of the Mozilla project which uses CVS with a good share of success.

Re:What went wrong?

[Anonymous Coward]

Well, a reason that you're not seeing any absolutely excellent open-source games is because a team designing a game needs to work very, very closely together. This is one area where closed development wins.

Think about it, first you need game mechanics everyone can agree on, then plot, art, and level design. And most programmers arn't good at any of them, just programming. This is why crystal space is good, but many games just fall flat.

If anyone had the time, coordination, and teamwork, then there would be a great, open game.

Re:Success due to Bitkeeper?

[HuguesT]

This reminds me of the silly software comparison charts that one finds in PC magazines and of some not-very-honest adverts in the same mags. The journalist lists a number of feature each piece of software has and puts a bright green tick in the right column where the feature is implemented and a nasty red cross where it's not. At a glance one is able to see which is the better piece of software. Not.

Yes CVS lacks lots of features that may be important in some software projects, on the other hand it is pretty much bug free, has seen a huge amount of usage, is very simple to use (it takes me all of 5 minutes to get a new user up to speed with it), has no silly file locking, has a simple text-based repository which is in fact very robust.

I never tire of saying that I've been using CVS for nigh on 12 years now, that I've also used SCCS, raw RCS, and Perforce, which everyone swears by.

By and large CVS is the simplest to use and does get the job done. Whereas I couldn't get any of my users to use RCS and that a lot of them don't like Perforce because of the individual file locking feature. I have had exactly zero problem with CVS, and this is an experience that is reflected pretty much around the globe.

Regarding the issues that SourceForge has, I'm not sure it would be helped by switching to another source control system. Sourceforge doesn't appear keen to try, they must have good reasons for it.

Now for some things you are right, CVS is not the right tool. We are talking massive complicated and distributed systems like the Linux kernel. In this instance we are talking about sophisticated users and developers who know the value of using the right tool for the right job, even if the tool is more complicated at first. Neither BK nor Arch and not even Subversion are as simple as CVS at first.

CVS is a decent answer to a very important problem. It doesn't have to go, developers need to be aware of the alternatives when they reach the limits of what CVS can do.