One of the recent discussion topics on Planet Debian has been version control systems, especially distributed VCS versus centralized VCSes like CVS and Subversion. (I have some opinions on this myself, so I read the entries with some interest.)

One of the points brought up for DVCSes, expressed for example here or the comments here, is that with a DVCS you don't have to start your serious involvement with a project by begging for commit access (that you are unlikely to get, since you have no track record).

But there's another benefit: they let you be a first-class (VCS) citizen even if you are doing something that people don't like or are uninterested in accepting. You get to be a first-class citizen even if you're just doing local hacks or working on an unpopular or unwanted feature.

This matters a lot, because when you are working on something that won't get merged is just when you really need merging and other VCS support to keep it all straight. And there will always be local hacks that people want or need to do on any project of decent size.

For example, I recently patched the Linux kernel to take out a printk() about a SCSI ioctl that's now considered obsolete, because my CD player uses it a lot and right now I'm not interested in either hacking the program or changing to another one. The Linux kernel people would rightfully laugh at me if I tried to send this patch in, so my odds of getting commit access (even on a branch) in any centralized system are low.

In a distributed VCS like the Linux kernel uses, though, there's no problem. I don't have to set up my own VCS environment for the Linux kernel and try to keep it synchronized and so on; I can just branch in my own local copy of the real one, which makes pulling updates and merging and so on fairly painless.