A Git story: Not so fun this time | Brachiosoft Blog
Table of contents
Linus Torvalds once wrote in a book that he created Linux just for fun, but it ended up sparking a revolution. Git, his second major creation, was also an accidental revolution. It’s now a standard tool for software engineers, but its origin story wasn’t so much fun this time, at least for Linus.
Linus doesn’t scale
1998 was a big year for Linux. Major companies like Sun, IBM, and Oracle started getting involved with Linux. That spring, Linus’s second daughter was born. It had been almost a year since his family moved from Finland to California, settling into their new life. Even though Linux hadn’t brought Linus much financial gain yet, he was doing well in both his career and family life.
On the other hand, the Linux kernel developer community was growing, and the existing collaboration methods were becoming insufficient. Linus started struggling to keep up with the pace of code changes from developers, becoming a bottleneck in the process.
On September 28, 1998, Linus was reading the Linux kernel mailing list as usual when he came across this message:
Please don’t waste your time on creating these patches. These things are functional in the vger tree.
This message annoyed Linus. Linux code changes relied heavily on Linus himself. If you wanted to make a change, you’d email the mailing list, and if Linus saw and approved it, he’d incorporate your patch into his version and release new versions on FTP from time to time. Linus liked to work this way because it allowed him to control all changes. And everyone trusted Linus to manage Linux.
However, since David Miller, a senior Linux kernel developer, set up a CVS server called vger, some people thought they could bypass Linus and just submit changes to vger. This wasn’t the first time Linus encountered this issue, and he responded unhappily on the mailing list:
Note that saying “it’s in vger, so you’re wasting your time” is still completely and utterly stupid. The fact that it is in vger has absolutely no bearing, especially as there’s a lot of stuff in vger that will probably never make it into 2.2.
A heated debate ensued between Linus and a few developers, who complained about Linus’s slow responses, sometimes requiring three emails to get a reply from the “benevolent dictator.”
“These people should look at themselves in the mirror,” Linus thought. “I have to read so many emails a day. If sending three emails is too much trouble, I’d rather not have the patch.” He left this message before storming off:
Quite frankly, this particular discussion (and others before it) has just made me irritable, and is ADDING pressure.
Go away, people. Or at least don’t Cc me any more. I’m not interested, I’m<br>taking a vacation, and I don’t want to hear about it any more. In short,<br>get the hell out of my mailbox.
Linus’s emotional outburst prompted some people to offer help.
One of the open source movement leaders, Eric S. Raymond, author of the famous essay “The Cathedral and the Bazaar,” calmly urged:
People, these are the early-warning signs of potential burnout. Heed them and take warning. Linus’s stamina has been astonishing, but it’s not limitless. All of us (and yes, that means you too, Linus) need to cooperate to reduce the pressure on the critical man in the middle, rather than increasing it.
Larry McVoy also extended a helping hand. In an email titled “A solution for growing pains,” he wrote:
The problem is that Linus doesn’t scale. We can’t expect to see the rate of change to the kernel, which gets more complex and larger daily, continue to increase and expect Linus to keep up. But we also don’t want to have Linus lose control and final say over the kernel, he’s demonstrated over and over that he is good at that.
Figure out a means by which Linus can surround himself with some number<br>of people who do part of his job. Add tools which make that possible.
The mechanism which allows all this to happen is a distributed source<br>management system…
Larry was developing a new version control system called BitKeeper.
The origin of BitKeeper
In the early 1990s, Sun Microsystems introduced an internal tool called Network Software Environment (NSE) to manage their code, but NSE was slow and had a terrible user experience. Some engineers even quit in frustration.
Larry McVoy, a seasoned operating system developer with a background in performance work, was approached by Sun’s management to improve NSE’s performance.
When Larry looked at NSE’s code, he was surprised. “This thing wasn’t designed with performance in mind at all.” He also discovered that NSE was built on top of SCCS, a version control system from the 1970s, older than...