"Producting Open Source Software" book and distributed SCMs

I have read lately classic book "Producing Open Source Software. How to Run a Successful Free Software Project" by Karl Fogel (2005).

Among others, author advocates using version control system as a basis for running a project. In "Choosing a Version Contol System" he writes:

  As of this writing, the version control system of choice in the free
  software world is the Concurrent Versions System or CVS.

Further on much of examples of managing project and managing volunteers revolves around the idea of "commit access", and it is assumed implicitely that version control system is centralized. It is understandable, as in 2005 there were (according to Linus) no good distributed version control systems (SCMs). Also Karl Fogel writes in preface that much of material came from the five years of working with the Subversion project, and Subversion is centralized SCM meant as "better CVS" and used itself as revision control system; any experience described had to be with centralized SCM.

The distributed SCM is mentioned in footnote in section "Comitters" in Chapter 8, Managing Volunteers:

 http://producingoss.com/producingoss.html#ftn.id284130

  [22] Note that the commit access means something a bit different in
  decentralized version control systems, where anyone can set up a
  repository that is linked into the project, and give themselves commit
  access to that repository. Nevertheless, the concept of commit access
  still applies: "commit access" is shorthand for "the right to make
  changes to the code that will ship in the group's next release of the
  software." In centralized version control systems, this means having
  direct commit access; in decentralized ones, it means having one's
  changes pulled into the main distribution by default. It is the same
  idea either way; the mechanics by which it is realized are not
  terribly important.

I'm interested in your experience with managing projects using distributed SCM, or even better first centralized then distributed SCM: is the above difference the only one? Linus has said that fully distributed SCM improves forkability:

 "Re: If merging that is really fast forwarding creates new commit"
 Message-ID: <Pine.LNX.4.64.0611070841580.3667@g5.osdl.org>
 http://permalink.gmane.org/gmane.comp.version-control.git/31078

  Time for some purely philosophical arguments on why it's wrong to have 
  "special people" encoded in the tools:

  I think that "forking" is what keeps people honest. The _biggest_
  downside with CVS is actually that a central repository gets so much
  _political_ clout, that it's effectively impossible to fork the
  project: the maintainers of a central repo have huge powers over
  everybody else, and it's practically impossible for anybody else to
  say "you're wrong, and I'll show how wrong you are by competing fairly
  and being better".

According to "Producting Open Source Software" it is very important feature for an OSS project. See section "Forkability" of Chapter 4, Social and Political Infrastructure (beginning of chapter):

 http://producingoss.com/producingoss.html#forkability

  The indispensable ingredient that binds developers together on a free
  software project, and makes them willing to compromise when necessary,
  is the code's _forkability_: the ability of anyone to take a copy of
  the source code and use it to start a competing project, known as
  a fork.  The paradoxical thing is that the _possibility_ of forks is
  usually a much greater force in free software projects than actual
  forks, which are very rare.  Because a fork is bad for everyone (for
  reasons examined in detail in the section called "Forks" in Chapter 8,
  Managing Volunteers, http://producingoss.com/producingoss.html#forks),
  the more serious the threat of a fork becomes, the more willing people
  are to compromise to avoid it.

Besides that, what are the differences between managing project using centralized SCM and one using distributed SCM? What is equivalent of committers, giving full and partial commit access, revoking commit access? How good support for tagging and branching influences creating code and build procedure? Is distributed SCM better geared towards "benovolent dictator" model than "consensus-based democracy" model, as described in OSSbook?

Thanks in advance for all responses