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.

Comments

Not Quite as Described

[Bruce Perens]

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.

Re:Not Quite as Described

[Bruce Perens]

Well, I guess Linus needed a good tool more than he needed the relationship. Larry was kind of difficult to deal with at the time. Linus was also friends with Andrew had great respect for Andrew, and Larry had publicly threatened to sue Andrew and the Open Source lab where Andrew was doing his research (where Linus also worked and the predecessor of Linux Foundation), so things might have soured between Linus and Larry.

Re: Not Quite as Described

[Trongy]

Here is a contemporary account based on Tridge's talk at linux.conf.au in 2005

The help command showed that there was a clone command.

"Tridge concluded that perhaps the clone command could be utilized to obtain a clone of a repository. Sure enough, it returned a large volume of output. Even better, that output was a simple series of SCCS files. At that point, the "reverse engineering" task is essentially complete. There was not a whole lot to it. "

Re:Not Quite as Described

[Bruce Perens]

Linus actually was a real dick to Andrew.

I had something to say about that.

Re:Too late

[DarkOx]

The Internet was sort of in its infancy

No web 2.0 was already a thing. We had already seen other VCS stuffs like CVS and SVN rise and fall in favor before. Most of us had been use VSS for years at work by then.

BK was adopted by a then 15+ year old Linux kernel project because it was better than CVS and SVN that had come before it. 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. 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.

Re:Too little, too late

[tlhIngan]

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.

That's thinking as a developer. And git is great... if you're a developer.

But it's confusing if you're not - and it's even worse if you don't understand the underlying data model (i.e., how stuff is stored in git) because without understanding the internal data model, a lot of things become very strange.

Stuff like staging files for commits, for example - most other VCS stage files, and if you change the file later while it's stage, the updated version is automatically included. But with git, you have to re-add it to the staging index again. And it's possible to orphan changes if you're not careful.

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.

The only thing BitKeeper has these days is its underlying data model is based on SCCS

We used BitKeeper at one point in time with our open-source products, but when they yanked all the free licenses away, we migrated to perforce We've since moved onto Git since that's what Android uses internally

But it's good that what's effectively a dead product is being open-sourced - BitKeeper was quite nice back in the day and they could've just died and abandoned it, but instead just letting it go open-source and hopefully someone will continue development. If not, someone will learn from it.

Re:Too late

[hibiki_r]

Many large companies have a lot of trouble with git. It's not a coincidence that Facebook and Google have been working on Mercurial backends: For their needs, Git is absolutely insufficient. You also won't catch a videogame company using git either. And that's discounting all of git's problems with documentation, or the cli becoming nonsense very quick after you leave the most basic commands.

So yes, the world has moved on, but git is very far from perfect.