Q:

How were some language communities (eg, Ruby and Python) able to prevent fragmentation while others (eg, Lisp or ML) were not?

The term "Lisp" (or "Lisp-like") is an umbrella for lots of different languages, such as Common Lisp, Scheme, and Arc. There is similar fragmentation in other language communities, like in ML.
However, Ruby and Python have both managed to avoid this fate, where innovation occurred more on the implementation (like PyPy or YARV) instead of making changes to the language itself.
Did the Ruby and Python communities do something special to prevent language fragmentation?

A:

Ruby and Python both have benevolent dictators at their helm.  They are languages deeply rooted in pragmatic concerns.  Those are  probably the most significant factors inhibiting fragmentation.   Lisp and ML, on the other hand, are more like "design by committee" languages, conceived in academia, for theoretical purposes. 
Lisp was originally designed by John McCarthy as a practical mathematical notation for computer programs.  He never implemented it as an actual programming language; the first implementation was developed by Steve Russell, but he was not a benevolent dictator.  Over time, many different implementations of Lisp appeared; Common Lisp was an attempt to standardize them.
Lisp is more of a "family" of languages.  So is ML, which followed a similar evolutionary path to Lisp.

A:

One likely factor is simply age. Lisp and ML are a lot older than Python and Ruby:

Lisp: 1958
ML: 1973
Python: 1991
Ruby: 1995

Lisp and ML have obviously seen much greater change in hardware capabilities, more trends in computer science, and a great many more Ph.D students looking for something to work on.

A:

They're essentially all implementation defined languages
When it is easy to create a new implementation of a language that is largely compatible with existing code, then hackers being hackers, they go ahead and do it. Everyone writes a Lisp implementation at some point. ML compilers are almost mandatory for grad students in language design -- the language is after all famously well documented.
On the other hand we have the ad hoc and implementation-defined languages. Or languages that are just so complex that it is a signficant barrier to ever producing a viable alternative implementation:

ruby; perl; python -- all too implementation-defined to produce viable alternatives
ghc haskell and erlang -- well defined, but so hard to do anything that competes with ghc (or erlang) that people don't usually bother

This seeming downside -- languages that are too hard to produce viable alternatives to, have the massive upside: scarce developer resources are concentrated on the one true implementation.

As a historical note, several in the Haskell community actively pursued mergers and concentration of dev effort, recognizing that any splintering of the dev community would mean we'd not succeed. GHC was chosen and championed.

