I can imagine being on the fence about Rails, and Ruby in general, and 
coming to the OnLAMP article, trying the examples, seeing that they 
break because the API has changed, and being turned off by this. So 
maybe that's something that needs to be addressed, not necessarily by 
changing the way libraries are coded, but at least in communications.

I think David makes a pretty decent argument when he says

>> I'd argue that if nothing else, the time freed up from not having to 
>> do many of the tasks Rails intends to relieve you off should provide 
>> plenty of buffer to 1) stay informed of documented breakage between 
>> releases and 2) apply the outlined fixes.

This is a decent tradeoff, I think, even for Ruby itself. So maybe 
that's one of the talking points to use here: "Yeah, Ruby's moving 
quickly and APIs are a little less stable than in, say, Java. But 
you're going to save so much time in your day-to-day programming that 
keeping up with API changes won't be that hard." That's certainly been 
the case for my Ruby usage.

Which makes me think that most of Ruby's growth is going to come from 
people leaving Java and PHP, not from (cough) people leaving Python. I 
suppose the success of Rails has already proven that, though.

Francis Hwang
http://fhwang.net/