Anil Dash writes about the culture of forking in the open source world, and how the introduction of Git changed that culture. Before Git, forking could just as well have been called secession. After Git, forking is seen as a healthy form of participation.

What I find interesting about this is that Linus Torvalds didn’t set out to change the culture of open source software when he created Git. He was trying to efficiently manage the work being done on the Linux kernel.

Linux kernel development is (or at least was) handled differently than most other large projects. Linus approves all of the code changes that go into the official kernel releases. Below him, there are a number of lieutenants who each have their own branches and their own approval process. In order for your code to make it into the official kernel, your change has to be accepted into one of those other branches. Below those, there can be any number of other branches as well.

In order to support this style of work, a source code management system was needed that would make it easy to push changes in all directions. The lower level branches need to easily pick up all of the changes that are accepted into the official branch, and people at the lower levels needed a way to push their changes up the chain to whatever branch was used to create their branch. Furthermore, nobody wanted to be dependent on a single centralized server that would host all of this work.

As it turns out, Git satisfied a lot of other people’s needs as well, but originally it was created to scratch a very specific itch.