There are a number of ways that a project or company can look at contributions from "the community." Let me start by saying that in almost every case, it is amazing to have people suddenly show up and surprise you with some gift of work that is given in the same spirit with which the rest of the code was offered, namely, freely. The fact that it's possible to work like this is something that is easy to take for granted within software, and completely unimaginable almost anywhere else (very few of my non-software friends and colleagues understand it at all).
That said, I think it gets done better and worse in different contexts. I'm an admirer of projects (usually they are large) that value contributions at the edges, contributions that take the core work in unintended directions. Such contributions--for example embedding the code in some new runtime, porting it to another environment, or using 1/3 of it do solve a problem in some other space--don't often address the core roadmap. Worse, they usually require distractions by the core team in order to get things landed and fix bugs that don't affect the main use case.
It is this tendency to cause delays in the mainline work that leads many projects to ignore or discourage such contributions. There simply isn't time to spend on their use case when our use case needs so much attention. This approach makes a lot of sense in many situations, where the focus is on a product and its deadline, and often the only people really doing the work are employees.
What I see increasingly, though, is a view of contribution that hopes and expects for random people to show up and do a bunch of the mainline work. In these cases, there is only our use case, and the desire is to find people who either already share our goals, or can be made to do so. This approach can work, especially if the mainline work is so attractive and clearly laid out that people can find a place for themselves in it. I often see people doing this in order to become attractive as a potential employee to the company leading the work; often they do get hired. And often they don't, which can lead to its own problems, resentments, and hurt.
But for those projects that can find a way to value certain types of distraction, and thereby contributions, interesting things can happen. Before I discuss them, I need to emphasize that word can, because there is no guarantee in this approach. Instead, it is a belief in gratitude and giving, which cannot be scheduled, roadmapped, or planned. Rather, it is necessarily, and literally, gratuitous. One cannot produce or reproduce it, only accept and be thankful for it. However, one can lead a project that is respectful of this way: one can be open.
There are a number of benefits with projects like I'm describing. The first is that people using the code in new and surprising ways find and fix bugs that you would never have found. Want to know where your code has bugs? Port it to another environment, use it with a different toolchain, or build some new implementation of a core abstraction. Once you've watched someone take your stuff and spin it out in new ways, you'll know what I mean, and it's obvious that you want to do all that you can to help that person succeed.
Another advantage I've seen is that allowing distractions sometimes leads us to realize that our mainline work is actually a distraction from this other direction we could be taking. If your product and roadmap are genius, this may not make sense; but if you're engaged in building something new, the chances that you've already got it all figured out, and just need to execute, are slim. Twitter is a good example of this, in my opinion, with the complete shutdown of its APIs and hostile approach to external developers: Twitter could have used some distraction and flashes of insight at the edges from its community. That hasn't happened lately.
In the places where I've seen this happen best, it usually means that there are some core developers who are willing to discuss, experiment, and work with other people who are working on tangents. Notice I didn't say "mentor." I think mentoring is really important, but its not the only way that projects should be engaged with their community. By all means help people learn to be productive in your code, but also spend time working with people that are trying to bend your code into new shapes. Your role isn't always to teach, and if you're willing to also be the one who learns, you'll find that new ideas usually come not from within, but from without the project and its current ways of thinking.
Make room for distraction. Make room for new ideas. Make room for new people. This is how things grow.