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

[mwvdlee]

They could have done like Github and provide an infrastructure.
As BK's developers, they would have been ideally suited to provide an infrastructure not easily matched by competitors.

Re:Too late

[Bruce Perens]

Today it is entirely clear how it could have been monetized as hosted software as a service. I don't think the users would have believed in it as such back then.

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

[WarJolt]

Perforce to stay relevant had to create a p4 git fusion and created a Web UI called git swarm. I still think it's a terrible VCS that breaks every tool that you try to integrate with it, but at least they have a solution for those hardcore perforce guys who won't give up the reigns who need to work with real developers.

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.

Re:Too late

[Tough Love]

What isn't clear is if it could have been monetized effectively.

Git has been monetized effectively, and it is open source. I have my doubts that anything involving Larry McVoy can be monetized effectively, judging from his behavior in the whole sad tale (with a happy ending for the good guys).

Re:Too late

[Desler]

The Internet was its infancy in 2005? lolwut? That's one of the dumbest things I've read on Slashdot in years.

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

[cant_get_a_good_nick]

The problem was that Larry and Linus were good friends...

...and wrote git. This eventually destroyed Larry's company.

This, I find, is the oddest part of all this. I support my friend, so much that I'd rather write a competing product than allow his servers to keep running and a thousand clients bloom. I forgot all about bitkeeper.

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

[jmv]

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.

I believe trying commands to see what they do is still called "reverse engineering", despite being ethical, legal and not involving any decompiling.

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

[jmv]

Oh, I totally agree here. I also assume he did a little more digging than just typing HELP. Things like trying the commands listed in the HELP to see what they do and/or trying some variants. Again, entirely reasonable things to do, no matter what the author thinks or likes. The vast majority of reverse engineering techniques are still legal (as it should be).

Re:Not Quite as Described

[Tough Love]

It was not just that the community rebelled, it was that the free to use deal got steadily more oppressive as things progressed, just as those so called rebels knew it would.

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: Not Quite as Described

[MichaelSmith]

http://sourcepuller.sourceforg...

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:Too little, too late

[BasilBrush]

Git still has terrible command-line tools, where the meaning or all the arguments is very obscure and non-intuitive. The only thing that makes git tolerable is a good GUI. And there isn't one included.

Someone bad mouthed Perforce earlier. For sure it's a previous generation of SCM, which requires a central server, so people have moved on. But what it did have were command-line tools that were easy to use, with arguments that made sense, and a good IDE included - though with far less reason to use it than with git.

Re:Too little, too late

[BasilBrush]

Shame he didn't think about the user interface before he started coding.

Re:Too little, too late

[Xtifr]

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

That seems like a fairly positive thing...for a developer tool!

(If you want to argue that git could be more useful in more fields than software development if it were...something else, well, that might be true, but it was developed by developers for developers, and seems to be doing quite well in its intended role.)

Re: Too little, too late

[Bruce Perens]

If by user interface you mean something other than the command line, no that wasn't a job for Linus. It's okay to delegate, especially on an open source project. We need him to design the core architecture, while other people are better at GUI.

Re:Free as in money

[DiSKiLLeR]

Yup. Now I get it. You meant Torvalds had to find out the hard way wasting his time using a closed source solution for the kernel source in the first place.

Way too late...

[ndykman]

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.

ClearCase was marvelous. But at $3k/seat ...

[Ungrounded Lightning]

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.

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.

Re:Git documentation?

[Tenebrousedge]

The O'Reilly book, Version Control with Git, for me provided the "ah-ha!" explanation of git's internals that made things made sense.

Git Interface

[Tenebrousedge]

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

Not even upset

[DrYak]

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.

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.

Re: Not even upset

[Bruce Perens]

Microsoft told an HP VP that they would sue the Samba project, and I got the internal memo after that meeting. They ended up backing SCO instead because they had to allow Samba as a term of the of the anti-trust settlement.

I looked at Sega v. Accolade and contractual pre-emption regarding fair use in copyright. I don't believe the reverse engineering term was enforcible.

Re:Not even upset

[jabuzz]

You are assuming falsely that Tridge had entered into some sort of agreement to not reverse engineer the BitKeeper protocol and write an open source client. That was simply not the case so while LM was annoyed that someone was reverse engineering his software Tridge was not breaking any agreements.

Re: Not even upset

[Kremmy]

It's pretty ridiculous to me that Linux developers ever accepted the Bitkeeper terms. I honestly can't see a reasonable justification for it. Why the hell would anyone building an open source operating system rely on a closed source revision control system whose license could be - AND WAS - revoked because someone tried to write a tool to interoperate with it?

The resounding boom and development of git was a godsend.

Migrated to SVN a few years back...

[Phil Urich]

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.