Slashdot Mirror
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."
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.
Wireless News www.DailyWireless
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.
Javascript + Nintendo DSi = DSiCade
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.
Please do not let scientific accuracy interfere with the intended humourous/interesting/insightful value of this comment
BitKeeper is a fine product. Check out the other fine products in the same product line:
*BitCreeper debugging tool
*BitSleeper archiving tool
*BitDeeper anti-anti-enhancement spam tool
*BitPeeper anti-anti-porn tool
-[joke removed for your safety]-
BK uses a more distributed development model instead of having one central server, which allows people to maintain their own version controlled source tree from which Linus (or anyone) can pull patches from. This is more like Arch or SVK than CVS or Subversion. Although in the end it performs a similar function, the difference is fairly significant.
It gets the job done better, and in the end that's what counts
I've used many peices of software that have gotten "the job done better."
And, I've been burned too many times to count when the company that makes the software changes focus or goes out of business.
Free Software, for me, is great insulation from forced migrations, "upgrades" and unsupported software.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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
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.
"Ask not what your country can do for you." --John F. Kennedy
The fact that it's actually used outside of one project/domain (unlike BitKeeper) also helps as there's a wider pool of experience to tap into.
Having said that, while it's maturing fast it still has an evil UI (no Tom wrappers are NOT an acceptable solution for that), and lacks some important features like being able to turn a changeset into a flat text file and then email it in one command. If you're willing to do some scripting arch is the most powerful SCM I've ever seen, but it could always be better.
Finally it's a bit misleading to say that it was BitKeeper that made Linus 10x more productive. Before BK they didn't use any source control at all, and all patches were sent either in private email or onto lkml. It's not surprising that using source control improved things!
For comparison, Alexandre Julliard who maintains Wine processes approximately 100 checkins a week, so that's about 14 a day. We use CVS with a single committer. Given that Alexandre actually codes a lot as well, I think it's pretty clear that Linus' "productivity boost" more to do with being able to work full time and having a decent project structure (we all send patches to a dedicated mailing list for instance and we don't have a ton of "lietenant" trees) than anything magical about BitKeeper.
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.
Larry referenced some stuff I wrote for Open Source magazine recently. Here's the basic information if anyone wants to know what the real rate of change was for the 2.6 kernel development cycle. As for if it is faster than 2.4 we don't have real numbers (bk wasn't being used) but you can take the diffs and compare them for yourselves...
The Linux 2.6.0 kernel was released after 680 days of development. Here are some statistics about the development cycle during that time period:
- 27149 different changes were accepted into the kernel source tree. That averages out to about 1.66 changes per hour over the entire 680 days.
- 916 different developers contributed at least one kernel patch.
- 413 different developers contributed one kernel change.
- 117 different developers contributed two kernel changes.
- 57 different developers contributed three kernel changes.
- 38 different developers contributed four kernel changes.
- 20 different developers contributed five kernel changes.
- The top 10 developers contributed 10933 kernel changes.
- The top 5 developers contributed 6956 kernel changes, averaging out to about 10 kernel changes a day.
- There were 6175 merges in the kernel source tree, averaging out to about 9 merges a day.
- Including merges and code changes, there were just over 2 modifications per hour over the entire 680 days of development.
Idealism is nice and all but it doesn't get shit done.
Ok, ok, we get the message, Larry. You dont need to astroturf so vehemently. Or at least be more restrained, say, mention only 2 competitors at once in any of these completely spontaneous user testimonials, no?