There is a couple living nearby who my wife and I try to avoid at all costs. It's not that we don't like them, it's just that they consume so much of our time. We know that saying "hi" is tantamount to opening a filibuster-proof, hour-long conversation, so we try to evade that initial communication.
Contrarily, whenever I call my grandmother, she never wants to talk for more than five minutes. As a result, I call her often.
Open-source projects are often like my verbose neighbors: to interact with them, they demand huge chunks of time. Ever try contributing to OpenOffice? First you have to wade through acres of documentation to even know where to begin, and then you have to plan on mastering large bodies of code in order to incrementally add to it.
It's no wonder, then, that OpenOffice is primarily developed by just a few companies with a financial interest in doing so, leading one prominent developer to dub the project "profoundly sick."
Indeed the most active developers on many open-source projects are those who are paid to camp on the project. (GNOME is an example.) They're the only ones who can afford to do so.
This is why modularity is so important to successful open-source projects. Modularity enables "drive-by development," or development done in small buckets of time. The less time a project requires at one time, the more likely it is to get multiple bursts of development activity, which likely will add up to greater involvement.
In short, be more like my grandmother, and less like my neighbors, if you want to encourage outside development. The lower the bar to involvement, the higher the likelihood you'll get it, and lots of it.
Follow me on Twitter @mjasay.