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

Too late

[bool2]

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.

Re:Too late

[Bruce Perens]

If BitKeeper had done that in the first place they'd still be relevant, possibly even the market leader.

Maybe not immediately. The Internet was sort of in its infancy, at least compared to now, when all of this went down. But it's true that if Bitkeeper had been made Open Source then, there would probably be no Git or anything like it. Bitkeeper would be the dominant source-code control system today. Given the way that several companies seem to have made money on Git, Larry might have made that money.

There are a lot of ifs though. We all have 20-20 hindsight but we can't really say that things would have worked out better for Larry. At the time he had a conventional software company and salaries to pay. It would have been difficult for him to get over the economic hump to where things are today.

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 late

[serviscope_minor]

The world has already moved on to Git which is essentially perfect nowadays.

Want to know how I know you've never used submodules or subtrees?

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.

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

[F.Ultra]

Ask Netscape

Re:Not Quite as Described

[Bruce Perens]

It remains a lesson regarding how not to work with Linus Torvalds.

No. Linus would have been happy to continue to use Bitkeeper. What Linus did not understand was the developer community's commitment to Open Source and that they would rebel. I am sure he would have rather spent that time working on the kernel instead of making Git.

Re: Not Quite as Described

[Bruce Perens]

The HELP command has no other purpose than to give out exactly the information that Andrew received. To have that command and protest its use makes no sense.

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.

a bold move...

[Gravis Zero]

11 years too late.

Too little, too late

[etinin]

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

Re:Too little, too late

[Bruce Perens]

I remember him taking around 5 weeks off from kernel development. So, 2 weeks for the core is plausable. It proved that he's no one-hit wonder.

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:Larry McVoy threatened to sue me on /. years ag

[John Sirpa]

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.

BitKeeper is the reason to avoid proprietary

[edtice1559]

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.

Git Interface

[Tenebrousedge]

Like he said, it's the perfect *NIX source control system...

Re:Not even upset

[Bruce Perens]

So, you, Linus, and Larry were annoyed with Tridge for doing exactly what he did to create Samba. He figured out the over-wire protocol without ever looking at the software of the server. But nobody seemed to object to his work on Samba. At the time, every big corporation was using it, and IBM, Apple, and HP were building it into products. Maybe they still are.