No More BitKeeper Linux 958
An anonymous reader writes "KernelTrap has a lengthy article detailing BitMover's recent decision to drop support for its free version of BitKeeper. Linus Torvalds began using BitKeeper back in February of 2002, a decision that has resulted in frequent flamefests, but also in increased kernel development productivity. Evidently the recent decision was due to OSDL's decision to keep paying a developer who was working on reverse engineering BitKeeper... What tool Linus will move to is still being determined."
Oh great... (Score:1, Informative)
Mirror of article (Score:1, Informative)
Re:Oh great... (Score:4, Informative)
Classic Heroin Marketing (Score:5, Informative)
Get 'em hooked on the gimmes, then ream 'em on the return.
Let's hope that the impending avalanche of negativity will influence BitKeeper to reconsider at least a token giveback to the Linux community.
KDE is moving to subversion (Score:2, Informative)
Bazaar-NG might step in? (Score:5, Informative)
Re:Oh great... (Score:2, Informative)
Re:Too Obvious Answer (Score:3, Informative)
Have you ever used bitkeeper? It is highly distributed in the way it works.
Subversion on the other hand is very much like cvs (except it doesn't suck)
What tool, you ask? (Score:5, Informative)
Re:Take aim at foot, Fire! (Score:2, Informative)
They can either purchase licenses on their own, or find new employment.
Re:Take aim at foot, Fire! (Score:3, Informative)
Hopefully this will encourage development of a free (as in speech) alternative to BitKeeper.
Re:Freedom matters (Score:5, Informative)
Linus was dropping important patches - cos his versioning was done from a mail spool.
Larry was writing Bitkeeper and had been pushing this for a couple years. Finally Linus gave in - saying there was a problem - and agreed to use a vcs that didn't get in his way. Then Larry made his pitch...
Re:and thus, R.Stallman was right after all (Score:2, Informative)
When you are provided a powerful tool for no cost under the condition that you don't fund the creation of a competing tool based on that technology you are not at the whim of someone's goodwill. When they approached OSDL and said you have a employee doing this (reverse engineering our technology), please have them stop and OSDL says it's not our problem.
Its not like they all of the sudden started says hey OSDL/Linus you now need to start paying for this since you like it. They said we are giving you free access to our tool but you have staff that are now striking at our revenue line, which happens to be how we fund this tool you like. Please have them stop and we will continue to provide this tool.
When you still thumb your nose at the company who has employees to support and revenue to generate you are only putting them under the gun.
So based on this evidence you can see this isn't a RS versus Linus issue versus a OSDL taking responsibility issue. If OSDL came back to the table and said Ok, mea culpa, we will make this right then the problem wouldn't be there.
Make Sense?
Re:What tool to move to? (Score:5, Informative)
Re:I cant wait (Score:5, Informative)
Hi Bruce,
You want to keep an eye on Monotone [venge.net]. Recently, it has gone through a redesign specifically aimed at making it changeset-oriented, with a view to replacing BitKeeper. It has a ways to go, but the project is active and the work is professional. Arch and Subversion are both worthy and usable systems right now, and many projects are already working happily with one or the other.
Regards,
Daniel
Re:Too Obvious Answer (Score:3, Informative)
ps - now that I look at it again, it appears that svk has grown beyond a subversion add-on and supports other repository architectures.
Re:Linus Shminus (Score:2, Informative)
A kernel developer who uses BK can deliver patches to kernel using BK. These patches can be examined in BK, and applied to the main kernel tree with BK. In other words, the whole patch and change management process can happen with BK, and this makes Linus' job a lot easier. A kernel developer who uses BK to provide his change to Linus will have his change incorporated much faster than someone who doesn't use BK.
Re:Linus Shminus (Score:1, Informative)
As this is the version control system for the kernel tree the obvious answer to your question is, no. They will have to use the version control system that is used, that is essentially, the one Linus using, that's why there is so much talk about this issue.
And you were right, you first post probably should have been modded troll, or at least uninformed, funny to see the
Re:Too Obvious Answer (Score:3, Informative)
> choice is subversion:)
This would rather surprise me because svn doesn't support distributed repositories and branches which are necessary to maintain the different kernel branches.
Linus' side of the story (Score:5, Informative)
Re:I cant wait (Score:5, Informative)
Well, let me point out Andrew Morton is the guy who does most of the heavy lifting on the kernel these days, and he uses his own scripts [nongnu.org].
Re:Too Obvious Answer (Score:2, Informative)
A million people have probably told you this already, but...
I'm a big fan of Subversion myself, but it isn't at all appropriate for kernel development due to the distributed nature of kernel development. Subversion is a very centralized version control system.
Re:Freedom matters (Score:4, Informative)
But that is, of course, not what seems to have happened. What happened, accordingto the write up, is that someone who had at some point been been payed some moeny by OSDN was, completely unrelatedly, working on a possibly competitive product. No one is claiming this contractor was using BK in his work on that product.
basicly BM's interpretation of the licence is that no one who has any connection, however tenuous, with an organisation using the free BK can work on a version control system. This looks to me to be a clause specifically created to be impossible for the licencee to police, and so to provide a way for BM to remove the licence on a whim.
Re:Oh great... (Score:5, Informative)
This will soon prove (or disprove) the viability of subversion for very large projects. Linux kernel development model is significantly different though, so what works for KDE might not work for the kernel.
Re:Linus' side of the story (Score:3, Informative)
Re:Freedom matters (Score:2, Informative)
There is at least one linux developer who could not use BK because of his ties to subversion (or was it arch?).
Re:What tool to move to? (Score:2, Informative)
In the postscript to his announcement on moving away from BitKeeper [gmane.org], Linus rules out Subversion and states that Monotone [venge.net] "seems to be the most viable alternative".
Until I read that I had never heard of Monotone.
Re:I cant wait (Score:5, Informative)
I accept that it might have been the only working solution at the time, but Linus would have done better if he'd said it was temporary until a good Open Source product came along. Because it was anyway. There are consequences. 1000 people are going to have to learn a new facility, that facility is going to have to be deployed and files are going to have to be moved into it in a laborious version by version process to convert them, etc. There is also all of the surplus heat produced by the multi-year argument that Bitkeeper brought and some loss of productivity because of that, includng some untold number of people who would otherwise have worked on the kernel but bugged out because of the Bitkeeper decision.
Bruce
Re:Why change? (Score:2, Informative)
Re:Take aim at foot, Fire! (Score:3, Informative)
There are other ways to support development of a product:
1. Using said product and supplying bug reports and feature suggestions to the developer that improve the product for *all* of the product's users.
2. Using said product in a high-visibility project that instantly gives said product visibility and credibility it otherwise wouldn't have, leading other potential customers to at least consider using it.
By all accounts i've seen, Larry acknowledges that his product benefitted from having Linus use it - it's Larry offered Linux use of the free version of the software in the first place. Sort of like Nike paying Michael Jordan to wear their shoes. Note - I am in no way implying that this was a one-way deal. Both parties benefitted from this, however, many people were concerned that what has happened would happen (i.e. that once it was no longer convenient or necessary for Larry to provide the software to Linus (and others) for free, he would no longer do so, causing the developers to scramble to find an alternative).
Turns out they were correct.
Wha? (Score:3, Informative)
Granted, svn doesn't have some of the cooler distributed coding features, and that's really the pickle for kernel development. But speed really isn't an issue for it, in my experience.
Re:Why change? (Score:3, Informative)
Re:Larry just seems... "slimy" (Score:2, Informative)
There were benefits on both sides, but now it's time to move on. Read Linus' posting on the kernel mailing list for his take on the whole thing.
Did you run your repository on a 486? (Score:3, Informative)
It's true that svn is slower to compute "blame." The developers are working on this. But it's much faster at other operations. Overall, the edge is with svn already.
Re:Too Obvious Answer (Score:5, Informative)
Are you sure it was really that much slower with a huge repository? Or just with a huge working copy?
Subversion is not universally faster than CVS (checkouts and imports can be significantly slower, but you don't do those very often anyway), but it's generally faster where it counts. It also scales very nicely (for the most part), and I'd be surprised if correct use of SVN was really that much slower, even at 120K files. (I've never had a repository that big, but people talk about having them that big on the mailing list all the time.) One place where it might be slow is if you have a working copy with 120K files in it and try to do an update or commit from the top-level WC directory, since that would require SVN to locally crawl the whole WC tree. There is work being done to improve the places where SVN still lacks in speed, though.
As for being unusable around 1000 files? That's a bunch of crap. I use a >5000 file working copy every single day (>20000 file repos), and it is VERY zippy.
Re:Too Obvious Answer (Score:1, Informative)
Re:I cant wait (Score:5, Informative)
I have managed contracts to fund developers working on open [sf.net] source [sf.net] software [sf.net] projects [paraview.org]. My employer [llnl.gov] pays programmers to write software and to release it with an open source license. The Department of Energy (our funding source) has spent literally millions of dollars over the last few years on projects like this.
I contest the claim that writing open source software entails no monetary compensation to the software developer.
Re:and thus, R.Stallman was right after all (Score:4, Informative)
...and tells you that you can use it as much as you want, as long as you don't use it to transport parts for other cars. You switch your entire corporate fleet to this car, which would ordinarily be prohibitively expensively but is a lot better than the offerings at Joe's Free Car Lot. You come to depend on those loaner cars.
Some guy at an unrelated company looks at the loaner car's ignition system to see if he could make it work on one of the models available at Joe's Free Car Lot. Your "friend" responds by yanking everyone's loaner cars.
What do you do next? Try to find someone else to loan you an expensive car? Buy a new fleet of your own? Or decide that helping Joe upgrade his fleet to everyone's mutual benefit is a worthy investment?
Re:I cant wait (Score:5, Informative)
This excercise hasn't been a complete loss for either Bitmover Corp. or for the Open Source community. Both have gotten something out of it, but now they're going separate ways.
Also note that BitMover is attempting to make the split as amicable as possible. He could have shut down support and distribution of the free version as of yesterday. Instead he seems to be committing to providing one last (critical) major update, and then close down development of the free version, as well as providing a few month's warning. If he was being an asshole, he would have waited until the Kernel was a week away from the 65K change limit and then dropped support with no warning.
This is something like breaking up with a girlfriend. You can do it in a respectful way, or you can do it with yelling screaming and personal items thrown out in the street. Larry seems to be doing the former. Calling him a capital bastard is pushing things in the other.
Most of my ex-girlfrinds I can still show up at the door at 9pm and be invited in for some (herbal) tea and a nice chat. I really can't quite wrap my mind around people who can't visit any of their exs' without a court order. It's just so disrespectful of the quality time and experiences that came out of the relationship (presuming that the relationship wasn't just a 'gimme' fight). Yes, does take some work to do an amicable breakup, but here's lots of value to being able to have a sane conversation with your ex. Don't knock it until you've tried it.
Re:Freedom matters (Score:3, Informative)
Yea the gall of someone to take there ball and go home after you played with it and then punched them in the face when he asked you not too, what audacity indeed.
No, there upset that the community went back on a simple promise.
Re:I cant wait (Score:2, Informative)
Here you go. [redhat.com]
Re:Take aim at foot, Fire! (Score:4, Informative)
Well, that's the question, isn't it? You state this like it is obvious, but it isn't obvious. Reverse engineering for interoperability is protected under US copyright law AND the DMCA. In fact, there is at least one court case pending right now to determine this very issue. Read more about it here. [eff.org] Very interesting stuff.
Anyway, given that
- The OSDL had the license
- the employee was NOT employed by OSDL to do the reverse engineering and
- reverse engineering is protected under copyright law
I could see OSDL suing BitMover for breach of contract, which seems backwards, but I really think it is questionable if they gave BitMover any cause to do this, and it is going to cost them dearly to migrate over the entire version history to a new format, especially from one that is proprietary and needs to be reverse engineered before the move can happen.Re:I cant wait (Score:1, Informative)
What about all the lost productivity resulting from switching to something else now?
Sure, BitKeeper might be going away--so many useful things will not be accomplished because of it.
Re:Not what it seems? (Score:1, Informative)
Regards.
Re:I cant wait (Score:5, Informative)
You mean like this [apple.com]? Not that I'm claiming that the BSD license is better than the GPL or vice versa. Just trying to point out the fact that Apple has been pretty good about contributing back to the community, regardless of the license.
Re:I cant wait (Score:3, Informative)
The software is free, but the trademark isn't, so you can't call the modified collection of programs Red Hat.
Re:I cant wait (Score:5, Informative)
There was never a chance that this relationship could work, because of the lack of an Open Source license and the mercurialism Larry regularly displayed.
Thanks
Bruce
Re:I cant wait (Score:2, Informative)
And Haskell support isn't a big deal -- it can always be compiled statically.
Apple's UFS improvements are in FreeBSD (Score:5, Informative)
What Linus Has to say on Linux-Kernel (Score:5, Informative)
Here's [iu.edu] what Linus had to say about it today.
Re:I cant wait (Score:3, Informative)
About as happy as they have been with GCC bugs. They have seen more than their share of those, and they will deal with them in the same way.
Time will tell if that is good enough.
Couldn't I apply all of your arguments to Open Source in general? Shouldn't they be using Microsoft C and Visual SourceSafe for the wonderful support they'd get?
I can't imagine how much money Tigris have put into Subversion at this stage, and look at the criticism the product continues to incur and the major back-end overhauls that have been taking place.
Whatever they were thinking of, it didn't work. That's business - sometimes you lose. It seems that others have better ideas than Subversion.
with it's gargantuan achievements over recent years - still relies on private support and private funding in one way or another.
That's OK. Read my Economics paper [perens.com]. It will explain how and why, when it works, and when it does not.
Thanks
Bruce
Re:I cant wait (Score:2, Informative)
Go read the previous interviews to Linus and Larry McVoy. Larry had worked on TeamWare at Sun. He was already known for his ability to write source control management systems. He explained to Linus what he could give him. He would have succeeded selling BitKeeper anyway.
It's true that BitMover got marketing from Linux, but to say they got more than what they gave is plainly wrong.
Re:I cant wait (Score:4, Informative)
Every programming job I've had has been code for only one company. Mostly intranet/extranet coding (lotus domino shit), but also various programs for research companies etc. I can't imagine any of those jobs going if everything became opensource.
Linus' take (Score:2, Informative)
Date Wed, 6 Apr 2005 08:42:08 -0700 (PDT)
From Linus Torvalds
Subject Kernel SCM saga..
Ok,
as a number of people are already aware (and in some cases have been
aware over the last several weeks), we've been trying to work out a
conflict over BK usage over the last month or two (and it feels like
longer
is looking at alternatives.
[ And apparently this just hit slashdot too, so by now _everybody_ knows ]
It's not like my choice of BK has been entirely conflict-free ("No,
really? Do tell! Oh, you mean the gigabytes upon gigabytes of flames we
had?"), so in some sense this was inevitable, but I sure had hoped that it
would have happened only once there was a reasonable open-source
alternative. As it is, we'll have to scramble for a while.
Btw, don't blame BitMover, even if that's probably going to be a very
common reaction. Larry in particular really did try to make things work
out, but it got to the point where I decided that I don't want to be in
the position of trying to hold two pieces together that would need as much
glue as it seemed to require.
We've been using BK for three years, and in fact, the biggest problem
right now is that a number of people have gotten very very picky about
their tools after having used the best. Me included, but in fact the
people that got helped most by BitKeeper usage were often the people
_around_ me who had a much easier time merging with my tree and sending
their trees to me.
Of course, there's also probably a ton of people who just used BK as a
nicer (and much faster) "anonymous CVS" client. We'll get that sorted out,
but the immediate problem is that I'm spending most my time trying to see
what the best way to co-operate is.
NOTE! BitKeeper isn't going away per se. Right now, the only real thing
that has happened is that I've decided to not use BK mainly because I need
to figure out the alternatives, and rather than continuing "things as
normal", I decided to bite the bullet and just see what life without BK
looks like. So far it's a gray and bleak world
So don't take this to mean anything more than it is. I'm going to be
effectively off-line for a week (think of it as a normal "Linus went on a
vacation" event) and I'm just asking that people who continue to maintain
BK trees at least try to also make sure that they can send me the result
as (individual) patches, since I'll eventually have to merge some other
way.
That "individual patches" is one of the keywords, btw. One thing that BK
has been extremely good at, and that a lot of people have come to like
even when they didn't use BK, is how we've been maintaining a much finer-
granularity view of changes. That isn't going to go away.
In fact, one impact BK ha shad is to very fundamentally make us (and me in
particular) change how we do things. That ranges from the fine-grained
changeset tracking to just how I ended up trusting submaintainers with
much bigger things, and not having to work on a patch-by-patch basis any
more. So the three years with BK are definitely not wasted: I'm convinced
it caused us to do things in better ways, and one of the things I'm
looking at is to make sure that those things continue to work.
So I just wanted to say that I'm personally very happy with BK, and with
Larry. It didn't work out, but it sure as hell made a big difference to
kernel development. And we'll work out the temporary problem of having to
figure out a set of tools to allow us to continue to do the things that BK
allowed us to do.
Let the flames begin.
Linus
Re:Why change? (Score:4, Informative)
So yeah, it requires replacement if the BK folks say it does, and the friction got significant enough that Linus wants to make it happen. Linus has tried to make it sound like he & Larry McEvoy (?) have amicably come to this agreement. That may be the case. Larry isn't getting anything out of his free version anymore, and Linus isn't Vivien Leigh. He doesn't want to depend on the kindness of strangers.
LK thread on how it all got started (Score:2, Informative)
Re:Features Subversion lacks vs Bitmover (Score:3, Informative)
http://subversion.tigris.org/subversion-linus.htm
Re:What tool to move to? (Score:5, Informative)
Don't take my word for it, read the official statement from the subversion developers, "Please Stop Bugging Linus Torvalds About Subversion" [tigris.org].
The kernel development model, as molded by BitKeeper, needs a highly decentalized model which encourages forks as a way of staging kernel changes.
it's amazing how wrong (Score:2, Informative)
Um. No shit! He totally is within his rights.
That's the problem. Free software is about setting up a different right schema where on guy can't get impetuous or scared and screw over the rest, hold them hostage, etc.
He is within his rights and this is the problem with that type of software. It build dependencies.
It's not just personal decisions, in my experience usually the problem, this very problem but from different causes, comes from a business going out of business or, more often, being bought by a competitor.
Buying a comercial business is like buying the customers... as with Oracle buying PeopleSoft.
This is what I like about open source more than anything else, some reliability. A tool I'm using might grow stale if interest wanes, but it's bound to be smoother and the tool will NOT be taken away and I have avenues to personally extend its life if I want to take on the costs of that in time or money.
Saying "it's Larry's right!" is no different from pointing out that it was Jefferson's property right to sleep with his slave too. So what.
Do you guys know we invented these rights? In the state of nature you get the right to property you can defend yourself... nothing more. Everything else is a human invention and we can chose how to invent or, in this case, re-invent.
Re:I cant wait (Score:4, Informative)
We're talking about distributed change management in this case, it's not one database. The thread that matters to most people is the one Linus manages, and he pulls out a tarball every time he merges changes into that one. And I assume it will be mirrored and backed up. Now, I only know about Arch, but Arch doesn't even use a database as you would think of one. It's a tree of files, plain files, served by FTP or HTTP, and if you corrupt a revision you corrupt that one only.
I can't believe that things are going to be nearly so bad as you think. I suggest you watch the kernel list once Linus comes back.
Bruce
Re:Take a look at monotone (Score:3, Informative)
I'm curious what aspect of the darcs syntax you disagree with?
Re:which storage backend (Score:3, Informative)