I think ensuring first that peoples' lives would be helped if they learn and use Lisp is important, too. Some people take this for granted (and can come off as incredibly condescending, PS), but I'm not so sure anymore.

I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.)

I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway.

For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.)

While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.

I wonder how much this balkanization is a result of the syntactic extension capabilities of lispish languages? The fact that you can implement changes to the language in the language makes it easier to improve it in terms of coming up with new features/patterns etc. However this can be a double edged sword when you need to then train large numbers of programmers in order to create libraries etc. for the new language. Or maybe its not that the splintering occurs directly because of the language. Instead it might occur indirectly due to lisp programmers, having been exposed to the idea of language extension through lisp, become more prone to creating a whole new language when the one they have doesn't suit their needs precisely?

Well, first, the core Scheme spec is tiny. Tons of people have written at least half-complete Scheme interpreters (self included, in OCaml). It's a fun project, and it teaches you a lot about programming, even if you don't do the tricky parts (like full continuations). This seems to feed a strong "just fork your own" sentiment in the community, though, and that probably leads directly to a mishmash of incompatible libraries. That's Scheme, though, not Common Lisp; CL was an attempt to reign in several divergent Lisp dialects.

Also, I think people overuse macros. Certain people have put a lot of time into promoting them as the biggest asset of the language, which tends to encourage people to use them where they're not only unnecessary, but likely to make code harder to understand / maintain. (See, for instance, http://news.ycombinator.com/item?id=542746. Especially: "Q: What do you get when programmers design a language while trying to get something else done? A: PHP")

While I'm not knowledgeable enough about Ruby to say for certain, I could see making a big deal about "monkeypatching" causing similar problems there. Maybe the Ruby community encourages more restraint, though. Anybody?