Don Marti

Fri 13 Feb 2009 11:37:27 AM PST

Awarding a medal?

Can we take up a collection and buy a big shiny medal for Larry McVoy, inventor of BitKeeper, the first practical distributed version control system?

Linus Torvalds wrote, back in 2006, "I still don't think people give Larry enough credit for actually pushing this whole distributed SCM thing as a usable model. Very few of the open-source distributed SCM's are actually usable even today, and as far as I've been able to gather, the commercial ones aren't really any closer either. Larry didn't have the kind of examples of what can work that I had."

Brian Aker, one of the Slashdot developers and now an architect at Sun's MySQL, told me, "Larry McVoy cracked a nut with its design that really changed revision control and made people really think differently about revision control. And what’s been interesting to see is what is happening in the open source world as far as people adopting that same methodology and trying to make use of it."

A lesser entrepreneur than Larry would have fallen prey to the temptations of the US patent system, staked out an over-broad patent on the idea of distributed revision control in general, and mired his company in litigation with anyone who dared to build a different DVCS, such as Mercurial and Git. A lesser entrepreneur might not have started out wanting to do that, but could have fallen into the dreaded More Investors than Customers Trap, and ended up having to hire a shortsighted pinhead as CEO.

Instead, BitMover Inc. is playing it cool, doing its thing for an impressive customer list, and competing with the open source contenders on features and quality. It's sad that this kind of quiet productive activity is so rare in the software business, while intellectualproprietarian dramaqueenery is so common, but there you are. So let's recognize it and give Larry something like the Tim Berners-Lee treatment (minus the knighthood, of course) at the next appropriate event. Think of it as the IT version of the Mo Ibrahim prize, to encourage future software entrepreneurs to create value instead of playing the court system like the lottery.

If you had paid attention to Larry's talk at SVLUG in August 1999, you could have had more than nine years of distributed revision control practice by now. Or, if you chose not to accept the strict license that the software's actual users agreed to, the company wouldn't come make trouble for you. At one CodeCon panel in 2003, if I remember correctly, Larry told the wannabe open-source DVCS developers that distributed revision control was a really hard problem, that he and the BitKeeper team are smart and it took them a long time to solve it, and that it would take them a long time to catch up. He was right. So now he has long-term repeat customers, we have a thriving Free DVCS scene, the lawyers who would have parasitized that scene are off chasing ambulances instead, and life is good.

More and more open source projects are starting to catch DVCS fever. Of course, on the Internet any movement looks like a big argument, and it can be a mess to support multiple DVCSs from one application, but the distance isn't that bad. One useful intro to git by Carl Worth is actually based on Bryan O'Sullivan's intro to Mercurial.

(Another good git intro is Manoj Srivastava's. Not so much a step-by-step tutorial as a plan for reconciling the way you work with how git can help you.)

The future of DVCSs looks promising. They're more than just a system for gettting your own projects organized, or a tool to let a group of developers or other collaborative, organized people to work with each other. Once you have a DVCS going, and learn to think DVCS, it becomes a storage system to build interesting applications on top of. Joel Spolsky wrote, "Nobody cared then and nobody cares now, because synchronizing files is just not a killer application." But there are killer applications that could use a storage system with synchronized, mergeable, rollbackable files. Just because a tree of synced-up files is a yawn doesn't mean that a system that depends on having a tree of synced-up files is a yawn.

Avery Pennarun explains it best, in Git is the next Unix. "git is a platform. It's a new set of nouns and verbs that we never had before. Having new nouns and verbs means we can invent entirely new things that we previously couldn't do."

A SQL database is a useful back end for a lot of business applications, but there are a lot of useful tasks that map to trees and flows better than to grids and queries. Instead of torturing your mental model of what you want to do to fit into tables, now you have a choice.

Ikiwiki is the best-developed example of a DVCS-backed application so far. If you can use a DVCS as the storage for a wiki, and you can put useful workflow and business rules on a wiki, then you can put an application on a DVCS, giving you useful functionality such as bug reports that can be passed around from one project to another.

Some people are even putting mail into git. Yes, IMAP gives you pretty good sync, but it would be nice to roll back my mailboxes to where they were before either the spam filter or my clumsy fingers threw out that important message. Mix the ability to mail into a git repository with the ability to put workflow on a git repository, and you get an application that you can work with locally, but that others can interact with by mail. And that terists will have trouble disrupting. Maybe the Department of Homeland Security would help pay for that medal.