Slashdot Mirror
11 Years After Git, BitKeeper Is Open-Sourced (phoronix.com)
An anonymous reader writes: Eleven years after Linus Torvalds developed Git after a falling out with BitKeeper for managing the Linux kernel source code, BitMover Inc has finally decided to open-source the BitKeeper VCS. The latest BitKeeper release has made the code open-source under the terms of the Apache 2.0 license. The community edition code is available from BitKeeper.org. Does BitKeeper now stand a chance against free software systems like Git and SVN?To offer some context, Larry McVoy, the CEO of BitMover -- the company that makes BitKeeper -- offered free BitKeeper licenses to various open source projects -- Linux kernel utilized it as well. However, later, Australian computer programmer Andrew Tridgell reverse engineered BitKeeper protocol in an attempt to make his own client. Torvalds didn't like this practice, and accused Tridgell of "playing dirty tricks with his proprietary source code tool of choice," and as a result, he wrote Git.
If BitKeeper had done that in the first place they'd still be relevant, possibly even the market leader.
Do they stand a chance now? Not without some killer new features that can't trivially be copied and pasted into Git.
could never work. Free as in freedom is what matters. Stallman told us long ago. Torvalds needed to find out the hard way.
No
Andrew did not reverse-engineer the Bitkeeper transfer protocol. What Andrew did was to telnet to the Bitkeeper's server port, and type "HELP". Bitkeeper then obligingly told Andrew what its commands were, in the exact style used by all early TCP daemons like FTP, SMTP, etc.
The problem was that Larry and Linus were good friends, and Larry had convinced Linus to use Bitkeeper even though Bitkeeper was under something less than an Open Source license. Larry had this odd license requirement that if you wanted to use Bitkeeper for free, you had to tolerate it making its logs public, and at some time added a requirement that you not use it to develop competing software. Larry promoted these requirements as a means to make money with Open Source, but his license wasn't really compliant with the Open Source Definition.
Larry also got really nonlinear and pissed off a lot of the kernel developers. Which was probably the fatal step. Linus got tired of trying to hold two things together that did not want to stay together, and wrote git. This eventually destroyed Larry's company.
It remains a lesson regarding how not to work with the community.
Bruce Perens.
11 years too late.
Anons need not reply. Questions end with a question mark.
Torvalds claims, somewhat exaggeratedly, that he did write the core of git in two weeks, and, for any software developer, it's easy to see that git is a far more valuable tool to developers than any of its predecessors. After initial issues with bad command-line tools and crappy mswin compatibility, I think there are few reasons to complain about git nowadays.
It's a perfect *NIX source control system, doing one thing and doing it well.
To those who don't mind Linus's typical arrogance and want to see his side of the whole story, I recommend the following talk he gave at Google: https://m.youtube.com/watch?v=...
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
The world has already moved on to Git which is essentially perfect nowadays.
When discussing what source control system to use for any new project, how often does BitKeeper even come up as a suggestion?
In my experience, most conversations of that nature start out with git versus Subversion. Mercurial might get thrown in if git is "too hard." Microsoft's solution might get suggested if it's a Microsoft-centered project. CVS might get brought up by the C-level who read about it in a magazine in the 90's and/or is a year or two from retirement. But BitKeeper? Never even seems to come close to the list.
The infrastructure around Git is just too large and has too many large adopters. And it's not like there aren't open source alternatives (Mercurial) that people would shift in the unlikely case that Git imploded. Also, I doubt any remember, but SourceGear tried to make it's own open source DVCS (darcs) that is still going on too.
But, you never can tell who will be at the top of the hill. I remember when ClearCase was considered to be the top notch VCS, and it did have some very nice features in the day. But, things change.
The only game changer I can see is tools that know what it is tracking has structure beyond files. For example, it'd be nice to track changes to the level of a block in a function in a class in a project, not just file changes. And tools that allow for queries on that structure (show me every class method you can find with more than six parameters on it, for example). But, code repositories are hard to do in the general case.
I posted their price sheet and he threatened me with legal action.
Hitler uses git:
https://www.youtube.com/watch?v=CDeG4S-mJts
It used to be that everything I'd written on Slashdot in its infancy was still online. If anyone cares enough, you can probably find the links.
Bruce Perens.
The space for source code version controls is covered fine with SVN and Git, there is zero need to use of or move to a commercial tool, regardless of it being Open Source or free for some uses. Sure, some companies are still using them, but even very large customers I have been working for are using SVN or even Git these days, and often not even via a commercial front-end.
That ship has sailed, for almost all uses this problem is now FOSS solved and likely will stay that way. This, incidentally, is what FOSS is all about: Good quality open and free software for standard computing tasks that are well understood and are only slowly changing. And once that state is reached for a task, somebody creating artificial scarcity by making sure the only tools are locked, commercial ones, is just doing economic damage, but not producing any additional wealth.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Linus himself admits it.
It is a good thing that BitKeeper is now free software. That being said, the way Larry McVoy has handled his entire business has been harmful to the entire free software world. For example, if you work as an employee for a company that has a commercial license to BitKeeper then he would demand that you do not under any circumstance contribute to competing source control systems.
Never.
I remember when ClearCase was considered to be the top notch VCS, and it did have some very nice features in the day.
It was a top-notch VCS. It would still be a top-notch VCS (in an environment where you have continuous access to the repository).
In particular, the ability to construct "views" of the code base with a simple language, specifying, in a few lines, what versions of things you wanted, was invaluable for diverge-converge development in an environment that had to maintain several production threads concurrently.
But at $three grand per seat it was not suitable for hobbyist development and was a hard sell to startups and PHBs everywhere.
Sorry, guys. Loved the product. Couldn't use it outside a couple big houses - that were dinosaurs in other ways and went belly up on schedule.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It seems to me that Git documentation is very poor. Can you recommend something?
Since this is Larry McVoy I wouldn't be surprised if it is true. A different story, but related:
http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481
I have seen and accepted many non-free licenses over the years and I'm fine with most of of them. But Larry McVoy and BitKeeper stepped over the line. I will never under any circumstance defend him or his work, his actions have been downright harmful to creation of free software at a lever which is simply unacceptable.
I remember this saga pretty well. McVoy was pissed that Tridgell wrote an interoperability tool, so he pulled the license for all open source use including the Linux Kernel. This is the type of thing that RMS often warns us about. Don't use closed-source software to build open-source software. And don't use closed-source software in mission-critical applications. I don't think you can get a better example than this.
Give me a perfect FOSS GUI Tool for Bitkeeper that runs everywhere plus maybe a FOSS web-based BK GUI/Frontend and I'll move from Git to Bitkeeper faster than you can say "kinda-so-so Git tooling". However, if that doesn't happen and handling bitkeeper is just as much a hassle as Git was 7 years ago, I'll pass, thank you.
SourceTree isn't FOSS, although it's free-as-in-beer and GitKraken doesn't really seem to support my workflows, but I'm doing fine and it's still better than SVN, although SVN has near perfect tools available. Distributed is what makes the difference. If BK one-ups Git in the tooling dept., then it stands a chance. If not, it will remain a nice historic curiosity.
We suffer more in our imagination than in reality. - Seneca
"Does BitKeeper now stand a chance against free software systems like Git and SVN?"
Not a chance. GIT is simply better. A lot better.
It took me a long time to "get" GIT after coming from SVN, it's just *different*. But once I got it, I'd never go back.
Like he said, it's the perfect *NIX source control system...
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
And absolutly horrible to try an make system backups.
Several systems had the backups hang due to the poor design.
"Git's not perfect, the only real reason everyone's comfortable with it is well, you sorta grew with it and you forget about its idiosyncrasies. And the fact the developers have really fixed up the more confusing aspects of git to be simpler and less tricky to do. I still have issues with format-patch and am because if you fail to rebase your tree when merging branches, you can end up with duplicate patches - one from the branch, one from the merge into mainline."
It seems to me that Git demonstrated a limitation in Linus' thinking. Git was not designed to be user-friendly.
What's the best manual for Git?
This is a very interesting study about what Larry McVoy intended and how the absolutely complete opposite happened.
And this is different from the Streisand effect because really only few acting people were involved(git as the linux kernel scm tool at first), so to categorize it under a new term is appropriate. (McVoy isn't the first but this case is well documented)
The interesting thing is McVoy's actions set the path for the development of git, because git just needed to be created because McVoy could not let it just go, but needed to retract his "gift" therefore creating the urgent need for a replacement.
The question is, if did he not foresee that comming?
Perhaps, this is his character flaw, invent something lay something out, and think that nobody will be able to achieve something similar again - and hell bk was a really nice product that had unique capabilities.
And lets be frank, we all have character flaws, we all have our little McVoy or even a little Sheen in our head. What makes this interesting is if you have identified your character flaw by knowing how it would play out you can foresee the possible negative outcome of a certain behaviour.
People were upset it was not OSS and it got replaced mostly because that was preventing people from contributing to Linux and making the management processes harder.
Not even. According to several of Linus' keynote/speeches (to lazy to google them, but it should be trivial to look for them on Youtube), bitkeeper was maybe available for free for Linux kernel development, but the license came with a clause forbidding reverse engineering/rewriting a clone of bitkeeper.
Nonetheless, several hacker started building their own tools interacting with the various bitkeeper databases.
Apparently at that point, Linus decided it would be better to drop bitkeeper before it becomes too hairy.
In fact nobody was angry at anyone.
Implementing GIT was simpler for Linus than sorting the mess about reverse engineering/reimplementations (as he's always explained, he's a filesystem guy, and GIT is fundamentally a content-adressable filesystem - with a VCS interface slapped on top of it. For a brillant hacker like Linus, creating GIT *WAS* simpler than to try herding the "legal-problem" cats).
BK would be today's Git, pretty clearly if it had been open sourced at the time. What isn't clear is if it could have been monetized effectively.
Maybe an opensource bitkeeper would have been today's git, but without the company also being today's github, it would have been difficult for them to monetize it. And back then, it would have been difficult to convince people that a "source repository combined with a *social* hub for coding geeks" would become a thing.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I don't think the users would have believed in it as such back then.
Yup indeed. Github is best described as "source repository combined with a *social* hub for coding geeks", and you can plainly see all the elements which would have had raised eyebrows back then :
- *repository* and *social hub* ? Why would people want a Facebook- / Myspace- clone slapped onto their Sourceforge- / Google Code- clone ?
- *social anything* for developers ? Geeks are the demographic which most viscerally hates social networks !
Nope, never gonna work !
In that alternative history of a Bitmover opensourcing Bitkeeper, the only hope would be for at least one "bithub" start-up to be successful enough, so they can re-hire/subcontract Bitkeeper's developpers before Bitmover bellies up.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The wars between git and perforce are eternal. But I haven't seen SVN come up in a while.
I migrated the company I work for to SVN just a few years back now. Some of the programmers expressed worry that we were jumping on "the latest bandwagon", but I reassured them that if Subversion was a bandwagon, it was a bandwagon abandoned in a ghost town. Change-adverse as engineers are, they found that reassuring. And I mean hey, at least it isn't CVS anymore!
When I first came in as the sysadmin I found out the company was using CVS (specifically cvsnt running on an old CentOS box), which the lead programmer had been administering. First time the cvs lockdaemon went down, I tried restarting the service . . . and it didn't work. I tried again, didn't work. Eventually it came back up after 7 tries, writing nothing at all helpful to the log file in the meantime. I asked the lead programmer if he had any idea what was going on, and he just said "oh, it does that some times, once took me 11 tries!".
So, you can imagine that I was able to convince the herd of cats (ie. the dev team) to adopt any other version control scheme was a huge relief. I had been kindof hoping for Git, but the new guy replacing the older lead programmer hated Git with a burning passion (he's a hardcore Windows fan and hadn't used Git for many years at the time, but that didn't stop him from holding unwavering opinions on it). And, frankly, the "CVS done right" tagline may have been rightfully mocked by Linus Torvalds, but SVN as a version of CVS that works 450% more reliably and has quasi-modern tools associated with it was exactly what the doctor ordered in our case.
We'll migrate to Git in 2024.
I remember sigs. Oh, a simpler time!
As a sysadmin I hated ClearCase.
It's a database that looks like a filesystem. And everyone thinks it works just like a filesystem. It's not.
We had developers with 3 year old views. Heck, they insisted on backups of the views.
It *hammered* the network. It consumed at least 2 servers.
Worst of all IMO is it modifies the OS to provide a filesystem hook. In the days when we had multiple different Unixes instead of everything being Linux, it was hard to work across them. git works on everything.
I last saw it 3 years ago at my previous job. Some developers were using git inside ClearCase.
I'd put files from /etc and NIS in RCS. I'd do it in git today. ClearCase? What if it won't boot? How do you get the files?
Good riddance to ClearCase...
Nobody cares
I'd mod you up if I could. I understand and use git, but its command interface is a usability nightmare for just about everything beyond the most trivial operations, and its documentation isn't much better. If not for github, I'd be happily using mercurial instead.
Larry McVoy is an ass.
"Community edition" means it isn't free and open source software. They temporarily allow people to use a limited version of the software (Isn't that generous of them?), but what do you think will happen if everyone uses the community edition and not the paid for version? In fact, in order to make any money at all, they have to make sure that the community edition is more like a free trial, i.e. it isn't fit for purpose, so it doesn't compete with the paid for version.
How does BitKeeper compare to Git technically?
Wow! 574 pages! Looks professionally organized. I read a few paragraphs that seem written well and easy to understand.
Thanks. I'm borrowing it through Inter-Library Loan.
I'm skeptical about O'Reilly books. I've seen some that are poorly edited. But it's worth a look.
Getting used to an SCS and getting better at using it efficiently is a hassle. So at one point in time, I decided to "learn" bitkeeper and use it. After I had invested some time and effort in the suite, suddenly the licence is changed and it becomes incompatible with my use of the software. Do you think I'm going to switch back after 11 years? Nah! Not me. And actually git is a lot better. Linus wrote git to be good at a few things that are important to him and "his" little project (that isn't very little). Linus' intuition about what's important is good. That's what makes Linux and Git succesful.
I think GIT is just Linus's name for Tridge.
http://michaelsmith.id.au
I wonder if there are any differences between the 'open source' ('crippleware') and the 'paid for' versions, or if the open source version is the 'full' product ?
Oh, the righteous fog of clueless indignation.
Linux was in crisis at the time Linus adopted BitKeeper. The only work process that had so far panned out had been stretched beyond the breaking point. They had next to no idea precisely what kind of a source control system they required. BitKeeper was one of the few reliable, distributed systems around and the terms were hardly egregious on the whole compared to the risk of managing the Linux crisis some other way.
Linus has said over and over again that without the BitKeeper experience he wouldn't have felt qualified to develop the Git alternative. It was only through using a competent tool for that period of time that he came to understand his precise needs.
And you think a picture is worth a thousand words?
Now I think Larry was a complete ass about much of this, escalating this into a far bigger stink than it needed to be. I'm ecstatic he got thoroughly kicked to the open source curb.
As ungracious as he was over some of the details, he did throw the Linux community a rescue plank at a critical juncture. With a better attitude, he could have come out of this smelling like a rose. Instead he came out of this smelling a bit like an ass.
In any case, that's his shirt to wear. For my part, I'm in no rush to return to his product (for which I once had a commercial license) even if it remains far better than Git (after an awfully big head start). Our shop had no complaints about the BitKeeper technology at all back in 2005, and some of our diaspora later got in on the ground floor in other shops because after our BitKeeper boot camp, Git was so easy to understand and adopt in its more advanced use cases.
Morals of the story: Once BitKeepered, fly high. Once BitKeepered, twice shy.
Taking a bigger stance on this, the entire history of SCM is actually a weird, professionally embarrassing, upside-down thing that should never have been so late to the party in the first place.
We talk about people that come along like Einstein and advance an entire field, perhaps before its natural time. SCM is the anti-Einstein story, where some smart guy could have come along fifteen years earlier and changed everything, but somehow didn't.
It would have had to have been some guy who deeply understood collaborative work flow at scale (more from intuition than experience), who was razor sharp on attention to nasty detail, and in total command of certain key algorithms.
What we got instead was Larry, fifteen years late. By this point Larry really did understand collaborative work flow at scale, but from direct experience rather than intuition. Somehow getting there the hard way put a fly up his nose over certain control issues, and we ended up with this twisted Dr Strangelove-esque love story.
But please, don't go around claiming that no-one involved had sane reasons. Sir Galahad with the fly up his nose was a strangely compelling figure in that particular time and place.
So thanks, Larry, for all the fish, but also, don't call us, we'll call you.
More over schadenfreude. The inimitable Larry McVoy has taught us all how to crave a cheek-twisting German word for "nasty divorce gratitude".
In particular, the ability to construct "views" of the code base with a simple language, specifying, in a few lines, what versions of things you wanted, was invaluable for diverge-converge development in an environment that had to maintain several production threads concurrently.
I worked with ClearCase for several years. I found it very strange that you needed to keep a file somewhere _outside_ of your source control to know how to get to the correct files in your source control.
Also, the fact that you needed to "lock" a file to edit it... If another person locks a file you want to edit and he is on holiday, you need to wait for him to come back.
I was very happy if I did not need to use ClearCase anymore.
Good point! Book about Microsoft Word: 1056 pages.
That makes me wonder: If there were a better user interface, would the software be easier to explain?