Charles, once again I feel you are light on business drivers. Development
productivity itself is only a business driver for a company that sells
technology, not for a company that sells widgets or services. You give the
example of IBM. They have a deep and permanent commitment to Java, because
they sell Websphere, and anything that cuts into Java's hegemony will
threaten the market for Websphere. If I were IBM I would work very hard
against Ruby for that reason, and for another reason besides: anything that
increases development productivity decreases the value of IBM Global
Services. (IBM, not being dummies, recognize that this business is under
pressure, which is why they're trying to reinvent it as a management
consultancy.)

You also mention PHBs. But PHBs themselves report to still-higher PHBs (a
CIO ultimately reports to a CFO or a VP of operations), and no one in that
chain is interested enough in development productivity to push it as an end
in itself. They are interested in solutions to the larger business problems
that they face, which technology has not done a terribly good job of
addressing ("why don't we know what our customers are thinking?" "how can we
reduce our capital costs for inventory?" "why are you computer people so bad
at forecasting quarterly demand?" "why the hell doesn't my email work?")

Another problem with development productivity per se, which hasn't yet been
addressed, is how to create value *cumulatively* from it. In short (and at
the risk of being accused of Java-philia), Ruby applications don't work well
together, or with other enterprise systems (that represent capital assets
and may not be disregarded). I think Rails has a latent (and possibly fatal)
flaw in this regard, which Ruby itself does not share. But it's a problem
that must be solved.

For what it's worth, I think Google and (ironically) Microsoft, are
companies that might someday get into some serious Ruby advocacy.