I think you're looking at it as a purely tool vs tool comparison which doesn't amount to much. Consider then what the workflow a distributed version control system enables and you might see the difference clearer.
Consider a library being worked on by N different people concurrently. Each one can work on exactly the same code locally, making their changes locally. Then say someone pushes their changes to the "canonical" repository. Each person can then pull these changes locally, stabilizing their own local repository, and fixing things until it's stable. You can keep doing this every time without any one of these N people waiting on anybody to "finish".
That's exactly what we do now with SVN.
Now then imagine that there's only one person who has push capabilities/rights to that "canonical" repository and that person's called a maintainer.
All the N-1 people then ask this maintainer to pull changes in or merge patches submitted by them. If the maintainer is willing and capable, that's fine and dandy changes get merged. Now consider when maintainer is unwilling or incapable, what happens to the changes these N-1 people make? Simple, they publish their repository somewhere accessible and all the N-2 people can congregate around that repository instead. MIA maintainer out of the way, release managers can choose to pull from someone else's published version of the library. Easy as pie.
OK, if forking is a good thing then I can see how that helps. Question: what's to stop you from right now, building a better and greater version of library X in the sandbox, and then asking the Boost community to consider that the new Trunk and you the new maintainer? Different tool, same process. I still think there are pros and cons though: * As I see it Git encourages developers to keep their changes local for longer and then merge when stable. That's cool, and I can see some advantages especially for developers wanting to get involved, but I predict more work for maintainers of the canonical repro trying to figure out how to resolve all those conflicts. Obviously with SVN we still get conflicts - for example Paul and I often step on each others toes editing the Math lib docs - but these issues tend to crop up sooner rather than later which at least makes the issue manageable to some level. * I happen to like the fact that SVN stores things *not on my hard drive*, it means I just don't have to worry about what happens if my laptop goes belly up, gets lost, stolen, dropped, or heaven forbid "coffeed". On the other hand the "instant" commits and version history from a local copy would be nice... Regards, John.