Binstock does a quick compare and contrast between Ruby and NetRexx, showing how an active community promoted Ruby, and NetRexx's lack of a community left it languishing. I think that this analysis is only partly true, and misses part of the value of open source.
Specifically, IBM's proprietary NetRexx can't be extended, revised, tweaked or improved. It isn't the scripting, per se , that the community of users value. It's the ability to tweak the basic language and interpreter that is so valuable.
My theory is that the "serious" (growing, enthused, proselytizing) community springs up when people have a stake in the language (or interpreter or tool) itself. In the case of Python, the most serious advocation seems to follow from the language evolution: the community improves an idea into a good idea; advocacy makes it a great idea; enthusiastic support makes it part of the language (or libraries). And -- in the case of Python -- you have to convince the BDFL, Guido, that it's totally Pythonic as well as a great idea.
Scripts themselves aren't the ticket. If the NetRexx interpreter was open source, then people would fix the bumps and warts that they discovered while writing scripts. For example, the classic Python division operator had some serious problems in certain kinds of numeric programming contexts. It takes considerable exploration of alternatives to propose an improvement that preserves simplicity, but adds a distinguishing feature. If you don't have open source, you can't -- effectively -- explore the alternatives.
The source for the tool (or language) is the ticket. Once you have the source, you can add, change and delete features. If your changes are an improvement -- and you can prove it by using them -- then you have a compelling argument for your ideas. If, on the other hand, your changes are a paper-and-pencil exercise, they don't have any more merit than the insulated development team's pet project. Indeed, an isolated development team has a queue of bug-fixes and enhancement requests, a microscopic budget, and little real input except from schedule-obsessed managers.
Dynamic scripting languages aren't successful because of the community-driven scripting. They're successful because of community-driven language evolution, fueled by the needs of the community-driven scripting.