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."

Comments

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.

Re:Pretty impressive productivity increase

[niko9]

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

Bullshit. The guy never gets out to take a walk, or go for a drive in that yeallow sports car of his or, heaven forbid, take his kids to the fucking zoo for the day.

Yeah, he just sits there, 365, 24x7, turning out patches.

Please.

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.

Re:Pretty impressive productivity increase

[Spoing]

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

Active cooling, a dedicated fan, a big heat sink, and he should get up to 60-75 patches a day. No need to wait a year or two for Moore's law -- these changes can happen today!

Re:Pretty impressive productivity increase

[Short Circuit]

He doesn't make them, he reviews them. I'm no expert, but I'd guess he gives them a quick look over for obvious breakage and other no-nos.

Re:Pretty impressive productivity increase

[ZorinLynx]

Ever strap a large heat-sink to your forehead? This may sound silly, but it DOES feel really cool! Try it!

Of course, people might think you're odd if you're walking around on a hot day with a HSF going full blast on your forehead, but hey, it could be the new geek trend in hot climates!

FOREHEAD HEAT SINKS!

-Z

Re:Pretty impressive productivity increase

[hoggoth]

> Ever strap a large heat-sink to your forehead? This may sound silly, but it DOES feel really cool!

You must be a chick magnet.

Re:Pretty impressive productivity increase

[Anonymous Coward]

... dedicated fan, a big heat sink, and he should get up to 60-75 patches a day
Yeah, have heard about overclocking Linus. Probably new sheduler helps too...

Re:Pretty impressive productivity increase

[Thurn und Taxis]

Active cooling of an entire Linus, though, would require large quantities of beer, which would completely offset the productivity gains you would otherwise get.

On the other hand, it would make him look more like Tux.

Re:Pretty impressive productivity increase

[Peter S. Housel]

Linus has plenty of dedicated fans already. A lot of them hang out here on Slashdot.

Re:Pretty impressive productivity increase

[taniwha]

he already has lots and lots of fans - the project you describe is already in progress .... in fact if the fans go away we might suffer a meltdown ... probably an LN2 bath would be going a bit over the top, perhaps the occasional case of beer sent his way would help though

Re:Pretty impressive productivity increase

[cavemanf16]

With statistics, it's semi-dangerous to compare such incredibly long spans of time for something like this. I mean, there are so many HUGE factors in the "amount of change" to maintaining Linux (increasing volume of vendors selling and using it, more user visibility, constant improvements to the 'product', etc.) over the past 4 years that comparing the two years prior to the two years now is almost impossible. It is NOT a simple thing to compare the two differences!

Just because Linus *feels* more productive with BitKeeper doesn't necessarily mean that we can measure the change like this. What should be going on is the measurement over say a 3-month sapn of time on two very active projects, one which uses BitKeeper, and one that uses another well established 'product' or process, like CVS. Compare the efficiency's gained or lost between the two similar, active projects and you can start to use statistics. But without a baseline, and with a absolutely moving scale like Linux development over the past 4 years, these statistics make no convincing argument.

Re:Pretty impressive productivity increase

[Xenographic]

No, but he will be once he can find a few pounds of neodymium magnets to strap to himself ;]

Re:Pretty impressive productivity increase

[IWannaBeAnAC]

Ahem.

Maybe that was an average ?

Re:Pretty impressive productivity increase

[packeteer]

I agree that PROBABLY the two are unrelated but honestly i dont claim to be able to do what linus does and untill i can im not gunna talk shit about using BK.

Re:Pretty impressive productivity increase

[onkelonkel]

Forehead heatsink? Been there, done that.

Years ago on tv I saw a japanese product which was exactly that. It had a small (say 3 x 10 cm) finned heatsink with a tiny 12V fan on an elastic headband. It was supposed to keep automobile drivers alert.

Re:Pretty impressive productivity increase

[Lost Engineer]

The same could be said for almost any cool thing one might post about doing on slashdot. That one was kinda weird though.

Re:Pretty impressive productivity increase

[Just Some Guy]

But it's ok to give context-free statistics involving Linus' productivity being helped by BK?

I assert that RMS' productivity went up ten-fold since I started using Subversion. Are you going to get upset if someone asks for more proof?

Re:Pretty impressive productivity increase

[sburnett]

Best of all, a lot of slashdotters have an abundant supply of forehead grease for super heat conduction!

Re:Pretty impressive productivity increase

[silicon not in the v]

You mentioned using beer to cool Linus, but these guys used beer to cool the computers!

By the way, these are the same guys who run
http://www.microsith.com

Re:Pretty impressive productivity increase

[Anonymous Coward]

I've used Bitkeeper before, its awesome. Would I use it again? In a second I would for sure.

You really begin to notice how much it kicks ass when you have 5 people working very closely and the same areas of code and watching the merge happen with bitkeeper doing the work.

When their merge does not know what to do 100%, their merge tool makes it very quick and easy to merge the two files.

Brad.

Re:Pretty impressive productivity increase

[Bill, Shooter of Bul]

As long as there is a heat diference in your favor it will work. Do not try it if the ambiant temperature is greater than your body temp. That would move the heat into you, instead of out. Per Newton's law of cooling, the effect is dependant upon the temperature difference between your skin and the air. The farther they are appart the faster you will cool off. As the outside temp approaches 96 degrees( roughly the external temp of the skin on your forehead) it will become less and less effecient.

Re:Pretty impressive productivity increase

[master_twig]

Yeah but they generally only produce hot air

Re:Pretty impressive productivity increase

[Carewolf]

Exactly, skip the heatsink just strap a fan to your forehead. Although I prefer keep my fans at a distance.

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.

Re:Productivity

[XMyth]

Boy, you don't know the first thing about marketing, do you?

Re:Productivity

[dresgarcia]

"Here's how that announcement came about. I asked someone we were considering hiring why he wanted to come work for us. His response was, "I hang out on the kernel list and it is obvious that Linus is ten times more effective since he switched to BitKeeper." That sounded pretty nice, but I didn't believe it. I knew things were better, but ten times better? That sounded a little too good to be true."

Did you bother to read the article before posting? They say the real number is closer to 2.5x.
Sheesh.

Re:Productivity

[Bronz]

Isn't that what they just said? Is it really different to say "Linus is 10x" as opposed to saying "Linus is a whole lot more" productive?

Re:Productivity

[grub]

I'm 10x more productive when I don't read /. at work.

Re:Productivity

[AKAImBatman]

Did you bother to read the article before posting? They say the real number is closer to 2.5x.
Sheesh.

Then why didn't the article poster say that instead? Sheesh. ;-)

Re:Productivity

[MrRuslan]

I agree with you 100%...it's about the right tool for the job and the tool the user works better with...to some photoshop is better and to some gimp is better...not about making a big deal about something being not free but suits the needs better.

Re:Productivity

[Ravensfire]

Accuracy? From an article submitter?

lol - what next, you want the editors to make sure there isn't a dupe already out there?

-- Ravensfire

Re:Productivity

[Anonymous Coward]

Lighten up moderators...it was a joke for crying out loud.

Re:Productivity

[Anonymous Coward]

I agree with you 100%...it's about the right tool for the job and the tool the user works better with...

Exactly. That's why so many people choose Windows. :)

Amazing how philosophical and noncommittal the FOSS community gets when a commercial app is shown to be immensely better than FOSS alternatives from an unquestionable source like Linus.

Re:Productivity

[gosand]

Then why didn't the article poster say that instead? Sheesh. ;-)

Ahem. I can field that one... :-)

OK, I probably should have used the word "perception" instead of "estimation", because the estimates were about 2.5x.

Here is what it did say in the article:

Here's how that announcement came about. I asked someone we were considering hiring why he wanted to come work for us. His response was, "I hang out on the kernel list and it is obvious that Linus is ten times more effective since he switched to BitKeeper." That sounded pretty nice, but I didn't believe it. I knew things were better, but ten times better? That sounded a little too good to be true. I know some of the senior kernel people personally so I started asking around. I spoke with Dave Miller, Jeff Garzik, Greg Kroah-Hartman, Andrew Morton, and Linus about this. Dave was the first person I spoke with and he said that he thought that 10x wasn't at all unlikely, and it was certainly 8x. Interesting. So I talked to Jeff and his comment was, "Oh, man, it's so much better, it has to be 10x." Greg had a fairly similar reaction.

Re:Productivity

[AKAImBatman]

OK, I probably should have used the word "perception" instead of "estimation", because the estimates were about 2.5x.

You look like a good kid. I'll let you off with a warning this time. Just don't do it again! ;-)

Re:Productivity

[the chao goes mu]

"the guy likes the tool and performs better with it". Isn't this true of every guy?

Re:Productivity

[aled]

I'm 3.14159x more productive but I'm stuck in a loop.

Re:Productivity

[JungleBoy]

I'm 10x more productive when I don't read /. at work.

I don't think I could say that for myself because 10 x 0 is still zero.

I would have that simply say that I am productive when I don't read /. at work. When I read /. at work, my productivity isn't mostly dead, its all dead.

Re:Productivity

[gosand]

You look like a good kid. I'll let you off with a warning this time. Just don't do it again! ;-)

Heck, who would have thought that my submission would have been accepted?! I mean, everything was spelled correctly, I didn't blame Microsoft, and the story hadn't been posted yet. :-)

Re:Productivity

[osgeek]

Please send your resume to:

Bill Gates
C/O Microsoft
Redmond, WA

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.

Re:10x... riiiight...

[happyfrogcow]

probably not, but maybe in the absence of BK, he would never get to the actual *writing* of code.

Re:10x... riiiight...

[Wesley Felter]

Linus doesn't hammer out code; he merges code that other people wrote.

Re:10x... riiiight...

[Anonymous Coward]

Who the hell modded this insightful? Making a successful build of a software project isn't simply about proper coding... it's about successfully merging the changes made by EVERYONE working on it at the same time.

Re:10x... riiiight...

[DreadSpoon]

Bull. Linus is still very active in the actual coding. Look through the patches and see how many have him listed as the author.

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:10x... riiiight...

[ceswiedler]

Furthermore, other developers are more productive. It's very easy (assuming you can comply with the licensing terms) to set up your own tree and pull from Linus. In fact, the best way to work with BK is to use many trees, one for each (broad) set of changes you're working on. BK will gracefully handle merging them. Not only developer -> Linus, but also Linus -> developer: when Linus's tree is updated, it's easy for a developer to pull those changes down. It's better all around.

The other, very convincing, argument is that all of the previous 'functionality' is there, and then some. Linus still creates releases in the same way--you can just get stuff earlier with BK. The release notes are better, because they're generated from BK, and include the author's name and comments, not just Linus's summary. You can still send diff-style patches via email. Bitmover also added CVS gateways for those who want early changes without using BK. The LKML community was extremely skeptical to say the least, but pretty much everyone except the rabid zealots are convinced.

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.

Re:The right tool for the job

[BK425]

Since I stopped holding my breath my productivity is up far more then that... isn't it possible that other factors should be considered here?

Re:The right tool for the job

[beatleadam]

Since I stopped holding my breath my productivity is up far more then that... isn't it possible that other factors should be considered here?

Beyond a shadow of a doubt "Yes"...nay...Hell Yes!

I was merely stating that sometimes a certain tool or application, regardless of its origin (i.e. Open Source or "Other") has to be considered on its individual merits and what it can do for you as a whole. Frankly, I am was more than a little suprised to hear that Linus was using a non OS tool.

is there more than bk involved???

[millahtime]

There are other things to think about for terms of productivity. Like, how much time per day is he putting into it? How much faster is his setup to allow him to apply patches? Are the patches more/less/equaly in size to the ones from years ago when Linux was getting off the ground.

Re:is there more than bk involved???

[Hatta]

Yes, methamphetamine.

Re:is there more than bk involved???

[ichimunki]

I agree. There could be confounding factors, but the people who came up with the number are all pretty smart and if Linus says the tool helps, then probably the tool helps. Maybe the numbers aren't exact or even all that useful. All I can say is: I wouldn't want to use CVS for this task either, and if you've looked at the other revision control systems out there, it's a pretty sorry landscape. I've never looked at BK myself, because of the license... which to me says: how much do we have to pay McVoy to open source this thing? He's giving so much away for free as-is, we really ought to consider bribing him into making it Free Software. :)

Re:is there more than bk involved???

[paule9984673]

One should also take into account that Linus did all the Kernel work in his free time while working in a day job (last at Transmeta) and has only recently been able to work on Linux full-time.

Bitkeeper usage might just be circumstantial to the percieved productivity gain.

BitKep'R

[Leffe]

"BitKeeper has made me more than twice as productive, and its fundamentally distributed nature allows me to work the way I prefer to work - with many different groups working independently, yet allowing for easy merging between them." -- Linus Torvalds, February 2004

Interesting... and BTW, is BK just another SCM(is that the right acronym ;)?) or what?

If it is, I'm using Subversion, and it's nice ^^

Re:BitKep'R

[Benabik]

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.

Re:BitKep'R

[Leffe]

Thanks, this diagram explains everything!

Re:BitKep'R

[DARKFORCE123]

SCM is a lot more than just a tool to store and maintain different versions of file elements.

Anyone one trying to say using CVS you can be as productive as someone using Bitkeeper or Clearcase has to be joking.

I hope that free software does come out that is just as good but it just isn't there yet.

Re:BitKep'R

[Unknown Lamer]

Subversion is a CVS replacement. It is not and will never be as powerful as Bitkeeper. It does its job as a CVS replacememnt well.

The only Free SCM that can be compared with Bitkeeper is Arch. Arch should be able to replace Bitkeeper in the future if not already (it's been a while since I used Arch). It is Free Software and part of the GNU Project now too.

Re:BitKep'R

[Anonymous Coward]

or darcs or monotone....

Re:BitKep'R

[cduffy]

Mmm. There's a better one; see here for a presentation by Colin Walters (a Red Hat employee) on GNU Arch.

Incidentally, Arch is where SVK got its star-merge algorithm.

Re:BitKep'R

[trance9]

Arch is not the only one, monotone is another, cleaner tool.

Re:BitKep'R

[casret]

Yeah, it's the correct acronym, (Software Configuration Management (I don't get it either)).

I've used a bunch of them over the years, it's a bit of a hobby for me. I won't try to do a comparison of them all, there's one

here. But I'll give some general impressions. BK is definetely the best of the bunch so far. The distributed nature, the solid tools around it, the don't lose any piece of change data philosophy.

I've been on an Arch kick though, it follows the same principles, distributed repositories and all that, but there aren't as many tools around for it quite yet, but I think it's building a community around it. There are some idiosynchrocies that bug me though.

Still haven't gotten around to playing with Subversion, it just didn't seem ambitious enough for me to bother with.

Perforce and CVS are the other ones I have the most experience with. They are pretty typical for a client-server type model of SCM, with Perforce being well supported on the commercial end. That external database gets large and slow though if your tree gets too big.

Re:BitKep'R

[shish]

(Software Configuration Management (I don't get it either)).

You don't get it because it's wrong :P. It's source code management, hence it managing source code.

Re:BitKep'R

[Anonymous Coward]

Or maybe even Source Code Management.

Re:BitKep'R

[tzanger]

What about Darcs? It seems to do the distributed-repository-merge-between-anything-danc e pretty good, too.

Re:BitKep'R

[casret]

Don't tell me, tell these guys:
Bitkeeper
Perforce
Clearcase
(Look at the titles)

Probably want to send and email over to the guys on comp.software.config-mgmt, I'm sure they are going to want to hear they've been using the wrong acronym all this time.

Re:BitKep'R

[William Tanksley]

I suspect others will comment on this too, but there are other close equivalents in the free software world.

Arch is groundbreaking, but it was designed in a rather ad-hoc way, and it _really_ shows. You have to know a lot about the implementation details in order to get stuff done in it.

Darcs is much, much easier to use, and is supported on more platforms (including win32). The shortcomings include slow execution time (due to a complex merging algorithm that's part of the reason it's much easier to use) and an unusual implementation language (I like Haskell, but I recognise that many people don't know it).

OpenCM and Monotone are in much earlier stages of development, and I haven't tried to use either in a production environment.

Bitkeeper still has one big advantage: it's got killer graphical utilities and it's really complete. Both arch and darcs are still growing into their full statures.

But I strongly recommend darcs. I don't see any reason to use any other SCM tool, honestly -- darcs _just works_ and is free. Copy the executables into your path, type 'darcs inittree', and start working; it's just that easy. No worries about file identities, no worries about archive locations; it's all taken care of thanks to a well-thought-out model.

-Billy

Re:BitKep'R

[cos(0)]

Arch looks fantastic, but after some research, I came to the conclusion that there is no way for Windows-using developers to utilize it -- there are no Windows programs to interface with an Arch repository. Its official site offers only Linux (source/RPM) downloads.

Does anybody care to disprove me?

Re:BitKep'R

[rweir]

See, people who've only used CVS and Subversion just don't understand why subversion will never be suitable for this.

Imagine if the kernel was in subversion, and you wanted to make a change. You'd check it out and change it, make a diff and send it to the list. uh, yay, it's just like working with tarballs. But, if it was in Arch or BK, you'd make your own *local* branch on your machine, make whatever changes you like in it, commit to it (offline if you like, since the archive is on YOUR machine), move files around, etc, etc. When you're done, you merge the changes Linus has made in his tree into yours (so he has less merging to do), and tell him where your archive is hosted (arch can serve your archives to other people via plain http/ftp/webdav, BK has it's own daemon, aiui).

Oh yes, and how do you merge linus's changes into your tree? "tla star-merge <name-of-linus-branch>". No fucking around finding what you've merged before, arch keeps track of that for you. BK does the same.

Re:BitKep'R

[shish]

Hmmm, looking on google, they're both used often and interchangably (Some also call it software change management). But IMHO source code management is better, seeing as it manages source code. Software configuration management is illogical, seeing as it doesn't manage configuration of software (unless you count version controlling a .conf file)...

Re:BitKep'R

[William Tanksley]

Nope, that's the case; no Windows clients yet, and none in sight. It's possible that were one to be written, it wouldn't be very good at compatibility.

Use darcs instead if you care about cross-platform bitkeeper-like version control.

-Billy

Re:Productivity?

[Sv-Manowar]

I think you will find that productivity has increase d due to open source, the big companies know that they can be beaten by free software now

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?

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, 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.

Re:Pretty impressive productivity increase-Methods

[Anonymous Coward]

Andrew thought that anything would have been an improvement over what Linus was doing before and he agreed that BitKeeper was a lot better than CVS. But his take was that just a move to CVS would have been an improvement. Linus disagreed. Linus was adamant that if he had moved to CVS it would have slowed him down. So in Linus's mind, whatever improvement had happened was due to BitKeeper.

Duh yourself.

Re:Pretty impressive productivity increase-Methods

[dgatwood]

Must have misread that line. That having been said, Linus believing that CVS would have slowed him down does not make it so (except insofar as his preconceived notion would likely have turned it into a self-fulfilling prophesy). In the general case, this is, at best, an eye-roller story.

Just my $0.02.

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.

Re:I don't see

[WanderingGhost]

Who cares if it's Free or not?

I usually don't, butif you read the BK license, you will notice that it disallows you to work on competitors (including CVS and subversion) if you are a BK user. I think at least one of the subversion developers (who also contributes to the Linux Kernel) is not allowed to send Kernel patched using BK because of that (he sends them via email).

Re:I don't see

[zulux]

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.

Re:I don't see

[gevmage]

You know, I don't think that can possibly be an enforcable license provision. That would be like M$ trying to control what sorts of papers people could and couldn't write with Word.

Re:I don't see

[BRSloth]

I care.

Suppose you current tool doesn't do what you want. You can simply check the sources to see why I isn't working correctly and you can even patch it.

Now, with a closed tool (even if it's free), you have to contact the developers and wait for a new release.

As I have a good "tracking problem sense", I will always use an open source tool over a closed one. I don't care if the closed one is better or not, I just want to feel safe when the troubles arise.

Re:I don't see

[pqdave]

IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

Re:I don't see

[Power Everywhere]

Obviously Linus and company aren't having such "need to see the source to fix bugs" problems if they're 10x more productive. Your point also kind of collapses when you look at the fact as the previous tool, that they got 10x less work done with, was Free.

Re:I don't see

[happyfrogcow]

or like MS not allowing developers to write a MS Access competitor or other competing software using Visual Studio?

i) your Licensed Product shall not substantially duplicate the capabilities of Microsoft Access or, in the reasonable opinion of Microsoft, compete with same;

Re:I don't see

[Icculus]

IIRC, the license you speak of is only for the free (beer) version for the LK devs. If you pay for a license those restrictions are absent. I think Larry's reasoning was that if he was giving it away he didn't want to give it to someone trying to take his market and dollas away.

Re:I don't see

[Anonymous Coward]

You know, I don't think that can possibly be an enforcable license provision. That would be like M$ trying to control what sorts of papers people could and couldn't write with Word.

Hopefully unenforcable, but remember that Microsoft has *this* clause in their Visual Studio EULA:

1.2 Documentation. This EULA grants you, as an individual, a personal, nonexclusive license to make and use an unlimited number of copies of any documentation, provided that such copies shall be used only for personal purposes and are not to be republished or distributed (either in hard copy or electronic form) beyond the user's premises and with the following exception: you may use documentation identified in the MSDN Library portion of the SOFTWARE PRODUCT as the file format specification for Microsoft Word, Microsoft Excel, Microsoft Access, and/or Microsoft PowerPoint ("File Format Documentation") solely in connection with your development of software product(s) that operate in conjunction with Windows or Windows NT that are not general purpose word processing, spreadsheet, or database management software products or an integrated work or product suite whose components include one or more general purpose word processing, spreadsheet, or database management software products. Note: A product that includes limited word processing, spreadsheet, or database components along with other components that provide significant and primary value, such as an accounting product with limited spreadsheet capability, is not considered to be a "general purpose" product.

So apparently, they *do* feel that they can dictate what you produce with your software -- at least by preventing you from looking at their documentation.

Re:I don't see

[Short Circuit]

That clause isn't really enforcable. If they tried, it would give significant credibility to a competitor's product.

Compound that with it being an open-source project, and Microsoft won't touch 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.

Re:I don't see

[ceswiedler]

You might think that requiring people to distribute any modifications they make to your product to be an unenforceable license.

The logic goes, you wouldn't have a license at all if I didn't grant it to you somehow, so you can't complain about the terms. All you can do is reject the license and not use the product. I can require you to wear a heatsink on your forehead if I want to.

Re:I don't see

[Anonymous Coward]

That doesn't work though. It's like selling a physics textbook and saying that you can only read it if you agree not to write a another physics textbook using what you learned. It's bullshit.

Re:I don't see

[Richard_at_work]

And only limits you to not using BK itself to aid in the development of the replacement, IE storing development code for the replacement within BK. Using BK and a rival at the same time is perfectly OK, otherwise the Kernel wouldnt be able to be exported to CVS, as it is on a continuing basis.

Re:I don't see

[Anonymous Coward]

1. The tool is basically custom made to Linus's specifications and to fit the way he works. That is why he doesn't have much need to modify it.
2. The previous tool was no tool, i.e. everything was done by hand. That is why progress was so slow, patches were getting dropped, etc.

Re:I don't see

[WanderingGhost]

IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

Which is the one used for Kernel development, if I'm not mistaken...

Re:I don't see

[Richard_at_work]

Ignore my previous comment on this, it is indeed if you have anything to do with a replacement, other than distribute it for free, or use it. The exact clause is thus:

(d) Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabil- ities of the BitKeeper Software, or, in the reason- able opinion of BitMover, competes with the BitKeeper Software.

Also on my travels, I also notice that BK does not have this license available for reading anywhere other than within the BK install itself, you need to install BK and then run a command to view the license. Nasty.

Re:I don't see

[RedWizzard]

I usually don't, butif you read the BK license, you will notice that it disallows you to work on competitors (including CVS and subversion) if you are a BK user.

The BK restriction only applies if you are using the free license. You can do whatever you like if you pay for it. Basically: "we'll give you BK for free, but you're not to use it to undermine our business". Seems fair to me.

Re:I don't see

[RedWizzard]

IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

Which is the one used for Kernel development, if I'm not mistaken...

It's irrelevant what license other kernel developers are using. If you want to contribute to a BK competitor and the kernel you need to either pay for BK, not use BK, or ask Larry nicely for an exception (which he has said he's willing to consider in individual cases). I can't see anything wrong with that policy.

Re:I don't see

[WanderingGhost]

It's irrelevant what license other kernel developers are using. If you want to contribute to a BK competitor and the kernel you need to either pay for BK, not use BK, or ask Larry nicely for an exception (which he has said he's willing to consider in individual cases). I can't see anything wrong with that policy.

It's not the BK license and policy actually. I think that what bothers me is that the Kernel developers agreed to use BK, putting some others in this uncomfortable situation.

Re:I don't see

[RedWizzard]

I think that what bothers me is that the Kernel developers agreed to use BK, putting some others in this uncomfortable situation.

Why? It didn't stop anyone contributing. Linus will always accept email patches. It's just a tool that some kernel developers are able to use and a very small minority are not (and that's not even true as they could buy a license). Even those that don't use it gain some benefit from it via Linus' increased productivity, and can use the web and CVS interfaces to it.

Don't forget that at the time there was no viable alternative. Now Arch or Subversion may be reasonable alternatives that would provide most or all of the advantages of BK, but they weren't ready for the mainstream 2 years ago. It was BK or nothing. As it was it took a lot of convincing to get Linus to try it as he was pretty sceptical that any version control system could be unobtrusive enough to be worth using.

Re:I don't see

[WanderingGhost]

Don't forget that at the time there was no viable alternative. Now Arch or Subversion may be reasonable alternatives that would provide most or all of the advantages of BK, but they weren't ready for the mainstream 2 years ago. It was BK or nothing. As it was it took a lot of convincing to get Linus to try it as he was pretty sceptical that any version control system could be unobtrusive enough to be worth using.

Yes, I had forgotten about that. You're right...

Re:I don't see

[FauxPasIII]

> Basically: "we'll give you BK for free, but you're not to use
> it to undermine our business". Seems fair to me.

You've missed a pivotal nuance. It doesn't say you can't use bitkeeper to work on such a system; it says that if you use bitkeeper, you're not allowed to work on such a system AT ALL. That is, it prevents you from doing so even when you're not using BK.

Re:I don't see

[dbullock]

And Larry McEvoy has bent over backwards to the point of breaking to enable non-BK users to push and pull patches without using BK so that the developers can avoid that entanglement.

Re:I don't see

[Anonymous Coward]

"That doesn't work though. It's like selling a physics textbook and saying that you can only read it if you agree not to write a another physics textbook using what you learned. It's bullshit."

Key difference here. He's not SELLING it, he's GIVING it away. If I wrote a physics book, I wouldn't give it to you if you were going to write a competing one. But if you went and bought that book in the store, that's fine.

Re:I don't see

[FattMattP]

or like MS not allowing developers to write a MS Access competitor or other competing software using Visual Studio?

Not at all. The difference is that Visual Studio isn't free. You have to purchase it. If you purchase Bitkeeper then you get a different licence than the free one. You can use the one you paid for with any code, including a bitkeeper competitor or replacement.

Re:I don't see

[ComputerSlicer23]

Actually, you should read the license carefully some time. There's nothing in one of the licenses about using it to develop a competitor. However, there are two licenses (there might be only one, with two separate conditions, it's been a while since I've read it).

You could just as easily complain that you are required to allow it to "phone home" to the bitkeeper servers and post your source code for the public to see. That's a completely assine requirement if you are paying for it. However, as a non-paying customer who is being granted a "free as in beer" license don't complain too much. He could instead just issue license to Linus and Co, and make the rest of you pay for them, not giving a copy to anyone he doesn't personally know.

You might think he's a real bastard, but you got something from him for free, and now you're complaining that isn't enough? If you had paid for a license, your legal analysis is correct, you do have the right to reverse engineer the product. Larry has flat out said that in publicly posted e-mails.

Kirby

Re:I don't see

[BRSloth]

That was not my point. The original poster asked who cared about if a software was free or not. I was. If Linus or someone else doesn't care doesn't matter me. Linus can use Microsoft SourceSafe if it worked for him and he doesn't care about free (as speech) software. But I care about free software, and I will always use a Free (as speech) option instead of a closed one.

Re:I don't see

[RedWizzard]

You've missed a pivotal nuance. It doesn't say you can't use bitkeeper to work on such a system; it says that if you use bitkeeper, you're not allowed to work on such a system AT ALL. That is, it prevents you from doing so even when you're not using BK.

You're right that my wording was sloppy. The license says "we'll give you BK for free, unless you are a competitor to our business". Specifically:

Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software.

Note that this is the other way round from what you stated - it doesn't say that if you use BK you can't work on competing systesm, it says that you can't use BK under the free license if you work on competing systems.

That clause is really aimed at making sure any free software replacement isn't just a straight ripoff of BK. A commercial competitor will just pay for a commercial license. McVoy feels they have a right to protect themselves from a free software replacement specifically because they support the community via their free license, and their support for projects such as the kernel and MySQL. I don't think that is at all unreasonable. IMHO this is one of those situations where the open source community appears to believe that they are entitled to a free lunch.

Re:I don't see

[Anonymous Coward]

Wow, posting a retraction to slashdot? You must be new here.

Re:I don't see

[FauxPasIII]

> IMHO this is one of those situations where the open source community appears to believe that they are
> entitled to a free lunch.

I wouldn't characterize it that way. There are some people for whom freedom is what it's all about; a mediocre but free tool is better than a more powerful non-free tool. It is from that faction that the controversy over bitkeeper comes.

Re:I don't see

[justins]

I usually don't, butif you read the BK license, you will notice that it disallows you to work on competitors (including CVS and subversion) if you are a BK user.

Only if you're a user of the free version of BK. You have to pay for the commercial version of BK in that case. I find it very entertaining that the subversion people complain about this.

Re:I don't see

[RedWizzard]

There are some people for whom freedom is what it's all about; a mediocre but free tool is better than a more powerful non-free tool. It is from that faction that the controversy over bitkeeper comes.

It's funny that that particular faction seems to want to impose their views on Linus, rather than respecting his freedom to use whatever tools he likes.

Re:I don't see

[MrResistor]

That makes it doubly unenforcable. Not only are they on tenuous legal ground to begin with, but at no point did you actually agree to be bound by that clause.

Remember that there is no such thing as a "license to use" a copyrighted work. There are contracts which may govern usage, and software vendors are quite fond of calling them licenses, but they are still just contracts and thus need to play by the rules of contract law, like for example one must be able to read the full terms of the contract before entering into it. If what you say is indeed true, it fails the most basic test of a legally valid contract.

Other key points are negotiability and quid pro quo. Obviously, if you can't see the terms until after you're supposedly bound by them, there's no chance to negotiate. It fails quid pro quo as well, since it doesn't give you anything in return for the rights it attempts to take away. The common arguement there is that what you're getting is the right to use the software, but according to copyright law you already had that right, so long as you didn't break any other laws in obtaining your copy and getting it installed, which in this case you clearly haven't.

Re:I don't see

[IpalindromeI]

Actually, if you believe in the whole software license mumbo-jumbo, you're both wrong. As licenses are contracts, authors can legally define any terms that are valid for a normal contract. Although not the case here, he *could* have terms in the for-profit license that exclude using it on or with competing software. Heck, he could put terms that say you have to send him a pig every time you do a code checkout. If you don't agree to the terms, you don't get a license, and you can't use the software. That's it. If you want to use it, you have to agree to the terms. You have no other recourse. You don't have automatic rights to use anything ever produced simply because it exists.

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.

Re:Lesson to be learned

[Spoing]

1. 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.

While I agree this is the case, OSS is often seen as 'freeware' by most people. This in itself is dammaging far beyond the rants of a few OSS advocates.

(For the record: I'm using Linux 2.6.5 with NVidia's video drivers, have paid for Transgaming's WineX, Crossover Plugin and Office, VMWare, numerous native and ported Linux programs,. At the same time I don't have Windows running (dual boot or not) and only use VMWare for testing or running other instances of Linux or BSD.)

Re:Lesson to be learned

[Quill_28]

Not if you fall into the RMS crowd.
Which believes proprietary software is immoral pure and simple.

It seems OSS falls into two groups: pragmatic and idealogical.

And as time moves along the differences between the two grow larger.

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 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:Lesson to be learned

[Anonymous Coward]

see www.faifzilla.org - and yes, you're right.

Re:Lesson to be learned

[bwcbwc]

Will you stop it? This thread addresses your claim about the license. All you've demonstrated is that you have an axe to grind against your competition.

Re:Lesson to be learned

[maxbang]

No, you trolling fool. Proprietary software doesn't allow the public to examine and improve the code. Free software does. It's not about religion, zealotry, or any other FUD you can dream up. It's about freedom, plain and simple. Who the hell's moderating today, Bill Fscking Gates?

Re:Lesson to be learned

[aggieben]

From the original post: 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.

Absolutely. Although I would have qualified the statement with "The OSS scene suffers because some have the idea..."

Then: No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems.

I don't call that evil. I call that smart. For everyone except competitors, those who have an obsessive compulsive reaction to the unavailability of source code, and commercial software makers, the BK license is just fine.

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.

How so? You can use BK to do work on the linux kernel just like anyone else. What does that have anything to do with your work on free RCS alternatives?

Particularly given that Free alternatives to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available...

From everything I've seen or heard, nothing comes close to BK in terms of features or ease of use. I have been keeping an eye on the free alternatives, and so far I haven't seen any evidence that they can hold a candle to BK, except for the fact that I like the BSD/LGPL license better than BKs.

using BitKeeper is arguably much more destructive than it is useful.

Arguable by whom, and using what logic? The only large production OSS project that I know of that uses BK is Linux, and I think it would be quite hard to argue that BK is destructive in that case.

Don't get me wrong here; I believe in the OSS movement as much as the next guy. However, I think too many people are totally irrational in their distaste of software that doesn't meet their definition of "free". BK *is* free for those who use it for noncommercial products. My definition of free is "doesn't cost anything". There is no cost associated with BK (ok, ok, maybe a microscopic fraction of your bandwidth costs for open logging and maybe you can count the soul-sucking email registration that they require), and it serves its purpose better than any alternatives.

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:Lesson to be learned

[cduffy]

How so? You can use BK to do work on the linux kernel just like anyone else. What does that have anything to do with your work on free RCS alternatives?

I don't qualify for the zero-cost form of the BitKeeper license. Thus, I can't use it for working on the Linux kernel, or anything else.

From everything I've seen or heard, nothing comes close to BK in terms of features or ease of use. I have been keeping an eye on the free alternatives, and so far I haven't seen any evidence that they can hold a candle to BK, except for the fact that I like the BSD/LGPL license better than BKs.

Look more closely at Arch. The only features that stand out in my mind from when I used BK that Arch doesn't have are the graphical merge tools. Personally, I don't need them -- and even so, there are folks working on alternatives.

The only large production OSS project that I know of that uses BK is Linux, and I think it would be quite hard to argue that BK is destructive in that case.

As opposed to "using no revision control", sure, using BK is a huge gain. As opposed to "using non-BK Free revision control"... well, then it's a little bit easier.

There is no cost associated with BK (ok, ok, maybe a microscopic fraction of your bandwidth costs for open logging and maybe you can count the soul-sucking email registration that they require)

That, and contractually agreeing not to work on any competing revision control system. How much that cost equates to monitarily, I suppose, depends on just how interesting of a problem you consider revision control to be.

Re:Lesson to be learned

[gr8_phk]

"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."

That would be an extreme view. Most just realize that there is a significant risk in using proprietary infrastructure. Imagine BK had no bridge to CVS. BK starts charging a lot of money to use BK (monthy fee even). Great, so the kernel hackers check out the code and put it in CVS - no big deal. Next SCO comes along and makes claims about the history of the code. Oh wait, the history only goes back to the switch from bitkeeper.... Oh, but the last BK archive is still around - oh but BK went out of business so it's not accessible....

It's OK to use proprietary tools when working on your bread and butter, but they must not be able to prevent you from having full access to said bread and butter.

Are your business documents stored in MS Word format? What will you do when they switch to a subscription model and charge $$$ per month? Save them all as .rtf or .txt and import into OpenOffice.org? What if support for saving those formats is removed before the price goes up? Remember, in this scenario it's YOUR data that is not under your own control. Certain things just shouldn't be proprietary, and most people never thought about that when they allowed it to happen.

Re:Lesson to be learned

[FattMattP]

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.

Stop trolling. The entire linux kernel and all the history is available via CVS if you don't wish to use BK. That's even mentioned in the article. You did read the article, didn't you?

Re:Lesson to be learned

[cduffy]

Yes, yes, I know that there's a BK->CVS mirror. Still means that one has to use suboptimal means to submit changesets back upstream.

That said -- frankly, I regret my involvement in this thread; I was, admittedly, shooting my mouth off without cause.

Re:Lesson to be learned

[ClosedSource]

Some people believe dancing is immoral, but if they're smart they don't lecture their boss or customers about it. That's good advice for the "idealogical" OSS folks as well.

Re:Lesson to be learned

[treke]

This is only true for the kernel. Other projects ( including the kernel trees that do not work directly out of linus's repository) started by people using bitkeeper do not have that luxury, and having core developers who can only work by emailing in patches is a pain in the ass.

Re:Lesson to be learned

[justins]

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.

No, it doesn't. It prevents people only from using the free version of BitKeeper to create competing systems. How evil!

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.

Oh, well, he's not nice. That changes everything!

Re:Lesson to be learned

[oconnorcjo]

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.

How does BitKeeper hamper you? Aren't you still allowed to send regular patches like Linus got before using BitKeeper?

Yes I agree that the SCM compete clause is lame but Larry is giving the tool away for free and the obnoxious clause is not there if you are willing to pay for it. So if using bitkeeper would really improve your productivity then buy the thing and not worry what projects you can work on. If the price is too high (and I could understand that) then do things the old way and not worry about it. I only wish there was a version around a hundred dollars without the silly clauses that I could use. I agree with Linus Torvalds philosophy of "he who writes the code gets to choose the license". Bitmover owes you no favors and if you don't like it then that is fine but whining about how free(dom) a piece of software is seems churlish.

Re:Lesson to be learned

[oconnorcjo]

BK starts charging a lot of money to use BK (monthy fee even). Great, so the kernel hackers check out the code and put it in CVS - no big deal.

Oh, but the last BK archive is still around - oh but BK went out of business so it's not accessible....

Could all happen but many pieces of software still WORK even if the company goes out of bussiness!
Before BK there was nothing because Linus did not find an SCM up to the task of working the way he works and if BK flies off the handle, Linus and group are no worse off than they were before BK- which is back to nothing.

What will you do when they switch to a subscription model and charge $$$ per month? Save them all as .rtf or .txt and import into OpenOffice.org?

who says you have to upgrade? Word 97 should STILL work with those "old" documents.

your post goes off the handle with "what if the sky is falling" without taking into consideration any common sense.

Re:Lesson to be learned

[aggieben]

I don't qualify for the zero-cost form of the BitKeeper license. Thus, I can't use it for working on the Linux kernel, or anything else.

You are correct; my mistake per section 3.d of the BK license. However, I don't suspect that this applies to a large number of people.

Look more closely at Arch. The only features that stand out in my mind from when I used BK that Arch doesn't have are the graphical merge tools. Personally, I don't need them -- and even so, there are folks working on alternatives.

I also prefer to use the command-line clients, but saying "there are people working on alternatives" isn't much of an argument. Nice, easy to use graphical interfaces are a built-in feature of BK; arch cannot boast that. If I did care about GUIs, I certainly wouldn't want to install a collection of "alternatives" to get the features that I want. Also (according to what I've read), arch doesn't support in-repository file and directory copying with history support. BK does. There are a number of other minor feature differences too --- most of which go in favor of BK, not to mention Windows portability.

As opposed to "using no revision control", sure, using BK is a huge gain. As opposed to "using non-BK Free revision control"... well, then it's a little bit easier.

You're not making much sense here. The Linux project was using "non-BK Free revision control", namely CVS. BK is a huge gain over that.

That, and contractually agreeing not to work on any competing revision control system. How much that cost equates to monitarily, I suppose, depends on just how interesting of a problem you consider revision control to be.

...or on whether or not I work on competing revision control software, which I don't (as most other folks don't). I'm not trying to argue that everyone should use BK. What I am trying to argue is that BK is the system with the most robust set of features and that it should be considered a viable alternative to CVS for open-source developers. RMS notwithstanding, non-"Free" (as some would define free) licenses aren't evil. Do I wish that BK had a GPL or BSD license? Sure I do. But just because they don't doesn't mean it's unusable or "evil". The current BK license is perfectly suitable for any open-source developers to use except for those working on competing systems or those who don't have access to the internet, and I imagine that those two groups combined are pretty darn small.

Re:Lesson to be learned

[cduffy]

Consider any claims re the BK license being "evil" or morally repugnant dropped. I still don't qualify for it, and will readily argue that Arch is an appropriate tool for the job, but I'll grant that BK is a vastly better tool than CVS.

Also (according to what I've read), arch doesn't support in-repository file and directory copying with history support.

Correct -- moves and renames are supported (of course), copying isn't. There's a very good reason for this: If you merge from a pre-copy branch where a change to the original was made to a post-copy branch with two (modified) files based off the original -- where does your first change apply? Is it really the Right Thing to apply it to both? Even worse, presume you're merging from a post-copy branch back to a pre-copy branch. Now you're really stuck -- do you try to apply the changes that were made to both copies to the original? How do you decide which one?

It's a situation that introduces cases where there is no intuitively right behaviour, and thus bad news. Now, there's been discussion of coming up with a standard tag to insert in a patchlog entry saying "this file is a copy of $FOO and inherits its history, but is in and of itself a distinct file; changes to it should not be propagated back to the original" which would be understood by the web-based and graphical history browsers. It's not implemented right now, because frankly nobody much cares about that feature. Perhaps at some point someone will care, and thus it'll get implemented (in the Arch history browsers; little-to-no change would be required in Arch itself).

All that said, there hasn't been a detailed feature comparison done between Arch and BK that I recall -- most of the people who would be interested in doing so don't qualify for the free BK license and aren't particularly interested in a paid one. Arguably, BK may have more features right now. (Arguably, Arch may have a better underlying design -- but then, that really depends on whether you ask Tom or Larry). Whether BK is sufficiently superior as to be worth giving up ones' ability to look at / play with / improve / bugfix / branch the source... well, after all the claims that I'm abandoning, that I think is where we differ.

Re:Lesson to be learned

[Anonymous Coward]

A small correction:
The Linux project was using "non-BK Free revision control", namely CVS.

Linus was not using CVS prior to BitKeeper. He was not using any revision control, which is the point your parent was making.

Re:Lesson to be learned

[cduffy]

No, it doesn't. It prevents people only from using the free version of BitKeeper to create competing systems. How evil!

No, not "to create competing systems". It stops folks who create competing systems from using the free version of BitKeeper for anything at all, including work not related to their creation of competing systems. That's a pretty damn critical distinction.

Oh, well, he's not nice. That changes everything!

*shrug*. Changing terms of a zero-cost license to stop an impoverished startup from being able to use it (after you're fully aware that they've become dependent on the tool and the terms) is indeed pretty damn unnice, and that's what I understood to have happened at the time I wrote the initial post. It's that kind of "unnice" that I'd argue is sufficient to make one wish to avoid having an individual or company as a supplier or other business partner.

I since receieved a private email from LMV describing his side of the incident, which does indeed sound plausible. Hence, I'm inclined to back off a bit on the position I took here, at least until I've gotten in touch with some people close to my former management and heard something one way or another.

Re:Lesson to be learned

[cduffy]

My beef isn't with BitMover, but rather with Linus choosing to use a tool with a license that either impells folks who work with him to buy a paid license or restrict what other projects they work on. One can argue that it's rather antisocial.

Well, actually, I did have a beef with BitMover, but I've since been in communication with LMV who'se indicated that there may well be quite a bit more to the story than I (and the other engineers on-staff at the time) was aware of.

Re:Lesson to be learned

[aggieben]

Whether BK is sufficiently superior as to be worth giving up ones' ability to look at / play with / improve / bugfix / branch the source... well, after all the claims that I'm abandoning, that I think is where we differ.

I can agree with that, and indeed, this is the statement that the discussion should end with instead of creating a new form of bigotry like so many others have done. Well said.

Re:Lesson to be learned

[TheSunborn]

But then it's not the license that is evil, but the price.

Re:Lesson to be learned

[gr8_phk]

Yes, it was a "what if the sky is falling" sort of worst case thing. I actually have Word 97 at home and it works fine. What if I want to buy a MAC next time? Sure, I'm contriving very bad worst cases here and any specific scenario in very unlikely to actually happen. The point is that as long as you have total control of your data you will be able to continue no mater what actually happens. Open source goes a long way toward this. Bitkeeper provided something else that achieves the same goal - the ability to export YOUR data to an open source tool.

Claiming you can continue to use an obsolete product to maintain access to your own data isn't really a solution. It lacks common sense.

numbers...

[happyfrogcow]

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

No, it's that *everyone* was just 10x more productive after everyone stopped arguing about the whole matter.

just kidding. If BK really helps the kernel dev's, all power to them. I havn't looked at the BK website in a year or so, but one thing I think i didn't like was having to connect to the internet every couple of days if using the unregistered version. while I understand the concept, it's just a bit unsettling. it's nothing in comparison to "yearly subscriptions" for software, as seems to be the current trend for other softwares.

but that's neither here nor there. new evils do not make old evils any less evil, to be a bit extreme.

i currently have no need for BK. i'm done rambling now... mod me sideways!

Other products in the line

[galonso]

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

Re:Other products in the line

[Anonymous Coward]

And ByteKeeper, which increases productivity 8x

Re:Other products in the line

[Hektor_Troy]

I think your sig malfunctioned.

Re:Other products in the line

[Anonymous Coward]

Bitsweeper for cleaning the soot of your hard disk.
Bitreaper for killing those hard-to-kill tasks.
Bitweeper for crying about how Linux is BETTER than Windows.

And Bitheaper for keeping track of all the BK products you've bought.

Re:Other products in the line

[Suidae]

BitBleeper - Automated audio censorship
BitCheeper - Coupon managment
BitLeeper - Compression and organization
BitSteeper - For perfect digital Earl Gray

arch?

[dash2]

The arch people have been making a lot of noise recently, and I've seen more projects using it. Does arch aim to provide the features that BK has currently? How close are they? Has anyone got any experiences to share?

Re:arch?

[IamTheRealMike]

I haven't used BitKeeper (I can't as I have done a couple of trivial bugfixes in arch, duh), but arch works pretty well for me. It could be a bit faster, but I like its transparent design and responsive and friendly community.

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.

Re:arch?

[Anonymous Coward]

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.

On this subject, I've heard Wine is seriously considering GNU Arch. Anyone care to comment on this?

Re:arch?

[IamTheRealMike]

On this subject, I've heard Wine is seriously considering GNU Arch. Anyone care to comment on this?

Sure. I set up the prototype gateway. Julliard is keen, but it's a major change you know, not something you do overnight. And to be frank CVS works OK for most of the developers, it'd be primarily useful for those of us who do a lot of hacking, like the D3D developers or the CodeWeavers gang (we have to maintain multiple trees for crossover and it's a pain in the ass).

Re:arch?

[justins]

I haven't used BitKeeper (I can't as I have done a couple of trivial bugfixes in arch, duh), but arch works pretty well for me.

Sure you can. You'd just have to pay to use BitKeeper.

The horror!

Re:arch?

[justins]

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!

It's also not surprising that Linus believes a source control package (BitKeeper) that was developed specifically with his needs in mind and based on his input is much more effective than the other products available would be.

Re:arch?

[Anonymous Coward]

All the people defending the BitKeeper licensing seem to be unable to see the issue from the perspective of a developer who contributes to a free version control system as well as some other project using BK.

Consider this - you contribute to version control system X, which obviously means you think it is or has potential to be pretty good. Now, you also would like to work on project Y, which has chosen to use BK. You probably think that they could've made a better choice of version control system, but you're willing to adapt, since the project leads decided on BK...but wait, you have to pay for it, unlike those project leads who chose it.

Wouldn't that start to piss you off just a little?

C'mon, the people required to pay for using BK for contributing to a free project are those who wouldn't have chose it in the first place! Now I don't have a problem with paying for software, if I decide it's something I want to use, but I have a huge problem with paying for software that I didn't choose to use, when most other people using it (including the ones who chose to use it) don't have to pay.

Re:arch?

[rweir]

Arch provides:

* versioned file renaming (simple, but CVS doesn't)
* symlink versioning (nto essential, but handy sometimes, and something svn|cvs doesn't do)
* whole-tree changesets (commit multiple files at once)
* smarter merging. it won't try to merge changes again and again as svn or cvs would.
* (optional) distributed archives. all the arch developer's have their *own* archive and branches of the main arch source tree, to which they make their own changes. you can have everyone commit to a single archive if you prefer, too.
* signed revisions. arch can sign (with gpg) every change made to an archive, so other people can verify who actually made a change.
* archives can be made available to others via a variety of protocols, including http and ftp. yes, you can host a arch archive on cheap webspace somewhere, or in your ~/public_html/.

As far as I know, BK doesn't do the last two, but does the rest. On the other hand, BK does handle some less common patch-flows better than arch does.

Arch does need more tools around it, but the basics are there. There are 3 web-based viewer things for it,

Re:arch?

[Anonymous Coward]

I find arch to be a bit hard to use, yeah, even if I'm a just user who just wants to check out the source to a particular project.

Seeing that they use arch is enough to make me groan and go re-read the tutorials.

SVN and CVS doesn't have these problems - I'm hoping that arch can mature since it seems to be a good idea for larger projects.

Re:arch?

[justins]

C'mon, the people required to pay for using BK for contributing to a free project are those who wouldn't have chose it in the first place! Now I don't have a problem with paying for software, if I decide it's something I want to use, but I have a huge problem with paying for software that I didn't choose to use, when most other people using it (including the ones who chose to use it) don't have to pay.

When you characterize the problem like that it sounds even LESS like BK's fault. With everyone now aware of the licensing terms the solution seems simple: don't use it if it's going to cause problems.

I happen to think the license is a bit silly (though perhaps necessary for BK's survival as a company). But in any case, it seems like the solution is for people to just plan their software usage accordingly. With a BK to CVS gateway available, there's literally nobody forcing you to use the thing.

Its sounds like the right decision

[Omega1045]

Sometimes the correct decision is to make a decision and stick with it. I hate it when people go back and forth, and can't really nail down what they want to do. I admire that Linus made the decision, stuck with it despite outside pressure, and has proven to at least be much more productive than he was before. Linux has come a long way both technically and work-flow-wise in the last couple of years. It sounds like BK is doing a good job, even if it isn't FOSS.

Re:Its sounds like the right decision

[cwis42]

I hate it when people go back and forth, and can't really nail down what they want to do.

DON'T CLICK HERE.

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?

Re:New unit of measurement?

[phurley]

I hope not, because I don't want my boss coming to me to say you are only working at 0.1 Linus and you need to have at least 1.0 Linus to get a bonus.

50 patches a day - that is amazing.

Re:New unit of measurement?

[EnsilZah]

Something along the lines of:

"Program X parses 23.5 Libraries of congress per fortnight, a 1.32 Linus Productivity increase over Program Y"

Re:New unit of measurement?

[kpansky]

Yes. I believe its called LinPack. :-)

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.

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:Although there are no hard numbers

[Anonymous Coward]

the ten percent figure seems more like a number pulled out of thin air

Not necessarily. What you're missing is that it's simply a misleading statistic because of its inspecificity.

If Linus is merging 10x as many patches in half the time (because BK reduces the hassle or whatever), he's 1000% more productive at merging patches.

But another perspective [read: mine] says that if now, with the help of bitkeeper, he has 25% more time to enjoy life and write code and smell roses, then he's only 25% more productive.

So this "statistic" is meaningless without reference to its context.

Anything else than free software is not kosher

[Anonymous Coward]

Indeed.

So why the big uproar back when Linus began to use BK? Because it was just not "kosher" to use anything else than GNU tools.

Just like the war-against-drugs bigots who cannot accept that fact someone who's a succesful professional can still smoke a joint now and then (a Finnish MP just ruined her career by admitting that she smoked pot a year ago), the free software crowd bigots feel that the reality must be made to fit the theory instead. There must not be better, more productive software than free software.

Re:Anything else than free software is not kosher

[phoenix.bam!]

Some people here must watch King of the Hill. Hank (the main character) Is a dedicated/obsessed propane salesman. He has propane everything. He lives propane.
One night he goes to his bosses house for dinner (the owner of the propane store) and the boss has an electric stove. Linus is a lot like Hanks boss. He uses what works for him, because it works, but because of some unnatural connection to a belief.

Why is it so productive

[stecoop]

I have evaluated bitkeeper and it is an ok in terms of configuration management. Most of you are probably not familiar with SCM but what it does is allow you to have branches and multiple configurations at the same time with no threat of destroying other work. Most good tools allow you to visually see structures of files with visual branching history. CVS is a good file management tool but doesn't handle the SCM side very well (Linus mentioned in the article refusing to use CVS). I have used various SCM tools most are very good and if you don't complain but try to understand the process, you'll find yourself 10x more productive (I said I was 10x more productive but no one believed me) - I'm just finally glade someone can actually measure the success of a good SCM product and people may believe others when they say that a good SCM tool will make them much more productive; instead of looking like a dog when you blow a high pitch whistle.

Re:Why is it so productive

[Anonymous Coward]

" Most of you are probably not familiar with SCM ... " - you're going for a flamebait mod?

Bitkeeper is fun

[Anonymous Coward]

I like Bitkeeper. It is the best. I think that everyone should use Bitkeeper.

What is the "natural" growth rate?

[file-exists-p]

What would be interesting is the volume per year since 1993, so that we could see if the growth rate has changed since BK. If I remember well, the volume has always increased a lot.

--
Go Debian!

support monotone

[trance9]

The monotone project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.

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.

Re:10x - I misread it as 10%!

[jjhlk]

Maybe 10x was some hyperbole?

Re:10x - I misread it as 10%!

[Anonymous Coward]

Too lame.

You don't even know that linux is *maintaining* the kernel - not doing programming itself.

All you need is to troll and put idiotic sig insulting MS or BG and will be modded insightful now on slashdot by the brain damaged moderatror of the same kind.

Phew.

Sanity check

[Anonymous Coward]

The only way Linus could be ten times more product on account of Bitkeeper is if he spent NINE TIMES as much time fighting with tar and patch as he did reviewing code.

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.

10x more productive my ass.

[Eminor]

If it is true that bitkeeper makes him ten times more productive, then he must have spent more 90% of his time in the tool he used previously (was it RCS?).

Re:10x more productive my ass.

[Vintermann]

No, it wasn't RCS, it was nothing. He just used diff and patch manually.

That makes the productivity gain a lot less impressive.

Re:10x more productive my ass.

[Eminor]

No, it wasn't RCS, it was nothing. He just used diff and patch manually.

Well in that case, using ANY tool would have increased his productivity. So the increase in productivity is not neccessarily because Bitkeeper is better than CVS or RCS.

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:Emphasis on 2x, NOT 10x

[Anonymous Coward]

the 10x productivity number mentioned in the article was only an anecdotal claim; Larry McVoy claimed 2x
You fool, it's binary

Distributed revision control is Good Stuff(tm)

[cduffy]

That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch is another distributed revision control system, and Free Software to boot.

"BitKeeper makes Linus 10x more productive" might be generalizable to "distributed revision control makes Linus 10x more productive" -- pity we don't have more sample data yet. :)

I don't see-Freedom hurts.

[Anonymous Coward]

"Who cares if it's Free or not? It gets the job done better, and in the end that's what counts."

Is it? Is it really? Are we really that selfish a species, that if we get immediate gratification it's all good? We've seen this with the Nvidia drivers. We've seen this with Debian and Red hat decisions. And now we seen this with BK. Would anyone care to point out why exactly we all embarked on this journey and elected to put it under of all things a FREE license? Obviously this whole FREE thing isn't important, if we're going to so casually discard it when things get difficult.

Re:I don't see-Freedom hurts.

[Power Everywhere]

What's more important? The journey or the destination? Philosophically, the journey. But in the world of making money, the destination is the focus. We need working products. Your principles will go out the door each and every time in favor of greenbacks.

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.

Re:Since when did Linus...

[dokebi]

Since when did Linus need to justify himself to the Slashdot crowd?

I think you just answered that yourself

Re:Since when did Linus...

[Anonymous Coward]

...Linus isn't a Linux zealot
Ah, tnx, now I know what lilo stands for...

Re:Since when did Linus...

[Just Some Guy]

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.

And that's perfectly OK, for him. He is free to use whatever tools he wants. However, that doesn't mean that we can't be disappointed that he chose a closed tool with a nasty license, especially since his decision makes for a de-facto Linux development system that is unacceptable to many of us.

Linus is a great guy with a lot of talent, but that doesn't qualify him for sainthood. I think that going with BK was a mistake, and it is my right to believe so regardless of how much I otherwise respect him.

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?

Re:Success due to Bitkeeper?

[cduffy]

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?

BitKeeper has distributed revision control and history-sensitive merge support. Of the alternatives you mention, Arch is the only one which is comparable.

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

Some, largely because they have a great deal of process set up around beating CVS into submission. It's much more work and dicipline than most teams are willing to go through, though.

Re:Success due to Bitkeeper?

[Anonymous Coward]

FreeBSD is a larger project than both linux and gcc. They use CVS.

Re:Success due to Bitkeeper?

[Anonymous Coward]

Yeah except arch has a crappy interface. *dreaming of a decent Free version control system*.

Re:Success due to Bitkeeper?

[aled]

SVK supposedly has distributed revision control and different flavours of merging. SVK uses Subversion as a versioned filesystem.

Re:Success due to Bitkeeper?

[Anonymous Coward]

CVS is decent.

Re:Success due to Bitkeeper?

[tzanger]

What about Darcs? We're using it for the Vexi project and it seems to be VERY good.

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:Success due to Bitkeeper?

[cduffy]

Yup, SVK does have that -- they even adopted Arch's star merge algorithm.

That said, I'm not sure that the Subversion-as-backend thing makes sense, as opposed to just using Arch (with its dumb server model, cryptographically signed changesets, append-only repository format, etc).

Re:Success due to Bitkeeper?

[aled]

For me is not conceptually different as using a DB as the data repository for a web app. It should be transparent to the user.

Re:Success due to Bitkeeper?

[cduffy]

One of the complaints I've heard from ex-SVN users that they've on occasion needed to rebuild their datastore. One of the issues I've seen with CVS users running CSCVS is corruptions occuring in the ,v files (presumably while they're rewritten to add new data) preventing access to old history (often *very* old history; since these parts further down the file don't get accessed much, it's rare that their corruption is detected until something like cscvs is used). One of the nice things about being an Arch user is being able to take advantage of the nature of its write-once datastore format for backup, integrity-checking, enhancing OS-level security, and like purposes.

Sure, the backend doesn't matter if the abstractions don't leak and you don't want to take advantage of any of the side-effects that one (particularly nice) storage format may have over another. When one gets sufficiently far into the "advanced user" category, though, or encounters bugginess inside the code that's hidden behind the abstractions -- well, then, whatever's sitting behind the curtain starts to make a difference.

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.

Re:Success due to Bitkeeper?

[KewlPC]

Well, yes, CVS is obviously better than SCCS and raw RCS.

But some things about it really suck. Like individual versioning on files, thanks to its lack of atomic commits. Or the fact that it has a hard time dealing with file and directory renaming and changes to the project's directory layout.

I recommend Subversion to anyone looking for an open-source source code control system. It does atomic commits, so if one part of the check in fails, the whole thing is aborted, to make sure that partial check ins can't happen (let's say changes made to File A depend on changes made to File B; what would happen if File A gets checked in OK, but File B doesn't? How fast can you get the conflicts in File B fixed and checked in?). It also handles file and directory renames in a civilized manner, so that if your project's source code grows beyond your initial layout you can fix it without a lot of headaches (at least, not any headaches stemming from Subversion).

As to your remarks about how much easier CVS is, I'd like to remind you that Subversion is basically supposed to be "a better CVS" (and does it quite well, IMHO), and as such the commands are intentionally very similar to CVS. After first installing Subversion, and having never used it before, I was up and running in less than 5 minutes.

Re:Success due to Bitkeeper?

[cduffy]

I'll agree that good version control is about more than counting check boxes. That said, the features I'm mentioning are ones that are genuinely valid. Distributed repository support makes it dramatically easier for arbitrary third parties to branch the code (either to maintain revision-controlled private branches with changes local to their installation, to do work on new features for upstream inclusion, or for whatever other purpose) and also makes it easier for maintainers to control the process of reviewing and merging in those 3rd-party patches (hence BK making Linus's job easier). Further, a good distributed revision control system does all this without the security implications of giving Joe Yahoo commit access to your CVS server. History-sensitive merge support means you can maintain multiple branches, apply some of the same patches to both, and merge them together without generating loads of spurious conflicts (sufficiently advanced CVS users will know how much of a headache this is). Dumb server support means that I can open access to my revision control repository to the world (or my intranet) without anything more than a patch of webspace available -- no more depending on a CVS host such as SourceForge. Changeset-level granularity eliminates issues where a developer makes two dependent changes and then someone else checks out only one of those changes (doing a partial-tree update or somesuch) and thinks the tree's broken; permits sets of dependent changes to be cherry-picked between branches (so that I can take Feature A -- which may involve changing 3 files -- from Branch Foo and merge it into Branch Bar -- in one atomic step), makes for better automatic changelog generation, and is otherwise damn useful in practice. And then there's stuff like supporting moves and renames (and correctly merging between a branch where a more or rename has happened and another where it hasn't) -- things folks would expect any decent SCM to do that CVS just doesn't.

What I'm saying here is that the features I'm mentioning are the things that I make use of in real-world practice to the point where I'd be hurting to be without them again. I'm not listing the piddly bits like automatic changelog generation, but rather real-world functionality that makes my life easier as a Free Software developer. (If I were talking about my other life as a commercial software developer, I'd be talking about arch-pqm validating that the test suite passes before permitting a checkin to go through to the main repository, or how Arch makes it easy to use different branches for organizational purposes like tracking down to the individual changeset what code the QA department has reviewed and approved).

Re SourceForge not switching, I've actually talked with them about it before: No matter how theoretically scalable an alternate SCM is, they're not going to switch until someone on the same scale of operations as themselves is already using it succesfully. And on the topic of usability: Arch and BK are certainly not as easy to learn as CVS. SVN, I'll argue, is OTOH every bit as easy as CVS to use -- just much harder to administer. (IMNSHO, the post-learning-curve benefits of distributed version control are more than sufficient to justify the up-front cost; however, if your goals are different, SVN is not necessarily a bad choice).

Yes, CVS may "get the job done" -- but then, your definition of "the job" has been shaped by your use of that tool and others like it. Modern revision control systems do a much bigger job, and do it much better -- in a way that makes life easier not only for the core development team, but also for 3rd parties who want to contribute or maintain their own trees.

Re:Success due to Bitkeeper?

[HuguesT]

I pretty much agree with everything you said, thanks for the cogent response.

Yes there are better tools than CVS both proprietary and free, at least on paper, however the really enormous savings that SCMs deliver for most developers are already available in CVS. These are: versionning (and hence backup from mistakes), collaborative environment with conflict resolution and remote access. CVS does not have nice branching or even nice renaming, which are its main drawbacks. The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

Of course if I could do quick and easy renaming in CVS I would use the feature, instead I only do a renaming when I really need to. Same with branching. I've actually done branching with CVS and it does hurt a bit, but it is possible to maintain concurrent versions of the same software and backporting of patches is possible. Again if I could do that more easily in CVS I would do branching more often, whereas now I only do it when I really need to.

However I don't have the impression that any of the above is impacting productivity *that much*. Being cautious and conservative sometime actually helps. On the other hand I vividly remember the time before CVS as compared to now. It is like night and day.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

Re:Success due to Bitkeeper?

[cduffy]

The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.

But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.

An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.

Re:Success due to Bitkeeper?

[Eivind Eklund]

I'll just give a quick comment on the "recover from error"-issue: I don't see recovering from error as a particularly important side of a version control system.

In practice, I find the history, the ability to see what changes I have in the active space easily, and the ability to manage several spaces (including merge from a moving baseline) much much more important. I hardly ever need to recover from error that are committed - but I use the other features all the time.

I haven't tried using distributed branching yet, but I've seen a large number of places where it would apply. When it gets done right, I think it will revolutionize free software development.

Eivind.

Re:Success due to Bitkeeper?

[HuguesT]

OK, thanks for the pointers, I'll certainly take a look.

And for the rest of us..

[Anonymous Coward]

And for the rest of us who enjoy using free software, there's the Subversion (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.

Re:And for the rest of us..

[William Tanksley]

SVN also compares poorly to BitKeeper and its kin. The problem is that SVN, like CVS, needs to have a configured central repository; BK doesn't.

There are some good free software alternatives; the only one I know of that works like BitKeeper is darcs. (Arch is very close, but it still requires you to configure a central archive.)

-Billy

Re:And for the rest of us..

[Cochonou]

I'm fairly sure anybody who's tried SVN would never want to go back to CVS.

There are great CVS clients available that may ease your pain, though.
TortoiseCVS allows the user to commit files just by right-clicking on them. It's a great way to incite people to put their work under version control when they don't want to be bothered with learning and using more complicated software.
SmartCVS allows you to do the more complex CVS operations (pinning a revision, locking a file, etc...) quite easily. And it has a great interface, too.

Re:And for the rest of us..

[Anonymous Coward]

One thing I have been looking for, for ages now, is a way to PGP sign commits.

It would be MUCH easier to verify if the tree was "hacked" into using this method.

Savannah claimed they were going to make CVS handle it, after there break in last year. It never happened.

People talked about making subversions handle it, never happened.

This article states BK _can_ handle it, I am going to look into using it.

I founded and work on a large open source project. Currently, our CVS tree is 400+ MB. Its really annoying when Savannah goes down, we are screawed for a few days until they get things back up and running. It doesn't happen offten, but always pops up at the wrong times.

Eitherway, based on what I read in the article, I am sold on BK. But, there are a few very big problems with changing over to it.

a) Price. Unless someone works over the cash, or they have a free version for open source projects, it won't happen.
b) I don't know if everyone will appericate migrating over to it. Yes, they do have a CVS gateway, which would be nice.
c) Been using CVS for this project for close to 5 years now, I don't know if all the developers are going to like a change :P

Re:And for the rest of us..

[tsmoke]

Actually, NO ARCH DOES NOT REQUIRE A CENTRAL ARCHIVE AT ALL.

that's displays a rather fundamental misunderstanding of how arch works, and fairly amusing too. usually, people complain that arch lacks a central server, and that's why it should be avoided.

Re:And for the rest of us..

[William Tanksley]

No, actually it's the result of a thorough understanding of arch as a result of comparing it with a LOT of other SCM systems. But you can get the same result as me by reading the arch manual, which discusses creating a new archive. Note that creating a new archive is distinct from creating a new workspace; a workspace has to be associated with an archive.

In other systems, including BitKeeper and darcs, creating a new workspace is the same thing as creating a new archive. They are truly distributed; there's no need to tell it which archive it'll be using, because the answer is "the one I'm working in right now". Every workspace is its own archive, every archive is its own workspace.

The difference is astounding -- it's like the difference between CVS and arch. And yes, I was an arch fan, I even converted someone else to arch. He uses darcs now, just like myself.

-Billy

10X More? Must be in Metric.

[PetoskeyGuy]

That's only 6.3X more productive in Imperial Productivity Units.

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.

Subversion Anyone?

[cornice]

I remember a discussion about this a while back and a number of people saying that Subversion should be used but isn't yet ready. I'm certainly ignorant of the nuances of version control systems. Does anyone have an update on how Subversion compares to Bitkeeper especially as it might handle kernel development?

Re:Subversion Anyone?

[Eric Smith]

Subversion works quite well, but it uses the central repository model, so it doesn't do the same things BitKeeper does. That said, Subversion is an excellent replacement for CVS. It is almost a drop in replacement, and has file rename/move versioning and atomic commits. It doesn't yet automate repeated merges, but the use of properties makes it easier to track the necessary information. And tagging and branching are almost instantaneous, since they only have to add a small amount of metadata rather that touching every file in the repository.

For a project as large/distributed as Linux, BitKeeper may well be the right thing. For a smaller project where a single central repository is acceptable, Subversion is great. I've converted all my projects from CVS to Subversion, and am pushing my employer to switch as well.

Re:Subversion Anyone?

[pHDNgell]

Subversion is centralized.

With arch, for example, I've branched projects on my laptop (with my standard replicates to a webdav server and a plain http server), made whatever changes I want in a few commits, tracked more changes from head-of-line, and eventually got my changes brought into the original project (doing a merge from my tree).

I.e. anyone, anywhere can branch the tree for any reason and track other people's changes. Additionally, you can track changes from more than one tree at a time. For example, you can track head-of-line, some guy's branch that has feature you want, another guy's branch with another feature, and a third guy's branch with a bug fix. More importantly, it's easy enough that people are actually likely to try that.

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:Testing Expertise

[The Bungi]

Perhaps the folks that run Slashdot could offer some advice on this topic.

Re:10X More? Must be in Metric.

[red floyd]

Yeah, but what about Canadian units?

Countless times, huh?

[Anonymous Coward]

And, I've been burned too many times to count when the company that makes the software changes focus or goes out of business.

Please, detail these closed-source disasters for us. They were working and all of a sudden one day, the software you had paid for quit working? Like when they went out of business, or changed focus? They used a remote-control device in the software to make it stop working?

I keep hearing these justifications for why OSS is allegedly better, but I've yet to see any evidence that this situation has ever actually happened.

Since there were "too many times to count," how about just a few? Did you learn from these experiences, or did you just keep repeating them with shoddy companies? Have you gotten better at picking vendors whose software doesn't self-destruct when they go out of business, or change focus?

Inquiring minds want to know.

Re:Countless times, huh?

[Anonymous Coward]

Did you learn from these experiences, or did you just keep repeating them with shoddy companies?

The worst case that hit us hard was when this little company decided that it wouden't support, or even sell, this piece of software that was required to run a manufactuing plant.

The little compnay was Microsoft and the software was MS-DOS.

Re:Countless times, huh?

[Anonymous Coward]

You are a moron and probably cost your company tons of money with your ignorance and stupidity.

First, Windows 98 Volume Licence contains downgrade rights to MS-DOS. Read it and weep.

Second, IBM PC DOS, same damn thing, different box, is still sold and supported.

Re:Countless times, huh?

[Anonymous Coward]

When apple bought NeXT and killed OPENSTEP Enterprise (Cocoa for Windows, if you prefer).

Boom. No more ways to legally get the product which you used to develop your application and that is needed to execute at you customers.

Cool, isn't it ?

Re:Countless times, huh?

[Fred Or Alive]

I though PC DOS forked from MS DOS at some point, after IBM and Microsoft's falling out. Although it is compatible (and also Y2K fixed and stuff that MS DOS doesn't do), but it isn't the same darn thing, at least not anymore.

Re:Countless times, huh?

[Anonymous Coward]

BUT THEY ARESNT' TEH OPAN SORES!!1!!1!

Pretty much the empty excuses that I expected. I'd feel really comfortable having people who can't figure out a workaround for sales of MS-DOS digging into a custom Linux kernel to keep a production line humming along.

Re:Countless times, huh?

[Anonymous Coward]

I should have made a special exception for Apple because they are the kings of killing off year or two old OSes, or crippling them, or marginally tweaking the API so that you get locked out of new applications.

It would have been really simple if you just paid your $129 annual subscription and pre-ordered OS-X.5 Tabby.

Re:Countless times, huh?

[dustmite]

Please, detail these closed-source disasters for us.

Hmm .... well, I can't seem to get Puyo Puyo to run on Windows XP!

Seriously though, with relation to BitKeeper, if you RTA he mentions that there is a "BK2CVS gateway", which will automatically export your BK repository (with history) to a CVS database nightly. So if BK disappears, NO PROBLEM. That also ensures that they (BK) have no meaningful incentive to pull a bait-n-switch and hold your data to ransom.

MS Scaremongering?

[blorg]

*I may be wrong*, but I presume that is to prevent people from producing pass-through programs that use Access as a component and just duplicate Access functionality. As a Studio developer (Enterprise edition only, IIRC?) you can use Access as a component in your compiled software without the end-user having to buy an Access licence. So this is to prevent someone packaging up the Access engine in such a product as a new piece of database software, not preventing you from writing a new database from scratch using Visual Studio.

Re:You know...

[Anonymous Coward]

Nuh-uh. No he didn't!

Very funny, where's the REAL Larry McVoy

[Anonymous Coward]

I've read the BK flames, and what have you done
with the REAL Mr. McVoy?

Here's the rate of change for 2.6

[kroah]

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.

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.

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:Linus - Practical

[Anonymous Coward]

No, leprotard, because those GNU tools you mentioned weren't idealistic and unique. They were intended to be good editors, compilers and shells.

The Hurd, however, is totally idealistic in its approach - see the docs on gnu.org. It's meant to take power away from the admin and promote cooperation and sharing.

That's all fine, but it's too idealistic to be practical now. Conversely, Linux is practical and pragmatic, and works today.

Now do you understand?

Yes, BK Makes an Enormous Difference

[Anonymous Coward]

Unless you've used BK you really have no idea just how much more powerful it is than everything else. And yes, the p2p model that BK seemingly employs is a big part of it, but only a part of it.
BK has beautiful diff and merge tools. It has incredible file history tools. But most importantly, it's best at doing it's job: accurate revision control while staying near completely out of your face. That's why we used it at SOMA, and that's why I really wish we used it at Alias. Of course, all this really just scratches the surface.
Try it. Check in code. Share it with others. Propogate changes between people. Imagine sharing a development branch served off your desktop without doing any setup other than typing "bkd". Imaging 10 people pushing and pulling code between themselves and the server. Now you understand BK. It's not that source is stored or even the toolset alone. It's the fact that umpteen developers can push and pull between themselves and/or the server and accurately propogate changes all around. Combine that with the tools Larry and crew have written, and now you'll understand why it's better.
And to be fair, I work in the field and I've used SourceSafe, CVS/RCS, BitKeeper, Perforce, ClearCase, arch, Subversion, Accurev, and others. BK is easily the best of them... by far!

--ck

Re:Yes, BK Makes an Enormous Difference

[IgnoramusMaximus]

...BK is easily the best of them...

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?

Re:Yes, BK Makes an Enormous Difference

[georgn]

Knowing both Larry and the poster about whom you're
whining, I can assure you that they are both
_very_ different people living and working over
3000 miles apart.

Re:Yes, BK Makes an Enormous Difference

[William Tanksley]

Can you compare it to darcs? (I can't, because I've done some work on darcs and am not willing to pay money just to do a simple comparison.) I ask because the way you describe BitKeeper sounds pretty much like darcs.

(Except for the graphical utilities -- I'm told that darcs has an experimental graphical merge, but that's all right now.)

-Billy

Re:Yes, BK Makes an Enormous Difference

[Anonymous Coward]

Let me guess. You are larry's mother and ck is larry's brother.

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.

Slashdot Sigs

[Dareth]

Which one would be best to archive all my Slashdot sigs. I can't just look at my old posts and copy them back cause they all change!!

We have the technology ...

[icedcool]

We have the capability to make the world's first Bionic man. Stev... Linus Torvalds will be that man. Better than he was before.
Better . . . stronger . . . faster.
*Show Linus typing while hearing that whooshing sound*
I could see it.

Re:The right numbering system for the job

[Anonymous Coward]

I get it, "10x" is in binary! They're just saying he's twice as productive.

[NT] bk's syntax is no prize pig, either

[Luyseyal]

Where do the free competitors stand now?

[The Pim]

Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).

Linus is working for OSDN now...

[lordmage]

thus the improvement.

Come now, did he NOT leave transmeta and go to OSDN and now has a lot more TIME for kernel work? Regardless of the tool.. more time = more production.

BK may be better but the tool is only as good as the operator.

You want fries with that?

[Aardpig]

...Linus has been 10x more productive with BK.

Well, MacDonalds are not going to be happy about this news, are they now?

Re:You want fries with that?

[Tumbleweed]

Why would McDonalds care about Linus wearing British Knights shoes?

Arch CLI usability

[cduffy]

The CLI has gotten a lot better since 1.0; there are a lot of places where you can use 1 command now to do things that used to take 3.

Anyhow, that's a learning curve issue, not a post-learning-stage usage issue. The post-curve functionality is, IMNSHO, more than enough to justify scaling the curve.

KOTH: one of the two shows worth owning a TV for

[Anonymous Coward]

The other is The Simpsons.

Darcs

[cduffy]

*shrug*. I've seen folks describing Darcs as a simpler, easier-to-use Arch with worse performance characteristics, but haven't used it myself.

One plus in Arch's favor is a larger userbase (and thus the availability of tools like arch-pqm, aba, all the miscellany in Arch-contrib, and so forth). All that said, though, I haven't used Darcs, so anything I say about it is pretty much just hearsay.

10x Productivity increase??

[edxwelch]

If I were to switch to Bitkeeper it would be more like 100x, mainly due to the fact that we use PVCS Dimensions at work :(

feh. just submit one line or one word patches:)

[Anonymous Coward]

What can I say, I'm an optimizer..

sadly, your numbers are bogus

[Albert Cahalan]

Many kernel developers send their changes in via
the top few developers. This causes changes to get
credited to the wrong person.

So there are many more than 916 different developers,
and the top 5 developers aren't as active as you
thought they were.

Re:sadly, your numbers are bogus

[kroah]

Not true, a number of the main kernel developers use bitkeeper to show who the original developer of the patch was. I know I do, as does Dave, Jeff, and a few others.

Some notible exceptions are Andrew Morton and Rusty's kernel patch monkey. So for people who sent in patches through them, yes you are correct. But the original patch author can easily be determined by looking at the changelogs for those submitted patches. It also would not be that hard for someone to go through and properly fish out the "real" numbers if they so wanted.

But the rate of change is the same, either way.

Chicken and the egg?

[Skiron]

So does BK keep BK keep BK... I bet they use OS to manage it. :)

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: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:What went wrong?

[Anonymous Coward]

Cathedrals are better than bazaars, and giving stuff away for free doesn't pay the bills. Duh.

Re:What went wrong?

[Trogre]

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.

True, but you'd think the same would apply to an operating system kernel.

I do take your point about artists, level designers etc. That's why I believe FOSS philosophies can and in fact need to extend far beyond the realm of computer programmers. If you could co-ordinate a group of artists to develop a work solely for the love of it there's no telling what they'd accomplish. If they could agree on anything, that is :)

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.

rabidzealot.com.....

[zogger]

...doesn't exist, nor dot org, I just checked, it sounded so cool.

this is just wrong. it is just too good of a name to go unused, but I'm broke right now.

Will whomever gets it please give me an email addy from there? Or just start a web based email there? It's certainly got more zing that @google or @hotmail or @yahoo or @my_isp.com

Re:rabidzealot.com.....

[kashani]

I just registered it. Shoot me an email of the address you want and I'll get it setup for you this week.

kashani

Re:rabidzealot.com.....

[zogger]

way cool! So, what ya gonna do with it then?

I'll send ya off an email soonest,today or tomorrow, got storms coming here, might have to log off soon, don't know.

Re:rabidzealot.com.....

[kashani]

I've been thinking about doing some writting on how to be a system admin. More of why we do things than a how to set your system up sort of thing. Doing it under rabidzealot would be funny as I could expound on why I hate all software, hardware, methods, other system admins, etc.

Either that or I could move all my Gentoo how-to's over. :-)

kashani

Difference between movements often misunderstood.

[jbn-o]

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.

This is not the open source movement's message. Open source is far more compatible with business interests, in fact the whole movement was defined to be more friendly to businesses. The reason they push aside software freedom is because the founders of the open source movement believed that "free software" made business leaders feel uncomfortable. So the open source movement founders not only dropped the phrase "free software", they also adopted a similar but more lax set of rules by which they would judge licenses. As a result, licenses that don't qualify as "free software" can (and some do) qualify as "open source". One is wise to be careful when evaluating licenses approved by the Open Source Initiative that they don't adversely affect your ability to continue developing your own software (such as having to choose between defending patents and licensing software, like the early APSLs did; or making embrace-and-extend possible, because the OSI has no criteria that is comparable to copyleft).

The charge of being a "religion" is nonsense, even when it is lobbed against the free software movement. It shows a lack of appreciation for what religions are and what the free software movement has been working on achieving since 1984. Nobody in the free software movement frames their argument in religious terms, in fact I've seen RMS take pains to avoid such reference. Their argument is based on what kind of society we want to live in -- one that caters to business interests or one where we and businesses can work as equals to give us all the freedom to make our computers do what we want them to do. I recommend you read the essay from the FSF that elaborates on the differences between the two movements and then reconsider the arguments the two movements are making.

Will Linus become a patch robot one day...?

[ReyTFox]

The article's estimate is 50 patches a day. If kernel development continued at an accelerating rate, it might someday happen that he gets 100, 200, even 300 patches per day.

I can't imagine him having anything resembling a sane life if that happens :P He'd probably have to start delegating the work somehow...

self-improvement

[kwoff]

I personally don't care what they use, but it seems to me that for judging the improved productivity it would be important to consider that the kernel team itself became better over time and also that the team grew and more features are requested as Linux becomes more popular.

Re: Large CVS projects

[Knuckles]

But FreeBSD is a cathedral, no bazaar. And IIRC the main argument against using CVS for Linux was that it is not up to the task in the highly distributed and diconnected environment which is Linux development

Re: Large CVS projects

[Eivind Eklund]

I'm a FreeBSD developer/committer (and has been for 7 years).

We use CVS for the primary repository, and Perforce for an extra repository with a gazillion branches where a lot of the larger projects are done.

The primary reasons we use CVS is (A) habit (it was the only relevant alternative when we started), and (B) The distribution architecture we have for it (cvsup).

Given that we use cvsup as one of our primary methods of distributing continous updates, we would have to re-train about a million users (guesstimate). We also have thousands of developers that are familiar with CVS, these would also need re-training.

Those of us that has looked carefully at the version control/configuration management issues believe we are taking a continous and fairly high cost from CVS. We are probably going to do the switch at some point, but before we do, the relevant infrastructure needs to be in place (distribution of repository copies and checkout a la cvsup is probably the most important), and we should get something with all of the features we need, so we don't have to do one more switch.

The most important that we presently lack are cheap branching, distributed branching (being able to create a branch that only exists in a mirrored repository), and idempotent merges (the same change can be merged through several branches and only enter the system once). Tracking directory metadata and helping with renames etc would be nice, but isn't that important for FreeBSD. (I believe this to be more important than the other shortcomings of CVS for smaller projects, BTW).

A final interesting thought: I believe that the sharp distinction between NetBSD, OpenBSD, FreeBSD, and DragonflyBSD is a result of the lack of distributed branching and easy merging. The personality issues and different goals are there, of course, but I believe these would have been "overrun" with the ability to easily move changes back and forth. The single issue that has resulted in the "deep" splits is the effort involved in moving changes.

Eivind.