We hear so much about the technical advantages (speed, offline committing, instant branching, cherry picking, rebasing) that we often forget the real advantage of DVCS: the D. That this article starts with the technical advantages makes me think we've done a bad job selling tools like Git and hg.<p>Yes, Rails still uses a 'central' development model. But it's trivial for me to fork Rails then track development, add my own features, fix bugs, or go my own route with a personal or corporate version of the framework. Many people do this. Rails has almost 300 forks on GitHub alone. In fact, every time you `git clone` Rails you fork it.<p>If someone has stopped maintaining a small library, you can fork it and take over. It's now your library. Others can pull down your changes and watch your development.<p>If you don't like the direction someone is taking their library, you can fork it and head a new direction. And the two tracks can live in harmony. You can even take changes you do like from the original library and merge them into yours with ease.<p>These things happen all the time and are possible with a DVCS because of the opinions (or rather, lack of opinions) present in software like Git. Yes, you can add this stuff to Subversion - add offline committing, use shas instead of revision #s, enable inline branching - but as soon as you do Subversion becomes a DVCS.<p>For me, it's always been about the social aspect of DVCS. That is the interesting part. The technical awesomeness is icing on the cake.