I think the key of this text is that groovy had a big community making
suggestions, but lacked leadership in terms of structure:

exemple of problems: "The big problem of course was ambiguities -
feature interactions could lead to very confusing errors"

Suggestion for what was needed: "pair up James with someone who is good
at writing specs"
"It's time for someone to take leadership, produce a clear document
showing a
clear vision for Groovy, with a list of features that will be
implemented
and others that will be dropped.  With a clear roadmap and precise
deliverables that future users can judge Groovy by and decide whether
it's a
solid project they can rely on or just another aborted open-source
project
they can safely ignore....it takes a real "tech lead" to do this.
Someone who understands the issues but also has a clear vision, sees
the "big picture" and is not afraid to bark a few orders and do things
himself if they don't get done."

As far as I can tell, there has not been this kind of problems with
Ruby. Ruby's center is fairly small and "unambiguous" and the growth
has been lead by libraries based on the core. As James has said, the
language has been around for years even in the US, so I think it is
well past the "immaturity stage" talked about in the article.